Point-of-Sale malware attacks – crooks expand their reach, no business too small

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Filed Under: Featured, Malware

Numaan Huq and Richard Wang of SophosLabs have been keeping track of the evolution of Point-of-Sale malware.

We've recently been tracking a set of incidents involving malware attacking Point-of-Sale (PoS) equipment.

Your personally identifiable information (PII) flows into PoS devices, across PoS networks, and is processed by PoS servers, every time you pay for things without using cash.

As a result, PoS equipment and the local-area networks to support it are found all over the world, in both developed and developing countries.

When was the last time you tried to pay for a hotel stay in cash, for example?

Even if you settled the bill with cash, you probably swiped or waved a payment card when you checked in, just to avoid having to lay down a large cash deposit.

As a result, PoS systems are a lucrative target for crooks.

So it's not surprising that we've written about this particular malware family, Troj/Trackr-Gen, and its thirst for credit card data before.

It seems the criminals behind it have added a few new tricks in the last 15 months.

The most interesting development is that some versions now include the ability to exfiltrate data directly rather than just dumping it to disk.

? The Payment Card Industry has a set of Data Security Standards, known unsurprisingly as PCI-DSS. The standards specify, amongst other things, that credit card data must in general be encrypted if it is stored, and that some data, such as CVV numbers, mustn't be stored at all once a transaction is complete. Ironically, the crooks have learned from this, and are avoiding reading from or writing to disk themselves.

Another change is found when examining some of the targets.

As before, the criminals are avoiding very large businesses but in addition to the commonly attacked hospitality industry and hotel targets there are smaller victims, including a single car dealership in Australia.

A couple of cosmetic changes have also been made.

There is a new generator for random filenames, creating completely random five-character names such as IXWIG.exe and KPAOE.exe.

For variants using hardcoded names the common use of rdasrv.exe has been extended to include filename options designed to hide in plain sight such as windowsfirewall.exe or msupdate.exe.

It seems that no victim is too small for Point-of-Sale malware.

The popularity of terms like "Advanced Persistent Threat" and "state-level malware actors" may make it sound as though only the biggest multinationals and parastatals are at risk these days.

But stealing $75 each from 1,000,000 people gives the same financial result as stealing $75 million from a megacorporation.

So you simply cannot assume that your business or organization is not a big enough target to worry about web attacks or targeted malware.

Remember this: there is no radar below which you can fly.

As a final thought, since we already know the how and the why of this latest round of PoS attacks, we invite you to consider the where.

There's an intriguing hint buried in the code:

We don't know if that's where the crooks are from, or if it's where they've been most successful in infiltrating PoS networks (Botswana, home to the astonishing inland Okavango Delta, has a strong hospitality industry), or perhaps just where they spent some of their ill-gotten gains on a vacation.

Do you run a small business that relies on PoS equipment?

If so, how much of a challenge are you finding it to stay ahead of crooks like this?

Have your say in the comments...

Follow @sophoslabs

Image of PoS machine courtesy of Shutterstock.

View the original article here

Facebook owns up - admits network breached, blames "Java in the browser"

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

There's a scene in the movie The Social Network where Mark Zuckerberg is arguing with Eduardo, his CFO.

Eduardo's just frozen Facebook's bank account.

The plan is to get Zuckerberg's attention and to try to get Zuck back on what Eduardo thinks is the straight and narrow.

But Zuckerberg is irate.

He thinks it might end up with an unpaid bill and thus a network outage, and that won't do!

Zuck rants:

Let me tell you the difference between Facebook and everybody else: WE DON'T CRASH EVER!

It's only a movie, of course.

In real life it's not true that Facebook never goes down, but when you consider its size and the online activity it supports, Facebook's uptime and availability is astonishing. Stellar. Intergalactic, even.

The movie version of Zuckerberg goes on to explain:

If the servers are down for even a day, our entire reputation is irreversibly destroyed. Users are fickle... Even a few people leaving would reverberate through the entire user base.

But what about getting owned by hackers?

What effect do you think that might have?

If you're the world's biggest social network, and if collecting, storing and using other people's personal information is your bread and butter?

Hold your horses, because we're about to find out.

Facebook just published an article entitled Protecting People On Facebook, and it doesn't cover what you might at first expect when you see the title.

Sure, it starts upbeat enough:

Facebook, like every significant internet service, is frequently targeted by those who want to disrupt or access our data and infrastructure. As such, we invest heavily in preventing, detecting, and responding to threats that target our infrastructure, and we never stop working to protect the people who use our service.

But that's followed by a hint of what's coming next:

The vast majority of the time, we are successful in preventing harm before it happens, and our security team works to quickly and effectively investigate and stop abuse.

And then the bombshell. OK, not really a bombshell. Let's be fair and say it's actually a pretty candid admission for which the company deserves at least a nod of respect:

Last month, Facebook Security discovered that our systems had been targeted in a sophisticated attack. This attack occurred when a handful of employees visited a mobile developer website that was compromised. The compromised website hosted an exploit which then allowed malware to be installed on these employee laptops.

Later on in the article, Facebook claims that it has "found no evidence that Facebook user data was compromised," and and for what it's worth, I'm willing to accept that claim.

? Update. In an interview with Ars Technica, Facebook CSO Joe Sullivan has admitted that the crooks made off with information from the laptops themselves. ("What you typically find on an engineer's laptop, including corporate data, e-mail, and some software code.") But despite being able to get "some limited visibility" into Facebook's production systems, Sullivan confirmed that a forensic review found no evidence that the crooks got away with any data off those systems. Close, in a word, but no cigar. (Added 2013-02-16T22:11Z)

The crooks had a Java zero-day at their disposal, and this exploit let them infiltrate Facebook's network and inject malware.

But the company says it was fully patched and anti-virused, and it sounds as though the malware that followed the exploit was quickly spotted and cleaned up, with no lasting harm done.

Just one suggestion to Facebook developers: why not read Naked Security?

We've given you loads of good reasons to turn off Java in your browser, starting from the middle of last year.

That alone could have side-stepped this problem.

Even just using a browser with click-to-play (so that Java and Flash applets, amongst others, can't launch quietly in the background from compromised websites) would surely have been enough.

I'm guessing now, but I'd be very surprised if the mobile developer website alluded to above actually required Java, so there would have been no reason to have Java turned on for that site.

Similarly, the mobile developer website could have considered using outbound web or packet filtering to block the egress of Java applets if, indeed, its site was never supposed to serve them up in the first place.

? IPS technology is usually thought of as a way to keep bad guys out, not least because it stands for intrusion prevention system. But most decent IPSes work bidirectionally, and can act as effective EPSes, or exfiltration preventers, too. You filter email for spam both ways (don't you?), because you can, and because it makes sense. The same applies with network traffic in general. If the bad guys have already got in, you may as well stop them getting back out as well!

Having said all that, it remains for me to ask. You have turned off Java in your browser, haven't you?

If not, here you are: How to turn off Java in your browser.

And fear not that you will break JavaScript: Java is not JavaScript.

Follow @duckblog

View the original article here

Can freezing an Android device crack its encryption keys?

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Every few years, someone reads, or remembers, or rediscovers something we often forget: computer memory isn't volatile, after all.

RAM chips don't lose their contents immediately when you turn your computer off, and that can have interesting security ramifications.

Don't get too excited: RAM contents don't persist without power in a reliable and consistent way.

If you accidentally pull the plug out of the wall before you've saved that fantastic new presentation, don't expect to get it back.

But if you can cycle the power quickly enough, and reboot under your own control from some secondary device, such as a USB key, you might be able to see the ghostly remnants of what the previously-running operating system was up to.

You can guess where this is going.

If you clean boot a computer with a hard disk that's running full disk encryption, or FDE, you can't get anything off it.

Not just the data, but also the operating system, swap and hibernation files are scrambled. Nothing can be accessed without the decryption key.

But what if the decryption key, or a large enough chunk of it, is part of the RAM that didn't fade to grey when you cycled the power?

That can happen, thanks to the phenomenon of left-behind data in RAM.

(The name you'll hear is remanence, a word originally used for residual magnetic fields, and now also used to refer to the not-yet-decayed electrical charge in memory chips.)

And if you cut the power abruptly, you prevent the operating system from taking any emergency shutdown measures, such as deliberately purging critical areas of memory to wipe any active encryption keys.

The latest researchers to rediscover remanence in a newsworthy way are from FAU, the Friedrich-Alexander Universität Erlangen-Nürnberg.

They've turned their sights on Android, building a custom distro of Android Linux called FROST, short for Forensic Recovery Of Scrambled Telephones.

So far, they've only tried it on the Samsung Nexus phone from Google.

That's because they need three planets to align before the attack will even begin to work:

The bootloader needs to be unlocked.The device needs an easily-removable battery.Ideally, the device needs to be at or close to 0°C.

The reason for these limitations are the things that go wrong if they aren't in place.

If the RAM is at room temperature, its remanence is greatly reduced, so it "forgets" much more quickly.

If you can't get at the battery, you can't easily cycle the power abruptly.

If the bootloader is locked, the device will automatically get wiped if you try to unlock it.

The wipe-on-unlock feature is a clean and simple security process enforced by Google, at least on recent devices.

? Android devices support a stripped-down mode called FASTBOOT, which gets its name because it boots up your device in a second or two. A magic chord of keys pressed down at power-up is typically used when you want to engage FASTBOOT's services. It has very limited functionality, but the key features are that it allows you to unlock your firmware, and to reflash it. Locked firmware can't be flashed, for security reasons, and unlocking (assuming your device allows it) it will wipe the device so that your freedom to reflash doesn't come at the previous owner's expense.

The first thing you need to do, when you rediscover remanence and want to use it against a specific device, is to find out if your proposed attack is practicable.

That means loading up memory with something you'll easily find and recognise later, and seeing how well your chosen content survives a power outage.

When a posse of Princeton programmers famously brought remanence into the limelight back in 2008, they used images of Mona Lisa.

The FROST crew picked a more modern mascot, Google's Android robot:

The results weren't terribly convincing at room temperature, given that rebooting the phone quickly by jiggling the battery takes an unpredictable time.

Lowering the temperatures offered improved results, as the authors showed graphically:

(They neglected to label the axes, a peccadillo usually restricted to marketing departments, so we'll have to assume that the X-axis shows reboot time in seconds, and the Y-axis shows the percentage of bits lost. The obvious conclusion: take less than a second, and head towards freezing point.)

The authors eventually settled on popping the target phone in a freezer at -15°C for an hour. They laconically point out that they can't promise you that your phone will survive, noting that "damaging the phone is your own risk, but we haven't experienced any problems yet."

? A word of warning. If you live somewhere warm and humid, such as Singapore, Dar es Salaam or Brisbane, your phone will rapidly start to collect moisture when you remove it from the freezer. If you're fiddling with the battery and the buttons of your phone to try to orchestrate this attack, you won't be able to dry it off as you go along. As the FROSTers say, damaging the phone is your own risk.

To find the FDE decryption keys in memory (Android uses AES encryption), the authors used a modified version of a program called aeskeyfind, originally created for the 2008 paper referenced above.

This cleverly-written tool uses a variety of heuristics to churn through memory, looking for contiguous blocks of RAM that look like the output of the AES key schedule.

This is the algorithm that AES uses at the outset to convert a 128-bit key into 176 bytes of key material to use in the AES process itself, or a 256-bit key into 240 bytes.

And now the burning question. Did the FROSTERs succeed?

Sort-of. They've got some visual material that suggests they did, though whether the key information was actually enough to unscramble the encrypted data on the phone is not specified.

The paper is similarly ambiguous, saying somewhat noncommittally that the authors were "able to recover the disk encryption keys (given that no or only a few bits were decayed)."

That's a bit like saying that "we came out ahead financially every time we placed a winning bet." It doesn't tell us much about the practicability of the attack in real life.

Nevertheless, the FROST paper teaches, nay proves, an important lesson:

If you have an Android phone with an unlockable bootloader,
LOCK IT AGAIN WHEN YOU'RE DONE REFLASHING.

The authors are unequivocal about this.

When they needed to unlock the bootloader to try to attack an encrypted phone, they ended up with nothing to decrypt.

Oh, and if you pick up your phone to make a call and it seems unusually cold against your ear, look out!

You may have been FROSTed.

Follow @duckblog

Image of frozen lake courtesy of Shutterstock.

View the original article here

Was Alicia Keys hacked, or is she cheating on BlackBerry with iPhone this Valentine’s Day?

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

BlackBerry recently surprised the tech industry when they announced at their major launch event on January 30 the appointment of musician, Alicia Keys, as the Global Creative Director.

And since then Keys has been pimping BlackBerry’s new smartphone model, Z10, tweeting from it since launch. But is there a secret that Keys has been keeping? An extra-cellular affair with the iPhone?

At the BlackBerry launch, Keys told the audience about her on-again/off-again love affair with BlackBerry.

She said she had been lured away from BlackBerry by “hotter, sexier phones, something with more bling” in the past, but now declaring that she and Blackberry were “exclusively dating”.

So it was a bit of a surprise when a tweet from her account went out to her 11 million followers on February 11 – just days after the BlackBerry launch – sent not from her exclusive BlackBerry, but from her ex, the iPhone.

Started from the bottom now were here!

Later the same day, Keys sent out a tweet stating that the previous tweet quoting lyrics from recording artist, Drake, had not come from her, but likely a hacker. (But don’t be offended – she still likes Drake.)

What the h*ll?!!!! Looks like I’ve been hacked… I like @Drake but that wasn’t my tweet :-(

But that doesn't explain this tweet pic posted a day before from her account showing the musician looking radiant in her dressing room at the Grammys with not just one, but two, of her exes in reach – iPhones.

Now, we at Naked Security have seen our fair share of hacked Twitter accounts of celebrities such as Justin Bieber and Britney Spears – and this doesn’t quite smell the same.

Would a hacker that has gone through the trouble of hacking an account of such a well-known figure with access to *11 million followers* really only send one tweet with just a song lyric?

This story reminds us of a previous incident when Kim Kardashian claimed her Twitter account was hacked after having trouble logging in to Twitter from her home computer.

Could it be that Keys is using the many recent celebrity Twitter hacks as a scapegoat for her mishap?

Of course, there is also the possibility that Keys could have her PR people monitoring and tweeting on her behalf, and this error could have been a mistake on their part. We can’t know for certain.

But the one thing we do know is that whoever accessed her Twitter account is hanging out with her ex.

Awkward.

Follow @NakedSecurity

Alicia Keys headshot image courtesy of Featureflash / Shutterstock.com

View the original article here

Unlock an iPhone without the passcode - harmless trick or computer crime?

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

A YouTube video showing you how to unlock an iPhone 5 without the passcode has racked up nearly 300,000 hits over the past two weeks.

There are some caveats, though:

You need physical access to the device.You need manual dexterity or a fair bit of practice.You only get access to some of the data.You have to make a phoney emergency call as part of the process.

I'm not going to repeat the instructions here.

I'll just say that they're reasonably arcane: you almost turn the phone off twice during the process, as well as actually placing an emergency call but cutting it off before it goes through.

For the last reason alone, I invite you never to pull this trick, even on your own phone "to see if it works".

Deliberately dialling the emergency services when you don't need to, or, indeed, when you know your intention is not to complete the call at all, is a pretty poor show.

I'm not sure what the regulations are in your country, but there's every possibility you could get in trouble with the authorities for that part of the trick alone.

In fact, it's not really a trick. It's a crime, even without the bogus emergency call.

Not, perhaps, a terribly serious crime. But mucking around with other people's computers is behaviour we ought to stamp out of our lives.

Interestingly, the last time we wrote about this sort thing was when an MP in the New South Wales parliament live-tweeted joke comments from a colleague's iPad while the latter was giving a speech.

I suggested a zero-tolerance policy, especially from members of a legislative assembly, who ought to be setting standards, not flouting them, but not everyone was so sure.

Commenters Josh and foo suggested otherwise:

? For the record, I would vigorously oppose any attempt to regulate whoopee cushions. Like Dr Sheldon Cooper of the Big Bang Theory, "I still maintain the whoopee cushion has comic validity."

The good news is that this unlock crime trick doesn't give full access to the phone, but apparently only to your contact list, voicemails and photos.

That's still a lot of important stuff, though.

Macworld reports that Apple told the magazine that it was "aware of this issue, and will deliver a fix in a future software update."

That beats Apple's usual tight-lipped (and still apparently official) policy.

For the protection of our customers, Apple does not disclose, discuss or confirm security issues
until a full investigation has occurred and any necessary patches or releases are available.

So, watch out for the update, watch out for your phone, and don't let this bug make you complacent about phone lock codes overall.

It's still worth having a decent password on your iPhone, to protect all the data this bug doesn't give a miscreant access to.

To help you choose wisely, here are the Top Ten iPhone passcodes not to use:

5683, by the way, spells out L-O-V-E.

In conclusion, let the arcane nature of this trick remind you that hackers, in both the good and bad sense of the word, aren't deterred by secrecy, obscurity or complexity.

Indeed, this trick is surely making you wonder, "How did they think of that?"

Bear that in mind if you are ever called upon to design, implement or enforce security software, policies or procedures.

Follow @duckblog

Image of mobile phone courtesy of Shutterstock.

View the original article here

Bit9 hacked, used to inject malware into customers' networks

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Security vendor Bit9 has been hit by a serious security breach of its own network.

Intruders broke into a core part of the company's service and used its own trusted digital certificates to create pre-authorised malware.

The result, apparently, was that a small number of customers got infected with malware that wasn't merely missed by Bit9's detection algorithms, but was actively endorsed by its protection system.

It's always tricky to write about compromises and problems with competitors' products, but please bear with me here. I'll try to be as balanced as I can.

As a colleague wryly and compactly pointed out the other day when Kaspersky hit the news by cutting customers off from the internet with a dodgy update, "John 8:7."

Bit9's case is a bit different because the company eschews traditional security and anti-malware techniques and instead favours whitelisting.

? I'm not a fan of that name because at least some people find it offensive, and because there is a much clearer, self-descriptive alternative: allowlisting. Likewise, blacklisting is much more directly rendered as blocklisting. Simply put, blocklisting aims to recognise known bad stuff and to stop it. Allowlisting aims to recognise known good stuff and to stop everything else.

For what it's worth, Bit9 has done the right and honourable thing, and 'fessed up on its website.

The company is still keeping the precise details close to its chest, as it's entitled to, but has offered a general overview that's pretty clear. Call me old-fashioned, but that counts for a lot.

I'm not entirely convinced by the entire explanation, however.

Bit9's observation that "this incident was not the result of an issue with our product," for instance, is a trifle misleading.

I think I know what they mean, and why they said it, but the truth is simple: Bit9's service made the wrong call.

It misrecognised malware as good software (a false negative, in industry jargon) and let an infection through.

Conceptually, this is no different (in industry jargon, it had a similar failure mode) to what happens when a traditional anti-virus fails to spot malware as malware.

The truth is that any programmatic means of analysing another program and predicting its behaviour must be imperfect.

Regular readers of Naked Security will have heard me pronouncing on this matter before. That's because I'm a big fan of Alan Turing, who studied this very issue back in the 1930s, before digital computers even existed.

It's known as the Entscheidungsproblem (usually rendered into English as the Halting Problem), and it pretty much says that any security software must, at least occasionally, make mistakes.

It's become fashionable recently to bash anti-virus software harder than ever, decrying it as reactive, behind-the-times and even as "digital homeopathy." (Even I had to smile at that tweet.)

Allowlisting is often trumpeted as the preferred, scientific, simpler, cleaner, greener approach.

There's a lot to be said for that, if you can reliably predict in advance the complete list of software files you will need on your computers, and if you don't make any mistakes in ensuring that everything on the list really is good.

Of course, the pace of change is swift enough these days that you need to keep updating the list of known good stuff, and that's where errors can creep in.

In practice, modern anti-virus software doesn't rely on (indeed, hasn't relied on for about two decades already) a purely reactive, list-of-known-badness approach.

Today's anti-malware solutions aren't merely blocklists, and if you buy one and engage only its pure-play blocklisting parts, you're missing a trick.

Several tricks, in fact.

Similarly, any decent product that claims to work by permitting only known-good stuff doesn't rely entirely on allowlisting.

If a file is already known to be bad, you'd be silly not to use that information to ban the file so it never gets onto your allowlist by mistake!

No security solution can be perfect, because no solution can decide all the answers.

That's why defence in depth is really important, and why you should run a mile from any security vendor who still makes claims like "never needs updating" or "all others are imposters."

To the Bit9 crew: when I read the part where you wrote that "the threat from malicious actors is very real, extremely sophisticated, and that all of us must be vigilant," I felt your pain, brothers and sisters.

We may have varying approaches and differing opinions, but we're on the same side here.

I hope you catch the villains behind this, or at least find out more about the who, what and why...

Follow @duckblog

View the original article here

Anatomy of a vulnerability - cURL web download toolkit holed by authentication bug

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

You may not have heard of cURL, but you've probably used software that uses it.

It's an open-source programming toolkit that helps you deal with writing client-side code that deals with URLs.

In the words of the project itself, "cURL groks those URLs."

It's popular because it's a URL Swiss Army knife, making it easy to handle popular protocols like HTTP, SMTP, POP3 and many more. It also supports uploads, downloads, authentication, proxies, cookies and SSL/TLS.

It even supports Gopher, if you remember that far back.

One risk with an all-singing, all-dancing library, of course, is that there's more code to go wrong.

And sometimes, even obscure bits of code you thought you'd never use might get triggered. Worse still, they might be triggerable by external circumstances you never predicted.

That's the curly problem here.

The vulnerable code was introduced in the 7.26.0 release, when support for DIGEST_MD5 authentication was added to the cURL software.

DIGEST_MD5 is an rudimentary way of allowing you to login over an unencrypted connection, for example to an HTTP or POP3 server, without sending your actual password.

The server sends a random challenge string, or nonce, together with a bunch of other authentication-related data; you reply with a cryptographic hash of your password mixed up with that server-supplied data:

So a cracker who sniffs your reply can't directly recover your password from it, and since the challenge is random and varies every time you log in, the cracker can't re-use your reply later.

As an aside: avoid using DIGEST_MD5 authentication. Encrypt the entire session using TLS instead.

A cracker who sniffs a DIGEST_MD5 reply can't re-use it directly, but he can use it to try to recover your password offline using a dictionary attack.

TLS not only prevents this, but also keeps the entire transaction secret, including the contents of your web session or email. That's a much better security outcome.

Here's the buggy code from a vulnerable version of cURL:

Don't worry if you aren't familiar with C. I'll explain.

In C, the management and use of memory is left up to the programmer. You can use library code to help you deal safely with variable-length data, such as user-supplied text strings, or you can deal directly with memory yourself.

Above, the programmer has done the latter.

Firstly, he allocates a series of fixed-length memory blocks on the stack.

Then he copies text strings supplied by the caller of the function into those blocks, but be uses the system functions strcpy() and strcat(), which stand for "string copy" and "string concatentate" (tack one string on the end of another) respectively.

In modern code, you should never use those functions, because you can't limit how much data they copy.

They simply duplicate every byte from the input string into the output string, until a NUL (zero) byte has been found. A NUL is how the end of a text string is denoted in C.

So, if the server sends too much data in its authentication challenge, for example an overly-long realm string (the contents of which can be whatever the server chooses), this function will stuff too much data into the buffer it uses to compute the authentication response.

A buffer overflow will result, and in this case, since the destination data blocks were allocated automatically on the stack, the function will crash when it ends.

That's because the stack also stores the address in memory from which the function was called, so the cURL software can return there when it's finished. The return address is overwritten in the above code if the string response get over-filled.

The fix was a simple one.

The uncontrollable strcpy() and strcat() functions have been replaced with the function snprintf(), which stands for "formatted print of string into at most n bytes":

You can still make mistakes with snprintf, since it's up to you to specify n, and if you aren't careful, you may get it wrong.

But the point is that is is at least possible to restrict the output of snprintf to a known buffer size, which you simply can't do with the old-fashioned strcpy() and strcat().

? The updated cURL code above still isn't perfect. The programmer should really check the return value of snprintf(), which reports how many bytes it wanted to write. If your buffer wasn't big enough, then the output will be incomplete and therefore incorrect. You ought not to use it: increase the size of your buffer and try again, or report an error instead.

You're probably thinking, at this point, that exploiting this vulnerability would be hard because most programs that use cURL do so in the background. They aren't interactive.

Autoupdating software, which might use the cURL library (known as libcurl) typically comes pre-configured with a list of known-good URLs, or asks you to enter a URL at install time, and that's that.

An attacker who could talk you unto switching your known-good autoupdate URL for a dodgy one, or who could persuade you to change from the POP3 email server you've always used to one you've never heard of, would surely find it easier to infect you simply by getting you to run his malware directly.

That's true, but there's still a risk.

If an attacker can redirect the requests from your autoupdater or your POP3 client, for example by fiddling with your DNS settings, or by hacking a server at the edge of your service provider's network, he could send you off to an imposter site and attempt to exploit you from there.

? As @kyprizel points out in the comments below, cURL only actually calls the vulnerable function from its POP3 and SMTP protocol handlers, so an HTTP request cannot directly put you in harm's way. But cURL follows HTTP redirects, even unusual ones that send you off to a POP3 server, so a crook who can modify your HTTP replies may be able to attack you nevertheless.

Because of the buffer overflow, this could lead to a drive-by download, where cURL itself is tricked into misbehaving, cutting your informed consent out of the loop altogether.

The lessons?

Don't use strcpy() or strcat().Ever.Use snprintf (or strlcpy() and strlcat(), or similar) instead.Always check the return value of string-handling functions so you don't end up using incorrect results.

Your next problem is to find out which software you are using, if any, includes cURL code with these bugs. (Versions of cURL from 7.26.0 to 7.28.1 inclusive are affected.)

Best start asking around...

Follow @duckblog

NB. Although several Sophos products use libcurl, none of them use code from the vulnerable versions.

View the original article here