So…in an Errata Security field trip today Rob and I saw Untraceable(A whopping 13% on the Tomatometer). While I did not cringe as much as I did in other movies like Live Free or Die Hard (Who could ever forget that whole "reroute all the gas in the country" bit) I could not help but notice how mainstream botnets have become. I do not want to give any plot points away but if you do not have adequate botnet protection you could end up sitting in a giant vat of battery acid. That is right, forget any compliancy or regulatory problems you may have, a vat of battery acid awaits people who cannot shutdown botnets. Battery acid. I mean it is not like a vat of chocolate or Vaseline, freaking battery acid. This movie taught me that battery acid and the human skin do not mix well. In fact amid a odd plot where a badguy is killing people in some twisted way user Google adsense, err, viewer involvement on a website the only really take away I have is that I do not want to end up in a vat of battery acid...and I should learn how to blink Morse code under very bad conditions.
Aside from the battery acid bath penalty for the lack of botnet protection, I found the movie to be a weird combination of “The Net” and Saw. There was a lot of techno jargon and pretty technical looking screens including what could be the first look at the “FBI rootkit” that made headlines last year. I doubt it though as it seems to use the Metasploit reverse VNC shellcode to show exactly what the bad guy seeson his screen. But you have to wonder what’s going on when fake FBI agents seem to know more about actual cybercrime than real ones.
My last gripe about this movie is the FBI instantly declares someone must be guilty because he has 3 handguns and 2 rifles registered. It seems to me that a person who legally bought the weapons has less of a chance of being guilty than people who did not. After deciding the absolute guilt of an individual because of firearms ownership our intrepid FBI cyberheros are able to get an FBI SWAT team to kick in a door in less than 10 minutes. I could not get over how streamlined the ability to get a no-knock warrant is these days in movie land.
The entire movie I was hungry for pasta and I could not figure out why till I realized that Diane Lane, the FBI cyber-heroine, starred as Judge Hersey opposite Sylvester Stallone in the runaway 1995 blockbuster hit Judge Dredd. I know we are still waiting for the Academy to give that gem a nod.
In hindsight, I feel like I should have seen Rambo or Meet the Spartans. Rob has a review as well, I can only imagine what he has to say about this movie.
Monday, January 28, 2008
Wednesday, January 23, 2008
Hacking Flash Memory
I've got three computers now (Asus Eee PC, OLPC, and Dell M1330) that have flash disks instead of moving disks. In addition, my desktop has numerous flash chips to store the BIOS, network card ROM, video ROM, disk controller ROM, and so forth. It's time we look at the security risks of flash.
What we call "flash memory" is a type of memory that retains its contents after your turn the power off, as opposed to normal computer memory that loses its contents. In most cases, it's slower than normal memory, so it's more like a hard-disk than it is like normal memory. (NOR flash is fast but low capacity and is often used for BIOS ROMs, whereas NAND flash is slow buy high capacity, and is used for things like USB flash drives).
The major feature we are concerned about from a security point of view is that you cannot infinitely rewrite it. With normally memory and normal hard-disks, you can rewrite the contents trillions of times without concern. With flash memory, after rewriting data a few hundred thousand times, the block goes bad. It's quite easy to intentionally write a program that would continuously overwrite a block of flash until it failed.
At my previous employer, we found vulnerabilities in Cisco routers that would potentially allow us to create a worm. As part of our threat modeling, we considered what would happen if such a worm were to intentionally destroy the flash in a Cisco router. These routers boot from flash, so all the worm had to do was continuously overwrite the boot sector, then the router would no longer be able to boot.
The flash in many (if not most) Cisco routers is soldered in. Therefore, destroying the flash would "brick" the device. In other routers, the flash is socketed and can be replaced by the user.
Think of a hypothetical worm that infected the backbone routers and destroyed their flash chips. In one scenario, all those routers have soldered flash. It would take weeks or months for Cisco to send replacement motherboards to all those customers. In another scenario, all those routers have socketed flash, and the customers woul.d have spare flash modules on hand. In this scenario, they just simply install a (patched) copy of IOS on the flash modules, plug them in, and be back up and running within hours.
It's not just backbone ISPs that should take this threat into account, but anybody where the network is critical to operation. Financial networks (like the New York Stock Exchange) and the power grid are two examples that come to mind.
We therefore suggest that a element of critical infrastructure protection is to (1) require devices to have socketable flash, (2) for owners to have replaceable flash modules on hand, and (3) a way for owners to get the system back up and running after replacing the flash module.
Besides boot flash, mass storage flash has its own particular quirks. Take, for example, the notebook computers I mention above. A standard operating system continuously writes to a hard disk in the background. Windows frequently writes to the registry, and is constantly swapping memory to the disk. Linux is constantly updating /var/log files, and is constantly updating the atime record (last time you accessed a file). Thus, if you tried to boot Windows or Linux from a normal flash chip, you would quickly destroy the chip.
There is an obvious solution to this problem called "wear leveling". You create an extra layer between the operating system and the flash drive. Every time you rewrite a block of data, you instead write a new physical block. Thus, a logical disk location is different than the true physical location. This means all the blocks on the flask drive are overwritten equally, rather than any particular block being overwritten many times.
There are two ways of doing wear leveling: in the hardware, or in the software. You can now buy replacement IDE/SATA hard drives that replace your disks that have this wear leveling built-in. These are often called "solid state drives" or "SSDs". A good example is my Dell M1330, or Apple's new MacBook Air.
Whereas Windows is stuck with NTFS/FAT file systems that require to you solve wear-leveling in hardware, Linux can boot from special file systems that do wear-leveling in software. One popular flash file system is JFFS2. My Eee PC ($300 laptop) uses an SSD with hardware leveling, therefore, it boots using ext3 file system, and I can boot it with Windows if I wanted. My OLPC ($200 laptop) uses a cheaper flash chip without wear leveling. Therefore, it boots Linux with JFFS2, and I cannot install Windows on it.
The problem with either JFFS2 or SSDs is that a hacker can still attack the system and destroy the underlying flash and brick the system.
Besides boot flash or bulk storage, a hacker could also destroy the flash on your video card, network card, disk controller, and so forth. In some cases, the flash is only for optional features (like "network boot"), so destroying the flash won't impact most users. In other cases, the flash is a required part of the system. In order to boot from a SATA controller, the flash ROM must install its drivers at boot time.
Most desktops have a switch on the motherboard that would prevent a virus from destroying the BIOS flash, but such switches do not exist on laptops. There are likewise no switches protecting the other flash chips on the system whose destruction will prevent the system from booting. Again, we would suggest that for critical systems (such as servers), companies examine how well the flash is protected from destruction, and whether they can easily replace it in the field.
While destroying flash is easy, subverting is more fun. Errata Security conducted an experiment where we wrote a bit of malware under Windows that would subvert the flash of a network card. This flash would then subvert the boot process to in turn subvert a driver loaded from the hard disk, thus leaving a memory resident piece of code that could not be found on the hard disk. Re-installing the operating system did not remove the malware. We could also move the card to a new machine and infect that machine.
Such "flash rootkits" would therefore allow an attacker to take permanent control of a machine. Since the problem isn't addressed by security products, it's likely that the hackers can gain control without being detected, and if detected, would force the victim to replace the hardware completely.
There are some complications to subverting flash. Flash used for BIOSs are meant to be easily read and hard to write. Writing to flash often requires weird techniques. A typical example is that to switch the flash to write mode, you have to read from specific locations in the flash in a specific order to tell the chip you want to write, then do strange things to write data. Sometimes if you do all the correct things, the write operations will actually fail, so you have to try again until you get it right.
Luckily (for hackers), most systems do a raw pass through to the flash chips. A vendor of network cards, for example, wants to be able to choose different flash vendors, depending upon whoever has the cheapest chips at the moment. That means hackers don't need to worry about the quirks of a hundred different network chips - just the quirks of a few flash vendors. There is an open source project for flashing BIOSes that already contains the necessary code that a hacker could use to destroy/subvert almost any flash chip in any sort of addon card.
Most people don't have to worry about these threats, of course. Few hackers want to destroy the average person's systems. However, we would like to reiterate our belief that those responsible for protecting critical infrastructure take flash threats seriously. We believe they need to be able to respond a widespread infection that destroys the boot flash on critical devices.
What we call "flash memory" is a type of memory that retains its contents after your turn the power off, as opposed to normal computer memory that loses its contents. In most cases, it's slower than normal memory, so it's more like a hard-disk than it is like normal memory. (NOR flash is fast but low capacity and is often used for BIOS ROMs, whereas NAND flash is slow buy high capacity, and is used for things like USB flash drives).
The major feature we are concerned about from a security point of view is that you cannot infinitely rewrite it. With normally memory and normal hard-disks, you can rewrite the contents trillions of times without concern. With flash memory, after rewriting data a few hundred thousand times, the block goes bad. It's quite easy to intentionally write a program that would continuously overwrite a block of flash until it failed.
At my previous employer, we found vulnerabilities in Cisco routers that would potentially allow us to create a worm. As part of our threat modeling, we considered what would happen if such a worm were to intentionally destroy the flash in a Cisco router. These routers boot from flash, so all the worm had to do was continuously overwrite the boot sector, then the router would no longer be able to boot.
The flash in many (if not most) Cisco routers is soldered in. Therefore, destroying the flash would "brick" the device. In other routers, the flash is socketed and can be replaced by the user.
Think of a hypothetical worm that infected the backbone routers and destroyed their flash chips. In one scenario, all those routers have soldered flash. It would take weeks or months for Cisco to send replacement motherboards to all those customers. In another scenario, all those routers have socketed flash, and the customers woul.d have spare flash modules on hand. In this scenario, they just simply install a (patched) copy of IOS on the flash modules, plug them in, and be back up and running within hours.
It's not just backbone ISPs that should take this threat into account, but anybody where the network is critical to operation. Financial networks (like the New York Stock Exchange) and the power grid are two examples that come to mind.
We therefore suggest that a element of critical infrastructure protection is to (1) require devices to have socketable flash, (2) for owners to have replaceable flash modules on hand, and (3) a way for owners to get the system back up and running after replacing the flash module.
Besides boot flash, mass storage flash has its own particular quirks. Take, for example, the notebook computers I mention above. A standard operating system continuously writes to a hard disk in the background. Windows frequently writes to the registry, and is constantly swapping memory to the disk. Linux is constantly updating /var/log files, and is constantly updating the atime record (last time you accessed a file). Thus, if you tried to boot Windows or Linux from a normal flash chip, you would quickly destroy the chip.
There is an obvious solution to this problem called "wear leveling". You create an extra layer between the operating system and the flash drive. Every time you rewrite a block of data, you instead write a new physical block. Thus, a logical disk location is different than the true physical location. This means all the blocks on the flask drive are overwritten equally, rather than any particular block being overwritten many times.
There are two ways of doing wear leveling: in the hardware, or in the software. You can now buy replacement IDE/SATA hard drives that replace your disks that have this wear leveling built-in. These are often called "solid state drives" or "SSDs". A good example is my Dell M1330, or Apple's new MacBook Air.
Whereas Windows is stuck with NTFS/FAT file systems that require to you solve wear-leveling in hardware, Linux can boot from special file systems that do wear-leveling in software. One popular flash file system is JFFS2. My Eee PC ($300 laptop) uses an SSD with hardware leveling, therefore, it boots using ext3 file system, and I can boot it with Windows if I wanted. My OLPC ($200 laptop) uses a cheaper flash chip without wear leveling. Therefore, it boots Linux with JFFS2, and I cannot install Windows on it.
The problem with either JFFS2 or SSDs is that a hacker can still attack the system and destroy the underlying flash and brick the system.
Besides boot flash or bulk storage, a hacker could also destroy the flash on your video card, network card, disk controller, and so forth. In some cases, the flash is only for optional features (like "network boot"), so destroying the flash won't impact most users. In other cases, the flash is a required part of the system. In order to boot from a SATA controller, the flash ROM must install its drivers at boot time.
Most desktops have a switch on the motherboard that would prevent a virus from destroying the BIOS flash, but such switches do not exist on laptops. There are likewise no switches protecting the other flash chips on the system whose destruction will prevent the system from booting. Again, we would suggest that for critical systems (such as servers), companies examine how well the flash is protected from destruction, and whether they can easily replace it in the field.
While destroying flash is easy, subverting is more fun. Errata Security conducted an experiment where we wrote a bit of malware under Windows that would subvert the flash of a network card. This flash would then subvert the boot process to in turn subvert a driver loaded from the hard disk, thus leaving a memory resident piece of code that could not be found on the hard disk. Re-installing the operating system did not remove the malware. We could also move the card to a new machine and infect that machine.
Such "flash rootkits" would therefore allow an attacker to take permanent control of a machine. Since the problem isn't addressed by security products, it's likely that the hackers can gain control without being detected, and if detected, would force the victim to replace the hardware completely.
There are some complications to subverting flash. Flash used for BIOSs are meant to be easily read and hard to write. Writing to flash often requires weird techniques. A typical example is that to switch the flash to write mode, you have to read from specific locations in the flash in a specific order to tell the chip you want to write, then do strange things to write data. Sometimes if you do all the correct things, the write operations will actually fail, so you have to try again until you get it right.
Luckily (for hackers), most systems do a raw pass through to the flash chips. A vendor of network cards, for example, wants to be able to choose different flash vendors, depending upon whoever has the cheapest chips at the moment. That means hackers don't need to worry about the quirks of a hundred different network chips - just the quirks of a few flash vendors. There is an open source project for flashing BIOSes that already contains the necessary code that a hacker could use to destroy/subvert almost any flash chip in any sort of addon card.
Most people don't have to worry about these threats, of course. Few hackers want to destroy the average person's systems. However, we would like to reiterate our belief that those responsible for protecting critical infrastructure take flash threats seriously. We believe they need to be able to respond a widespread infection that destroys the boot flash on critical devices.
Sunday, January 20, 2008
Why the OLPC promotes terrorism
When you see a hobo starving in the street, there are two things you can do. One is to ask the hobo what he would like to eat. The second is to hold a Big Mac over his head and say "Dance for your food, bum!". The second method is a win-win: the hobo eats, you get entertainment, and all it costs is the bum's dignity.
This is the philosophy behind the OLPC, the "One Laptop Per Child" project. It's a morally corrupt organization that believes in providing technology to the third-world in exchange for their dignity. It was created by a bunch of PhDs for their own amusement. It was not built by asking the poor what they want.
It's not really a laptop that the rest of the world would recognize. The PhDs decided that the way everyone else uses computers is wrong, so they designed an entirely new user interface. They also decided that the way the rest of the world teaches their children is wrong, and come up with an entirely new education system.
I'm watching a video from their website talking about the "mesh" networking feature of the laptop. One of their PhDs says: "We don't want them just using the computer so they can just use the technology; we want them to use this computer so they can become social with each other and collaborate with each other". The PhDs spend a lot of time talking about what they themselves want, but not a lot of time talking about what the children want. In the end, what the PhDs really want is to rob the children of their dignity.
It's not just their collectivist education philosophy, everything about the organization is rabidly communist. I'm watching a BBC documentary about the project where they describe it as a hope for a 'great leap forward'. Apparently, the BBC means this seriously without irony. The "Great Leap Forward" was name given by Chairman Moa for industrializing China in the 1950s. Quoting Wikipedia: "The Great Leap Forward is now widely seen - both within China and outside - as a major economic and humanitarian disaster, with estimates of the number of people killed by famine during this period ranging from 14 to 43 million".
Their dispute with Intel is particularly illuminating. Like any communist organization, the OLPC suppresses dissent. When OLPC announced their project, Intel announced their competing "Classmate PC" program. The basic philosophy of communism is that there is only one "best solution" for everyone, whereas capitalism believes in different solutions suited to different needs. Thus, OLPC is upset with competition, believing that everyone should work collectively on the best solution, rather than working competitively on different solutions for different markets.
At the heart of the Intel vs. OLPC squabble is the fact that Intel "disparaged" the OLPC. Well, that's what competition means: pointing out your advantages while describing the disadvantages of competing solutions. Nobody is above criticism, no matter how high-minded and moral their goals are.
As a result of their suppression of criticism, the OLPC has a lot of chronic problems that it's unwilling to fix. It's not just whether their Great Leap Forward is a good idea. It's the more basic problems with the computer. For example, it's extremely buggy. I was unable to do anything useful with it for any length of time without having to reboot it. It's painfully slow. The processor is more than fast enough to run software written in capitalistic programming languages like C++, but the majority of the user interface is written in slow left-wing languages like Python. The OLPC has a link to Gmail on its screen, but the system becomes slower and slower and eventually stops working if you attempt to use Gmail. I got a unit to fuzz test the WiFi stack, but the stack crashes often by itself even without me fuzzing it.
The PhDs claim its "easy to use", but this is the same hubris that all programmers have (all programmers claim their software is easy, no matter how difficult the users think it is). Most people can't even figure out how to open the box. I like to hand people the unit and say "it's so easy even children from the third world can figure it out"; it's funny watching them struggle for 10 minutes before I show them how it works.
In contrast, Intel's Classmate PC runs the same Windows or Linux desktops that everyone else in the world uses. Intel's computer has no enforced educational agenda. It doesn't have communist software on it, yet the children collaborate with each other anyway without software forcing them to.
The real danger with the OLPC is that it's like sending guns to terrorists to attack us with. The OLPC teaches the world the ideals of university PhDs. It teaches children that capitalism and democracy is evil and the cause of their problems, rather than the solution. Yet, at its core, it's still a computer than people can use to hack the United States. It is a weapon that can attack our nation's infrastructure much more effectively than a gun would. Here is a picture of us installing Metasploit on it:
EDIT: A lot of people think this last paragraph is a bit of a stretch. I thought it was obvious. A certain percentage of any population of computer users will use their computers for evil rather than good. If you flood the third-world with computers, a certain percentage of them will also use the computer for malicious purposes. As soon as Nigerians got hold of computers in the late 1990s, the rest of the world started receiving e-mail from the grieving widow of Sese-Seko needing help transferring her fortune out of the country.
In places like Russia, there are more skilled computer nerds than there are employment opportunities for those skills, so programmers turn to cybercrime. In other places, such as India, where computers skills gets a well-paying job, cybercrime is less prominent. The recent DDoS attack against Estonia is a good example of the result.
When your choices are $10 a month herding goats or $100 a day herding bots, it's hard not to choose the later. While computers are mostly benign, they also have the potential to be weapons. Dumping weapons on third world countries has rarely turned out well.
We can address these risks. We can find ways to provide further education and employment, to give the best and brightest other opportunities than cybercrime. However, we cannot do so in the current climate of the OLPC that suppresses all criticism and dissent.
EDIT: Look at the comments to this post and how they assume I'm against helping poor nations get access to technology. I'm not. I love free-market solutions (like Intel's) that people freely criticize. While OLPC gets all the press, a lot of companies are designing or shipping low-cost PCs for poor nations; those are the ones we should support. While some computers are purchased by rich nations and sent to the poor ones, the majority are purchased by the poor nations themselves. Instead of textbooks. Because everyone says says how wonderful the OLPC is, nobody criticizes it, so if their education ministers think something is wrong, it's because "they just don't get it".
EDIT: Some people seem surprised at my communist conspiracy theories. I don't think there is a conspiracy, of course, or even that it's very communist. However, if you ever used the OLPC, you'd understand better what I'm talking about.
This is the philosophy behind the OLPC, the "One Laptop Per Child" project. It's a morally corrupt organization that believes in providing technology to the third-world in exchange for their dignity. It was created by a bunch of PhDs for their own amusement. It was not built by asking the poor what they want.
It's not really a laptop that the rest of the world would recognize. The PhDs decided that the way everyone else uses computers is wrong, so they designed an entirely new user interface. They also decided that the way the rest of the world teaches their children is wrong, and come up with an entirely new education system.
I'm watching a video from their website talking about the "mesh" networking feature of the laptop. One of their PhDs says: "We don't want them just using the computer so they can just use the technology; we want them to use this computer so they can become social with each other and collaborate with each other". The PhDs spend a lot of time talking about what they themselves want, but not a lot of time talking about what the children want. In the end, what the PhDs really want is to rob the children of their dignity.
It's not just their collectivist education philosophy, everything about the organization is rabidly communist. I'm watching a BBC documentary about the project where they describe it as a hope for a 'great leap forward'. Apparently, the BBC means this seriously without irony. The "Great Leap Forward" was name given by Chairman Moa for industrializing China in the 1950s. Quoting Wikipedia: "The Great Leap Forward is now widely seen - both within China and outside - as a major economic and humanitarian disaster, with estimates of the number of people killed by famine during this period ranging from 14 to 43 million".
Their dispute with Intel is particularly illuminating. Like any communist organization, the OLPC suppresses dissent. When OLPC announced their project, Intel announced their competing "Classmate PC" program. The basic philosophy of communism is that there is only one "best solution" for everyone, whereas capitalism believes in different solutions suited to different needs. Thus, OLPC is upset with competition, believing that everyone should work collectively on the best solution, rather than working competitively on different solutions for different markets.
At the heart of the Intel vs. OLPC squabble is the fact that Intel "disparaged" the OLPC. Well, that's what competition means: pointing out your advantages while describing the disadvantages of competing solutions. Nobody is above criticism, no matter how high-minded and moral their goals are.
As a result of their suppression of criticism, the OLPC has a lot of chronic problems that it's unwilling to fix. It's not just whether their Great Leap Forward is a good idea. It's the more basic problems with the computer. For example, it's extremely buggy. I was unable to do anything useful with it for any length of time without having to reboot it. It's painfully slow. The processor is more than fast enough to run software written in capitalistic programming languages like C++, but the majority of the user interface is written in slow left-wing languages like Python. The OLPC has a link to Gmail on its screen, but the system becomes slower and slower and eventually stops working if you attempt to use Gmail. I got a unit to fuzz test the WiFi stack, but the stack crashes often by itself even without me fuzzing it.
The PhDs claim its "easy to use", but this is the same hubris that all programmers have (all programmers claim their software is easy, no matter how difficult the users think it is). Most people can't even figure out how to open the box. I like to hand people the unit and say "it's so easy even children from the third world can figure it out"; it's funny watching them struggle for 10 minutes before I show them how it works.
In contrast, Intel's Classmate PC runs the same Windows or Linux desktops that everyone else in the world uses. Intel's computer has no enforced educational agenda. It doesn't have communist software on it, yet the children collaborate with each other anyway without software forcing them to.
The real danger with the OLPC is that it's like sending guns to terrorists to attack us with. The OLPC teaches the world the ideals of university PhDs. It teaches children that capitalism and democracy is evil and the cause of their problems, rather than the solution. Yet, at its core, it's still a computer than people can use to hack the United States. It is a weapon that can attack our nation's infrastructure much more effectively than a gun would. Here is a picture of us installing Metasploit on it:
EDIT: A lot of people think this last paragraph is a bit of a stretch. I thought it was obvious. A certain percentage of any population of computer users will use their computers for evil rather than good. If you flood the third-world with computers, a certain percentage of them will also use the computer for malicious purposes. As soon as Nigerians got hold of computers in the late 1990s, the rest of the world started receiving e-mail from the grieving widow of Sese-Seko needing help transferring her fortune out of the country.
In places like Russia, there are more skilled computer nerds than there are employment opportunities for those skills, so programmers turn to cybercrime. In other places, such as India, where computers skills gets a well-paying job, cybercrime is less prominent. The recent DDoS attack against Estonia is a good example of the result.
When your choices are $10 a month herding goats or $100 a day herding bots, it's hard not to choose the later. While computers are mostly benign, they also have the potential to be weapons. Dumping weapons on third world countries has rarely turned out well.
We can address these risks. We can find ways to provide further education and employment, to give the best and brightest other opportunities than cybercrime. However, we cannot do so in the current climate of the OLPC that suppresses all criticism and dissent.
EDIT: Look at the comments to this post and how they assume I'm against helping poor nations get access to technology. I'm not. I love free-market solutions (like Intel's) that people freely criticize. While OLPC gets all the press, a lot of companies are designing or shipping low-cost PCs for poor nations; those are the ones we should support. While some computers are purchased by rich nations and sent to the poor ones, the majority are purchased by the poor nations themselves. Instead of textbooks. Because everyone says says how wonderful the OLPC is, nobody criticizes it, so if their education ministers think something is wrong, it's because "they just don't get it".
EDIT: Some people seem surprised at my communist conspiracy theories. I don't think there is a conspiracy, of course, or even that it's very communist. However, if you ever used the OLPC, you'd understand better what I'm talking about.
Friday, January 18, 2008
Hex.lore
If I ever get around to writing a computer book, one of the first I would write would be about the lore of hexadecimal. We teach children the basics of mathematics by starting out with addition and subtraction. The equivalent in hacking is hexadecimal (or simply, "hex"). Hex is the starting point for most hacking.
The reason I'd want to write an entire book about it is that most people don't fully grok hex. Indeed, some very smart people can demonstrate a lot of expertise in hacking without quite understanding hex. It's one of those things that you can safely skip most of the time, but you can't quite skip it all the time. Among those at the very top of our industry, groking hex is required. There are some things that can only be fully explained by analyzing a raw hex dump.
I think one problem people have is that hexadecimal is introduced to people as a "base-16 numbering system". This mathematical explanation is unsatisfying because hackers rarely add/subtract hex numbers. We may occasionally add '0x9' to '0x41' to get '0x4A', but this is rare. Instead, hackers are mostly concerned that '0x41' represents the ASCII letter 'A', the x86 instruction 'inc ecx', or the binary value 01000001.
Hackers are also interested in a deeper lore. Many intrusion detection systems trigger on a sequence of bytes having the value 0x41 because that is a common buffer filler in proof-of-concept exploits. A significant amount of hacker literature ends with a demonstration of a computer crashing because it tried to exploit code at location 0x41414141 - which meant that the hacker was able to redirect execution of computer code with the contents of a buffer. This is "meaning" to the hex data far beyond any mathematics.
Another part of hex lore is seeing data structures. Data inside a computer has structure. In other words, some of the bytes hold the data itself, and other bytes tell us how to interpret the data. For example, text within a computer is sometimes "nul-terminated" and sometimes "length encoded". The 'nul' byte has the value of zero, or 0x00. The "ABC" represented as a nul-terminated string would look like:
41 42 43 00
A length-encoded string would look different. The first byte would have a value that would indicate how long the rest of the string is:
03 41 42 43
Back in 2006, Dave Maynor caused a bit of controversy by claiming that Apple had bugs in their WiFi drivers. The bugs were when the SSID (name of the access point) was longer than 96 bytes, or the number of speeds (11-mbps, 54-mpbs, etc.) was larger than 17. The controversy started when Apple's PR machine claimed that Dave Maynor hadn't found these bugs. Whether you believe Apple or Dave Maynor is largely determined by whether you've seen the hex dump of a WiFi packet. The WiFi standard says that an SSID should not be longer than 32-bytes, and that there aren't more than 17 possible speeds that an access point can have. However, WiFi "length encodes" these fields with a single byte, meaning they can be as long as 255-bytes. Therefore, if a hacker creates a packet with lengths longer than the code expects, they can cause a problem.
This issue is obvious to anybody who has looked at the packets in hex, but a mystery to everybody else. Hence, the controversy.
Groking hex gives you psychic abilities. For example, one of my favorite computer games of all time is Diablo 2. I completed hacked that program to get an advantage over other players. There are two basic ways of hacking online games: (1) hack the packets and (2) hack the code. I started by looking at the packets. I noticed that they consisted of purely random bytes with the occasional hex sequence of FF FF FF. From this data, I immediately concluded that they were "compressed using Huffman encoding", and quickly found the tables involved within the code.
It would take a chapter of a book to explain the above conclusion - and I think that would be a good basis for a book. Another chapter could explain WiFi packets. Another chapter could dissect a hex dump of a virus. My favorite chapter would be a discussion of the "Witty" worm: everyone believes it was launched with a "hit" list, but that can be disproved by analyzing the hex in the slack area of the packet.
If anybody has similarly interesting tales of taking raw hex information and turning it into useful information, I'd love to hear about them. Please send me mail, or add a comment to this blog.
The reason I'd want to write an entire book about it is that most people don't fully grok hex. Indeed, some very smart people can demonstrate a lot of expertise in hacking without quite understanding hex. It's one of those things that you can safely skip most of the time, but you can't quite skip it all the time. Among those at the very top of our industry, groking hex is required. There are some things that can only be fully explained by analyzing a raw hex dump.
I think one problem people have is that hexadecimal is introduced to people as a "base-16 numbering system". This mathematical explanation is unsatisfying because hackers rarely add/subtract hex numbers. We may occasionally add '0x9' to '0x41' to get '0x4A', but this is rare. Instead, hackers are mostly concerned that '0x41' represents the ASCII letter 'A', the x86 instruction 'inc ecx', or the binary value 01000001.
Hackers are also interested in a deeper lore. Many intrusion detection systems trigger on a sequence of bytes having the value 0x41 because that is a common buffer filler in proof-of-concept exploits. A significant amount of hacker literature ends with a demonstration of a computer crashing because it tried to exploit code at location 0x41414141 - which meant that the hacker was able to redirect execution of computer code with the contents of a buffer. This is "meaning" to the hex data far beyond any mathematics.
Another part of hex lore is seeing data structures. Data inside a computer has structure. In other words, some of the bytes hold the data itself, and other bytes tell us how to interpret the data. For example, text within a computer is sometimes "nul-terminated" and sometimes "length encoded". The 'nul' byte has the value of zero, or 0x00. The "ABC" represented as a nul-terminated string would look like:
41 42 43 00
A length-encoded string would look different. The first byte would have a value that would indicate how long the rest of the string is:
03 41 42 43
Back in 2006, Dave Maynor caused a bit of controversy by claiming that Apple had bugs in their WiFi drivers. The bugs were when the SSID (name of the access point) was longer than 96 bytes, or the number of speeds (11-mbps, 54-mpbs, etc.) was larger than 17. The controversy started when Apple's PR machine claimed that Dave Maynor hadn't found these bugs. Whether you believe Apple or Dave Maynor is largely determined by whether you've seen the hex dump of a WiFi packet. The WiFi standard says that an SSID should not be longer than 32-bytes, and that there aren't more than 17 possible speeds that an access point can have. However, WiFi "length encodes" these fields with a single byte, meaning they can be as long as 255-bytes. Therefore, if a hacker creates a packet with lengths longer than the code expects, they can cause a problem.
This issue is obvious to anybody who has looked at the packets in hex, but a mystery to everybody else. Hence, the controversy.
Groking hex gives you psychic abilities. For example, one of my favorite computer games of all time is Diablo 2. I completed hacked that program to get an advantage over other players. There are two basic ways of hacking online games: (1) hack the packets and (2) hack the code. I started by looking at the packets. I noticed that they consisted of purely random bytes with the occasional hex sequence of FF FF FF. From this data, I immediately concluded that they were "compressed using Huffman encoding", and quickly found the tables involved within the code.
It would take a chapter of a book to explain the above conclusion - and I think that would be a good basis for a book. Another chapter could explain WiFi packets. Another chapter could dissect a hex dump of a virus. My favorite chapter would be a discussion of the "Witty" worm: everyone believes it was launched with a "hit" list, but that can be disproved by analyzing the hex in the slack area of the packet.
If anybody has similarly interesting tales of taking raw hex information and turning it into useful information, I'd love to hear about them. Please send me mail, or add a comment to this blog.
Thursday, January 17, 2008
Monday, January 14, 2008
Intresting
This is old hat for most people but I am still amazed by the number of people who think Bit torrent is anonymous.
New Apple Quicktime Problem – UPDATE
On Thursday an advisory was released to several security research mailing lists with an advisory for an unpatched flaw in Quicktime as well as a simple Proof-Of-Concept(PoC). Over the weekend, that simple PoC morphed into a much more robust attack tool. The current PoC, which is really a weaponized attack tool in sheep’s clothing, will cause memory corruption in both Vista and OSX 10.5.
Quicktime has had a rough time recently with a number of flaws putting both Windows and OSX users at risk. You can’t fault them for having flaws in their software, everybody does. The problem I have with Apple is that these attacks would not be exploitable if they took advantage of advanced security features in Vista. This exploit requires an attacker to know a static offset in the process space that they can use to their advantage. Taking advantage of ASLR in Vista would mitigate this risk and keep millions of Windows users safe. In the update form the last problem, ASLR was not enabled and as I have previously shown it is nothing more than changing a bit a QA cycle.
Due to Apples lack of adoption of these features or a secure development cycle, I have recommended to our customers that all Apple software should be removed from Windows machines. That is Quicktime, iTunes, and Safari.
Quicktime has had a rough time recently with a number of flaws putting both Windows and OSX users at risk. You can’t fault them for having flaws in their software, everybody does. The problem I have with Apple is that these attacks would not be exploitable if they took advantage of advanced security features in Vista. This exploit requires an attacker to know a static offset in the process space that they can use to their advantage. Taking advantage of ASLR in Vista would mitigate this risk and keep millions of Windows users safe. In the update form the last problem, ASLR was not enabled and as I have previously shown it is nothing more than changing a bit a QA cycle.
Due to Apples lack of adoption of these features or a secure development cycle, I have recommended to our customers that all Apple software should be removed from Windows machines. That is Quicktime, iTunes, and Safari.
What the exploit looks like running with default options.
The OSX 10.5 crash.
The WinDBbg output on Vista.
More SideJacking
Our sidejacking stuff was named one of the top 5 hacks of 2007. Since then, we've noticed a few more things about it.
To recap: websites typically encrypt your password so it cannot be sniffed, but then send you an unencrypted "session-id" for that session. The session-id is either some random data in the URL, or more often, random data in an HTTP cookie. A hacker who sniffs the session-id can then use it to gain access to that session, which usually means gaining access to the account. Thus, the hacker can read your Gmail/HotMail/YahooMail, look at what books you've ordered from Amazon.com, control your MySpace/Facebook page, and so on. The hacker still cannot get your password nor your credit card number, but can most everything else.
SSL doesn't protect Google Mail
When I originally tested sidejacking, I found that there were some solutions. For example, Salesforce.Com by default encrypts EVERYTHING over SSL. While some of their customers choose to use non-SSL for some reason, the majority of their customers are protected.
SSL is not always complete. A good example is Gmail. In theory, using the HTTPS version of Gmail should protect you by going to https://mail.google.com/mail, but this doesn't work as you think. The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default - but they become unencrypted if SSL fails.
When you open your laptop and connect to a WiFi hotspot, it usually presents you with a login page, or a page that forces you to accept their terms and conditions. During this time, SSL will be blocked. Gmail will therefore backoff and attempt non-SSL connections. These also fail - but not before disclosing the cookie information that allow hackers to sidejack your account.
This happens to Dave Maynor a lot. He leaves Gmail running using HTTPS. We sit down at a coffee shop. He opens his laptop to read a file. He doesn't even want to connect to the WiFi hotspot. However, the WiFi stack connects anyway, and Gmail sends out his session-id. I then connect to his e-mail account before he realizes what he has done. This has happened a lot, he has become very paranoid, and the first thing he now does whenever he sees me is verify his WiFi is turned off.
Hacking tools outlawed
Germany, and now the UK, outlaw the distribution of hacking tools. My sidejacking tools (Ferret, Hamster) are exactly the sort of thing they outlaw.
Does anybody know the legal ramifications of this? Does that mean I can no longer travel to those countries? Does that mean I can't travel anywhere in the European Union? BlackHat Amsterdam is coming up, and I need to know whether I shouldn't go.
This also begs the question why I distribute these if they are hacking tools. The answer is: because they demonstrate the problem. People don't believe a problem exists unless they can see it for themselves. Hackers don't need my tools - they can use the standard Wireshark product and the Mozilla cookie editor to do the job instead. What my tools do is make it obvious so that a reporter can point-and-click and hack their own accounts. Web 2.0 is fundamentally insecure because data isn't encrypted (except for passwords and credit card numbers). This insecurity exists because people can't see for themselves how the problem affects them. With my tools, they can see the danger they are in, and sidejack their own accounts.
This is part of living in a free society. Vulnerabilities released with Proof-of-Concept code help us understand the vulnerability, and security in general. Conferences like BlackHat are much more interesting because presentations release code that prove their assertions. We don't have experimental evidence in our industry, all we have is code.
Sure, the downside is that it helps hackers, but in the end, it's the defenders that win. Hackers had the edge over Windows for many years. Windows XP SP2 caught up with them, and now Vista is ahead of the hackers. The reason for this was the free and open society where we discussed and proved problems with code.
Which cookies to sidejack?
One of the problem with my tools is that they don't always work as easily as I would hope.
The basic problem is that I don't see the "Set-Cookie" sent from the server to the browser in SSL. I have to guess what that cookie is by seeing how it is used. A cookie is attached to a directory, and is sent for all accesses to that directory and subdirectories. If I see cookie "x=y" sent with subdirectory "/foo", it may actually have been attached to "/". If the browser accesses directory "/bar", I won't know if I should send the cookie or not.
One solution to this problem is to create my own accounts, and within my own browser look at where the cookies have been set. Unfortunately, the cookie editors I've used only show the permanent cookies, not the temporary cookies. In order to crack open the temporary cookies sent via SSL, I have to either rewrite a cookie editor or do a man-in-the-middle decryption of the SSL stream.
However, for HotMail, Gmail, etc., I've made some guess about what where the cookies are attached, and hard-coded them into the Hamster source code. These seem to work pretty well.
The bad part about this is that my tool may not work for a website. This will lead people to the false sense of security that sidejacking isn't a problem. However, sidejacking is ALWAYS a problem: there is no way to fix it other than encrypting the data with SSL. Just because the program guesses wrong doesn't mean that a hacker can't figure out the correct guesses and gain access to the data.
To recap: websites typically encrypt your password so it cannot be sniffed, but then send you an unencrypted "session-id" for that session. The session-id is either some random data in the URL, or more often, random data in an HTTP cookie. A hacker who sniffs the session-id can then use it to gain access to that session, which usually means gaining access to the account. Thus, the hacker can read your Gmail/HotMail/YahooMail, look at what books you've ordered from Amazon.com, control your MySpace/Facebook page, and so on. The hacker still cannot get your password nor your credit card number, but can most everything else.
SSL doesn't protect Google Mail
When I originally tested sidejacking, I found that there were some solutions. For example, Salesforce.Com by default encrypts EVERYTHING over SSL. While some of their customers choose to use non-SSL for some reason, the majority of their customers are protected.
SSL is not always complete. A good example is Gmail. In theory, using the HTTPS version of Gmail should protect you by going to https://mail.google.com/mail, but this doesn't work as you think. The JavaScript code uses an XMLHttpRequest object to make HTTP requests in the background. These are also SSL encrypted by default - but they become unencrypted if SSL fails.
When you open your laptop and connect to a WiFi hotspot, it usually presents you with a login page, or a page that forces you to accept their terms and conditions. During this time, SSL will be blocked. Gmail will therefore backoff and attempt non-SSL connections. These also fail - but not before disclosing the cookie information that allow hackers to sidejack your account.
This happens to Dave Maynor a lot. He leaves Gmail running using HTTPS. We sit down at a coffee shop. He opens his laptop to read a file. He doesn't even want to connect to the WiFi hotspot. However, the WiFi stack connects anyway, and Gmail sends out his session-id. I then connect to his e-mail account before he realizes what he has done. This has happened a lot, he has become very paranoid, and the first thing he now does whenever he sees me is verify his WiFi is turned off.
Hacking tools outlawed
Germany, and now the UK, outlaw the distribution of hacking tools. My sidejacking tools (Ferret, Hamster) are exactly the sort of thing they outlaw.
Does anybody know the legal ramifications of this? Does that mean I can no longer travel to those countries? Does that mean I can't travel anywhere in the European Union? BlackHat Amsterdam is coming up, and I need to know whether I shouldn't go.
This also begs the question why I distribute these if they are hacking tools. The answer is: because they demonstrate the problem. People don't believe a problem exists unless they can see it for themselves. Hackers don't need my tools - they can use the standard Wireshark product and the Mozilla cookie editor to do the job instead. What my tools do is make it obvious so that a reporter can point-and-click and hack their own accounts. Web 2.0 is fundamentally insecure because data isn't encrypted (except for passwords and credit card numbers). This insecurity exists because people can't see for themselves how the problem affects them. With my tools, they can see the danger they are in, and sidejack their own accounts.
This is part of living in a free society. Vulnerabilities released with Proof-of-Concept code help us understand the vulnerability, and security in general. Conferences like BlackHat are much more interesting because presentations release code that prove their assertions. We don't have experimental evidence in our industry, all we have is code.
Sure, the downside is that it helps hackers, but in the end, it's the defenders that win. Hackers had the edge over Windows for many years. Windows XP SP2 caught up with them, and now Vista is ahead of the hackers. The reason for this was the free and open society where we discussed and proved problems with code.
Which cookies to sidejack?
One of the problem with my tools is that they don't always work as easily as I would hope.
The basic problem is that I don't see the "Set-Cookie" sent from the server to the browser in SSL. I have to guess what that cookie is by seeing how it is used. A cookie is attached to a directory, and is sent for all accesses to that directory and subdirectories. If I see cookie "x=y" sent with subdirectory "/foo", it may actually have been attached to "/". If the browser accesses directory "/bar", I won't know if I should send the cookie or not.
One solution to this problem is to create my own accounts, and within my own browser look at where the cookies have been set. Unfortunately, the cookie editors I've used only show the permanent cookies, not the temporary cookies. In order to crack open the temporary cookies sent via SSL, I have to either rewrite a cookie editor or do a man-in-the-middle decryption of the SSL stream.
However, for HotMail, Gmail, etc., I've made some guess about what where the cookies are attached, and hard-coded them into the Hamster source code. These seem to work pretty well.
The bad part about this is that my tool may not work for a website. This will lead people to the false sense of security that sidejacking isn't a problem. However, sidejacking is ALWAYS a problem: there is no way to fix it other than encrypting the data with SSL. Just because the program guesses wrong doesn't mean that a hacker can't figure out the correct guesses and gain access to the data.
Friday, January 11, 2008
New Quicktime Flaw, this is not Deja Vu
No really. Its ANOTHER QuickTime flaw. It also involves RTSP. It was posted to Full Disclosure on Thursday afternoon. We have verified a crash on the latest OSX and are currently researching if it can lead to remote code execution and which platforms are affected.
The advisory is here:
http://aluigi.altervista.org/adv/quicktimebof-adv.txt
The advisory is here:
http://aluigi.altervista.org/adv/quicktimebof-adv.txt
SCADA the easiest target...
I remember once talking to an older gentleman who was responsible for some critical infrastructure networks and the gear that made them up. He did everything up shake his fist in the air and call me a whipper snapper over my mere suggestion that SCADA security should involve more than just making sure you have proper documentation of your support agreements with the hardware vendors. He then preceded to tell me what a nusicace people like me are because even things like simple port scans could bring down SCADA gear and I had no regard for the delicate nature that people like his staff have when it comes to this equipment. He then punctuated his rant with “and my equipment is not internet accessible so I am in no way worried about your so called hacker threat”.
I was flabbergasted that actually lives depended on this gentleman.
I thought of this story this morning while reading this news article.
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/01/11/wschool111.xml
Just because you do not think you have an internet connection doesn’t mean you are not at risk.
I was flabbergasted that actually lives depended on this gentleman.
I thought of this story this morning while reading this news article.
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/01/11/wschool111.xml
Just because you do not think you have an internet connection doesn’t mean you are not at risk.
Thursday, January 10, 2008
Anybody that spends anytime with me knows that I change phones with the same regularity most people change socks. Since some of the work I do is around mobile device security I at any given time have between 2-4 active cellular number on my person or in my bag. A phone will average about 6 2-3 months as my primary communication device before I get bored and switch it with a newer, shiner model. I just switched from the ATT Tilt (otherwise known as the HTC Kaiser) back to a Blackberry Curve 8310. Now I want to note this was not my first HTC phone and I find them to be well designed, functional, and generally good vehicles for Windows Mobile.
The Tilt suffered from a major flaw with its lack of battery life. The battery sucking blame seemed to fall squarely on the head of the 3G radio. I found a ton of stuff on the web about tools that can force it into EDGE mode to save battery. This is a good solution but then I end up with an expensive phone with nifty features I cannot use because of battery drain. The Microsoft Direct Push email is pretty good but all in all I missed my Blackberry so I switched back.
Saturday, January 05, 2008
Terminator TV Show
http://www.aintitcool.com/node/35197
From Ain't It Cool News: You can watch the first episode of the new upcoming Terminator TV show now on Yahoo TV before its January 13th premier. I watched it and thought it was pretty decent, much better than T3. It will be nice to have something to fill the lack of good sci-fi on tv now, tha is until Fox cancels it.
From Ain't It Cool News: You can watch the first episode of the new upcoming Terminator TV show now on Yahoo TV before its January 13th premier. I watched it and thought it was pretty decent, much better than T3. It will be nice to have something to fill the lack of good sci-fi on tv now, tha is until Fox cancels it.
Wednesday, January 02, 2008
Subscribe to:
Posts (Atom)
