Schneier on Security
A blog covering security and security technology.
« Apple Turns on iPhone Tracking in iOS6 |
| Genetic Privacy »
October 16, 2012
Studying Zero-Day Attacks
Interesting paper: "Before We Knew It: An Empirical Study of Zero-Day Attacks In The Real World," by Leyla Bilge and Tudor Dumitras:
Abstract: Little is known about the duration and prevalence of zeroday attacks, which exploit vulnerabilities that have not been disclosed publicly. Knowledge of new vulnerabilities gives cyber criminals a free pass to attack any target of their choosing, while remaining undetected. Unfortunately, these serious threats are difficult to analyze, because, in general, data is not available until after an attack is discovered. Moreover, zero-day attacks are rare events that are unlikely to be observed in honeypots or in lab experiments.
In this paper, we describe a method for automatically identifying zero-day attacks from field-gathered data that records when benign and malicious binaries are downloaded on 11 million real hosts around the world. Searching this data set for malicious files that exploit known vulnerabilities indicates which files appeared on the Internet before the corresponding vulnerabilities were disclosed. We identify 18 vulnerabilities exploited before disclosure, of which 11 were not previously known to have been employed in zero-day attacks. We also find that a typical zero-day attack lasts 312 days on average and that, after vulnerabilities are disclosed publicly, the volume of attacks exploiting them increases by up to 5 orders of magnitude.
Posted on October 16, 2012 at 6:12 AM
• 16 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
"We also find that a typical zero-day attack lasts 312 days on average and that, after vulnerabilities are disclosed publicly, the volume of attacks exploiting them increases by up to 5 orders of magnitude."
Not unexpected, but still sobering statistics.
All operating systems are completely vulnerable, all of the time.
This is because all have multiple zero-day remotely execution and escalation of privilege vulnerabilities, all of the time.
That is an uninteresting remark.
In the same way, everyone can get infected with a biological bacterium or virus at any time and everywhere. Still, we are able to stay healthy quite well.
Despair does not help much. Prevention does help.
Well the comment,
Moreover, zero-day attacks are rare events that are unlikely to be observed in honeypots or in lab experiments. honeypots or lab experiments
Well zero-day are not that rare in that we tend to get more than a couple a year, and probably a lot more.
However there is a quite good reason why you don't tend to spot them in Honeypots/nets, which I've mentioned before.
If people tthink back a few years a PhD thesis by a UK Camb Lab student showed how by using TCP time stamp changes you could correlate it's various host addresses due to the fact the motherboard XTAL driving the cpu(s) was common to them and had a unique change in frequency against time. So the time stamps from each host interface could be quite easily correlated with each other.
Whilst the PhD showed how this could be used to identify comms with a host across various different routes it failed to point out a much more usefull attack.
It allowed the likes of Honeynets constructed using the likes of VMware to be fairly easily identified with what looked like a brain dead script kiddy attack.
IN other words, just like in real world LE, no one knows about the new crime / attack until a victim speaks upm somebody notices something curious is happening, or someone gets caught doing it... WOW, AMAZING, SUCH INSIGHT!!!
@Bruce, @ Moderator:
OT comment for Bruce.
Praise for Twofish:
as you read you find this:
The SPE / miniFlame backdoor:
The main purpose of miniFlame is to act as a backdoor on infected systems, allowing direct control by the attackers.
The following commands are understood by the malware:
All the commands are issued through the C&C server and are encrypted with a basic XOR of 10 bytes and an additional layer of Twofish encryption.
@Clive: Would the analysis of XTAL-driven clock drift be feasible in an environment where a clock sync utility like NTP was in use? Or does the drift become measurable sooner than the clock-sync correction occurs?
I think what Clive is saying is that a honey pot network will run in a bunch of VMs on one single machine. Thus, all packages arriving from this network will show a very strong correlation in the drift of the timestamps, whereas a real network would show no correlation. As an time update via NTP can be seen just as another drift, it won't change the observation.
This may be the paper: "Remote physical device fingerprinting" T. Kohno, A. Broido, and K. Claffy IEEE Transactions on Dependable and Secure Computing, vol. 2, no. 2, pp. 93--108, May 2005
If I remember correctly, the device fingerprinting method works on TCP sequence numbers, which on a number of operating systems is based on clock-cycles, not on the RTC.
But I think you are forgetting the most important reason why most 0-day exploits are not seen on honeypots: honeypots impersonate passive server systems or maybe a badly configured Windows client, they do not usually browse the Internet and access unsafe web pages.
You touch on an interesting point. The people who configure sophisticated honeypots use levels of usage and access availability in their virtual environment. A Honeypot environment will span several IPs with different nodes having a different level of patched software.
They try to emulate legacy servers with older control software that have some nodes connected via unsecure connection, a couple of terminals with various access levels, and administrator connection and so on.
When a honeypot environment gets fielded, (depending on who is doing the fielding) the environment will start connecting to internet nodes depending on the intended testing areas. For example: A honeypot set up to catch banking attackers will ping finance related websites like a bank server would with maybe a couple of nodes that ping random IPs to emulate bank employees' usage. Bank servers do not usually "surf" the internet.
Honeypot environments can be configured to look like any business, government, university or personal network.
The real problem is that Honeypots have no connection history or a freakish one. These days, with static IPs, when a University server starts acting like an airport or a mortgage bank it looks obvious to most sophisticated attackers. To combat this, the honeypots need to be hosted by the relevant institution or spoof their IP. I have also seen honeypots that grow slowly and organically with different levels added over time.
... which on a number of operating systems is based on clock-cycles, not on the RTC
As far as I'm aware all major OS's use the CPU XTAL not the RTC XTAL (32Khz Beta cut watch crystal). Which has a direct relationship to CPU cycles. Also I actualy said,
due to the fact the motherboard XTAL driving the cpu(s) was common to them and had a unique change in frequency against time
I'm sorry if you thought I ment the RTC I did not.
@ John Hardin,
Would the analysis of XTAL-driven clock drift be feasible in an environment where a clock sync utility like NTP was in use.
Yes and no it depends very much on the external refrence and how it's applied at both ends (ie your measuring system and the remote multi host interface system) and if it's hardware or software corrected. Do it wrong at your measurment end and the results are meaningless, if done badly at the remote end it makes your job easier due to the more visable artifacts on the Delta F traces.
I have the advantage of having a system at my disposal that has an external hardware refrence (ie an atomic lamp which phase locks a VXCO) that replaced the motherboard XTAL entirely (in normal use the system is actually the controler in a specialised radio receiver / test set).
If you think about what you are looking to measure is the Delta F between your local clock measurment of the timestamp roll over on all the host interfaces, then cross correlate them to decide if they have the same master clock. On a single system they all roll over with the same time interval +- a very small fraction of the drift rate between your timer and the remote system timer (on some VM's they all roll over together which makes life easier). Normal drift is a slow linear process and the divergance can be seen as a straight line on a graph and the inclination of this line is what produces the fingerprint.
Now if someone uses a software corrector of the internal time it can exhibit a course sawtooth which can be seen as a result of the accumulated error of the drift rate, which when averaged looks like a sinewave at the difference frequency. Better software clock correctors actually implement the equivalent of a PLL, which if correctly setup produces what looks like a low frequency sine wave error function. In both cases this "difference frequency" sine wave can cause some strange side effects in certain applications. But as indicated it produces not a straight line but a straight line modulated by the correction effects (which usually makes the fingerprinting job easier)
Which is partly the reason the ones I've developed actually use a long sequence random generator to jitter the timing edge and then put the result through a twenty tap or more lowpass filter. The reason for this is to remove certain side effects that cause issues in RF and Audio measurement (think sub harmonic sampaling). You could (at a squint) view it as a Delta-Sigma loop system.
Oh and enumerating honeynets actually was in my view a minor uses of the time stamp technique by attackers. A more obvious one would be to work out which VM's shared the same hardware in a co-host situation. That is if two otherwise entirely seperate web sites ran on the same hardware it might be possible to use errors in one site to get at another site in some way (basicaly exploit weaknesses in the VM issolation).
@Clive, @735: Ah, yes, I didn't think of it being used to identify VMs per host. That does make a lot of sense. Thanks!
I find the discussions about enumerating Honeypots interesting because it does seem to assume that Zero days are almost exclusively found by the most skilled of hackers (or more probably state / criminally supported orgs ). Since zero day are so difficult to find, it raises the question, in my mind at least, How many of these zero days were really errors (or sloppy coding, whatever) vs intentional errors added to support the ongoing need for zero days?
Come on, Dumitras, those document properties don´t update themselves!
I absolutely agree with you, that's why they need to privately address the involved parties and patch it before openly announcing it.
That is an uninteresting remark...
Especially are there are tools like MS's EMET (Enhanced Mitigation Experience Toolkit) which blocks the vast majority of 0-days...
I finally discovered and loaded it's All.XML comensurate with the last IE 0-day before the patch came out...
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.