STE WILLIAMS

SSCC 118.99

andropirate_170To wrap-up the three part Sophos Security Chet Chat 118, Vanja Svajcer from SophosLabs Croatia joined me in Berlin to discuss the finer points of unwanted software for Android.

While most of us can identify something truly malicious without too much difficulty, there are many other things that fall into more of a gray area.

Are ad pop-ups and your browser home page fair game when you download a free travel|game|puzzle|social app? Should apps be allowed to comb through your addressbook? Are hacking tools and p0rn appropriate for your work device?

These questions typically fall into the category of potentially unwanted applications (PUA), depending on the disposition of the user.

In the podcast, Vanja explains the lack of standards for defining which mobile apps are PUAs and then explains the proposal he and Sean McDonald from SophosLabs Australia put forth in their paper.

Listen to this episode

Play now:

(5 October 2013, duration 11’52”, size 8.5MB)

Download for later:

Sophos Security Chet Chat #118.99 (MP3)

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/s4aCr7klxYU/

SSCC 119 – Happy 10th, Patch Tuesday – Adobe "goes open source"

Monday review

Catch up with the latest security news in this week’s roundup. Watch the top news in 60 seconds, and then check out the individual links to read in more detail.

Monday 30 September 2013

Tuesday 1 October 2013

Wednesday 2 October 2013

Thursday 3 October 2013

Friday 4 October 2013

Saturday 5 October 2013

Sunday 6 October 2013

Would you like to keep up with all the stories we write? Why not sign up for our daily newsletter to make sure you don’t miss anything. You can easily unsubscribe if you decide you no longer want it.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/tsuvm7PZcK4/

US indicts 13 suspected Anonymous members for Operation Payback

Anonymous two faces. Image from ShutterstockThirteen alleged hackers labeling themselves with the Anonymous brand were indicted on Thursday on charges that they conspired to coordinate distributed denial of service (DDoS) attacks against websites that included the Recording Industry Association of America (RIAA), Visa, MasterCard, and The Motion Picture Association of America (MPAA).

The indictment, handed down by a grand jury, was filed in US district court in Alexandria, Virginia, and charged the 13 with conspiracy to intentionally cause damage to protected computers by launching the attacks.

As the indictment describes, the attacks were part of Operation Payback (aka Operation: Payback is a Bitch) – an orchestrated series of attacks that targeted victims worldwide.

As The Register’s John Leyden reported after the initial attacks in September 2010, Operation Payback actually started out, as its name implies, as a tit-for-tat move.

Anonymous initially launched the operation in retaliation against DDoS attacks unleashed by Aiplex Software – a firm hired by several Bollywood companies to launch DDoS attacks on sites hosting BitTorrent trackers that had failed to respond to takedown notices.

The attacks, which were carried out from September 2010 to January 2011, started as an effort to support such file-sharing sites.

They then evolved to back WikiLeaks and its founder, Julian Assange, and to take down the financial sites such as MasterCard that had cut off WikiLeaks’ funding.

The hackers’ tool of choice, Low Orbit Ion Cannon (LOIC), is apparently a favorite among those who label themselves Anonymous.

Sophos’s Vanja Svajcer wrote up this detailed analysis of LOIC back in December 2010.

In the indictment, prosecutors outlined how simple it was for the hackers organizing the operation to launch one such attack, against the MPAA.

On or about September 16, 2010, a member of the conspiracy posted a flier advertising the MPAA attack on a web bulletin board.

The flier announced:

We target the b*stard group that has thus far led this charge against our websites, like The Pirate Bay. We target MPAA.ORG! The IP is designated at [IP address], and our firing time remains THE SAME.

The flier provided the location at which co-conspirators could download the LOIC tool, and gave instructions so as to unleash the attack as “a calm, coordinated display of blood.”

The indictment names 13 hackers, but thousands more participated in the attack by simply clicking on Web links that downloaded LOIC and temporarily turned their computers into what the New York Times called “a digital fire hose aimed at each victim,” which, in this case, were the targeted websites, including Visa.com and MasterCard.com.

The 13 people charged range in age from 21 to 65 and hail from 13 different US states.

As Svajcer pointed out, participation in DDoS attacks is illegal in many countries, and anybody who accepts an invitation to partake in one runs a serious risk of having the law come down on them hard and fast.

As arrests and indictments such as this most recent one show, attackers’ source IP addresses inevitably end up in a targeted site’s log files.

After that, all that law enforcement requires is the cooperation of an internet service provider (ISP) to track down willing participants in a DDoS.

It only takes a moment to click on a link, but the payback for Operation Payback is promising to be far more onerous for those 13 and for whomever else prosecutors drag into court.

Image of Anonymous masks courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/mFaWGRDMjQY/

Party advertised on Facebook leads to 600 gatecrashers and one very-trashed home

A £1 million ($1.6 million) London home has been redecorated with vomit-saturated furniture and carpets, laughing gas canisters strewn across the ruined carpet, and a skylight broken after somebody fell through it, all courtesy of the 600 gatecrashers who showed up after a party was posted on Facebook with the toggle set to “public”.

Facebook party post

What homeowner Catherine Seale said to her 17-year-old son, Christopher, before leaving with her husband for a holiday in the south of France: “Don’t throw a party.”

What Christopher did: Threw a party.

Christopher, in fact, invited 60 guests to a gathering at his parents’ home on Saturday.

Unfortunately, his best friend mentioned the party on Facebook without realizing the post was public, according to the Huffington Post.

His mother found out about it after a friend called to tell her that 600 partygoers were wrecking her home.

Neighbors told the Huffington Post that six police back-up units were required to break up the crowd, which in the space of two hours mushroomed to a crowd of at least 600 and well beyond just teenagers.

One girl was reportedly rushed away in an ambulance, suffering from alcohol poisoning.

One neighbor, Mark Daly, told the Huffington Post that he caught men in their 30s urinating on his front door step and on his car:

He was just standing on my car relieving himself. I caught him and told him to pull it together. As soon as he saw me he stumbled away.

But then five minutes later there was another one urinating close to my letterbox. When I opened the door he got a fright and nearly injured himself trying to jump off the doorstep and run away from me.

Another neighbor, Adam Keyne, told Huffington Post that his BMW’s wing mirror had been smashed, leaving him with a £250 bill, and confirmed that these weren’t just kids on a bender:

The first couple of hundred people were teenagers getting a bit drunk, which shocked me because they were all very posh yet very raucous.

But then I became worried because there were men in their thirties and forties looking to cause real trouble. They were sitting on people’s wall screaming and insulting passers-by.

Another neighbor, Ian Grant, told The Telegraph that one gatecrasher vomited outside his front gate before asking for a postcode so his mother could come get him.

No arrests were made, but Catherine Seale made sure her son apologized to neighbors and told news outlets that Christopher will be donating his free time to charity.

Party group. Image courtesy of ShutterstockAs it is, the public posting of a party on Facebook has left the Seales with a home that’s still a bit sticky, with the smell of vomit lingering days after the bacchanalia.

Still, it could have been worse, Ms. Seale told Huffington Post, beyond the one case of alcohol poisoning and the thousands of pounds worth of damage done to her home:

They could have been killed. Even though it had been cleaned up when I got back from France, everything felt sticky and dirty and it stunk.

There was vomit in the sitting room, cushions were completely ruined, and the sofa stank for days.

There’s nothing new about her admonishment regarding parents’ need to realize that leaving a 17-year-old alone can result in episodes like this:

All parents should be warned that this could happen if you go away and leave your 17-year-old alone.

Facebook is, of course, the twist to this age-old tale. Ms. Seale offered advice on the matter of checking Facebook settings before posting applies to every one of us in Facebook nation, whether we’re posting truly embarrassing updates that could get us fired or parties that a) haven’t been parentally approved and/or b) could wind up in a riot that trashes our parents’ posh homes.

She says:

I think if anyone is going to throw a party, they need to look at their privacy settings on Facebook. It’s absolutely essential that children are made aware of this.

Hallelujah to that, Ms. Seale, and best of luck in getting that stench to come out.

Image of party and people dancing courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/yhj51WkJLk8/

SSCC 118.99 – How do you define a Potentially Unwanted Application (PUA)?

andropirate_170To wrap-up the three part Sophos Security Chet Chat 118, Vanja Svajcer from SophosLabs Croatia joined me in Berlin to discuss the finer points of unwanted software for Android.

While most of us can identify something truly malicious without too much difficulty, there are many other things that fall into more of a gray area.

Are ad pop-ups and your browser home page fair game when you download a free travel|game|puzzle|social app? Should apps be allowed to comb through your addressbook? Are hacking tools and p0rn appropriate for your work device?

These questions typically fall into the category of potentially unwanted applications (PUA), depending on the disposition of the user.

In the podcast, Vanja explains the lack of standards for defining which mobile apps are PUAs and then explains the proposal he and Sean McDonald from SophosLabs Australia put forth in their paper.

Listen to this episode

Play now:

(5 October 2013, duration 11’52”, size 8.5MB)

Download for later:

Sophos Security Chet Chat #118.99 (MP3)

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/5ZPg_hLAOjk/

Microsoft Patch Tuesday – get ready for a bumper Tenth Birthday edition!

It’s Get Ready For Microsoft Patch Tuesday time again already, and this month’s update will be the tenth anniversary of Microsoft’s regular security bulletins.

As you will have read at the start of the month, October 2013 is also the tenth anniversary of Cybersecurity Awareness Month.

I suspect that’s a coincidence, but it’s worth a smile anyway.

Microsoft has had a slightly rough time with updates lately, with some updates not working properly in August, and others working far too well in September, downloading themselves over and over again.

Despite the problems, however, things haven’t been too bad, so headlines like “A Decade of Botched Updates and Broken PCs” (I shan’t link to it; you can find it if you must) are needlessly discouraging.

(That article goes on to contradict itself almost immediately by describing early updates as trouble-free, so it can safely be dismissed as disingenuous, but it is nevertheless representative of real-world sentiment against Redmond and its patches.)

So, please don’t be discouraged this month, because the marquee update, Bulletin One, is almost certainly a formal fix for the Internet Explorer (IE) zero-day vulnerability that made the news half way through September.

That vulnerability, CVE-2013-3893, is being actively exploited in the wild by cybercrooks and Metasploit alike, so it’s pretty much open for anyone to acquire, study, tweak and use.

Existing CVE-2013-3893 exploits don’t work against all versions of IE, but they do work even when DEP (data execution prevention) and ASLR (address space layout randomisation) are in play, so you should assume that a really determined attacker could figure out an unlawful way into all versions of Windows running any version of IE, from IE 6 on XP to IE 11 on 8.1.

→ I say “almost certainly a formal fix” because Microsoft’s Advance Notifications don’t actually detail exactly what is going to be fixed. So we can’t be sure that CVE-2013-3893 is being patched for good, but given the seriousness with which Microsoft handled its appearance in the wild, it’s a good guess.

Interestingly, seven out of the eight bulletins this month deal with RCEs, or Remote Code Execution bugs.

That’s where an outsider can send you something that isn’t suppose to cause a silent download – like a document or a web page – and infect you with malware, without so much as an “Are you sure?” dialog, even if all you do is look at it.

Four of these RCEs are branded Critical, which you can take to mean “if you don’t patch this hole, crooks will probably try to sail through it and may very well succeed.”

The other three are merely Important, perhaps because they “only” affect Office and SharePoint server software.

The eighth Bulletin involves an Information Disclosure hole in Silverlight.

As usual, SophosLabs will be publishing its own risk analysis once Microsoft’s publish-no-earlier-than deadline has passed (usally as soon the patches are publicly available), helping you to estimate the likelihood of each vulnerability being exploited if you choose to delay the patch.

The last things to notice as you plan for Tuesday are:

  • Reboot required for the big Internet Explorer fix, so you’ll be rebooting most of your boxes.
  • Server Core installs are unaffected, proving the wisdom of using the minimalist flavour of Windows wherever you can.
  • Mac users get some Patch Love this time round, with an update for Office for Mac 2011 to close an RCE hole.
  • Windows 8.1 gets an update to IE 11, so your pre-release adopters will be patching and rebooting too.

Good luck with your Tenth Anniversary of Tuesday patching!

And if you’d like a quick review of terminology like RCE and Information Disclosure, and how to decide whether a Critical patch is more urgent to you than an Important one, why not listen to our recent Techknow Podcast, Understanding Vulnerabilities?

Listen now:

(18 September 2013, duration 15’08”, size 9.1MB)

Listen later:

Download Sophos Techknow – Understanding Vulnerabilities [MP3]:

Image of birthday balloons courtesy of Shutterstock.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/lWimJWxvfvc/

Silk Road bust, Adobe breach and Lavabit chutzpah

Adobe source code breach

Yesterday, we wrote about the latest network security breach at Adobe.

Customer data was stolen, including login IDs, hashed passwords, encrypted credit card numbers and card expiry dates. (Adobe didn’t apply the adjective “encrypted” to those, so maybe they weren’t.)

But the breach wasn’t limited to customer records: some 40GB of Adobe source code was supposedly spirited away at the same time.

Some of you expressed concerns about the effect that this source code theft might have on security, and suggested that we offer some opinions on what the risks might be.

Here you are.

Note. We’re not out to excuse Adobe’s breach here, nor to imply that code leaks of closed-source software are inconsequential. We’re just trying to help you see all sides of the picture. We hope you agree with our conclusions.

Which product sources were stolen?

According to Adobe, source for Cold Fusion and Cold Fusion Builder (used for creating websites), and for Acrobat (for creating portable documents) was almost certainly taken.

Other products may have been scooped up as well.

Will the stolen source code lead to lots of zero-day exploits?

This is a common fear – in fact, one of the researchers who came across the stolen code on the underweb went so far as to suggest that “this breach may have opened a gateway for a new generation of viruses, malware, and exploits.”

It’s true that source code usually means you don’t need to spend ages disassembling executable files to find out what they do, especially if you have fully-commented code and the original variable names.

You might even find notes from the programmers explaining complex or arcane parts of the code, or offering warnings of bugs that need fixing.

But researchers regularly find obscure and complex exploits against proprietary products without source code, while at the same time failing to spot long-standing vulnerabilities in products that are entirely open source.

So I don’t doubt that the crooks are pleased with their haul, but even if the source code makes their vulnerability research easier, it isn’t an automatic gateway to new exploits.

Remember that most vulnerabilities aren’t uncovered through manual analysis by humans, but through automated, deductive techniques such as fuzzing (running a program millions of times with successive inputs that change slightly each time until it crashes).

And working out how to exploit a vulnerability usually requires you to build up a detailed picture of what is going on inside the product’s executable code as it actually runs, whether you have the source code or not.

But if there *are* new zero-days found via the source, won’t it be the crooks that find them?

As a commenter on our earlier article pointed out:

Opening up the source code to uninvited criminals is very different from opening it up, as open source, to the public at large, so we now have the worst of all worlds. Obscurity of still-closed source code known only to the owners and a team of people intending to exploit it. That can’t be good.

Those are reasonable fears, since the only “new eyes” on the source are going to be those of criminals.

So, even if possessing the source bestows only a tiny advantage, that advantage won’t be used for good.

Do you think these “new eyes” will focus Adobe on reviewing its code promptly, and thus be a silver lining?

I think you can guess the answer to that question for yourself. (Perhaps it was rhetorical?)

And remember that although new eyes may well see something that has been overlooked before, “old eyes” have the twin advantages of familiarity and experience.

Will the source make it easier for the crooks to build Trojanised verions of Adobe products?

If the crooks have the necessary build environment and build tools, then they may be able to create their own official-looking versions of the software.

But large, proprietary software projects are notoriously difficult and time consuming to build, especially outside their usual development ecosystem, so this might not actually be the quickest and easiest way to produce Trojanised versions.

After all, the crooks have an easier way of getting official-looking versions already: just pirate the real thing.

Even if you build from source instead of patching an existing executable, you won’t be able to sign your new creation as a legitimate Adobe file without an Adobe code signing key.

And you’ll still have to persuade your victim to download and install your unofficial version.

But what if the crooks stole code signing keys along with the source code?

If so, they can make any program appear legitimate, even one without a single line of Adobe source code in it.

(This already happened to Adobe, about a year ago.)

What if the crooks got write access to the source while they were inside the network?

That might have allowed them to Trojanise Adobe’s own code repository by adding in a backdoor, a security hole, or any other sort of malware.

Then, when Adobe produced an official build and digitally signed it, the Trojan would be built-in from the start.

That would, indeed, be very bad.

But I’m sure that Adobe is already industriously conducting a stricter-than-usual audit of all recent changes to its codebase, which ought to allow it either to find and remove any unauthorised changes, or to conclude that no such changes were made.

Note that open source products, where there is often much less control over who can introduce or propose changes, and where the code is already a matter of public record, face the problem of maliciously-minded changes all the time.

Although there have been some occasional failures in the open source community, they are rare.

Sneaking unwanted changes past experienced code maintainers using modern change management tools is harder than you might think.

Why doesn’t Adobe just make its products open source and have the last laugh at the crooks?

Cute idea.

But you’d have to convince the Adobe shareholders that it wouldn’t affect the value of Adobe’s business.

Also, there are almost certainly parts of the codebase that couldn’t easily be open-sourced, for example because they were licensed from a third party.

What if Adobe opened up the code to selected resesrchers, and threw in some tempting bug bounties?

Cute idea, and a good way to get some carefully-chosen “new eyes” that aren’t crooks to scrutinise the code.

If you’re asking because you’d like to have a crack at Adobe’s source code yourself, then I suggest you go straight to Adobe with that question.

Adobe’s Chief Security Officer might a bit busy right now, but I’m sure he won’t mind you asking, as long as you are polite (as well as genuine and serious about getting involved).

The worst he can say is, “No.”

Was the NSA behind this attack?

Cute idea.

You’ll have to ask the US government.

The worst it can say is, “No.”

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/m5U7y7fCWD4/

Adobe source code breach – is it a gateway for new malware and exploits?

Yesterday, we wrote about the latest network security breach at Adobe.

Customer data was stolen, including login IDs, hashed passwords, encrypted credit card numbers and card expiry dates. (Adobe didn’t apply the adjective “encrypted” to those, so maybe they weren’t.)

But the breach wasn’t limited to customer records: some 40GB of Adobe source code was supposedly spirited away at the same time.

Some of you expressed concerns about the effect that this source code theft might have on security, and suggested that we offer some opinions on what the risks might be.

Here you are.

Note. We’re not out to excuse Adobe’s breach here, nor to imply that code leaks of closed-source software are inconsequential. We’re just trying to help you see all sides of the picture. We hope you agree with our conclusions.

Which product sources were stolen?

According to Adobe, source for Cold Fusion and Cold Fusion Builder (used for creating websites), and for Acrobat (for creating portable documents) was almost certainly taken.

Other products may have been scooped up as well.

Will the stolen source code lead to lots of zero-day exploits?

This is a common fear – in fact, one of the researchers who came across the stolen code on the underweb went so far as to suggest that “this breach may have opened a gateway for a new generation of viruses, malware, and exploits.”

It’s true that source code usually means you don’t need to spend ages disassembling executable files to find out what they do, especially if you have fully-commented code and the original variable names.

You might even find notes from the programmers explaining complex or arcane parts of the code, or offering warnings of bugs that need fixing.

But researchers regularly find obscure and complex exploits against proprietary products without source code, while at the same time failing to spot long-standing vulnerabilities in products that are entirely open source.

So I don’t doubt that the crooks are pleased with their haul, but even if the source code makes their vulnerability research easier, it isn’t an automatic gateway to new exploits.

Remember that most vulnerabilities aren’t uncovered through manual analysis by humans, but through automated, deductive techniques such as fuzzing (running a program millions of times with successive inputs that change slightly each time until it crashes).

And working out how to exploit a vulnerability usually requires you to build up a detailed picture of what is going on inside the product’s executable code as it actually runs, whether you have the source code or not.

But if there *are* new zero-days found via the source, won’t it be the crooks that find them?

As a commenter on our earlier article pointed out:

Opening up the source code to uninvited criminals is very different from opening it up, as open source, to the public at large, so we now have the worst of all worlds. Obscurity of still-closed source code known only to the owners and a team of people intending to exploit it. That can’t be good.

Those are reasonable fears, since the only “new eyes” on the source are going to be those of criminals.

So, even if possessing the source bestows only a tiny advantage, that advantage won’t be used for good.

Do you think these “new eyes” will focus Adobe on reviewing its code promptly, and thus be a silver lining?

I think you can guess the answer to that question for yourself. (Perhaps it was rhetorical?)

And remember that although new eyes may well see something that has been overlooked before, “old eyes” have the twin advantages of familiarity and experience.

Will the source make it easier for the crooks to build Trojanised verions of Adobe products?

If the crooks have the necessary build environment and build tools, then they may be able to create their own official-looking versions of the software.

But large, proprietary software projects are notoriously difficult and time consuming to build, especially outside their usual development ecosystem, so this might not actually be the quickest and easiest way to produce Trojanised versions.

After all, the crooks have an easier way of getting official-looking versions already: just pirate the real thing.

Even if you build from source instead of patching an existing executable, you won’t be able to sign your new creation as a legitimate Adobe file without an Adobe code signing key.

And you’ll still have to persuade your victim to download and install your unofficial version.

But what if the crooks stole code signing keys along with the source code?

If so, they can make any program appear legitimate, even one without a single line of Adobe source code in it.

(This already happened to Adobe, about a year ago.)

What if the crooks got write access to the source while they were inside the network?

That might have allowed them to Trojanise Adobe’s own code repository by adding in a backdoor, a security hole, or any other sort of malware.

Then, when Adobe produced an official build and digitally signed it, the Trojan would be built-in from the start.

That would, indeed, be very bad.

But I’m sure that Adobe is already industriously conducting a stricter-than-usual audit of all recent changes to its codebase, which ought to allow it either to find and remove any unauthorised changes, or to conclude that no such changes were made.

Note that open source products, where there is often much less control over who can introduce or propose changes, and where the code is already a matter of public record, face the problem of maliciously-minded changes all the time.

Although there have been some occasional failures in the open source community, they are rare.

Sneaking unwanted changes past experienced code maintainers using modern change management tools is harder than you might think.

Why doesn’t Adobe just make its products open source and have the last laugh at the crooks?

Cute idea.

But you’d have to convince the Adobe shareholders that it wouldn’t affect the value of Adobe’s business.

Also, there are almost certainly parts of the codebase that couldn’t easily be open-sourced, for example because they were licensed from a third party.

What if Adobe opened up the code to selected resesrchers, and threw in some tempting bug bounties?

Cute idea, and a good way to get some carefully-chosen “new eyes” that aren’t crooks to scrutinise the code.

If you’re asking because you’d like to have a crack at Adobe’s source code yourself, then I suggest you go straight to Adobe with that question.

Adobe’s Chief Security Officer might a bit busy right now, but I’m sure he won’t mind you asking, as long as you are polite (as well as genuine and serious about getting involved).

The worst he can say is, “No.”

Was the NSA behind this attack?

Cute idea.

You’ll have to ask the US government.

The worst it can say is, “No.”

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/SzWh0trrPW8/