Apparently a rogue IT administrator decided to leave an Easter egg (or "time bomb" or "logic bomb" or whatever you prefer) within the Fannie Mae server network designed to wipe 4,000 servers on 31st January 2009.
He appears to have created the "Server Graveyard" Easter egg after being dismissed on October 24th last year - but before his system access permissions were revoked later that evening.
The Easter egg was at least discovered a few days later - but it goes to show how much damage a disgruntled IT administrator can do if they set their minds to it, along with the fact that if you're going to let go of an IT administrator (or user with a high level of system access) you'd better be prepared to lock out all his accounts while he's in the room being told by his manager he's fired and to escort them out of the building immediately afterwards.
Larry Dignan over at ZDNet has a good blog about the case (Fannie Mae IT contractor indicted for planting malware; Mortgage giant didn’t revoke server privileges).
Thursday, January 29, 2009
Monday, January 26, 2009
Attack Coordination Using Social Networking Sites
With little doubt, the fastest growing and most influential Web 2.0 technology has been that of the Social Networking site. Sure, the concepts have been around for quite some time - harking back to the first dial-up BBS' of the 1980's - but the growth of sites like Facebook and MySpace is unheralded. The amount of time people now spend "Social Networking" has even overtaken the quest for porn (see the BBC's "Porn putting on its Sunday best").
Now, if you combine the facilities of social networking sites to coordinate large groups of people incensed by another group with tools that enable members to "donate some of their computers bandwidth", you can quickly develop massive "opt-in" DDoS systems.
The first component - the groups of incensed and motivated members - are already out there. Just look at the Facebook groups that sprung up backing either Israel or Hamas in the most recent conflict, or older groups such as the animal cruelty activists like "Stop Huntingdon Life Sciences Animal Cruelty".
The future of Social Network initiated/coordinated DDoS attacks is just around the corner (if it hasn't already happened in less-than-newsworthy cases already). Welcome to the birth of SDoS - Social network Denial of Service.
I posted a longer blog on the topic, along with the tools available to activist and social conscience groups - and some future threat motivations up on the IBM Frequency-X Web site.
Take a gander at "Social Network Denial of Service (SDoS)?" for more thoughts and analysis.
Now, if you combine the facilities of social networking sites to coordinate large groups of people incensed by another group with tools that enable members to "donate some of their computers bandwidth", you can quickly develop massive "opt-in" DDoS systems.
The first component - the groups of incensed and motivated members - are already out there. Just look at the Facebook groups that sprung up backing either Israel or Hamas in the most recent conflict, or older groups such as the animal cruelty activists like "Stop Huntingdon Life Sciences Animal Cruelty".
The future of Social Network initiated/coordinated DDoS attacks is just around the corner (if it hasn't already happened in less-than-newsworthy cases already). Welcome to the birth of SDoS - Social network Denial of Service.
I posted a longer blog on the topic, along with the tools available to activist and social conscience groups - and some future threat motivations up on the IBM Frequency-X Web site.
Take a gander at "Social Network Denial of Service (SDoS)?" for more thoughts and analysis.
Friday, January 23, 2009
Firefox Update Dynamics
Last year, along with Stefan Frei, Thomas Duebendorfer and Martin May, we published the well-received paper "Understanding the Web Browser Threat" - which looked at how the various update mechanisms of the most popular Web browsers compared, and derived the minimum estimates of how many Web browsers constantly failed to apply the latest security patches - based upon analysis of Google USER-AGENT data.
Well, as a follow up to that research, a new paper has just been published in the January edition of ACM SIGCOMM Computer Communication Review. The paper, titled "Firefox (In)Security Update Dynamics Exposed", takes a much deeper look at how Firefox is updated (for real) by Internet users.
There are many very interesting findings to be found in the paper, but I wanted to share some of the things I found most interesting from the research.
Weekend Usage
When you take a closer look at the frequency at which a particular Web browser version is used during the week, you can see a noticeable pattern that revolves around weekend usage patterns.
For example:
Here we see the usage pattern of Internet Explorer versions 6 and 7 over a year. Clearly, IE7 grows in popularity over IE6 and, by early 2008 becomes the most popular IE version in regular use.
But, looking closely at the fluctuations you'll notice something very interesting - IE7 grows in popularity over the weekends.
What this most likely means is that the newer version of IE is probably in greater use by home users. Meanwhile corporates, with greater restrictions on patch/update rollouts have stuck with IE6 for longer periods. Therefore you see IE6 getting greater use during the working week, and IE7 over the weekends.
Oddly enough, the same pattern can be seen with the latest versions of Firefox.
So, once again, we see the most recent version of a Web browser getting more use over the weekend.
The new paper also explores the effect on Safari and Opera Web browsers too.
Applying Updates
Another interesting aspect to the research is the dynamics behind the pace at which updates to the respective Web browsers are applied. By examining the minor version information contained within the USER-AGENT data, the authors were able to observe how quickly(?) users applied public patches.
For example, the graphs above show this pace of patch application and the percentage of Firefox/Opera browser users using the most current (and secure) versions.
Rest of the Paper
There is of course a lot more information contained within the paper and I'd whole heartedly recommend that any security professionals out there take some time out of the day to read it.
I think it raises the interesting angle on the dynamics of weekday vs weekend drive-by-download attacks. Going purely off the numbers, I'd be inclined to say that users are "safer" conducting their Internet browsing when they're away from work. So, if you have need of checking out your online bank balances throughout the day - wait until the weekend?
Unfortunately the BIG unknown are the plug-in's - which I suspect are a bigger problem for home users... which probably more than negates the previous paragraph.
Well, as a follow up to that research, a new paper has just been published in the January edition of ACM SIGCOMM Computer Communication Review. The paper, titled "Firefox (In)Security Update Dynamics Exposed", takes a much deeper look at how Firefox is updated (for real) by Internet users.
There are many very interesting findings to be found in the paper, but I wanted to share some of the things I found most interesting from the research.
Weekend Usage
When you take a closer look at the frequency at which a particular Web browser version is used during the week, you can see a noticeable pattern that revolves around weekend usage patterns.
For example:
Here we see the usage pattern of Internet Explorer versions 6 and 7 over a year. Clearly, IE7 grows in popularity over IE6 and, by early 2008 becomes the most popular IE version in regular use.
But, looking closely at the fluctuations you'll notice something very interesting - IE7 grows in popularity over the weekends.
What this most likely means is that the newer version of IE is probably in greater use by home users. Meanwhile corporates, with greater restrictions on patch/update rollouts have stuck with IE6 for longer periods. Therefore you see IE6 getting greater use during the working week, and IE7 over the weekends.
Oddly enough, the same pattern can be seen with the latest versions of Firefox.
So, once again, we see the most recent version of a Web browser getting more use over the weekend.
The new paper also explores the effect on Safari and Opera Web browsers too.
Applying Updates
Another interesting aspect to the research is the dynamics behind the pace at which updates to the respective Web browsers are applied. By examining the minor version information contained within the USER-AGENT data, the authors were able to observe how quickly(?) users applied public patches.
For example, the graphs above show this pace of patch application and the percentage of Firefox/Opera browser users using the most current (and secure) versions.
Rest of the Paper
There is of course a lot more information contained within the paper and I'd whole heartedly recommend that any security professionals out there take some time out of the day to read it.
I think it raises the interesting angle on the dynamics of weekday vs weekend drive-by-download attacks. Going purely off the numbers, I'd be inclined to say that users are "safer" conducting their Internet browsing when they're away from work. So, if you have need of checking out your online bank balances throughout the day - wait until the weekend?
Unfortunately the BIG unknown are the plug-in's - which I suspect are a bigger problem for home users... which probably more than negates the previous paragraph.
Tuesday, January 20, 2009
100 million transactions per month - largest data breach ever?
I don't normally cross-post, but I'm delving in to the Heartland Payment Systems data breach. With over 100 million transactions processed monthly (apparently), and the fact that the malware appears to have been sniffer-based, this will likely be the biggest data breach so far.
Credit to Heartland for dealing with it so well thus far (except maybe the possible obfuscation factor of waiting until Obama-day to release it).
I wrote a blog about the breach on Frequency-X earlier today -- Largest Data Breach So Far? Heartland Payment Systems.
The Washington Post has more background here (I wish I'd found it before I posted to Frequency-X...)
Credit to Heartland for dealing with it so well thus far (except maybe the possible obfuscation factor of waiting until Obama-day to release it).
I wrote a blog about the breach on Frequency-X earlier today -- Largest Data Breach So Far? Heartland Payment Systems.
The Washington Post has more background here (I wish I'd found it before I posted to Frequency-X...)
Wednesday, January 14, 2009
"In-session Phishing" Vector
This morning I came across a couple of news stories concerning a new phishing vector referred to as "in-session phishing", which basically relates to the use of counterfeit popup windows that explain that your current online banking session has expired, and that you should type in your credentials to carry on.
This vector is defined in the advisory published by Trusteer dated December 29th.
When I first read the Dark Reading story ("New Phishing Attack Targets Online Banking Sessions with Phony Popups", I was thinking "wow, interesting attack vector, I wonder why the phishers went down that route?", then as I re-read the story I came to realize that it's not an attack circulating in the wild, but the one postulated by Trusteer.
So, whats the problem? Well, sure, this type of theoretical attack is possible - all the building blocks exist - and it would be easy enough to socially engineer victims in to believing that it was a legitimate popup and steal their banking login credentials, but I don't think we're going to see this technique added to the phishers arsenal or widely adopted (if ever).
Why? Mainly because there are easier vectors for attack. If you've gone to the trouble of either compromising a Web site or built a fake one from scratch, and managed to set up all your scripts etc. then you might as well go the full hog and exploit the victims Web browser and install a full banking Trojan. Just stealing the users banking login credentials has practically no value today.
Yes, if the phisher used "in-session phishing" to harvest your login credentials they could probably access your account and view balances etc. but it's a wholly different thing to instigate and validate a funds transfer. This is why the bad guys rely upon drive-by-download vectors to install malware on hosts and use specialized banking Trojan malware.
So, if you extract all the media hype, this "threat" isn't really a threat we're going to have to worry about. And besides, there's several other mitigating technologies for this vector.
Perhaps it was a slow news day yesterday in the lead-up to Microsoft's patch release.
This vector is defined in the advisory published by Trusteer dated December 29th.
When I first read the Dark Reading story ("New Phishing Attack Targets Online Banking Sessions with Phony Popups", I was thinking "wow, interesting attack vector, I wonder why the phishers went down that route?", then as I re-read the story I came to realize that it's not an attack circulating in the wild, but the one postulated by Trusteer.
So, whats the problem? Well, sure, this type of theoretical attack is possible - all the building blocks exist - and it would be easy enough to socially engineer victims in to believing that it was a legitimate popup and steal their banking login credentials, but I don't think we're going to see this technique added to the phishers arsenal or widely adopted (if ever).
Why? Mainly because there are easier vectors for attack. If you've gone to the trouble of either compromising a Web site or built a fake one from scratch, and managed to set up all your scripts etc. then you might as well go the full hog and exploit the victims Web browser and install a full banking Trojan. Just stealing the users banking login credentials has practically no value today.
Yes, if the phisher used "in-session phishing" to harvest your login credentials they could probably access your account and view balances etc. but it's a wholly different thing to instigate and validate a funds transfer. This is why the bad guys rely upon drive-by-download vectors to install malware on hosts and use specialized banking Trojan malware.
So, if you extract all the media hype, this "threat" isn't really a threat we're going to have to worry about. And besides, there's several other mitigating technologies for this vector.
Perhaps it was a slow news day yesterday in the lead-up to Microsoft's patch release.
Friday, January 9, 2009
The Week that Was... Full of Predictions
It's Friday evening and the end of the "Week of (everyone else's) 2009 Security Predictions".
It could have gone on for longer, stretching beyond a month, but it's pretty surprising just how many vendors "predict" the same thing and how many of those predictions were as predictable as the morning sunrise. To a large extent, most of the predictions can be summed up as "more of the same".
To recap upon the week, I looked at security predictions from the following...
Day 1 - Cisco
Day 2 - MessageLabs
Day 3 - PandaLabs
Day 4 - Websense
Day 5 - Dark Reading
...and they weren't as terrible as many thought. Obviously, there were several that could be encapsulated in the term FUD, but the majority of the predictions were extensions of common security trends that we've all be observing for several years.
It was an interesting experience, and the feedback I received from most of the readers was generally good - but I apparently upset a handful of Cisco followers. Oh well, that's the problem with opinions - everyone has one.
It'll be interesting to see how these predictions stack up at the end of the year.
It could have gone on for longer, stretching beyond a month, but it's pretty surprising just how many vendors "predict" the same thing and how many of those predictions were as predictable as the morning sunrise. To a large extent, most of the predictions can be summed up as "more of the same".
To recap upon the week, I looked at security predictions from the following...
Day 1 - Cisco
Day 2 - MessageLabs
Day 3 - PandaLabs
Day 4 - Websense
Day 5 - Dark Reading
...and they weren't as terrible as many thought. Obviously, there were several that could be encapsulated in the term FUD, but the majority of the predictions were extensions of common security trends that we've all be observing for several years.
It was an interesting experience, and the feedback I received from most of the readers was generally good - but I apparently upset a handful of Cisco followers. Oh well, that's the problem with opinions - everyone has one.
It'll be interesting to see how these predictions stack up at the end of the year.
Tuesday, January 6, 2009
Marching Orders on how to Counter-Blog
Wired has a neat story about the US Air Force's new counter-blogging strategy. The "Air Force Releases 'Counter-Blog' Marching Orders" article has a really interesting flow chart depicting how US Air Force personnel should consider their blogging responses to blogs that mention the service in a disparaging way.
I can think of several commercial organizations that may want to adopt a similar framework for their employees to follow - instead of these past sneaky and thinly-veiled responses by their corporate denizens ranting on behalf of their company.
Oh yeah, that should extend to their "marketing" teams as well.
I can think of several commercial organizations that may want to adopt a similar framework for their employees to follow - instead of these past sneaky and thinly-veiled responses by their corporate denizens ranting on behalf of their company.
Oh yeah, that should extend to their "marketing" teams as well.
Monday, January 5, 2009
Encouraging the UK police to hack a little more often
Apparently the UK Home Office is going to be encouraging the British bobby to do a little more hacking against those big bad cybercriminals out there - according to the BBC news.
With the prospect of hacker-bobby knocking on your virtual door, you just know that someone'll complain about the breach of privacy etc. Oh well, it'll be interesting to see if the police take up the hacking challenge. If not, I'm sure these no shortage of willing volunteers.
One other quick note about the BBS news article. I'm not sure who Professor Peter Sommer is, but I'm not sure about the following statement...
Here's a proposition to the police officers that are worried about being detected by anti-virus - buy the same software the organized criminal teams are using.
In a statement regarding the agreement, the Council stated that "the new strategy encourages [the police and the private sector] to…resort to remote searches."I'm not sure exactly what the Council thinks the "private sector" encompasses, but wouldn't it be rather jolly if that included commercial penetration testing teams? (obviously not including commercial criminal hacking-as-a-service providers) I'd love to take a legal crack at the multitude of known criminal sites out there, and so would just about every professional pentester I know.
British law already allows police to remotely access computers under the Regulation of Investigatory Powers Act 2000, which allows surveillance to "prevent or detect serious crime".
With the prospect of hacker-bobby knocking on your virtual door, you just know that someone'll complain about the breach of privacy etc. Oh well, it'll be interesting to see if the police take up the hacking challenge. If not, I'm sure these no shortage of willing volunteers.
One other quick note about the BBS news article. I'm not sure who Professor Peter Sommer is, but I'm not sure about the following statement...
Most anti-virus programs and firewalls will detect surveillance attempts because they are designed to stop the remote access software or Trojan-type viruses that hackers - even police hackers - usually use, he explained.As far as I'm aware most of the professional malware out there in use today by the real criminals is a generation or two more advanced that the anti-virus solutions in popular use. And, strangely enough, that very-same malware the criminals are using can be purchased by anyone willing to fork over a few hundred dollars to a hacking-as-a-service provider in Russia, Korea, Turkey, Brazil, etc. so I don't think that's an inhibitor.
Here's a proposition to the police officers that are worried about being detected by anti-virus - buy the same software the organized criminal teams are using.
Labels:
BBC,
cybercrime,
hacking,
malware,
security
Week of (not my) Security Predictions for 2009
For a bit of fun I'm taking a look at the multitude of "2009 Security Predictions" which all the key security vendors and magazines have been pumping out over the last month and picking at them a little.
To make it a little more exciting I'm calling it the "Week of (someone else's) Security Predictions 2009". I've posted the first blog today, and I'll continue throughout the week - short of being hit by a bus or the X-Force blog crashing (again).
You can find the first days entry on Frequency X, where I've picked on Cisco's rather lame and unimaginative predictions (as newbies on the block, I guess they're just playing it safe).
To make it a little more exciting I'm calling it the "Week of (someone else's) Security Predictions 2009". I've posted the first blog today, and I'll continue throughout the week - short of being hit by a bus or the X-Force blog crashing (again).
You can find the first days entry on Frequency X, where I've picked on Cisco's rather lame and unimaginative predictions (as newbies on the block, I guess they're just playing it safe).
Labels:
2009,
Cisco,
Frequency X,
IBM,
ISS,
predictions,
security
Friday, January 2, 2009
Software [In]security: Software Security Top 10 Surprises
InformIT has an interesting post relating to the top-10 security software surprises they encountered in their interviews for a piece on maturity models (I look forward to reading that one when it comes out).
Here's their list (summarized):
Now, probably because I'm coming from a security practitioners and consulting perspective, I'd didn't find them overly surprising - but at least they did some real interviews and have stats to back up their findings (which is great).
The most noteworthy "surprises" were (7) and (1), and I figured I'd briefly comment on those ones.
(7) I remember when vendors were first going around to their clients touting Web Application Firewall (WAF) technology back at the start of the millennium, and the trouble my clients had in understanding why their WAF hadn't stopped us during the penetration test. Within a year, most of the major client organizations had shelved their WAF's and become rather hostile to anyone that saught to sell them a new flavor of WAF. Over the last year or so, I've seen several organizations take a fresh look at the WAF technologies and redeploy smarter varients basically as IDS solutions tuned to a particular Web application they want to observe.
I think that most of the valuable security components of WAF's (such as the selective whitelisting and SQL/XSS Injection protection) have now been absorbed in to the standard commercial IPS boxes out there - i.e. WAF is (already) becoming a feature of IPS.
(1) While their analysis found that most organizations make use of external penetration testing consulting, they concluded that the role of pentesting is decreasing. In one sense I agree, yet in another I don't.
As major corporations have developed and matured their SDLC processes and adopted the use of standard automated testing tools (fuzzers and vulnerability scanners), they are catching many of the bugs that used to fill up the final reports issued by the external penetration testing companies. So, in that sense, I'd say that the role (and value) of traditional (i.e. "classical") pentesting has decreased in value.
However, the field of application security is particularly dynamic, and many of the major pentesting companies have become more boutique in their offerings and offer niche services that compliment an advanced SDLC strategy. So, in that context I'd say that the role of pentesting has increased.
Here's their list (summarized):
9. Not only are there are no magic software security metrics, bad metrics actually hurt.My Perspective?
8. Secure-by-default frameworks can be very helpful, especially if they are presented as middleware classes (but watch out for an over focus on security "stuff").
7. Web application firewalls are not in wide use, especially not as Web application firewalls.
6. Involving QA in software security is non-trivial... Even the "simple" black box Web testing tools are too hard to use.
5. Though software security often seems to fit an audit role rather naturally, many successful programs evangelize (and provide software security resources) rather than audit even in regulated industries.
4. Architecture analysis is just as hard as we thought, and maybe harder.
3. Security researchers, consultants and the press care way more about the who/what/how of attacks than practitioners do.
2. All nine programs we talked to have in-house training curricula, and training is considered the most important software security practice in the two most mature (by any measure) software security initiatives we interviewed.
1. Though all of the organizations we talked to do some kind of penetration testing, the role of penetration testing in all nine practices is diminishing over time.
0. Fuzz testing is widespread.
Now, probably because I'm coming from a security practitioners and consulting perspective, I'd didn't find them overly surprising - but at least they did some real interviews and have stats to back up their findings (which is great).
The most noteworthy "surprises" were (7) and (1), and I figured I'd briefly comment on those ones.
(7) I remember when vendors were first going around to their clients touting Web Application Firewall (WAF) technology back at the start of the millennium, and the trouble my clients had in understanding why their WAF hadn't stopped us during the penetration test. Within a year, most of the major client organizations had shelved their WAF's and become rather hostile to anyone that saught to sell them a new flavor of WAF. Over the last year or so, I've seen several organizations take a fresh look at the WAF technologies and redeploy smarter varients basically as IDS solutions tuned to a particular Web application they want to observe.
I think that most of the valuable security components of WAF's (such as the selective whitelisting and SQL/XSS Injection protection) have now been absorbed in to the standard commercial IPS boxes out there - i.e. WAF is (already) becoming a feature of IPS.
(1) While their analysis found that most organizations make use of external penetration testing consulting, they concluded that the role of pentesting is decreasing. In one sense I agree, yet in another I don't.
As major corporations have developed and matured their SDLC processes and adopted the use of standard automated testing tools (fuzzers and vulnerability scanners), they are catching many of the bugs that used to fill up the final reports issued by the external penetration testing companies. So, in that sense, I'd say that the role (and value) of traditional (i.e. "classical") pentesting has decreased in value.
However, the field of application security is particularly dynamic, and many of the major pentesting companies have become more boutique in their offerings and offer niche services that compliment an advanced SDLC strategy. So, in that context I'd say that the role of pentesting has increased.
Subscribe to:
Posts (Atom)