Snapchat images that have "disappeared forever" stay right on your phone...

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.

Snapchat is a wildly popular app for Androids and iDevices that allows you to share photos with your friends.

Snapchat replaces more pedestrian ways of sharing photos, such as sending them by email.

The app enables you - indeed, it pretty much encourages you - to share snapshots you would probably be wiser to keep to yourself, or better yet not to take in the first place (my emphasis below):

Snapchat is a new way to share moments with friends. Snap an ugly selfie or a video, add a caption, and send it to a friend (or maybe a few). They'll receive it, laugh, and then the snap disappears.

The image might be a little grainy, and you may not look your best, but that's the point. It's about the moment, a connection between friends, and not just a pretty picture.

The allure of fleeting messages reminds us about the beauty of friendship - we don't need a reason to stay in touch.

Give it a try, share a moment, and enjoy the lightness of being!

Clearly, Snapchat's primary feature, if not its raison d'etre, is "managed risk".

You can live a bit recklessly, Snapchat seems to be saying, because the snap disappears after your friends have looked at it.

In fact, the app description on Google's Play Store goes one step further, promising disappearance for all eternity:

Snapchat is the fastest way to share a moment with friends.

You control how long your friends can view your message - simply set the timer up to ten seconds and send.

They'll have that long to view your message and then it disappears forever.

We'll let you know if they take a screenshot!

As fellow Naked Security writer Graham Cluley asked late last year, early on in Snapchat's short history, "How do you reconcile 'dispappears forever' with 'if they take a screenshot'?"

After all, if the screenshot warning ever does come up (assuming the screenshot detector does its job), the one thing you can be sure of is that the image has not disappeared forever, or even at all.

That's because the screenshot function creates a new image, not managed by the Snapchat application, and saves it where your friend is in complete control of it, rather than you or Snapchat.

So "disappears forever" is something of a bogus concept to start with.

But just how meaningful is Snapchat's promise if you completely ignore the screenshot problem, or the taking-?a-?picture-?of-?the-?screen-?with-?another-?camera problem?

US-based computer forensics geek Richard Hickman thought he'd find out.

Be prepared to laugh (or cry - it's not really funny): according to Hickman, "expired" Snapchat photos don't disappear at all!

He grabbed a forensic image of a phone running Snapchat, found a directory called received_image_snaps and looked in it.

Both unviewed and expired images were still there.

If Hickman's analysis is correct (and it certainly seems to be), Snapchat relies on two steps to make your images "disappear":

It adds the extension .nomedia to the filenames, which is a standard Android marker that says, "Other apps should ignore this file. Do not index it, thumbnail it, add it to any galleries, or whatnot. Leave it to me." It adds a record to its own database to say, "The following image should be treated as though it doesn't exist. Leave it to me, and I will pretend it has disappeared forever."

Just as egregiously, Snapchat doesn't even come close to guaranteeing that your images get deleted from its own servers once they've been delivered:

When you send or receive messages using the Snapchat services, we temporarily process and store your images and videos in order to provide our services. Although we attempt to delete image data as soon as possible after the message is received and opened by the recipient (and after a certain period of time if they don't open the message), we cannot guarantee that the message contents will be deleted in every case.

So when you share that "ugly selfie", where does it end up?

It's stored on your phone, but you'd expect that because you took it, so that's your lookout.

It's stored on Snapchat's servers, where it will probably be deleted once it's been delivered, but not in every case.

And it's stored on the recipients' phones, from where it apparently won't be deleted at all, though it will be marked "not for display," which seems to be synonymous in Snapchat's argot with "disappears forever".

What to do about this?

The obvious first step is to share snapshots only if you don't mind them hanging around forever.

The second step is to stop using Snapchat until these issues get fixed.

And the third is to write to the Snapchat guys and suggest that they could use cryptography and positive erasure to come much closer to fulfilling their promises, so you can start using their app again.

Here are some cryptographic tricks that Snapchat might consider:

When user X signs up, generate a public/private key pair on his device and send the public key to the Snapchat servers.When storing an image for delivery to X, encrypt it with X's public key so it can't be decrypted unless and until X receives it on his device. That way, images implicitly 'disappear' from the Snapchat servers even before they are delivered.Encrypt each image delivered to X's device with a random key, and keep the key on the Snapchat server until X requests to view the image. That way, the key and the decrypted image only ever need to exist in memory on X's device, and thus implicitly 'disappear' once viewed.When 'disappearing' an image, positively erase (i.e. actively overwrite) the random key off the Snapchat servers. Without the key, the encrypted image becomes shredded cabbage.When 'disappearing' an image, positively erase the encrypted image file on X's device, just in case the key survived, for defence in depth.When uninstalling the app, positively erase X's private key. That way, as-yet unviewed images become shredded cabbage.Whenever X has no unexpired images left to view, positively erase X's private key and generate a new keypair as though starting a fresh install.

The bottom line?

Call me a killjoy, but don't share a selfie, ugly or not, or any other file, for that matter, unless you are willing to risk it being in circulation forever.

And if you're not willing to risk it being in circulation forever, consider not even taking it in the first place.

Follow @duckblog

View the original article here

A closer look at the malicious Redkit exploit kit

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.

In my previous article on the Redkit exploit kit, I provided an overview of how the kit operates. Specifically, how the attack uses a network of compromised web servers to serve up the redirects and malicious content.

In this article, I will take a closer look at the malicious content used to infect the user with malware.

The landing pages used by current versions of Redkit are pretty simple, consisting of just a tiny web page that loads up the malicious Java content. A single param attribute is used to pass in an obfuscated URL (underlined) to the Java code:

This string is retrieved and decoded (simple character substitution):

As noted previously on Naked Security, there have been several recent vulnerabilities in Java that are being targeted by exploit kits like Redkit. In a successful attack, security mechanisms will be bypassed and the malicious payload silently downloaded and run.

The specific vulnerabilities that are being targeted in Redkit change quite regularly, but have recently included:

The JNLP file referenced in the landing page (above) reveals a security bypass that is being used by several of the active exploit kits. The attacks make use of an undocumented parameter (__applet_ssv_validated) to bypass security restrictions, and enable silent (no user prompt) execution of an unsigned applet.

The file downloaded from the payload URL is actually AES encrypted. Clues to the use of AES litter the Java code, despite various attempts to obfuscate the intent. For example, reversing the Cipher transformation string:

Sure enough, looking at the downloaded file, it is easy to confirm that it looks encrypted or encoded in some way (it is not a regular Windows executable at least!):

Of course, to infect the user, the Java has to decrypt the file first. Elsewhere within the code is the necessary decryption key (and iv parameter):

Using these we can manually decode the encrypted file:

openssl enc -d -aes-128-cbc -in -out -K -iv -nosalt -nopad

The Java code does not simply decrypt and save/execute the downloaded file however. There is an additional block of code that inspects the decrypted stream, hunting for a string that is used as a marker.

The purpose of this mechanism is evident a little lower down in the code.

So, if the marker is found, the if condition is false, and two executable files are extracted from the decrypted stream and executed. If the marker is not found, only a single payload is present, and just that file is executed.

Looking at the decrypted file obtained from a recent Redkit payload, the marker is indeed present (highlighted in red), sitting between the two executables that the user is infected with (scareware and a data stealing Trojan).

This mechanism enables the Redkit exploit kit to infect the victim with up to two payloads in a successful attack. The mechanism could easily be extended to allow even more. Of course, this does not really make the attack "worse" - once any machine is infected with a single payload, it is common for that to download and execute others. Nonetheless, it is an interesting feature to note.

The diagram below provides an overview of the above information, summarising how Redkit infects victims with malware.

In these two posts on the Redkit exploit kit I have described the key characteristics of the kit. The most interesting of these are:

use of a network of compromised web servers to "host" the kitproxy malicious content (landing page, JAR, payload) from the C&C server to the victim via a compromised web serverdownload payload(s) in encrypted (AES) formenable infection of 2 payloads in a single attack

To conclude, a few points concerning how users can best protect themselves from this (and similar) attacks.

To start with users or organisations need to consider whether their machines are vulnerable to the exploits being used (just Java in the case of Redkit, at the time of writing).

Do you have Java installed? Do you actually require it? If not, remove Java from your browser.

If you do need Java, ensure you are fully patched, and running the latest version.

In terms of security software, regular good practice should be followed.

In short, use a reputable security product which is up to date.

Additionally, ensure the available functionality within that product is enabled (web reputation filtering, web content scanning, cloud protection, memory scanning, runtime protection/HIPS).

All of these features are designed to provide layered protection, which is crucial for effective protection against drive-by download attacks delivered from exploit kits like Redkit.

Follow @SophosLabs
Follow @NakedSecurity

Image of red eye courtesy of Shutterstock.

View the original article here

US Department of Labor website hacked, serves malware, now fixed

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 have read about the US Department of Labor "getting hacked".

It's true, but fortunately the story is not quite as gory as it sounds in those two fateful words.

A subdomain of the Department's main website, running off a separate server - what's known colloquially as a microsite - was modified to serve up malware.

There's a sort of double irony here, because news about the breach broke on May Day, which is Labour Day in much of the world, though not in the United States, where it is celebrated in September.

The affected microsite was www.sem.dol.gov, which is currently (2013-05-02T10:22Z) offline.

SEM stands for Site Exposure Matrices, but the "site" in the name refers not to websites but to worksites.

The SEM "is a repository of information on toxic substances present at Department of Energy sites and other locations where radiation exposure is a possible hazard.

We've already seen speculation that the radiation-related nature of the SEM site tells us that this is a targeted attack, and certainly the site is not one you would expect to draw a lot of traffic.

On the other hand, of course, it might just be that the site was attacked because it was vulnerable while other parts of the Department of Labor site were not.

? Many organisations use microsites for special purposes, such as conducting one-off marketing campaigns or, as in this case, for presenting specialised data. Often, this is to avoid bothering the IT team with change requests for the main website, or in order to try something new. If you use microsites this way, make sure you don't take any security shortcuts while you are "innovating".

The attack used a malicious JavaScript file to get your browser to download a file called bookmark.png.

This sounds like an image file, but is in fact a Windows program with the first byte altered so that it can't run by itself.

In theory, your browser shouldn't do anything more than simply, and harmlessly, download the offending file.

But the malicious JavaScript then uses the function called helo() in the script above in an effort to trigger the CVE-2012-4792 remote code execution vulnerability in Internet Explorer.

The attackers hope that this will trick your browser into jumping over its security checks to modify and run the downloaded malware program without asking you.

The exploit seems to have borrowed both code and concept from a publicly-available Metasploit module that gives more detail (perhaps a little too much for some readers' comfort) about this exploit.

The good news is that if you've patched Windows recently, or if you are using Internet Explorer 9 or 10, you should be safe, since the vulnerability will be fixed, the exploit won't work and the non-functional bookmark.png file will do you no harm.

? Sophos security products block the drive-by-download exploit script as Troj/ExpJS-IT and the "payload" executable as Troj/Agent-ABOB.

The attack also uses a malicious script file that includes what are known as anti-anti-virus techniques.

This means that the attacker actively attempts to evade detection by interfering with the operation of one or more of the anti-virus tools you may be running.

If you're using BitDefender, the script even tries to connect to the local web console to reconfigure the product on your behalf.

? Sophos security products block this malicious script as Troj/ExpJS-IV.

To summarise:

A patched version of Windows should be immune to the exploit used in this attack.Internet Explorer later than version 8 should be immune.The hacked site is off the air and unlikely to reappear until it is clean and safe.An up-to-date anti-virus ought to block the malicious files, even on an unpatched computer.

Oh, and one more thing.

If you use microsites for special-purpose content, take care to avoid introducing special purpose risks at the same time!

Follow @duckblog

View the original article here

Facebook introduces Trusted Contacts, makes you ask, “How much do I trust my friends?

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.

Losing access to your Facebook account is a big deal, especially if you use it to generate business as well as to keep up with your friends.

Getting control back over "lost" online accounts can be an even bigger deal.

It's not as though you went into a branch of Facebook, or Google, or Microsoft, and established your identity in a reliable and repeatable way when you opened your account.

And there's no-one at the branch you've never been to who would recognise you with certainty by your appearance, voice and mannerisms.

So you're stuck with unreliable methods, such as knowing the answer to various "security" questions, or sending in a scanned copy of a driving licence.

Neither of those approaches to account recovery are appealing from a security point of view, or terribly convincing as identification.

But what if there were someone who could speak up for you to the Facebooks of the world, and that you would trust to speak up for you because you selected them for that job in the first place?

That's the idea behind Facebook's just-announced Trusted Contacts feature.

You choose three to five trusted contacts that can request account recovery codes on your behalf, but you need to have three codes at the same time to complete the recovery process.

? To configure this feature, assuming it's available in your region and language, login to Facebook and go to the "gear wheel" dropdown menu. Choose Account Settings, go to the Security tab and click on Trusted Contacts, then Choose Trusted Contacts.

This is bit like setting up a corporate bank account so that it requires multiple signatures, to prevent a rogue director operating alone.

As Facebook points out in its evangelism of this new service:

With trusted contacts, there's no need to worry about remembering the answer to your security question or filling out long web forms to prove who you are. You can recover your account with help from your friends.

Will it work?

I'll give this approach a qualified "Yes."

I like the fact that this effectively decentralises your identity (or, more correctly, your right to assume a specific identity) on Facebook, and lets you take control of it yourself.

There are risks, however.

As Facebook points out, you need to "choose people you trust, like friends you'd give a spare key to your house."

But the company may be making a bit of a culutural leap there, because I'm not convinced that we yet treat access to other people's online accounts with the same gravity as we do access to their property.

Nick Statt, a Readwriteweb journalist who was still at college when Facebook came onto the social scene, wrote about this very issue under the headline, "Can You Really Trust Your Friends?"

His concern over Trusted Contacts lies mainly in the fact that he, and his friends, seem to have spent their formative adult years in a milieu in which "If anyone left their account open on any computer that wasn't their own that person's Facebook account was fair game."

And even if your friends don't share what Nick Statt calls the "joy of Facebook hacking," you have to be sure that your Trusted Contacts will heed Facebook's own warning:

Your trusted contacts should make sure it's you before giving you security codes.

In theory, three out of the three-to-five chums you choose to be your Trusted Contacts would need to collude to rip your account off.

But in practice, one turncoat "friend" might very well be able to collect three codes for himself by applying social engineering to two of your other friends.

For example, he could ask the others to generate recovery codes and send them to what he says is your new email account, and tell them that you weren't able to call everyone individually because you had to use a borrrowed phone.

Apple took a different approach when it introduced two-factor authentication recently, preferring instead to rely on a single recovery code so that only you can reset your password.

Apple reminds you to write down and keep somewhere safe - what you might do, in fact, with a spare key to your house.

That's an approach I think I prefer, but I can see why Facebook didn't want to rely on a single, long-lasting recovery code.

After all, the temptation to store the master password somewhere insecure (such as in an unencrypted file on your everyday computer) will just be too great for some users.

Worse still, if you lose that one-off master password, then you'll lose access to your account forever.

And that, if you remember, is the very problem we were trying to avoid at the top of the article.

Follow @duckblog

View the original article here

LulzSec hacker leader arrested in Australia

A self-proclaimed leader of the LulzSec international hacking group has been arrested in Australia, police said, charging him with attacking and defacing a government website.

The 24-year-old IT professional, who went by the online identity "ozshock", was seized at his office in a town 76 kilometres (47 miles) north of Sydney on Tuesday.

"The man is a self-proclaimed leader of the group Lulz Security (LulzSec), a computer hacking group that has existed since 2011," the Australian Federal Police said, adding that he was known to international police forces.

"It will be alleged that this person, known by the online identity ozshock, had gained unauthorised access and caused data impairment to a government website during this month."

LulzSec, an offshoot of the larger group Anonymous, has claimed responsibility for multiple cyber attacks, including against Sony Pictures, Rupert Murdoch's News International, and the CIA.

Police called the man, who has not been named, "a well-respected person within the Anonymous community, within LulzSec".

They added that he was employed "in a position of trust" at the company he worked for, although that company had no knowledge of his activities.

Australian Federal Police Cyber Crimes Commander Glen McEwen said the man's job gave him access to sensitive information, which allowed him to carry out the attack on the unnamed website.

"Police believe this man's skill sets and access to this type of information presented a considerable risk to Australian society," he told reporters.

"Our early intervention interrupted him before he could commit any further serious offences.

"But the ability to interrupt online trading, online transactions for governments, can have serious consequences in the long-term."

He has been charged with two counts of unauthorised modification of data to cause impairment and one count of unauthorised access to a restricted computer system and faces a maximum of 12 years in jail.

The man was released on bail and will face court in May.

Cyber attacks that LulzSec has taken credit for include an extensive breach of Sony Pictures computer system in 2011, which led to the personal data of thousands of Sony customers being posted online.

American Cody Kretsinger pleaded guilty to various charges related to that incident and was sentenced to one year in jail last week.

Last year, two British members of the group admitted carrying out attacks against the CIA and News International.

View the original article here

IBM takes a big new step in cryptography: practical homomorphic encryption

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.

IBM just released an open source software package called HELib.

The HE stands for homomorphic encryption.

Although it doesn't sound terribly sexy or impressive, HELib is actually an interesting and important milestone in cryptography.

HE is also a surprisingly relevant topic right now, with our ever-increasing attraction to cloud computing.

Bear with me, and I'll try to explain.

Imagine that I am your cloud provider, and I keep databases online for you.

Imagine also that I am a security-conscious vendor, so I keep all your data encrypted, both when I serve it up to you, and when I save it to disk.

That's about as good as it gets these days from a cloud security perspective.

? It doesn't matter whether I'm a pure-play over-the-internet cloud provider, or just the manager of the server farm team in your own IT department. The situations are similar, though they may differ in degree: I've got your data, and you have no alternative but to trust me to do the right thing with it.

Now imagine that you want me to search through your data, for example to see how many ACME-WIDGETS were bought by customers called DUCKLIN in the last year.

Traditionally, the process would go something like this:

You encrypt the search terms and upload them to me.I decrypt the search terms so I know what to look for.I decrypt your data (perhaps only record by record, not all at once - that's a detail that doesn't matter here) so I have somewhere to search.I perform the search using the decrypted data.I encrypt the search results, if there are any, and return them to you.

Additionally, you hope that:

I get rid of all remnants, on disk and in memory, of both the search terms and the decrypted data once the search is complete.I don't take advantage of you, since I'm decrypting your data for this search, to sneak in other searches at the same time, whether for my own benefit, or for my government, or for one of your competitors.

There's a lot that could go wrong - for you, at any rate.

Imagine, however, if I could simply take your encrypted search terms, leave them encrypted, search for them directly in the still-encrypted database, and get the same results.

If I can perform calulations directly on your encrypted data, yet get the same results that you get from the unencrypted data, we both win enormously from a security and privacy point of view.

You don't need to give me any decryption keys at all, so you no longer have to trust me not to lose, steal or sell your data. (You still have to trust me to tell you the truth about any results I work out for you, but that is a completely different issue.)

And I no longer need your decryption keys, so I can't lose or abuse your data even if I wanted to.

That's the promise of homomorphic encryption, which we mentioned at the start.

Until 2009, no-one was sure whether homomorphic encryption was even possible.

Then, a Stanford student and IBM researcher called Craig Gentry showed that it could be done, in a PhD thesis entitled simply, "A fully homomorphic encryption scheme."

We weren't home and dry yet, though.

Gentry had what amounted to an existence proof, showing that homomorphic encryption could no longer be considered impossible, but he didn't have a practicable real-world implementation of the concept.

At the time, back in July 2009, well-known cryptographic personality Bruce Schneier praised Gentry's efforts, but pointed out that:

Gentry's scheme is completely impractical... Gentry estimates that performing a Google search with encrypted keywords - a perfectly reasonable simple application of this algorithm - would increase the amount of computing time by about a trillion.

Well, we're now a few steps further forwards, with IBM's release of the abovementioned software package HELib:

HElib is a software library that implements homomorphic encryption (HE). Currently available is an implementation of the Brakerski-Gentry-Vaikuntanathan (BGV) scheme, along with many optimizations to make homomorphic evaluation runs faster, focusing mostly on effective use of the Smart-Vercauteren ciphertext packing techniques and the Gentry-Halevi-Smart optimizations.

With a package description like that, it's obvious that consumer-facing homomorphic encryption tools aren't going to be a click away at the Play Store or the App Store for a while yet.

On the other hand, four years ago we didn't even know whether it would be possible to have homomorphic encryption at all.

So, watch this space!

Follow @duckblog

View the original article here

Beware of encryption companies bearing gifts!

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.

Ancient Roman propaganda poet Publius Vergilius Maro, better known as Virgil, famously had one of his more cynical characters cry out:

If you don't know Latin, but you do know that Teucri refers to the people of Troy, and Danaos to the Greeks, you can probably guess what this is about.

The highlighted words mean, "Don't trust the horse, chaps!"

The thing about the Wooden Horse of Troy, of course, was the question that perplexed Laocoon, the priest who is speaking in the extract above, namely, "Why?"

Of all the gifts you could leave behind, why a giant wooden horse? Why that shape? Why that size?

Laocoon even flung his spear at the horse, by way of science, and noted that it didn't produce the sort of resonance that you'd expect from an innocently hollow wooden statue.

But no-one listened, and it didn't go so well for the Teucri after that.

As it happens, this story is about an App Store program that probably isn't a Trojan Horse - I didn't feel like paying six quid to find out, to be honest - but it is a great example of the sort of story that cries out for an answer to "Why?"

The software is called Redact Secure Messenger, and it claims to fill an important niche by sending "heavily encrypted messages from one phone to another without passing through any central servers."

The first thing that will attract your attention (perhaps not in the way the marketing people intended) if you are interested in cryptography is its claim to be "the world's first totally secure instant messenger application."

Wait a minute! Didn't Blackberry do that years ago?

Didn't Blackberry do secure, free instant messaging so well, in fact, that it got into hot water for it when a giant wave of criminality lashed the UK back in 2011?

And what are the words totally secure doing next to each other? Didn't Alan Turing have something cautionary to say way back in the 1930s about the problems of putative programmatic perfection?

Keep reading, because the story gets weirder.

The company behind this product, which identifies itself on its web properties (that I could find, anyway) only with a mailto:?info@?redactapp.com link, is offering a "£10,000 prize to anyone who can intercept a message" secured by the app.

Actually, that's not what it's offering at all.

It's not anyone, it's not any message, and merely intercepting it is not enough.

To have a crack at the £10,000, you have apply, and then be one of up to 20 people chosen by the company; then you get a chance to try to decrypt a single message that will be bounced back and forth between a pair of phones at an as-yet undisclosed location in London.

Oh, and it gets even weirder still.

When you apply, it's like being phished.

You have to fill in your full name, address, phone number and - wait for it! - upload your Curriculum Vitae (British English for resumé).

All this, even though you are as good as guaranteed in advance not to win.

(If if is, indeed, possible to win, then the app's claim to be totally secure is false.)

If you want to be a gung-ho encryption company with grandiose claims - like Kim Dotcom's MEGA, for example - then you should at least be open about your cryptographic methods, set a clear and public challenge, and be prepared to defend it against all comers.

That's what MEGA did with its bounty programme, and whatever you think of MEGA, of its founder and of its raison d'etre, it nevertheless reflects to the company's credit that it offered bounties at all.

What Redact is doing just invites too many "Whys".

This sort of thing is a bad look for the encryption industry, and we can do without it.

Follow @duckblog

View the original article here

Network gaming company uses its “cheat-prevention” client to build a Bitcoin botnet

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.

In one episode of the nerdtastic TV sitcom Big Bang Theory, the socially-challenged Caltech physicist antihero, Dr Sheldon Cooper, has his World of Warcraft account hacked.

A giant shopping-list of Sheldon's virtual property gets plundered: his wand of untainted power, all his gold, and even Glenn, his beloved battle ostrich.

As Sheldon laments, "Three thousand hours. Three thousand hours clicking on that mouse, collecting weapons and gold. It's almost as if it was a huge waste of time."

And that's the problem with games that you play across the internet: how do you trust the other people in the contest?

Even when there's no money involved, it spoils the fun if the other guys aren't on the level.

That's where on-line communities like ESEA, or E-Sports Entertainment, come into play.

ESEA describes itself on Facebook as "the leading game play based community. With a sweet pick up game mod, a custom anti-cheat client that works, and cool statistics to log all of your activity, ESEA is the place to play!"

To join ESEA's network, you need to install and use the company's custom client software.

The client is designed, amongst other things, to maintain a level playing field by detecting cheats, such as players who programmatically automate tasks - rapid, accurate shooting, for instance - that are supposed to be a battle of dexterity between human opponents.

Imagine the stirrings of discontent when players on ESEA's network started wondering about symptoms such as their GPUs (graphics processing units, the special graphics cards that speed up the display) running at high utilisation.

Overcooking your GPU can be a costly exercise, since it increases electricity consumption and may shorten the life of your hardware.

What was causing the hot and heavy running?

Surreptitious Bitcoin mining, it seems!

One customer took the simple precaution of looking in the ESEA client log file and found this:

Another user got in telephonic contact with a sysadmin at ESEA to discuss what was going on, and received some surprising admissions during the call.

Here's a partial transcript of the sysadmin's comments:

It shouldn't be any surprise, but the [anti-cheat] client is capable of doing a lot of things that people don't know about. [...] They think the client does screenshots and that's about it. Truth be told...it probably does more than about 50 different things, because there are more than 50 ways to cheat.

[...] Funnily enough, there was a debate, a conversation, regarding the subject of using the client to mine Bitcoins. That was a joke, but at the same time it was half serious.

The high-performance GPUs that many gamers own are handy for Bitcoining, because the Bitcoin system relies on computing massive numbers of SHA checksums, a task that just happens to be ideally suited to today's graphics hardware.

The ESEA staffer continues, rather unconvincingly:

It turned out I actually did write code to do it, but it wasn't supposed to be code that was everywhere. [...] I restarted the server and the [configuration] setting got reset and [the mining code] actually got turned on, which was only, like, it wasn't for very long.

We calculated how much we would actually make, if we really wanted to do it. We would make hundreds of thousands of dollars if we actually did it with everybody. But that would be pretty intense.

[Voice of caller] Not to mention kind of illegal.

And that's the problem with software that you run across the internet: how do you trust the other people in the protocol?

Even if there's no money involved, it spoils the fun if the other guys aren't on the level.

ESEA head honcho Torbull has now tried to make a clean breast of it, admitting that the company had toyed with the idea of using its customers as a giant Bitcoin botnet, but decided not to go ahead.

Nevertheless, someone inside the company didn't listen, and ran a Bitcoin farm on ESEA customers' computers for the next two weeks.

The outcome fell far short of the hundreds of thousands of dollars predicted above, but was nevertheless a handy sum to accumulate for free: just under $4000's worth of Bitcurrency.

It's a funny sort of infringement, because the Bitcoins weren't actually stolen, and the client software was voluntarily installed by each user, no doubt under terms and conditions that permit fairly arbitrary remote updates and reconfiguration.

Indeed, the Bitcoins didn't even exist until before the unauthorised mining started.

ESEA has decided to donate the proceeds to charity, to chip in the same amount again itself, and to create a prize pool for customers that will return $3,713.55 back into its customer community.

Peace with honour?

Probably - but it does raise the age old question: who will guard the guards?

Follow @duckblog

View the original article here

Apple ships jolly uninteresting iOS 6.1.4 update

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.

Apple's operating system updates, even the point releases, usually have quite a lot going for them.

(A point release is when only the number after the rightmost dot, or point, in the version string changes.)

For example, when OS X 10.8.2 was superseded by 10.8.3, Apple patched 21 security vulnerabilities.

Eleven of these vulnerabilities offered the possibility of remote code execution (RCE) exploits.

RCE holes are what make drive-by downloads possible, where you may end up getting infected merely by looking at a website, reading an email or viewing a document.

And when iOS 6.1.3 came out, we recommended it because it closed the door on a lock-screen bug that allowed you unlock an iPhone 5 without the passcode.

Just over a month later, and Apple has shipped iOS 6.1.4.

This time, though, there don't seem to be any security fixes - not even for the lock-screen bug that was found in iOS 6.1.3, the update that fixed a lock-screen bug.

Note that this update is for the iPhone 5 only, so owners of iPods, iPads and earlier iPhones won't be getting anything.

By the way, even if you do have an iPhone 5 and apply the update, assume that the iOS 6.1.3 lock-screen bug persists.

With that in mind, let me repeat our advice from March.

Make sure voice dialling is turned off, since the bypass trick only works if it is turned on.

Mind you, does anyone still voluntarily use voice dialling?

Surely you gave it up after the first time this happened:

A: [gossiping in the car] You know that odious chap, don't you?

B: Who?

A: That bloke CALLed JOHNATHAN [*]

Mobile phone: [inaudible over car noise] Do you want to call Johnathan?

B: I know him, YES.

Mobile phone: [inaudible] Calling Johnathan

B: That guy who thinks butter wouldn't melt?

Jonathan: [tinny, inaudible] Hello, Johnathan here.

A: Well, let me tell you something you didn't know about JOHNATHAN.

Jonathan: [tinny, inaudible] Yes, this is Jonathan.

A: Are you listening, because this is juicy!

Jonathan: [tinny, inaudible] Go ahead.

Since the primary purpose of iOS 6.1.4 seems to be to improve speakerphone voice quality, there's one more reason to turn voice dialling off!

Follow @duckblog

[*] Name changed for security reasons.

View the original article here

Reputation.com resets all user passwords following breach

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.

Reputation.com, one of the places that helps to bury negative search results about you, has been hacked.

The online reputation management company on Tuesday sent a letter to customers telling them that its network security personnel had recently discovered and "swiftly shut down" an external attack on its network.

Reputation.com said in the letter that the intruder(s) managed to siphon off names and email and physical addresses. In some instances, phone numbers, dates of birth and occupational information was also filched.

On top of that, a list of salted and hashed passwords for "a small minority" of users was accessed, the company said.

Although it's "highly unlikely" the passwords could be decrypted, the company immediately changed all users' passwords, it said.

What was not accessed:

Financial information, such as credit card numbers or bank account information, which the company doesn't store (hurray!), Social Security Numbers and drivers license numbers, which the company doesn't request (hurray!), Account details, including why users retained Reputation.com's services (hurray! I imagine that could get embarrassing and potentially be used to make negative content about users zoom back up in search results), Communication between users and Reputation.com, and Any details about the services users have received.

An interesting point is that the extent of the breach didn't trigger any legal obligation, worldwide (except for the US state of North Dakota. Hurray North Dakota!) to tell users about the breach, but the company thought it was important enough to let them know anyway.

It's such a kick in the teeth.

You think you find a site that helps you keep your private data from dribbling out of the myriad online places that siphon it off.

You imagine that the online sliming left by trolls, unhappy customers or whomever's out to get you has been, if not strangled entirely, at least buried far enough down in search results that its babbling just might be muffled.

Then somebody or somebodies goes and tries to stick a pin in those mission statements.

Well, it appears that Reputation.com's work to do those things hasn't been compromised by the attack, and much of the reason for that has to do with good security practices.

So kudos for going above and beyond disclosure requirements, and kudos for salting and hashing passwords, Reputation.com.

Follow @LisaVaas
Follow @NakedSecurity

Hacked image courtesy of Shutterstock.

View the original article here

Lifting the lid on the Redkit exploit kit (Part 1)

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.

Redkit is one of the lesser known exploit kits that is currently being used to distribute malware.

Though not as widely talked about as Blackhole, Redkit has gained some press recently, having been involved in the NBC site hack and the spam campaigns that followed the Boston bombings.

In the first of this two-part series, I will give an overview of the exploit kit: how it operates and where it is being hosted.

Part Two will take a deeper look into the malicious code being used in order to uncover some of the functionality it provides to the attackers.

To start with, let's take a look at how Redkit operates.

As with other exploit kit drive-by downloads, victims are typically redirected to the exploit kit when they browse a compromised web site. For Redkit attacks, there are several different flavours of redirect being used, but over the past few months, the most prolific is one that Sophos blocks as Troj/Iframe-JG.

This inject has been discussed previously. As you can see from the image below, the iframe injected into pages is fairly easy to recognise:

The conventional drive-by download model involves victims being redirected to a malicious exploit site. However, Redkit does things a bit differently.

The initial redirect (typically an iframe) will be to another legitimate, but compromised server. Let's call this the first stage redirect. This redirect will be to a four-character .htm or .html page in the root of the the target web server. For example:

compromised_site.net/dfsp.html
compromised_site.com/zpdb.html

The response from this redirect is a HTTP 301 redirect. Let's call this the second stage redirect.

The 301 redirect bounces the victim off to another compromised web server, again to a four-character .htm or .html page. This time, the malicious content is delivered via a simple landing page that loads the malicious JAR.

Historically, Adobe Reader has also been targeted, but Redkit has been targetting just Java vulnerabilities for a while now.

More recently, the landing pages are slightly different, using JNLP (Java Network Language Protocol):

Note: Older versions of the kit used .html for the first stage redirect target, and .htm for the second stage. In later versions of the kit this has changed.

As far as the victim is concerned, the malicious content is delivered from the compromised web server that is used in the second stage redirect. Interestingly, however, that content is never stored on that web server.

Instead, the compromised web servers used by Redkit are loaded with a PHP shell, which manages things. The PHP shell is responsible for:

Bouncing first-stage redirects on to another (randomly chosen) server. The PHP shell connects to a remote Redkit command and control (C&C) server in order to obtain a list of other compromised sites (updating the list each hour).Delivering malicious landing page and JAR content to the victim. This is not loaded from disk. Instead it is downloaded (using cURL) via HTTPS from the C&C server. So the PHP shell essentially acts as a proxy for the malicious content.

? Sophos products detect the PHP shell as Troj/PHPRed-A.

The PHP shell works in tandem with a rogue .htaccess file, which is responsible for guiding incoming HTTP requests (to the four-character htm/html files) to the necessary PHP script.

This is illustrated in the diagram below.

A large number of compromised web servers have been used by Redkit over the past few months. A breakdown by the countries hosting the hacked servers is shown below.

These servers are split across several ISPs:

How are the servers being compromised? Looking at the server strings returned from the compromised web servers, we get a fair spread.

This would suggest that it is not the server platform (Apache, IIS etc) that is being targeted/exploited. More likely software/applications installed on the server itself, or simply stolen credentials.

This concludes the first of these articles on Redkit. It provides an overview of how the kit operates, and describes the interesting techniques used to "host" the exploit kit. The data collected thus far also gives us an indication of the prevalence of this kit, and the number of compromised web servers involved.

In the next article in the series, we will take a closer look at the malicious Java code, and how it is used to infect the victim with the payload.

Follow @SophosLabs

Follow @NakedSecurity

View the original article here

Revenge-porn website victim files suit against ex and four porn sites

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 US woman in the state of Florida has filed charges against her ex-boyfriend and four websites for posting revenge porn images of her - i.e., nude photos and/or videos, including private facts and details of the victim, posted online without the subject's consent.

Holly Jacobs (a name she assumed at some point during the four years she says she's suffered repercussions) filed suit on April 18 against sextingpics.com, anonib.com, pinkmeth.tv and xhamster.com, as well as against ex-boyfriend Ryan Seay, for the "public disclosure of private facts" and "intentional infliction of emotional distress."

This is the second of two well-publicized suits against sites that enable revenge porn.

A similar case - this one a class action suit - was filed in January by 17 women victimized by revenge porn.

The earlier class-action suit was filed against revenge-porn site Texxxan.com, as well as against GoDaddy, for whatever profit it got off hosting a site dedicated to the victims' humiliation.

Some - such as Ars Technica's Timothy B. Lee - question whether the sites in question are, in fact, revenge porn sites, as opposed to being, in the case of Xhamster, for example, "a generic website for user-submitted pornography."

The argument is specious. A quick search on the term "revenge" on Xhamster shows that a site can certainly be both a generic porn site and a venue for revenge.

On Xhamster, you'll find titles such as "Revenge is a B*tch Real Ex Girlfriend," with a caption that describes "The ex getting f**ked on cam."

Jacobs describes the fallout of being victimized on the End Revenge Porn group's site:

Due to this act, I have had to legally change my name, stop publishing in my field (I am a PhD student), stop networking (giving presentations, going to conferences), change my email address four times and my phone number three times, change jobs, and explain to human resources at my school that I am not a sexual predator on campus.

That's a succinct and hygienic version of what happened to Jacobs.

Jacobs was interviewed by the Miami New Times, which wrote up details of the PhD student's ordeal.

Since 2009, Jacobs has experienced:

Naked photos of her appearing online and soon going viral, being displayed on hundreds of revenge porn websites, along with her name, phone number, and email address;Photos and videos being sent to her employers;Her Facebook account getting hacked, her profile photo replaced with a nude photo; Cancellation of a conference presentation after Seay allegedly encouraged tnternet trolls to show up and proposition Jacobs; Email threats after she began dating someone new; all of which lead her to Change her name.

Jacobs has been lobbying to change state and federal laws about revenge porn. Her efforts saw some initial success.

Florida House Bill 787, titled "Computer or Electronic Device Harassment," would make it illegal to post nude pictures of someone online and tag them with personal identifying information without their written consent.

If the bill becomes law, violators could face a third-degree felony, punishable by up to five years in prison, five years of probation and a $5,000 fine.

The bill covers both offenders in Florida and those living outside of the state who post content relating to Florida residents.

Unfortunately, according to Miami New Times, the bill has languished over the past week and now looks unlikely to pass by the time the session ends this Friday.

As far as Jacobs's lawsuit goes, Ars Technica's Lee characterized both it and the class action suit naming GoDaddy as "taking a broad, confused view of who's responsible".

Really? The suits strike me as broad, true, but not confused.

The notion of GoDaddy being taken to task hardly seems confused. It seems appropriate, the hosting provider being an accessory to the alleged crimes and having profited off them, to boot.

With regards to sites that host revenge content, they're now shielded by Section 230 of the Communications Decency Act, which states that websites aren't liable for user-submitted content.

Jacobs's case will take a while to wend its way through the courts.

In the meantime, let's hope that public awareness of the issue continues to rise, and that, eventually, laws will be passed to prevent revenge-fueled distribution of private images and data.

The world doesn't need more tragedies like that of Amanda Todd.

The world doesn't need young women being hounded into committing suicide because of shame.

Follow @LisaVaas
Follow @NakedSecurity

View the original article here