Surprising software vulnerabilities or exploits?

Question

What are the most strange/sophisticated/surprising/deeply hidden software vulnerabilities or exploits you have ever seen? Places in code where you thought that there is no danger hidden, but were wrong?

[To clarify: Everybody knows SQL injections, XSS or buffer overflows - bugs which often result from careless coding. But things like Ken Thompson hidden trojan (Reflections on Trusting Trust: http://cm.bell-labs.com/who/ken/trust.html), recent NULL dereference vulnerability in Linux kernel (http://isc.sans.org/diary.html?storyid=6820), or a complex attack on RNG using denial of service (http://news.ycombinator.com/item?id=639976) have disturbed me greatly.]

Update: Thanks all for answers, they were great. I had hard choice. Ultimately I decided to award the bounty to side channel/power monitoring attack. Nevertheless, all your answers combined show that I have to learn more about security, since it's a really deep subject :).

Somehow related: Best real "computer crime"?

Answer 1

My favorite and most impressive I've seen so far are a class of cryptography techniques know as Side Channel Attacks.

One type of a side channel attack uses power monitoring. Encryption keys have been recovered from smart card devices by carefully analyzing how much power is drawn from the power supply. The processors embedded within them use different amounts of power to process different sets of instructions. Using this tiny bit of information, it's possible to recover protected data, completely passively.

Answer 2

Blue Pill Hypervisor rootkit.

Answer 3

My favourites are a class of rather particular attacks known as Format String Attack. They exploit the printf-like formatting tags to overwrite data in the stack. Some of them use obscure tokens like %n, which althought are quite rare to find, could be injected in the code if the programmer is careless enough to allow an unfiltered input to reach the format string.

Although apparently not dissimilar from buffer overflows, they carry instead additional complexity: in a buffer overflow, you simply overwrite the return address on the stack. With the Format String Attack, you have to carefully tailor your attack to be able to redirect the execution flow without causing a crash, so they are way more complex to design.

Another interesting attack is the off-by-one error. Again, it's not easy to exploit, but definitely doable.

Answer 4

I think a relatively recent Linux vulnerability qualifies for your description of exploiting code that seems safe (though a bit mistructured).

This was specifically the piece of code in the Linux kernel:

struct sock *sk = tun->sk;  // initialize sk with tun->sk
…
if (!tun)
    return POLLERR;  // if tun is NULL return error

Due to a GCC optimization, the if statement and body are removed (which is reasonable for userland code, not so much for kernel code). Through some cleverness a person was able to build an exploit out of this.

A summary:

http://isc.sans.org/diary.html?storyid=6820

A posted exploit:

http://lists.grok.org.uk/pipermail/full-disclosure/2009-July/069714.html

EDIT: Here is a much more in depth summary of how this code was exploited. It's a short read, but a very good explanation of the mechanisms used for the exploit.

http://lwn.net/SubscriberLink/342330/f66e8ace8a572bcb/

Answer 5

The "naivety" of humans never ceases to amaze me.

Answer 6

Who doesn't remember the Killer Poke (non-technical explanation): old Commodore 64's has slow video memory. Using a POKE, you can write a special value to an address in video memory -- this causes all kinds of voodoo, not least of which is changing the voltage of some of the circuits which has the fortunate consequence of causing the screen to update more quickly.

When Commodore updated their video hardware, the same poke command causes the voltage to go all types of screwy and fry the hardware. A software exploit can actually cause hardware damage. Awesome.

Answer 7

The second edition of The Shellcoder's Handbook: Discovering and Exploiting Security Holes is quite entertaining :

Examines where security holes come from, how to discover them, how hackers exploit them and take control of systems on a daily basis, and most importantly, how to close these security holes so they never occur again

Google Books

Answer 8

One of the least sophisticated attacks I've ever seen was one of the most effective. A tester I knew was working on testing a VB6 application under Win98. The application was built to open up in a fixed-size window. The tester, being clever, created a shortcut to the application, and set the shortcut to open the application maximised. When the app opened in a much larger size than the developer ever intended, it exposed a data control that would not normally be visible. By manually clicking on the data control, the tester managed to move to a record he should not have been able to view, and modify it...

Answer 9

I read about a clever way to steal your browser history just yesterday: By adding JavaScript that looks at the color of your links (they change color for sites which you visited).

This can be used to attack sites which add a security token the URL (if that token is not too long) by simply trying all possible combinations.

Answer 10

One month ago I was in a french IT security conference (SSTIC) where a guy explained why and how the current trusted computing architecture should not be trusted. How ? He showed us an "acpi backdoor" which gave him uid 0 (root privs) after unplugging/re-plugging a couple of times the electric cable of his laptop. It is possible to read the paper and the slides (in french, but I think that a google search on "loic duflot +acpi" should give some results in english): http://actes.sstic.org/SSTIC09/ACPI_et_routine_de_traitement_de_la_SMI/

Answer 11

Hyper-Threading vulnerability:

This flaw permits local information disclosure, including allowing an unprivileged user to steal an RSA private key being used on the same machine.

Answer 12

A couple of years ago, a PhD student at the VU in Amsterdam came up with viruses for RFID tags: http://www.rfidvirus.org/

Answer 13

Ok, this isn't a software vulnerability or exploit, but even so:

"Van Eck Phreaking is the process of eavesdropping on the contents of a CRT and LCD display by detecting its electromagnetic emissions." (From Wikipedia)

Just... wow...

Answer 14

Here's a one-line shell command that does a privilege escalation for OS X:

osascript -e 'tell app "ARDAgent" to do shell script "whoami"'

It isn't as easy as it looks, since you need a separate attack vector to access a user's shell, but it's a really cool payload.

I'm not sure this works any more, but I remember doing it on my mac at the time (with a simple copy, paste) and it happily reported 'root'.

Here's the slashdot article:

http://it.slashdot.org/article.pl?sid=08/06/18/1919224

Answer 15

Everyone does know about SQL injections, but one of the most surprising exploits I recently heard about was putting SQL injections into bar codes. Testers should be checking ALL inputs for malicious SQL. An attacker could show up at an event and crash their registration system, change prices at stores, etc. I think just bar code hacking in general was surprising to me. No wow factor here, just something else to be aware of.

EDIT: Just had a discussion where the idea of putting the SQL injection on a magnetic card strip was brought up. I guess you can put one anywhere, so test any and all input, especially from users and these kinds of data storage devices.

Answer 16

Cross Site Request Forgery.

I've considered it to be one of the most simple, yet devastating ones. Until CSRF arrived on the scene, web developers assumed, or rather trusted browsers to send requests generated by the user, but not anymore. A classic example of a confused deputy.

Answer 17

Years ago I took a look at a program (on the Acorn Archimedes) that was protected with a complex system of encryption (just to see how it was done and learn from it). It was very cleverly done, with the decryption code itself used as part of the decryption key so that any attempt to mess with it would break the decryption and thus leave you with garbage in memory.

After 2 days trying to work out how it was done and how you could get around it, a friend visited. Using an operating system tool (a click and a drag to max out the RMA memory allocaton) he limited the available RAM for the process to run in to just slightly larger than the .exe's size. Then he ran it. Immediately after decrypting itself it tried to allocate memory, failed, and crashed. He then saved the decrypted program from memory. Total crack time: about 2 minutes, using only a mouse drag and a command line save command.

I learned from this that it isn't worth putting too much time and effort into protecting your software - if someone wants to crack it they will, and probably they'll do it by a simple means that never occurred to you.

(Disclaimer: We had both bought legal copies of this program, and never used the cracked code in any way. It truly was just an intellectual programming exercise)

Answer 18

The cold boot attacks are perhaps more a hardware attack, but nevertheless very interesting and surprising.

They showed that you can read the content of ordinary RAM after a reboot. By cooling the chips to -50 °C with a canned air duster spray (not liquid nitrogen or anything like that) they found that less than 1% of the bits were flipped after 10 minutes without power(!)

This is a serious attack on all disk encryption programs. They must keep the decryption key in RAM and if you can reboot the machine, you can probably get access to the key. You might say that you wont let people reboot your machine like that, but think of stolen laptops in standby mode. They will wake up and present a screen saver asking for a password. At that time the disk encryption key is in RAM => a reboot later the key could be in the bad guy's possession...

They have videos and the very readable conference paper on their homepage.

Answer 19

Yes, yes, we all know about SQL Injection - and we all know how to protect against it, right?
Your application should be doing input validation, calling Stored Procedures, etc. etc.

But did you know that in certain situations, SQL Smuggling can easily bypass all that?
The most shocking thing about it, is that this is caused by a little-known, mostly undocumented, "feature" in some databases, frameworks, db objects etc. In short - the database (or plumbing on the way there) might do you the favor of happily - and silently - translating some unfamiliar character into some other! For example, Unicode character U+CABC might become a quote (U+0027), which you tried to block in your app, but unfortunately the DB decided to create and allow the attacker to again mount his SQLi attack straight through your defenses.

Yes, I published the linked article, but when I originally discovered this behavior I was shocked.

Answer 20

Another surprising and recent exploit is Clickjacking, which once again shows the inadequecy of our current model of what a Web browser is and should be. Easily bypasses most defenses against XSS, CSRF, etc, and allows a malicious website to "steal" control of your clicking, and misdirect them at a specific spot on another website - e.g. the "OK" button on the "Transfer Funds" page on your bank's site, or the Flash options dialog allowing the attacker to VIEW YOUR WEBCAM WITHOUT YOUR KNOWLEDGE!
Shocking, and brilliant...

Answer 21

Not really software but i'm sure it plays a part somewhere.

Recently it has been discovered that you can intercept and decode the electromagnetic radiation emitted from all keyboards, not just wireless variations. This can be used to create a remote keylogger.

http://lasecwww.epfl.ch/keyboard/

Answer 22

One is wondering all of the time, isn't one? This years "Can't be real ... but wow" have been parameter pollution and sniffing your history without using JavaScript.

I'll go for the latter one, because it is both astonishing simple (I think everybody will have this moment where he realises that he could have had this idea himself... nay should hav had.) and it uses the very browsers bandwidth optimisation that ensures that a background picture is only loaded when it's needed.

I do like it.

And it is not easily mitigated without breaking a few things. Actually I am wrong here, you might prevent "invisible" iframes in the browser. Don't know if anybody really want those.

Answer 23

On the "sophisticated" scale Dowd's attack on the ActionScript VM is second to none. See this write-up for an entertaining summary of the paper.

Answer 24

LWN.net had a post about the Cheddar Bay exploit through null pointers, which by itself is not dangerous, but through gcc code optimization it can execute unwanted code even if you've configured SElinux.

Also using javascript inejction in webpages through mitm attacks to create a keylogger(onkey(press/up/down) and post to a url is pretty out of the box thinking I guess.

Answer 25

A classic exploit was Ken Thompson's hack to give him root access to every Unix system on Earth.

Back when Bell Labs was the sole supplier of Unix, they distributed the source code so each installation could build and customize their own OS. This source included the Unix logon command. Ken modified the C compiler to recognize if it was compiling the logon command, and if so add an initial password check. This password was his own magic one and granted root access.

Of course anyone reading the C compiler source would see this and take it out. So Ken modified the C compiler again so that if it was compiling a C compiler it would put the logon hack back in.

Now comes the mindbending part; Ken compiled the C compiler with his hacked compiler, then deleted all trace of his hack, deleting it from the source, backups, source control, everything. It only existed in the compiled binary that was part of the Unix distro.

Anyone who got this Unix from Bell Labs got a hacked login and C compiler. If they looked at the source, it was safe. If they rebuilt the OS, the hacked compiler would hack the rebuilt compiler, which would re-insert the hack into the logon command.

The lesson I take from this is that you cannot guarantee security from any amount of static analysis (inspecting the source code, OS, applications).

Ken revealed this in an ACM article titled Reflections on Trusting Trust.

Answer 26

I thought the recent hack into a Twitter employee's email accounts was pretty scary.

Basically took advantage of an expired email account and the "forgotten password" recovery system of another account.

Answer 27

Read this, it will blow your mind (it certainly blew my mind!).

http://news.ycombinator.com/item?id=639976

One hacker broke the 'Hacker News' site by exploiting how the random cookie generation was not really random. A comment on the same thread gives a perfect description for the hack,

Thanks dfranke. All these years, whenever I thought of the true hacker, this is what I pictured at the back of my mind - material complex enough for me to take out my Stats and Liner Algebra books. Every other web hack attempt over the past decade has been XSS, bad passwords, and stupid form submission issues. Frankly, I had given up on the existence of true whitehat hackers till this post. Hats off to you Sir.

Some praise for the hacker:

Fellow hackers, take note. This is how you solve a problem! dfranke is Pandora, a rat in a maze, Sherlock Holmes, General Sherman, William Randolph Hearst, and your father all wrapped in one.

Like Pandora, he is so curious, he has to check this out.

Like a rat in a maze, he keeps going looking for the clear path.

Like Sherlock Holmes, he applies logic to determine the next step.

Like General Sherman, he keeps marching, building tools along the way as he needs them.

Like William Randolph Hearst, he defines the landscape. ("You provide the pictures, I'll provide the war.") "so I decided on a more proactive approach: crash it!" (hilarious)

And like any parent, he didn't quit until his baby walked.

Thank you, Daniel. I sure hope you've found a way to channel that talent in your day job.

Answer 28

Extremely simple method to mess with your web application: If the application allows users to add pictures to profiles, messages board or blog posts, malicious user can set up image URL like '/Account/LogOut' (or any other valid local URL causing actions we don't want). If he manage to publish his profile/post/message "up to main page" - every user will be logged out immediately after logging in (the browser will execute te request to /Account/LogOut in context of the current user in order to download the image), so the page functionality will by serously damaged.