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"?

+5  A: 
James D
+1 for 'real-time retinal scan'
I was gonna +1, but the default outer glow really ruined it for me :(
Adobe Photoshop just makes it so easy...too easy...
James D
I have never understood this one. So being able to modify ("inject") the security provider code is a security vulnerability. How is that a surprise to anyone? What am I missing here?
I think people are upvoting a nice picture. As RBarryYoung said, being able to injecting code means game over, its hardly surprising, and its not a vulnerability its creative coding! Anyway, you would need some kind of pre existing vulnerability to be able to exploit something in this fashion. This is more like a payload.
Awww - pretty! This is why you should always key-sign/checksum SECURITY_PROVIDER.dll
Though this presents a simplistic (but pretty) picture, it is actually representative of a well-known technique called Luring Attacks. The missing bit of the puzzle here is that SECURITYPROVIDER.DLL may be on your desktop... and other applications may have shared access to it. Or maybe there is some kind of (non-secure) configuration file that dynamically points to files to load. Or maybe it is supposed to recieve a parameter that will point it to the internal DAL dll - and you can replace that. Point is, yes! - if I can get your code to run MY code, its not your code anymore...
+22  A: 

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.

Mark Renouf
Wow - that's scary! How are you meant to prevent that??
Among other things: Reverse optimisation. Take those hardware designers who've spent years figuring out how to get a function with least transistors, least power, most quickly, and put them in a new frame of mind where consistency is everything. If the device consistently takes 100ms to do a transaction and eats battery at a constant 150mW when running - then the side channel attack fails, and the customer may be willing to eat the increased hardware cost and reduced battery life for that benefit.
Depends on the encryption techniques of course. It's much better to use assymetric encryption where the key itself can be compromised without affecting your system.
This is sick nasty
Indeed an impressive attack... But for those wondering how to go about protecting themselves against this type of attack, I have a different answer - you don't. Not that you *can't*, but rather that you *shouldn't*. As in, don't bother - unless you're the CIA/DoD/NSA, or a parallel organization in that league - this is not often a serious threat, the cost of mounting an effective exploit with this is just too high, too problematic, and too much junk. Home users REALLY dont need to worry about this (unless you're Warren Buffet), and its even a bit too high for most common corporate espionage.
Definitely crazy, but is it a SOFTWARE vulnerability?
@TM Good point. Gray area I'd say. The software will get exploited, but the attack vector is hardware. It's a little of both. I recently started getting more involved with microprocessors and it's interesting some point to their "most instructions execute in a single cycle" as a strength against this type of attack as well. It's a little beyond me to extrapolate the meaning but it makes sense to me.
Mark Renouf
The most impressive application of side-channel attacks IMHO is the *AES cache timing attacks* http://cr.yp.to/antiforgery/cachetiming-20050414.pdf . Basically, the attacker measures how long it takes to decrypt certain sequences, measuring the response latency variations -- due to CPU caching -- over a network. This allows him to extract the key from the cipher.
+8  A: 

Blue Pill Hypervisor rootkit.

Jared Oberhaus
Agree +1. Advanced rootkitting stuff is like taking the red pill in the Matrix.
James D
Provided you have access to a realtime clock you can* detect that your os is having cycles stolen by the hypervisor. About the only way that you could deal with this is to have a root antivirus running in the hypervisor as well.
Could also be stolen by System Management Mode (SMM).
+2  A: 

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.

Stefano Borini
why the -1 ?.....
Stefano Borini
+12  A: 

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:


A posted exploit:


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.


+4  A: 

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

nice article ...
+3  A: 

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.

Yes, I remember you could use it to have the cursor blink faster, but it was just because yu had higher refresh.
Stefano Borini
On the MSX microcomputer you had a relais to enable / disable the cassette player. In BASIC, you could switch it on and off and have fun. When you knew assembly, you could switch it so fast that the relais could break. Always fun to run at a local RadioShack :)
Rutger Nijlunsing
That happened on the TRS-80 Model II, also - you could poke a value that would destroy the CRT. Radio Shack changed the POKE command so you couldn't do that from BASIC, but it wasn't at all difficult to call a machine-language subroutine.
David Thornley
Killer POKE was Commodore PET, not 64, right?
TRS-80 killer POKE was Model III, not II. You people are killing me!
there was a similar exploit for a matrox video card once.. one could reach in and boost the clock speed to values much higher than the heat spreader could handle !! This was before the overclocking fad started.

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

+6  A: 

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...

Lol @ whoever made that app (then again it was coded in VB6)
Not to be a pain in the derriere, but it sounds like this app would connect directly to the DB - in which case, the user would already have much more access than the programmer intended, since he could just connect to the DB himself!
Assuming the user knew the username and password embedded in the application, then yes...
+8  A: 

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.

Aaron Digulla
Mark Renouf
+2  A: 

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/

+1  A: 

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.

Jared Oberhaus
Nice; not that this is an example of a side channel attack, as described in Mark Renouf's post.
+2  A: 

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

+7  A: 

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...

Cosmic Flame
+2  A: 

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:


Jeremy Powell
+19  A: 

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.

This of course reminds me of the classic http://xkcd.com/327/
+3  A: 

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.

Vineet Reynolds
+8  A: 

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)

Jason Williams
+6  A: 

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.

Martin Geisler
+7  A: 

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.

"It is commonly accepted that strong input validation can prevent SQL Injection attacks." - WRONG - as pointed out in your article it's fruitless to try and sanitize input - the best practice today is to use parametrized queries only.
Well, yes, of course, but it's still common practice to rely on input validation alone - and until recently, it was possible to *apparently* block attacks in this manner, bad practice or no.
Oh, and in case it wasnt clear - the article explains how to mount an attack despite using SP/PQ (in some situations).
Yes, this is one of the biggest fallacies out there on SQL Injection. Input cleansing is a joke when it comes to security practices. User-supplied text should just NEVER become part of the execution stream. Input cleansing is just a hacker-defender game. We shouldn't be playing cames when it comes to security.
Great article, by the way.
Thanks :-)
+2  A: 

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...

+1  A: 

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.


Gary Willoughby
+2  A: 

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.

Don Johe
+2  A: 

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.


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.

+9  A: 

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.

Dour High Arch
If I'm reading correctly Wikipedia (http://en.wikipedia.org/wiki/Backdoor_%28computing%29) and the Jargon file (http://www.science.uva.nl/~mes/jargon/b/backdoor.html) he didn't - at least officialy - distribute it in that way.
The fact that very few sites reported this even after he revealed it makes me suspect he didn't distribute it. Still, by design it would leave no trace and be very very difficult to detect in action. And he never did reveal the password...
Dour High Arch
Says a lot about the whole "more eyeballs make shallow bugs" concept, doesnt it....

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.

+1  A: 

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


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.

+1  A: 
+1  A: 

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.