Verzeichnis
Suchen im gesamten Verzeichnis und blättern in Suchliste
Errata SecurityErrata Security is a high-end cyber security consulting company.
As everyone knows, an important threat against the Internet is that of a coordinated DDoS attack against the root TLD DNS servers. The way I'd solve is with a simple inline device that both blocks some simple attacks from hitting the DNS server, but which can also answer simple queries, offloading the main server, even if it's failed. This can be done with $2000, half for the desktop machine, and the other half for the dual-port 10-gig Ethernet.
This thing would need to run at high rates, namely 10-gigabits/second and 10-million DNS queries per second. That's a lot of queries, but it's not as hard as you'd think. Custom drivers like PF_RING and DPDK already capture packets at rates of 50-million packets/second by cheating: they bypass the operating system and send the packets directly to user-mode memory. With very little code, you can parse the UDP packet and simple DNS queries, and either answer the query yourself, or forward the packet onto the real server.
At these rates, you hit fundamental hardware limits, like memory bandwidth and memory latency. Something as simple as "virtual-memory TLB misses" can become the primary limiting factor.
The .com TLD has 100,000,000 subdomains, and each record takes about 100 bytes. That means the server needs 10-gigabytes of RAM to hold all those records. These days, 16-gigs of RAM costs $160, so that's not really a lot of memory.
But it is a lot of virtual-memory. Every memory request needs to be translated from the "virtual" address to the "physical" address. This is done by dividing up memory into 4096 byte pages. The processor looks up the virtual-address in a "page-table" in order to calculate the physical address.
These page tables are 1/512 the size of the memory you use. This sounds small, but when you are using 10-gigabytes of memory, that means that you are using 20-megabytes of page tables.
Now let's trace the path of an incoming UDP DNS request. Each one is for a different domain, at random. This randomness is a problem, because the CPU cache only holds recently accessed data, but random domain queries haven't been recently accessed. That means as you walk through your data structures, each memory access will be a cache-miss. This means that instead of taking 1 nanosecond to read the L1 cache, 4 nanoseconds to read the L2 cache, or 10 nanoseconds to read the L3 cache, it'll take 80-nanoseconds to read DRAM.
At 10 million packets/second, that works out to only 100-nanoseconds per packet, so it sounds like we've used up all our time just waiting for that first cache miss. Things aren't as dire as they appear, though. First of all, we can process several packets in batches and issue "prefetches" on the data, so that much of the time the data will be in the cache by the time we need it. Secondly, a standard desktop supports 8 cores/threads, so our budget is more like 10 cache misses per packet rather than a single cache miss.
But we have a problem: virtual-memory. As I pointed out above, the page-tables alone for our massive .com DNS database is 20-megabytes in size, but our desktop CPU only has 8 megabytes of L3 cache. That means on average, not only will our desired memory cause a cache miss, it'll cause a second cache miss reading the page-table entry.
That's why a common solution in scenarios like this would be to move our code from user-mode into kernel-mode, the advantage being that in kernel-mode, you don't use virtual-memory. However, kernel-mode is Morally Wrong, and I'd rather have the Internet crash due to DDoS than put my code there.
The other solution is to use larger page tables. The small 4096 byte memory page isn't the only option. You can also use 2-megabyte pages. Both are supported simultaneously. That's because virtual-to-physical translation is a multi-step process, and you can set a flag to skip the last step for some addresses. If we allocate that large 10-gigabyte chunk as 5000 2-gigabyte pages, instead of 2.5-million 4096-byte pages, then we have a lot less to worry about. That 40k for the upper page tables will easily fit within our cache.
Let's look at how virtual-memory translation works. I've draw the following diagram to illustrate it.
Note that the upper 16 bits are ignored. Today's 64-bit processors are really just 48-bit processors, but 'sshhhh', don't tell anybody, or they might get upset.
The first step in translating an address is to grab the CSR3 register. This register is at the root of the memory hierarchy. Each time that the operating-system does a context-switch to a different process, it overwrites this register with a pointer to the top of the page-table hierarchy.
This register points to a 4096-byte block of memory (called "Page Map Level 4" or simply "L4" in the diagram) that contains 512 pointers, each 8 bytes in size. Remember that we need 8 bits to store a byte having 256 combinations, that means we need 9 bits to address 512 combinations. Thus, we grab the first 9 bits of our 48-bit address, then to a lookup in the L4 table, and thus find a pointer to our L3 table.
We repeat the process three more times, grabbing the next 9 bits from the address, looking up that value in our current table, getting a pointer to the next step. This process ends in the actual memory page we are looking for. At that point, we simply append to low 12 bits onto the end of the final pointer, thus getting our physical-address from the virtual-address.
In practice, the L4 table will have only a single entry that we every use, unless you have more than 512-gigabytes of RAM in a system. At the L3 level, we'll only have a single page of 512 entries that we'll ever use. Things start getting big at the L2 level, which as noted above, requires 40-kilobytes worth of data to handle our 10-gigabyte DNS .com database. Finally, the L1 level is what destroys us, requiring 20-megabytes to handle our 10-gigabyte database.
Not that processors have a special cache called the "TLB" or "translation lookaside buffer" that caches the results from this "page table walk". Thus, you don't have to do this on every memory access. TLB misses, as the are called, take up only a few percent of normal CPU time. However, the more we tackle Internet-scale problems, the more TLB misses become a problem, and the more we have to look for solutions.
Lucky for us, we can skip the L1 stage. Page table entries are a full 64-bits in size, but they only ever use the high-order bits. They don't use the low-order bits, except as status flags. The lowest bit is a flag that means "skip the next level". This is showing in the following diagram, where the L2 lookup leads directly to a 2-megabyte page, rather than than to an L1 lookup to a 4096 byte page:
Likewise, the L2 can be skipped in when using 1-gigabyte pages. I haven't read the necessary documentation, but I assume that the L3 could also be skipped for 0.5-terabyte pages. Whether or not CPUs support that today, they'll probably support that 10 years from now.
All operating systems support the large pages. On Windows, use "VirtualAlloc()" with the flag "MEM_LARGE_PAGES". On Linux, compile the kernel with CONFIG_HUGETLBFS and use the call "mmap()".
The problem is that you may not be able to allocate 10-gigabytes worth of large pages. That's because as the operating system runs, it's constantly allocating/freeing the smaller 4096 byte pages, spreading them throughout the system. There may not be enough contiguous memory left to satisfy your request. (On Linux, you can set a boot option to allocate the memory for huge pages before this happens).
There is a downside the large memory pages. They can't be swapped of memory. Also, consider something like Apache that's constantly forking processes, setting "copy-on-write" bits in the page tables. Every fork forces a few 4096-byte pages to be copied, but now imagine how slow that would be if a couple 2-megabyte pages had to be copied for every fork. This means in general, small pages are better.
Fortunately, none of these disadvantages apply to our 10-gigabyte in-memory database. Indeed, had we not used large pages, we'd probably have configured the system to not page out that memory anyway.
Conclusion
This post describes an Internet-scale problem that can be serviced by desktop-scale hardware. The limiting factor isn't the hardware, but the software. With better software, we can tackle larger Internet-scale problems.
You can take any software, such as Nginx, BIND, SendMail, Snort, grab a tool like Intel's Vtune that monitors process-counters, create an Internet-scale workload to test them, and then see if virtual-memory issues like TLB-misses are a problem, and if so, change the memory allocators to large pages in appropriate places.
I drew the above diagrams using JavaScript and HTML5. For you enjoyment, I'm embedding the JavaScript code here:
This thing would need to run at high rates, namely 10-gigabits/second and 10-million DNS queries per second. That's a lot of queries, but it's not as hard as you'd think. Custom drivers like PF_RING and DPDK already capture packets at rates of 50-million packets/second by cheating: they bypass the operating system and send the packets directly to user-mode memory. With very little code, you can parse the UDP packet and simple DNS queries, and either answer the query yourself, or forward the packet onto the real server.
At these rates, you hit fundamental hardware limits, like memory bandwidth and memory latency. Something as simple as "virtual-memory TLB misses" can become the primary limiting factor.
The .com TLD has 100,000,000 subdomains, and each record takes about 100 bytes. That means the server needs 10-gigabytes of RAM to hold all those records. These days, 16-gigs of RAM costs $160, so that's not really a lot of memory.
But it is a lot of virtual-memory. Every memory request needs to be translated from the "virtual" address to the "physical" address. This is done by dividing up memory into 4096 byte pages. The processor looks up the virtual-address in a "page-table" in order to calculate the physical address.
These page tables are 1/512 the size of the memory you use. This sounds small, but when you are using 10-gigabytes of memory, that means that you are using 20-megabytes of page tables.
Now let's trace the path of an incoming UDP DNS request. Each one is for a different domain, at random. This randomness is a problem, because the CPU cache only holds recently accessed data, but random domain queries haven't been recently accessed. That means as you walk through your data structures, each memory access will be a cache-miss. This means that instead of taking 1 nanosecond to read the L1 cache, 4 nanoseconds to read the L2 cache, or 10 nanoseconds to read the L3 cache, it'll take 80-nanoseconds to read DRAM.
At 10 million packets/second, that works out to only 100-nanoseconds per packet, so it sounds like we've used up all our time just waiting for that first cache miss. Things aren't as dire as they appear, though. First of all, we can process several packets in batches and issue "prefetches" on the data, so that much of the time the data will be in the cache by the time we need it. Secondly, a standard desktop supports 8 cores/threads, so our budget is more like 10 cache misses per packet rather than a single cache miss.
But we have a problem: virtual-memory. As I pointed out above, the page-tables alone for our massive .com DNS database is 20-megabytes in size, but our desktop CPU only has 8 megabytes of L3 cache. That means on average, not only will our desired memory cause a cache miss, it'll cause a second cache miss reading the page-table entry.
That's why a common solution in scenarios like this would be to move our code from user-mode into kernel-mode, the advantage being that in kernel-mode, you don't use virtual-memory. However, kernel-mode is Morally Wrong, and I'd rather have the Internet crash due to DDoS than put my code there.
The other solution is to use larger page tables. The small 4096 byte memory page isn't the only option. You can also use 2-megabyte pages. Both are supported simultaneously. That's because virtual-to-physical translation is a multi-step process, and you can set a flag to skip the last step for some addresses. If we allocate that large 10-gigabyte chunk as 5000 2-gigabyte pages, instead of 2.5-million 4096-byte pages, then we have a lot less to worry about. That 40k for the upper page tables will easily fit within our cache.
Let's look at how virtual-memory translation works. I've draw the following diagram to illustrate it.
The first step in translating an address is to grab the CSR3 register. This register is at the root of the memory hierarchy. Each time that the operating-system does a context-switch to a different process, it overwrites this register with a pointer to the top of the page-table hierarchy.
This register points to a 4096-byte block of memory (called "Page Map Level 4" or simply "L4" in the diagram) that contains 512 pointers, each 8 bytes in size. Remember that we need 8 bits to store a byte having 256 combinations, that means we need 9 bits to address 512 combinations. Thus, we grab the first 9 bits of our 48-bit address, then to a lookup in the L4 table, and thus find a pointer to our L3 table.
We repeat the process three more times, grabbing the next 9 bits from the address, looking up that value in our current table, getting a pointer to the next step. This process ends in the actual memory page we are looking for. At that point, we simply append to low 12 bits onto the end of the final pointer, thus getting our physical-address from the virtual-address.
In practice, the L4 table will have only a single entry that we every use, unless you have more than 512-gigabytes of RAM in a system. At the L3 level, we'll only have a single page of 512 entries that we'll ever use. Things start getting big at the L2 level, which as noted above, requires 40-kilobytes worth of data to handle our 10-gigabyte DNS .com database. Finally, the L1 level is what destroys us, requiring 20-megabytes to handle our 10-gigabyte database.
Not that processors have a special cache called the "TLB" or "translation lookaside buffer" that caches the results from this "page table walk". Thus, you don't have to do this on every memory access. TLB misses, as the are called, take up only a few percent of normal CPU time. However, the more we tackle Internet-scale problems, the more TLB misses become a problem, and the more we have to look for solutions.
Lucky for us, we can skip the L1 stage. Page table entries are a full 64-bits in size, but they only ever use the high-order bits. They don't use the low-order bits, except as status flags. The lowest bit is a flag that means "skip the next level". This is showing in the following diagram, where the L2 lookup leads directly to a 2-megabyte page, rather than than to an L1 lookup to a 4096 byte page:
All operating systems support the large pages. On Windows, use "VirtualAlloc()" with the flag "MEM_LARGE_PAGES". On Linux, compile the kernel with CONFIG_HUGETLBFS and use the call "mmap()".
The problem is that you may not be able to allocate 10-gigabytes worth of large pages. That's because as the operating system runs, it's constantly allocating/freeing the smaller 4096 byte pages, spreading them throughout the system. There may not be enough contiguous memory left to satisfy your request. (On Linux, you can set a boot option to allocate the memory for huge pages before this happens).
There is a downside the large memory pages. They can't be swapped of memory. Also, consider something like Apache that's constantly forking processes, setting "copy-on-write" bits in the page tables. Every fork forces a few 4096-byte pages to be copied, but now imagine how slow that would be if a couple 2-megabyte pages had to be copied for every fork. This means in general, small pages are better.
Fortunately, none of these disadvantages apply to our 10-gigabyte in-memory database. Indeed, had we not used large pages, we'd probably have configured the system to not page out that memory anyway.
Conclusion
This post describes an Internet-scale problem that can be serviced by desktop-scale hardware. The limiting factor isn't the hardware, but the software. With better software, we can tackle larger Internet-scale problems.
You can take any software, such as Nginx, BIND, SendMail, Snort, grab a tool like Intel's Vtune that monitors process-counters, create an Internet-scale workload to test them, and then see if virtual-memory issues like TLB-misses are a problem, and if so, change the memory allocators to large pages in appropriate places.
I drew the above diagrams using JavaScript and HTML5. For you enjoyment, I'm embedding the JavaScript code here:
The question that drives us is 'scalability'. It's a systemic anomaly inherent to the programming of the matrix.I'm too lazy to spend more time Googling the answer to this question, so I thought I'd just ask it in a blogpost. I can allocate memory with a larger pagesize than 4096 bytes using VirtualAlloc()/mmmap(). The next step up is the 2-megabyte pagesize, but can I also allocate the next level pagesize of 1-gigabyte? Explanation: On 32-bit processors, there were two levels of virtual memory. A 32-bit address was divided into 10-bits for the first level lookup, with the next 10-bits being used for the next stage lookup, with the final 12-bits resulting in a 4096 pagesize (10 + 10 + 12 = 32-bits). But, you could skip the second level lookup, thereby having a 22-bit page (or 4-megabytes). On 64-it processors, the 64-bit address is broken up into 9-bit chunks, with the last chunk remaining at 12-bits, meaning that the default pagesize is still 4096. In today's system, the upper bits in a virtual address aren't used, so addresses are only 48 bits, resulting in a four stage virtual-to-physical memory translation (9 + 9 + 9 + 9 + 12 == 48). Going up one level means you can get a 21-bit pagesize (2-megabytes instead of 4096-bytes). Going up two levels means a 30-bit pagesize, or 1-gigabyte. The x86 architecture supports this. And I assume it also supports going up further levels (39-bit pagesize of 0.5-terabytes), but that would be crazy. The question I have is that even though x86 supports this, does the operating system?The reason they wouldn't want to is because most such allocations would fail. As the system runs, it's allocating/freeing 4096 chunks of memory. While this may seem contiguous in virtual memory, it is in fact spread throughout physical memory. You might be able to allocate a contiguous 1-gigabyte chunk of memory at system startup, but as time goes on, you have less and less a chance of that succeeding. The reason they should support this is because it's something like 20 lines of code. It's extraordinarily easy to support. In addition, they could support it without telling you. To allocate memory for the existing 2-megabyte pagesize, you call VirtualAlloc() with the MEM_LARGE_PAGES flag. If you do this asking for 1-gigabyte, the operating system can first attempt a single 1-gigabyte page, and if that succeeds, return it to you, and if not, return you memory using the smaller pages. Let's say that you are trying to create a system supporting 8-million concurrent TCP connections. At 512-bytes per TCP control block (TCB), that means you need 4-gigabytes of RAM just to store the TCP information. This further means that you'll need 8-megabytes of RAM just for the last-level of the pagetable (and 16-kilobytes for the level above that). This 8-megabytes is as large as the L3 cache on processors. The upshot is that when a packet arrives, the TCP control block will cause a cache-miss and go to main memory, which will cost 100 cycles. But, resolving the pagetable will also hit main memory, causing another 100 clock cycles. And that's just the TCB. The socket structure, and then application-layer memory will all likewise have a double-hit to main memory. You are up to 600 clock cycles just to get the memory into the CPU for the packet and you haven't done anything yet. Not to mention that you've consumed an enormous of memory bandwidth. But if you use large pagesizes, then you get rid of half the problem. This is especially true of the 1-gigabyte size. As applications grow, so does the cost of virtual-memory to physical-memory translation. On typical applications, that cost is already 10%, and at scale, it can reach 50%. That's why people see moving their code into the kernel as the only solution, because it works with physical memory and gets rid of this overhead. But, at gigabyte pagesizes, this cost completely disappears. The translation will be cached in the TLB (translation lookaside buffer), making virtual-memory accesses just as fast as physical memory. There is a lot of good reasons to have small 4096 pages, such as supporting Apache-style programming of forking processes, where you want all the processors to "copy-on-write" page entries. It would be a horrible performance loss moving to 2-megabyte pages. But on the other hand, Apache is stupid, and smart software like Nginx would prefer to have a few larger pages. As networks continue to scale beyond where even Nginx is today, we might want even larger pages.
I'm on the opposite side of the political spectrum from Byron Sonne, in that I believe in "globalization", the "G20", and all that he opposes. But even I recognize that the case against him was a travesty. There was never any good evidence against him. Instead, he was guilty of being different, as different as the rest of us in cybersecurity.
What defines us is that we are interested in "security". For example, I was detained by TSA for taking pictures of their security. It's an act that is explicitly allowed by TSA guidelines, it poses no threat to airline safety, yet because it's unusual behavior, they detained me.
I was only detained for a couple hours, but had I been arrested and the FBI had grabbed all my emails, search history, and hard drives, they could probably build a case that I was plotting something evil. That's because there is a lot of strange stuff that can't be explained except by assuming that it's all part of my bigger master plan. For example, I bought some Teflon online for $50 to coat the surface of my desk because I was curious what that would feel like with the mouse, because I'm a geek, and that's the sort of thing geeks do. I can't imagine how Teflon could be used for Evil, but I'm sure whatever explanation the FBI comes up with will seem more plausible than the truth. (BTW, Teflon is not nearly as frictionless as I'd hoped).
In Sonne's case, they found "explosive" material. Is that because he's a terrorist planning to blow things up? Or is it because he's a rocketry enthusiast? Well, when you are police, the first explanation looms a whole lot more probable than the second.
That makes all of us guilty. We all appear as a threat to security, and we all do strange things that are most easily explained by whatever theory the police concoct. Which means that all of us can go through what Byron Sonne went through, divorce, losing his job, and losing his life's savings -- even when found innocent -- for the crime of simply being a bit odd.
Update: @SergeyBratus tweets "What might 'they' think if I do/say this" is the most powerful form of control".
What defines us is that we are interested in "security". For example, I was detained by TSA for taking pictures of their security. It's an act that is explicitly allowed by TSA guidelines, it poses no threat to airline safety, yet because it's unusual behavior, they detained me.
I was only detained for a couple hours, but had I been arrested and the FBI had grabbed all my emails, search history, and hard drives, they could probably build a case that I was plotting something evil. That's because there is a lot of strange stuff that can't be explained except by assuming that it's all part of my bigger master plan. For example, I bought some Teflon online for $50 to coat the surface of my desk because I was curious what that would feel like with the mouse, because I'm a geek, and that's the sort of thing geeks do. I can't imagine how Teflon could be used for Evil, but I'm sure whatever explanation the FBI comes up with will seem more plausible than the truth. (BTW, Teflon is not nearly as frictionless as I'd hoped).
In Sonne's case, they found "explosive" material. Is that because he's a terrorist planning to blow things up? Or is it because he's a rocketry enthusiast? Well, when you are police, the first explanation looms a whole lot more probable than the second.
That makes all of us guilty. We all appear as a threat to security, and we all do strange things that are most easily explained by whatever theory the police concoct. Which means that all of us can go through what Byron Sonne went through, divorce, losing his job, and losing his life's savings -- even when found innocent -- for the crime of simply being a bit odd.
Update: @SergeyBratus tweets "What might 'they' think if I do/say this" is the most powerful form of control".
The government has recently put out a scary advisory claiming hackers are targeting travelers with malicious popups on the hotel networks. Cybersec people travel a lot, so they can confirm this by checking their own hotel.
The easiest way is by doing a "view source" on an HTTP (not HTTPS) web page and see if anything has been added. There are two ways hackers might change things. The first is that they might replace the page completely with a framing page, and then stick the real page inside the frame. The second is that they simply append some JavaScript code at the end, either right before or right after the page.
Go to some some famous login page, like http://twitter.com (you have to turn off things like HTTPSEverywhere for this to work). Don't login, just look at the raw page with "view source". Hit Ctrl-Ato select the entire thing, then Ctrl-C to copy, then paste it into an email and send it to me (pcap@erratasec.com). You can also check it yourself for suspicious framing or trailing JavaScript at the end.
Better yet, start "windump" or "tcpdump" on your machine, save to file, and email me the file, after capturing the login page (but before you login).
What can the hackers have broken into in order to man-in-the-middle webpages?
1. They have an evil WiFi access-point you connected to instead of the hotel's.
2. They compromised the hotel's access-point and installed OpenWRT on it.
3. They compromised a deep-packet-inspect device inside the hotel's network
4. They compromised a device in the upstream network.
If you send me raw captures, I should be able to figure this out, especially if during the capture you do a traceroute.
I've setup an email address to receive this information: pcap@erratasec.com.
The easiest way is by doing a "view source" on an HTTP (not HTTPS) web page and see if anything has been added. There are two ways hackers might change things. The first is that they might replace the page completely with a framing page, and then stick the real page inside the frame. The second is that they simply append some JavaScript code at the end, either right before or right after the page.
Go to some some famous login page, like http://twitter.com (you have to turn off things like HTTPSEverywhere for this to work). Don't login, just look at the raw page with "view source". Hit Ctrl-A
Better yet, start "windump" or "tcpdump" on your machine, save to file, and email me the file, after capturing the login page (but before you login).
What can the hackers have broken into in order to man-in-the-middle webpages?
1. They have an evil WiFi access-point you connected to instead of the hotel's.
2. They compromised the hotel's access-point and installed OpenWRT on it.
3. They compromised a deep-packet-inspect device inside the hotel's network
4. They compromised a device in the upstream network.
If you send me raw captures, I should be able to figure this out, especially if during the capture you do a traceroute.
I've setup an email address to receive this information: pcap@erratasec.com.
According to this warning from the government, travelers are catching viruses from their hotel wifi. Should you be afraid?
No. Popups tricking you are a danger all the time, and all hotspots (whether at the hotel, or Starbucks, or the local bar) are always an increased danger. But they cite no evidence that hotels in particular are more dangerous.
That hotels are more dangerous is plausible. For example, some people have reported credible evidence of a hotel intercept browsing to give you more advertising, and some advertising networks are poor at filtering out malicious attacks. Combining these two, there may be a slightly higher incidence of infection at hotels. But only slightly, it's absurd thinking that hotels are a dramatically different threat, or that there's something special you should do to protect yourself at hotels that you wouldn't do everywhere.
The above advisory is especially deficient in it's recommendations of what you should do to protect yourself. People assume government agencies are more credible and more competent, but this advisory shows the reverse is true. The lack of evidence and bogus remedies demonstrate their incompetence.
It doesn't have to be the legitimate routers that do this (as it was in the Marriot or Tunisia cases). Instead, a hacker can create a hostile access-point, either an "evil twin" that pretends to be the same access-point right next to it (like one also named "Marriot Courtyard"), or simply an evil one with an independent name "Free WiFi".
This sort of evil access-point simply forwards traffic to the normal access-point, but changes things as described above. Hackers can buy $40 wall-wart access-points, re-flash them with a linux distro, and leave them behind in hotel rooms, coffee shops, airports, and so on. They'll likely earn more than $40 from hacking or advertising, so they don't mind the fact that eventually they'll get stolen.
No. Popups tricking you are a danger all the time, and all hotspots (whether at the hotel, or Starbucks, or the local bar) are always an increased danger. But they cite no evidence that hotels in particular are more dangerous.
That hotels are more dangerous is plausible. For example, some people have reported credible evidence of a hotel intercept browsing to give you more advertising, and some advertising networks are poor at filtering out malicious attacks. Combining these two, there may be a slightly higher incidence of infection at hotels. But only slightly, it's absurd thinking that hotels are a dramatically different threat, or that there's something special you should do to protect yourself at hotels that you wouldn't do everywhere.
The above advisory is especially deficient in it's recommendations of what you should do to protect yourself. People assume government agencies are more credible and more competent, but this advisory shows the reverse is true. The lack of evidence and bogus remedies demonstrate their incompetence.
Technical Details
The technical details are this: devices can change web pages as they pass through the device. The most common change is to append JavaScript to the end of a web-page (any web page) that does something interesting. That could be simply to do extra advertising, which was recently caught at a Marriot Hotel. Or, it could append code to steal passwords entered in the page, which repressive regimes like Tunisia were caught doing to their citizens. Or, it could popup a window telling somebody to download software.It doesn't have to be the legitimate routers that do this (as it was in the Marriot or Tunisia cases). Instead, a hacker can create a hostile access-point, either an "evil twin" that pretends to be the same access-point right next to it (like one also named "Marriot Courtyard"), or simply an evil one with an independent name "Free WiFi".
Back in 2005 I briefed some high-level military people about the danger of flash memory, how a worm infected computers can easily trash the boot flash, turning computers into bricks. Such a threat isn't targeted at desktops, but servers, routers, and SCADA control systems. In most of these systems, flash memory is soldered onto the motherboard, and but even those where it's not, replacing the flash isn't an easy process. The consequence is this: a mass attack against Cisco routers would take down large parts of the Internet for days, if not weeks. Such an attack against SCADA control systems in the power grid would cause a blackout that couldn't be fixed for weeks. On the other hand, the solution is straightforward: make the flash boot for these systems user-replaceable, and supply and extra two boot flashes with any system where failure of the flash is catastrophic. (You need two, because after the first attack, you are going to replace it and get pwned again, requiring a third for replacement after you've fixed what's going on). Also, change systems so that they require manual intervention before they can be updated. Unfortunately, most people will set the jumper once to "enable flash update" and never change it, so you need to make it a button that after you press it, will allow flash update only on the next reboot, but not after that until you press the button again. Apparently, the military is now using this scenario as a scare tactic as part of their power grab for more control of the Internet, as reported by NPR. Seriously, where did these people go to journalism school? Gen. Alexander and Mike McConnell have been exaggerating cybersecurity risks for several years now, and the press is eating it up without questioning their facts or their motivations, or talking to experts (I'm only one of many, judging from Twitter reactions) that believe otherwise. The NPR story totally distorts the risk. This isn't an "incident", hackers havne't done this yet, it's just something they could do in theory. This isn't a "vulnerability" that lets hackers break into computers, it's a risk of what might happen after hackers get through numerous defenses in order to reach those systems. There is no imminent threat here. Rather, it's an issue of long-term planning: when designing critical systems, assume that hackers can make computers not boot. This does not "underscore the need for public/private partnerships" or "information sharing" as NPR implies. Quite the opposite, the lies and distortions by Gen. Alexander indicate that the government cannot be trusted, and is probably a greater threat than hackers. No server farm has been lost to hackers destroying the boot flash, several have been lost from the FBI confiscating the haystack in search of needle. Why oh why doesn't the media have a left-wing bias? I'd've thought after the threat inflation that led to the Iraq War they would be more sensitive to such things.
In networking, a hardware "bypass" is a device that is inert when powered off, connecting copper wires or fiber optics straight through. But, when powered on, it flips relays, and redirects network traffic through an intermedia device, such as an IPS, load balancer, web accelerator, or web-app-firewall. If these devices fail, relays switch back, and traffic continues to flow as normal. You don't use these things for traditional firewalls, because you want things to "fail safe", to stop all traffic in case of failure, but you use these for pretty much every other inline device. The first bypass I know of was created by me back in 1998 for BlackICE Guard (the first IPS). This was back in the days with 100-mbps copper, when such devices could be built with simple relay switches. If I remember correctly, our first unit was an external device powered by the keyboard connection, and we used the serial port to communicate with it (level triggering with one of the RS-232 control pins). One startup, we first put the Ethernet adapters into forwarding mode, then sent a signal to flip the relays and insert ourselves into the traffic. We'd then ping the device on a regular basis to keep the relays open, so that if our software crashed, within a quart second, the relays would switch back again, allowing traffic to flow normally. The solution couldn't work for gigabit Ethernet, so we worked with a contract manufacturer to build one for us into the Ethernet card itself, who then immediately marketed it to other clients. None of our early IPS competitors had bypass, they assumed customers wanted an IPS to "fail safe" like a firewall, and was a major selling point for us. Now all IPSs have bypasses. We had to invent our own because we could find no existing solution, but these days, such things are quite common. There is a wikipedia page on it, and such cards readily available everywhere, such as from NewEgg.com. So my question is this: were we really the first? or does somebody know of an Ethernet bypass adapter that predates 1998? Also, does anybody have a picture of the first BlackICE bypass unit?
15 years ago, when we started the industry of white-hat hackers finding vulns and reporting them, "everyone knew" that open-source was more secure than closed-source because of the "many eyeballs" theory that the many people looking at open-source would find/fix bugs faster than in closed-source products. This was analogous to cryptography, where the only trustworthy crypto algorithms were those widely published and analyzed, and that anybody attempting "security through obscurity" by hiding their crypto algorithm was inevitably found to have made a serious mistake. But things never worked out this way. Open-source has failed to demonstrate any advantage in security. The problem is that while many eyeballs can look at open-source, they don't. Open-source programmers just don't have the incentive. They want to write new code and add new cool features, not try to break old stuff. Conversely, at Microsoft, many eyeballs do look at code. Microsoft pays them to, then pays other programers to attack the code with fuzzers and static analyzers. PHP may be more popular than Microsoft's ASP/.NET, but more eyeballs have looked at the Microsoft stuff. The recent "cgi-php" vuln is definite proof that the "many eyeballs" theory doesn't work. PHP is one of the most popular bits of code on the web. The vuln was obvious to any eyeballs looking at the code. Yet it sat there undiscovered for 7 years. I'm not saying Microsoft is any better, or that other factors don't exist that make open-source better than closed-source. I'm just saying that the "many eyeballs" theory has been proven false as much as any theory can be proven false. Things slip through the open-source development process that even a small number of "eyeballs" should've caught. The putative eyeballs haven't materialized. The days of open-source ideology is over, it's time we judged software on its individual merits, not its origin.
Update: On Twitter, Weev points out bug bounties. I think those are a winner. You can trust Google Chrome or Mozilla Firefox because they pay people to find bugs. This directs eyeballs their way. I trust Chrome over Internet Explorer not because it's open-source, but because they pay people to put eyeballs on it. Thus, the new axis is "bounties vs. no-bounties", not "open-source vs. close-source". Update: On Twitter, people are pointing out that we ought to "crowd-source" bug-bounties. Is "crowd-sourced" the new "open-source"? Update:On Twitter, Dan Kaminsky argues that it's not coder eyeballs that makes code secure, but user eyeballs.
#1#2#3#4#5#6
Update: On Twitter, Weev points out bug bounties. I think those are a winner. You can trust Google Chrome or Mozilla Firefox because they pay people to find bugs. This directs eyeballs their way. I trust Chrome over Internet Explorer not because it's open-source, but because they pay people to put eyeballs on it. Thus, the new axis is "bounties vs. no-bounties", not "open-source vs. close-source". Update: On Twitter, people are pointing out that we ought to "crowd-source" bug-bounties. Is "crowd-sourced" the new "open-source"? Update:On Twitter, Dan Kaminsky argues that it's not coder eyeballs that makes code secure, but user eyeballs.
#1#2#3#4#5#6
Google’s WiFi scandal is a good test of Internet activism. Are activists intellectuals with a special insight into the consequences of technology? Or are they more like dogs that chase every passing car? The implication is that Google was able to capture your personal information as they drove by in their StreetView cars. In fact, the data they collected is too fragmentary to be useful. Most WiFi is encrypted (and hence, not eavesdroppable), and even if unencrypted, chances are that StreetView collected nothing in the few seconds it took to drive by. In other words, Google had as much chance of capturing your password/email as they did of taking a picture at the precise moment you stepped out of your shower with the curtains open. Sure, such events happened a few thousand times, but this was tiny compared to the billions of homes StreetView drove past worldwide. This is the test for Internet privacy activists. They aren’t intellectuals. They don’t understand the technology of WiFi sniffing. They don’t understand that what Google collected is worthless. They assume the worst, about what Google was able to collect, and about Google’s intentions. It’s funny to watch. Google hasn’t been forthcoming with details about the WiFi overcollection because they recognize that there is a witch-hunt going on. Since any rational person should be able to recognize the overcollected data is worthless, any attack must therefore come from the lunatic fringe. But this convinces the fringe that there is an important cover-up. It’s like how the US keeps Area 51 secret (it’s a military base where they test stealth technology), which convinces the fringe that there is a UFO cover-up. You can verify this yourself. Download "BackTrack 5 r2", the well-known Linux destro with a bunch of hacking tools. Boot your laptop with BackTrack and run "Kismet", then drive around neighborhoods for a few hours. Then, back home, run the collected data through hacking tools like ‘dsniff’ or ‘ferret’ to see if you got anything useful. I consider myself an "activist", but I hate being lumped in with the fringe. The road to tyranny is paved with good intentions of ignorant activists. We should not have laws preventing StreetView from taking pictures of naked people in their bedrooms, we should instead expect people to close their curtains. We should not have laws preventing StreetView from collecting unencrypted data, we should expect people to encrypt. Freedom means personal responsibility, getting rid of personal responsibility gets rid of freedom.
Update: Some people have suggested other analogies. One is "lynch mob" instead of "witch hunt". Another is "cry wolf": Google deserves a lot of criticism, but when you attack them for invalid concerns, you destroy your credibility.
Update: You can easily counter the argument of this post by demonstrating how Google can use that overcollected data for evil.
Update: Some people have suggested other analogies. One is "lynch mob" instead of "witch hunt". Another is "cry wolf": Google deserves a lot of criticism, but when you attack them for invalid concerns, you destroy your credibility.
Update: You can easily counter the argument of this post by demonstrating how Google can use that overcollected data for evil.
One of the myths of CISPA (cybersecurity law) is that organizations do not have to share data with the government, that it's voluntary. The reality is that the government has lots of ways to pressure individuals/companies into volunteering.
In 2007, the FBI showed up at my office because of a speech I was to give two days later at BlackHat (the most important cybersecurity conference). They wanted me to cancel my talk because it was a threat to national security. This was crap: it was a threat to TippingPoint (I demonstrated how reverse engineering their signatures could disclose 0day vuln info). After trying to bribe me and threaten me to cancel my talk, TippingPoint got the FBI to do their dirty work.
It was a surreal experience. On one hand, the FBI kept repeating that they couldn't tell me to cancel my BlackHat talk, because we live in a free country with the First Amendment. On the other hand, they made it clear that if I did not "do the right thing" they would taint my FBI file so that I could never pass a background check, and could never work for the government again.
The FBI does the same thing when investigating cybercrime. If an organization doesn't voluntarily share with them the data on their servers, they get a broad warrant to come in and grab all computer equipment, regardless if it's related to the crime they are investigating or not.
Even if a site thinks there is only a 10% chance might obtain a warrant, it still has to comply, because that's a 10% chance they could kill the business.
The government is incompetent at cybersecurity. They are less able to secure their own systems than the private sector. Sharing private information with the government isn't going to change this -- this bill just provides a conduit for the government to get more information about its citizens that other laws (and the Bill of Rights) currently block.
Update: Some have questioned the relevance of this story to CISPA. The point is that they can intimidate you into volunteering. I'm an individual who stood up to the FBI on principle, but businesses won't. Almost all will opt-in to the CISPA data, because the government will make them an offer they can't refuse.
Update: Here is an example where the FBI first came and asked nicely for data, and when stimied, came back later and confiscated the servers: http://www.infosecisland.com/blogview/21186-FBI-Overreaches-with-May-First-Riseup-Server-Seizure.html.
Update: The Economist agrees that government will coerce companies into sharing data.
In 2007, the FBI showed up at my office because of a speech I was to give two days later at BlackHat (the most important cybersecurity conference). They wanted me to cancel my talk because it was a threat to national security. This was crap: it was a threat to TippingPoint (I demonstrated how reverse engineering their signatures could disclose 0day vuln info). After trying to bribe me and threaten me to cancel my talk, TippingPoint got the FBI to do their dirty work.
It was a surreal experience. On one hand, the FBI kept repeating that they couldn't tell me to cancel my BlackHat talk, because we live in a free country with the First Amendment. On the other hand, they made it clear that if I did not "do the right thing" they would taint my FBI file so that I could never pass a background check, and could never work for the government again.
The FBI does the same thing when investigating cybercrime. If an organization doesn't voluntarily share with them the data on their servers, they get a broad warrant to come in and grab all computer equipment, regardless if it's related to the crime they are investigating or not.
Even if a site thinks there is only a 10% chance might obtain a warrant, it still has to comply, because that's a 10% chance they could kill the business.
The government is incompetent at cybersecurity. They are less able to secure their own systems than the private sector. Sharing private information with the government isn't going to change this -- this bill just provides a conduit for the government to get more information about its citizens that other laws (and the Bill of Rights) currently block.
Update: Some have questioned the relevance of this story to CISPA. The point is that they can intimidate you into volunteering. I'm an individual who stood up to the FBI on principle, but businesses won't. Almost all will opt-in to the CISPA data, because the government will make them an offer they can't refuse.
Update: Here is an example where the FBI first came and asked nicely for data, and when stimied, came back later and confiscated the servers: http://www.infosecisland.com/blogview/21186-FBI-Overreaches-with-May-First-Riseup-Server-Seizure.html.
Update: The Economist agrees that government will coerce companies into sharing data.
I haven't been maintaining my Ferret program because I've been working a rewrite of the core engine that is super-duper. But then, my rewrite got too ambitious and it's in a state of perpetual incompleteness. Sigh.
So I've gone back and fixed the bugs with the original Ferret. In particular, 64-bit is the major issue. There is a bug preventing it from working on 64-bit. I've fixed the bug and now it seems to work just fine.
I've checked it into http://ferret.googlecode.com. If you are a developer, I can add you to the list of contributors.
Also, I've made it link to "libSegFault.so", which should print out more useful crash dumps. If it crashes, you can send that output to me (robert_david_graham@yahoo.com).
So I've gone back and fixed the bugs with the original Ferret. In particular, 64-bit is the major issue. There is a bug preventing it from working on 64-bit. I've fixed the bug and now it seems to work just fine.
I've checked it into http://ferret.googlecode.com. If you are a developer, I can add you to the list of contributors.
Also, I've made it link to "libSegFault.so", which should print out more useful crash dumps. If it crashes, you can send that output to me (robert_david_graham@yahoo.com).
As reported by Wired, the programmer who stole code from Goldman-Sachs had his conviction overturned because "code is not physical property", implying that it's somehow above the law, that there is some sort of right to open source code. That's an incorrect interpretation of the decision. The conviction was overturned because of technicalities, while the laws may have been intended to cover to this theft of code, their wording is outdated and cannot be stretched to cover this incident.
The decision says:
It clarifies later that the NSPA wording clearly means "physical good", and not intangible goods. It cites similar cases, such as bootleg recordings also being intangible goods not covered by the NSPA.
The ruling says that congress could easily amend the NSPA to include intangible goods. It's not that intangible goods are special and above the law, the issue is simply that the court doesn't find that the wording of the NSPA covers intangible goods.
The ruling likewise found that the crime didn't fall under the Economic Espionage Act (EEA) because the source code wasn't used for interstate or international commerce. The source code in question was for high-speed trading by Goldamn-Sachs, something that happened within the state of New York. Again, the court finds that while law makers might've intended to cover this theft of secrets, the fact that they specifically mention "interstate commerce" means that the law doesn't technically cover this incident.
People on Twitter are interpreting this as meaning that "code" is somehow above the law, that there is some natural right that code must be free and open. The ruling specifically tries to dispel this interpretation. It says only that the wording of existing laws doesn't cover this specific case, and that a minor change in wording would've covered it.
BTW, I'm not criticizing the above article. The article makes the same points I make. It's just that people can't read, and make assumptions without paying attention to the article itself.
The decision says:
the source code was not a "stolen" "good" within the meaning of the National Stolen Property Act (NSPA)
It clarifies later that the NSPA wording clearly means "physical good", and not intangible goods. It cites similar cases, such as bootleg recordings also being intangible goods not covered by the NSPA.
The ruling says that congress could easily amend the NSPA to include intangible goods. It's not that intangible goods are special and above the law, the issue is simply that the court doesn't find that the wording of the NSPA covers intangible goods.
The ruling likewise found that the crime didn't fall under the Economic Espionage Act (EEA) because the source code wasn't used for interstate or international commerce. The source code in question was for high-speed trading by Goldamn-Sachs, something that happened within the state of New York. Again, the court finds that while law makers might've intended to cover this theft of secrets, the fact that they specifically mention "interstate commerce" means that the law doesn't technically cover this incident.
People on Twitter are interpreting this as meaning that "code" is somehow above the law, that there is some natural right that code must be free and open. The ruling specifically tries to dispel this interpretation. It says only that the wording of existing laws doesn't cover this specific case, and that a minor change in wording would've covered it.
BTW, I'm not criticizing the above article. The article makes the same points I make. It's just that people can't read, and make assumptions without paying attention to the article itself.
But over the years, Slashdot as slid into irrelevancy. It remained largely unchanged for 15 years while other sites innovated. The "Slashdot" effect is more likely to come from Reddit, Twitter, or YCombinator than it is from Slashdot itself.
The "nail in the coffin" for Slashdot was the Jan 18 SOPA/PIPA protest. As other sites blacked out, like Wikipedia and Reddit, Slashdot continued business as usual. It mentioned the blackout, but only as yet another story that hackers might be interested in. It failed to participate in the hacker cause, as it would've at its height.
Slashdot actually died last August 2011 when its founder Rob "CmdrTaco" Malda finally quit. But we didn't realize it had died. For all we knew, he could've passed the torch to the next generation of smart hackers. But the lack of a Jan 18 blackout or April Fools pranks prove otherwise. The lights are on, but nobody is home. Its corporate owner is leaving the servers on as long as advertising pays for it, but is doing nothing else to the site.
Slashdot was on life support even before CmdTaco left. The wannabes had long ago chased away the real hackers. Once the leader in comment moderation, it now fails to separate signal from noise. It once decided to cap moderation at a measly +5 points, but that's now that's too few. Comments appealing to popular prejudices ("Microsoft is evil") quickly get those +5 points for being "insightful", drowning out truly insightful comments. In contrast, comment moderation actually works on Reddit and StackExchange. Moreover, your "karma" or "ranking" on these sites is what matters. People are even putting their ranking on StackExchange on their resumes, to demonstrate their mastery in their field.
I've been Slashdotted around once a year since 1998, back when I served my site from a DSL line on a Pentium 90-MHz server. Nowadays, even when one of my blog posts makes it onto the Slashdot front page, I'll still get more hits coming from Reddit or YCombinator or Twitter or Facebook.
For hackers, there is a lesson here: innovate or die. Slashdot was so afraid of losing existing readers that it failed to make necessary changes to attract new readers. The Internet is a source of constant revolution – no matter how many years you are ahead of the competition, they will catch up, and they will surpass you. The new "Slashdotted" is what they did to themselves – remain static for 15 years while everything else passed them by.
So Slashdot, I'll miss you. In the dotcom boom, your nerd news indeed mattered. I visited your site several times a day to see what was going on. I eagerly read what other hackers had to say about a story, and I competed to write original, interesting comments myself to max out my karma. But these days, visiting your site is a painful experience, like going back to the town where you grew up where everyone you knew has moved away.
R.I.P 2012
Alan Shimmel has a post claiming If The Best Technology Won We Would All Be Using OS/2. It’s not true, OS/2 wasn’t the best technology. And in any case, we are still using it.
OS/2 was only a 16-bit operating system when it was released in 1987. Sure, it was better than MS-DOS, but it was already behind the Amiga and Xenix, a Unix variant that ran in a full 32-bits on the 80386.
It wouldn’t be until 1992 that OS/2 would go a full 32-bits. By that time, IBM and Microsoft had forked the source code. The disagreement was over support of the Windows APIs. By this time, Windows had become too popular to ignore. By adding the APIs to OS/2, porting applications from 16-bits to 32-bits would be a minor code change. But not having the APIs would force a complete rewrite.
Thus, "IBM OS/2 Warp" became the 32-bit version without Windows compatibility, and "Microsoft Windows NT" (or simply "WinNT") was the version with Windows compatibility. Note that WinNT was not Windows, it was instead OS/2 with Windows backwards compatibility.
Even today, we retain many OS/2-isms in WinNT (now known as Windows 7). For example, "beginthread" is an OS/2 API. OS/2 had threads from the beginning, but Windows never did, so the threading APIs are naturally the OS/2 APIs. Some networking vulnerabilities (in SMB) actually come from OS/2.
Their first 32-bit versions (OS/2 2.0 vs WinNT 3.1) competed head-to-head in 1993. OS/2 had strengths, such as running older MS-DOS programs, but on the whole, WinNT was a much better technology in almost every other aspect, quite apart from it’s backwards compatibility with the Windows API.
Superior technology is rarely superior, but is instead a choice of tradeoffs. The Beta vs VHS war is a good example. Beta had twice the video quality as VHS, and is described as "better". But it had half the run time, so you couldn’t fit an entire movie on a single Beta tape. Beta lost because customers didn’t like the tradeoff, not because somehow VHS tricked people.
But sometime a product does make a huge advance. A good example is the Commodore Amiga. It was a generation ahead of any competing system when it was released in 1985, which is why it’s fondly remembered even today.
A similar thing happened in 1996 with the Microsoft/Intel alliance. Intel started shipping its "Pentium Pro" microprocessor, which was faster on every relevant benchmark than competing RISC processors. At the same time, Microsoft released WinNT 4.0, which was faster on every "C10K" style benchmark than any competing Unix operating system. In addition, you could cheaply put two Pentium Pro processors into a system for little more than price of one, and WinNT 4.0 supported both processors. WinNT then became Win2k, then WinXP, then now Win7.
The conclusion is this: back in late 1980s, the only thing OS/2 was better than was MS-DOS. But it did evolve into WinNT, which eventually did win because it was indeed the superior technology.
Diclaimer: My first job out of college in 1990 was programming on OS/2. It was much better than MS-DOS, but it's 16-bit nature was a pain. By 1994, I was programming on WinNT, which has been my favorite environment since, despite the fact that most of my code runs on Linux.
OS/2 was only a 16-bit operating system when it was released in 1987. Sure, it was better than MS-DOS, but it was already behind the Amiga and Xenix, a Unix variant that ran in a full 32-bits on the 80386.
It wouldn’t be until 1992 that OS/2 would go a full 32-bits. By that time, IBM and Microsoft had forked the source code. The disagreement was over support of the Windows APIs. By this time, Windows had become too popular to ignore. By adding the APIs to OS/2, porting applications from 16-bits to 32-bits would be a minor code change. But not having the APIs would force a complete rewrite.
Thus, "IBM OS/2 Warp" became the 32-bit version without Windows compatibility, and "Microsoft Windows NT" (or simply "WinNT") was the version with Windows compatibility. Note that WinNT was not Windows, it was instead OS/2 with Windows backwards compatibility.
Even today, we retain many OS/2-isms in WinNT (now known as Windows 7). For example, "beginthread" is an OS/2 API. OS/2 had threads from the beginning, but Windows never did, so the threading APIs are naturally the OS/2 APIs. Some networking vulnerabilities (in SMB) actually come from OS/2.
Their first 32-bit versions (OS/2 2.0 vs WinNT 3.1) competed head-to-head in 1993. OS/2 had strengths, such as running older MS-DOS programs, but on the whole, WinNT was a much better technology in almost every other aspect, quite apart from it’s backwards compatibility with the Windows API.
Superior technology is rarely superior, but is instead a choice of tradeoffs. The Beta vs VHS war is a good example. Beta had twice the video quality as VHS, and is described as "better". But it had half the run time, so you couldn’t fit an entire movie on a single Beta tape. Beta lost because customers didn’t like the tradeoff, not because somehow VHS tricked people.
But sometime a product does make a huge advance. A good example is the Commodore Amiga. It was a generation ahead of any competing system when it was released in 1985, which is why it’s fondly remembered even today.
A similar thing happened in 1996 with the Microsoft/Intel alliance. Intel started shipping its "Pentium Pro" microprocessor, which was faster on every relevant benchmark than competing RISC processors. At the same time, Microsoft released WinNT 4.0, which was faster on every "C10K" style benchmark than any competing Unix operating system. In addition, you could cheaply put two Pentium Pro processors into a system for little more than price of one, and WinNT 4.0 supported both processors. WinNT then became Win2k, then WinXP, then now Win7.
The conclusion is this: back in late 1980s, the only thing OS/2 was better than was MS-DOS. But it did evolve into WinNT, which eventually did win because it was indeed the superior technology.
Diclaimer: My first job out of college in 1990 was programming on OS/2. It was much better than MS-DOS, but it's 16-bit nature was a pain. By 1994, I was programming on WinNT, which has been my favorite environment since, despite the fact that most of my code runs on Linux.
There was no #Anonymous blackout on March 31. For example, here is a graph for traffic to one of those servers. As you can see, there is no unusual traffic today (Saturday, the far right of the graph). This Saturday's traffic looks little different than last Saturday's (to the left).
As to whether the threat was "real" is a philosophical question. Many famous #Anonymous identities (e.g. @YourAnonNews) disavowed it. But there is no single official "Anonymous", so nobody truly has the authority to disavow it. If enough people undertake the attack in the name of "Anonymous", then it's a "real" attack, regardless if some others disagree.
With that said, there was no easy download of the "ramp" tool. There was no link to it in the original PasteBin post that announced the attack. The whole point of DDoS is to distribute your tool to as many many people as possible so they can all attack the target. No tool distribution means no attack. Whether the person who authored the original PasteBin link intended to follow up with a posting of the "ramp" tool is an unanswered question. The number of people that would've downloaded and run the tool is likewise an unanswered question.
I tend to agree that it probably wouldn't have been popular in the #Anonymous community. And, as I pointed out earlier, it probably wouldn't have worked even with the full weight of #Anonymous behind it.
As to whether the threat was "real" is a philosophical question. Many famous #Anonymous identities (e.g. @YourAnonNews) disavowed it. But there is no single official "Anonymous", so nobody truly has the authority to disavow it. If enough people undertake the attack in the name of "Anonymous", then it's a "real" attack, regardless if some others disagree.
With that said, there was no easy download of the "ramp" tool. There was no link to it in the original PasteBin post that announced the attack. The whole point of DDoS is to distribute your tool to as many many people as possible so they can all attack the target. No tool distribution means no attack. Whether the person who authored the original PasteBin link intended to follow up with a posting of the "ramp" tool is an unanswered question. The number of people that would've downloaded and run the tool is likewise an unanswered question.
I tend to agree that it probably wouldn't have been popular in the #Anonymous community. And, as I pointed out earlier, it probably wouldn't have worked even with the full weight of #Anonymous behind it.
As a Libertarian, I of course believe that employers are free to ask for your Facebook password, and that you are free to refuse. This also could be because I'm a conceited jerk who believes that any employer would be lucky to hire me, so I believe I have the upper hand in the power struggle.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
But completely separate from that, giving your employer your Facebook password does not give them the right to use the password. In fact, using the password to logon could be considered a crime, such as "computer fraud and abuse" or "identity theft".
Facebook's current legal terms say this:
You will not share your password, (or in the case of developers, your secret key), let anyone else access your account, or do anything else that might jeopardize the security of your account.
That means you are in violation of those terms if you give your password to your prospective employer. But, hypothetically, Facebook could add to their terms:
A account may be accessed only by its owner, by logging in you agree that you are the person who owns the account.
This makes it clear that logging into somebody else's account is identity theft, which means employers can be prosecuted under existing fraud and abuse laws. Facebook could just monitor multiple logins from a single location of unrelated accounts, and then send the police to go arrest the employer.
Of course, employers can respond by insisting that users log onto their own accounts during the interview process, but this is still an improvement. Presumably if one employer rejects you because those drunken nude party photos, you could remove them before the next job interview.
In the news, it appears that Chinese hackers got hold of the secret proof-of-concept (PoC) exploit for the recent Microsoft RDP bug. The most likely culprit was Microsoft’s MAPP program, which gives PoCs to security vendors 24 hours ahead of the patch so that they update their products to protect against the bug, to provide "zero-day" protection.
The MAPP program and zero-day protection is largely a scam. Vendors don’t use the provided PoCs to protect against the underlying vuln. Instead, vendors just write signatures that trigger on the PoC itself, but which are unlikely to detect exploits written by hackers that appear later in the wild.
In other words, MAPP’s PoCs are more likely to leak out and help hackers than they are to help IPS vendors.
Take, for example, the TippingPoint IPS. It is based on "pattern-matching" technology, which means most of their signatures trigger on known exploits rather than the underlying vuln. That means when they release "zero-day" protection, they are really just triggering on the MAPP PoC. Yet, they mislead there to customers about this. Their RDP advisory promises "TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 12138".
The truth is that the only zero-day protection they provide is against the MAPP PoC that was leaked to the Chinese hackers, not to the underlying vulnerability itself.
Not all vendors lie. Compare the TippingPoint inflated claims of protection with the equivalent Symantec RDP advisory which says "This signature detects attempts to exploit a remote code execution vulnerability in Microsoft RDP".
Sure, the language is a bit confusing, and can be interpreted as meaning "the vulnerability". But the slight change in wording means that the only thing they are promising is protection against the one known exploit (the MAPP PoC).
To protect against the vulnerability, and not just known exploits, you have to write code that decodes the RDP protocol. The vulnerability is in the "maxChannelIds" field, which is encoded with "BER". The typical encoding would look like "02 01 00", but Luigi Auriemmia (the creator of the PoC) change the encoding to be "02 04 00 00 00 00". This is how he knows it was his PoC – the packet used in the Chinese exploit contained all his changes.
Here is a list of some of the infinite number of encodings for this field:
Which of these encodings trigger the TippingPoint filter 12138? If only the first couple encodings trigger, then TippingPoint is lying about providing zero-day protection of the vulnerability. If all the above encodings trigger, then they are probably telling the truth.
Beware that you can’t actually use those 5 patterns I list above. The last time I made this criticism, TippingPoint simply added my patterns to their signature list, thus passing my test. So you have to use valid encodings of BER integers that aren’t already published. (You have no idea how irritating it is to reverse engineer a TippingPoint box only to find signatures that trigger only on a pattern discussed in a PowerPoint slide about how to change patterns to evade detection).
If somebody has a TippingPoint box (or any other IDS/IPS) that I can access remotely, I’d love to try this out. I’ll just grab the PoC, make some changes to the protocol, and see if the box triggers.
Full disclosure: I have worked with MAPP PoCs in the past. Back then, we struggled to create good "vulnerability" signatures that detected all possible variations. The process wasn't perfect, but we'd catch 0day exploits with different patterns about 2 times out of 3. This is far better than the crappy competing signatures that would trigger on the "AAAA" pattern designed to get EIP at 0x41414141 (i.e. hackers would have to change the pattern to something other than "AAAA" to get it to work -- which means by definition, the signature could never detect anything other than the PoC).
The MAPP program and zero-day protection is largely a scam. Vendors don’t use the provided PoCs to protect against the underlying vuln. Instead, vendors just write signatures that trigger on the PoC itself, but which are unlikely to detect exploits written by hackers that appear later in the wild.
In other words, MAPP’s PoCs are more likely to leak out and help hackers than they are to help IPS vendors.
Take, for example, the TippingPoint IPS. It is based on "pattern-matching" technology, which means most of their signatures trigger on known exploits rather than the underlying vuln. That means when they release "zero-day" protection, they are really just triggering on the MAPP PoC. Yet, they mislead there to customers about this. Their RDP advisory promises "TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 12138".
The truth is that the only zero-day protection they provide is against the MAPP PoC that was leaked to the Chinese hackers, not to the underlying vulnerability itself.
Not all vendors lie. Compare the TippingPoint inflated claims of protection with the equivalent Symantec RDP advisory which says "This signature detects attempts to exploit a remote code execution vulnerability in Microsoft RDP".
Sure, the language is a bit confusing, and can be interpreted as meaning "the vulnerability". But the slight change in wording means that the only thing they are promising is protection against the one known exploit (the MAPP PoC).
To protect against the vulnerability, and not just known exploits, you have to write code that decodes the RDP protocol. The vulnerability is in the "maxChannelIds" field, which is encoded with "BER". The typical encoding would look like "02 01 00", but Luigi Auriemmia (the creator of the PoC) change the encoding to be "02 04 00 00 00 00". This is how he knows it was his PoC – the packet used in the Chinese exploit contained all his changes.
Here is a list of some of the infinite number of encodings for this field:
02 04 00 00 00 00
02 01 00
02 02 00 00
02 81 03 00 00 00
02 84 00 00 00 08 00 00 00 00 00 00 00 00
Which of these encodings trigger the TippingPoint filter 12138? If only the first couple encodings trigger, then TippingPoint is lying about providing zero-day protection of the vulnerability. If all the above encodings trigger, then they are probably telling the truth.
Beware that you can’t actually use those 5 patterns I list above. The last time I made this criticism, TippingPoint simply added my patterns to their signature list, thus passing my test. So you have to use valid encodings of BER integers that aren’t already published. (You have no idea how irritating it is to reverse engineer a TippingPoint box only to find signatures that trigger only on a pattern discussed in a PowerPoint slide about how to change patterns to evade detection).
If somebody has a TippingPoint box (or any other IDS/IPS) that I can access remotely, I’d love to try this out. I’ll just grab the PoC, make some changes to the protocol, and see if the box triggers.
Full disclosure: I have worked with MAPP PoCs in the past. Back then, we struggled to create good "vulnerability" signatures that detected all possible variations. The process wasn't perfect, but we'd catch 0day exploits with different patterns about 2 times out of 3. This is far better than the crappy competing signatures that would trigger on the "AAAA" pattern designed to get EIP at 0x41414141 (i.e. hackers would have to change the pattern to something other than "AAAA" to get it to work -- which means by definition, the signature could never detect anything other than the PoC).
You'd think that politics has nothing to do with cybersecurity, but it does. You can often guess a person's political leanings by their opinions on cybersecurity.
For example, I'm a Libertarian. Because of this, I oppose concepts like "defense in depth". I claim that "the Internet is secure enough", and that "cybersecurity is a tradeoff". These things just flow unsurprisingly from the Libertarian way of looking at the world.
Therefore, I assumed McCain would be better than Obama at helping cybersecurity regulation. McCain talked about the old nasty telcoms regulation that stifled early Internet growth. He demonstrated understanding of the way laws killed innovation,. even though he didn't understand the Internet itself. Conversely, Obama preached how government was going to change the Internet for the better. I think think government can do little to make the Internet better, but can inadvertently do much to make things much worse, so I endorsed McCain. A fatuous thing to do, of course, but since Google endorsed Obama, I went ahead with it.
But the reverse happened. Obama has been largely "hands-off" on the Internet, letting the DHS, NSA, and DoD fight their turf war to see who'd get control of cyberspace. Meanwhile, McCain has been pushing exactly the sort of legislation I feared most, such as his recently introduced cybersecurity bill, described by some as "Orwellian" the way it gives government control over the Internet. McCain was also one of the chief sponsors of the NDAA amendment that authorizes the president to suspend habeas corpus (not precisely cybersec related, but something every cybersec person I know opposes). [My libertarian friends chide me, pointing out that McCains attacks on free-speech in the past demonstrated that he didn't really believe in civil liberties, so that I should've known.]
So I was wrong about McCain, so very very wrong.
This post is just to jot down interest bits of info on the Sabu arrest. All the good stories with details appear in the first few hours, then the Internet fills up with crud, and I can no longer find the original stories via Google.
Fox News as the original stories at these links:
http://www.foxnews.com/scitech/2012/03/06/hacking-group-lulzsec-swept-up-by-law-enforcement/
http://www.foxnews.com/scitech/2012/03/06/exclusive-inside-lulzsec-mastermind-turns-on-his-minions/
http://www.foxnews.com/scitech/2012/03/06/exclusive-unmasking-worlds-most-wanted-hacker/
They caught him because just once, he logged onto IRC without going through Tor, revealing to the FBI his IP address. This reveals a little bit about the FBI, namely that they've infiltrated enough of the popular IRC relays to be able to get people's IP addresses. We've always suspected they could, now we know.
This is a good lesson for Tor users. Tor, itself, is not enough to keep your identity hidden. It "fails open", which means that if you make a mistake, you'll expose your IP address. If "they" are coming after you, you need to configure a "fail close" network setup, such as by using a second machine as a transparent Tor proxy, such that everything is forced through Tor no matter what you do, and if the Tor service fails, your network connectivity also fails (fail close). Update: Two commenters think I'm criticizing Tor. I'm not. It's like that fact that crypto isn't enough to keep your data private. The FBI cannot crack AES128, but if you've chosen a poor password, they can crack that. It's not AES128's fault you chose a bad password. It's likewise not Tor's fault you bypassed it in order to log onto IRC. It's just that you should be aware of the importance of choosing good passwords, and practicing good Tor hygiene.
Another lesson about the FBI is that this is how they always work. You don't expect arrests right away after a major hack. Instead, the FBI will plod along for a year infiltrating as much of the organization as they can, turning key members, gathering hard evidence, and THEN they swoop in and gather everyone up.
This is mostly because hard evidence of past crimes is hard to get. You need evidence of future crimes. Once you've infiltrated the organization and can monitor what they are doing in real time, you'll get evidence of the crimes as they are happening, evidence you couldn't get on their previous crimes.
And the evidence the FBI most wants is for things like "conspiracy" [most of those arrested today are indicted on conspiracy]. Proving you committed a crime is hard, proving you conspired to commit it (by monitoring IRC) is pretty easy. Unless they find the stolen credit card numbers on your laptop, they'll find it difficult convicting you of cybercrime. But they can convict you of conspiracy, intent, obstruction of of justice, racketeering, and so on. For example, the Palin hacker was convicted of only misdemeanor hacking, but felony obstruction of justice because he deleted evidence of the hack.
When your little group has done something really bad, and you realize you've gotten over your head and the the FBI is coming after you, you have the prisoner's dilemma to consider. The first one of you that cracks and helps the FBI track everyone else down will get the sweetheart deal, and everyone else will go to jail. I can't see myself doing this, but at the same time, I can't see myself getting involved in such cybercrime.
Anyway, this is just my notes page. As my stories appear on this subject, I'm going to keep updating this post.
--
From the Jimmy Graham in the comments section comes this article (http://www.informationweek.com/news/security/attacks/231000584) from last June that outed Sabu's identity. It points to this pastebin (http://pastebin.com/iVujX4TR) which dumps some key data on their identities. I'm surprised we all missed this back then.
--
Official FBI press statement: http://www.fbi.gov/newyork/press-releases/2012/six-hackers-in-the-united-states-and-abroad-charged-for-crimes-affecting-over-one-million-victims
---
Post from IBtimes (http://www.ibtimes.co.uk/articles/293742/20120206/antisec-anonymous-hackers-fbi-anti-security-hack.htm) from a month ago that looks completely different now that this has been revealed.
---
Post from The Guardian (http://www.guardian.co.uk/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi?CMP=twt_gu) that regurgitates the Fox News article, though they have some good links to their past coverage of Sabu, such as this article (http://www.guardian.co.uk/technology/2011/jun/24/inside-lulzsec-chatroom-logs-hackers) from last June (around the time Sabu was secretly arrested) discussing leaked chat logs of the LulzSec group.
--
This document (http://blog.wearpants.org/media/namshub.pdf) outs a lot of Anonymous, I'm not sure when it was posted, but it apparently identified Sabu before today's announcement.
--
This post from last December (http://rickey-g.blogspot.com/2011/12/anonymousabu-aka-xavier-de-leon.html) finds some clues to Sabu's identity, which in hindsight, appear to be true.
--
Wild eye ravings? Is FBI and/or Anymous behind everything? (http://www.deathandtaxesmag.com/179764/anonymous-has-grown-beyond-lulzsec-and-sabu/) Dispels the more extreme notions of the FBI, but still assumes that that the FBI is controlled by corporate/political interests.
--
A paper written describing what LulzSec is: http://pastehtml.com/view/blpmqrn78.html
--
Six things you didn't know about Sabu: http://www.buzzfeed.com/jwherrman/five-things-you-didnt-know-about-sabu-the-lulzse
--
Sabu's indictment: http://www.nypost.com/rw/nypost/2012/03/06/media/030612_hackers.pdf
--
Sabu assumed he was an FBI agent, rather than just a CI: http://gawker.com/5890901/anonymous-snitch-tried-and-failed-to-pass-himself-off-as-an-fbi-agent-last-month (Has he never watched "White Collar" TV show??)
--
Barret Brown, who sometimes acts as a spokesman, had his house raided :http://www.nytimes.com/2012/03/07/technology/lulzsec-hacking-suspects-are-arrested.html?_r=3
--
Interesting Gawker piece (http://gizmodo.com/5890825/lulzsec-leader-betrays-all-of-anonymous) with chat logs with "Virus", a detractor of Sabu who has been claiming Sabu was a snitch nearly from the moment Sabu became a snitch.
--
Great piece from Ars Technica on how Sabu led them to Hammond: http://arstechnica.com/tech-policy/news/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon.ars
--
Fox News as the original stories at these links:
http://www.foxnews.com/scitech/2012/03/06/hacking-group-lulzsec-swept-up-by-law-enforcement/
http://www.foxnews.com/scitech/2012/03/06/exclusive-inside-lulzsec-mastermind-turns-on-his-minions/
http://www.foxnews.com/scitech/2012/03/06/exclusive-unmasking-worlds-most-wanted-hacker/
They caught him because just once, he logged onto IRC without going through Tor, revealing to the FBI his IP address. This reveals a little bit about the FBI, namely that they've infiltrated enough of the popular IRC relays to be able to get people's IP addresses. We've always suspected they could, now we know.
This is a good lesson for Tor users. Tor, itself, is not enough to keep your identity hidden. It "fails open", which means that if you make a mistake, you'll expose your IP address. If "they" are coming after you, you need to configure a "fail close" network setup, such as by using a second machine as a transparent Tor proxy, such that everything is forced through Tor no matter what you do, and if the Tor service fails, your network connectivity also fails (fail close). Update: Two commenters think I'm criticizing Tor. I'm not. It's like that fact that crypto isn't enough to keep your data private. The FBI cannot crack AES128, but if you've chosen a poor password, they can crack that. It's not AES128's fault you chose a bad password. It's likewise not Tor's fault you bypassed it in order to log onto IRC. It's just that you should be aware of the importance of choosing good passwords, and practicing good Tor hygiene.
Another lesson about the FBI is that this is how they always work. You don't expect arrests right away after a major hack. Instead, the FBI will plod along for a year infiltrating as much of the organization as they can, turning key members, gathering hard evidence, and THEN they swoop in and gather everyone up.
This is mostly because hard evidence of past crimes is hard to get. You need evidence of future crimes. Once you've infiltrated the organization and can monitor what they are doing in real time, you'll get evidence of the crimes as they are happening, evidence you couldn't get on their previous crimes.
And the evidence the FBI most wants is for things like "conspiracy" [most of those arrested today are indicted on conspiracy]. Proving you committed a crime is hard, proving you conspired to commit it (by monitoring IRC) is pretty easy. Unless they find the stolen credit card numbers on your laptop, they'll find it difficult convicting you of cybercrime. But they can convict you of conspiracy, intent, obstruction of of justice, racketeering, and so on. For example, the Palin hacker was convicted of only misdemeanor hacking, but felony obstruction of justice because he deleted evidence of the hack.
When your little group has done something really bad, and you realize you've gotten over your head and the the FBI is coming after you, you have the prisoner's dilemma to consider. The first one of you that cracks and helps the FBI track everyone else down will get the sweetheart deal, and everyone else will go to jail. I can't see myself doing this, but at the same time, I can't see myself getting involved in such cybercrime.
Anyway, this is just my notes page. As my stories appear on this subject, I'm going to keep updating this post.
--
From the Jimmy Graham in the comments section comes this article (http://www.informationweek.com/news/security/attacks/231000584) from last June that outed Sabu's identity. It points to this pastebin (http://pastebin.com/iVujX4TR) which dumps some key data on their identities. I'm surprised we all missed this back then.
--
Official FBI press statement: http://www.fbi.gov/newyork/press-releases/2012/six-hackers-in-the-united-states-and-abroad-charged-for-crimes-affecting-over-one-million-victims
---
Post from IBtimes (http://www.ibtimes.co.uk/articles/293742/20120206/antisec-anonymous-hackers-fbi-anti-security-hack.htm) from a month ago that looks completely different now that this has been revealed.
---
Post from The Guardian (http://www.guardian.co.uk/technology/2012/mar/06/lulzsec-sabu-working-for-us-fbi?CMP=twt_gu) that regurgitates the Fox News article, though they have some good links to their past coverage of Sabu, such as this article (http://www.guardian.co.uk/technology/2011/jun/24/inside-lulzsec-chatroom-logs-hackers) from last June (around the time Sabu was secretly arrested) discussing leaked chat logs of the LulzSec group.
--
This document (http://blog.wearpants.org/media/namshub.pdf) outs a lot of Anonymous, I'm not sure when it was posted, but it apparently identified Sabu before today's announcement.
--
This post from last December (http://rickey-g.blogspot.com/2011/12/anonymousabu-aka-xavier-de-leon.html) finds some clues to Sabu's identity, which in hindsight, appear to be true.
--
Wild eye ravings? Is FBI and/or Anymous behind everything? (http://www.deathandtaxesmag.com/179764/anonymous-has-grown-beyond-lulzsec-and-sabu/) Dispels the more extreme notions of the FBI, but still assumes that that the FBI is controlled by corporate/political interests.
--
A paper written describing what LulzSec is: http://pastehtml.com/view/blpmqrn78.html
--
Six things you didn't know about Sabu: http://www.buzzfeed.com/jwherrman/five-things-you-didnt-know-about-sabu-the-lulzse
--
Sabu's indictment: http://www.nypost.com/rw/nypost/2012/03/06/media/030612_hackers.pdf
--
Sabu assumed he was an FBI agent, rather than just a CI: http://gawker.com/5890901/anonymous-snitch-tried-and-failed-to-pass-himself-off-as-an-fbi-agent-last-month (Has he never watched "White Collar" TV show??)
--
Barret Brown, who sometimes acts as a spokesman, had his house raided :http://www.nytimes.com/2012/03/07/technology/lulzsec-hacking-suspects-are-arrested.html?_r=3
--
Interesting Gawker piece (http://gizmodo.com/5890825/lulzsec-leader-betrays-all-of-anonymous) with chat logs with "Virus", a detractor of Sabu who has been claiming Sabu was a snitch nearly from the moment Sabu became a snitch.
--
Great piece from Ars Technica on how Sabu led them to Hammond: http://arstechnica.com/tech-policy/news/2012/03/stakeout-how-the-fbi-tracked-and-busted-a-chicago-anon.ars
--
Sabu's Reddit Ask-Me-Anything thread, Sep'11:reddit.com/r/IAmA/comment… "Stick to yourselves. Friends will try to take you down if they have to."
(Update: this post is not obsolete, as Ruby-on-Rails is actually going to fix the problem, and this humorous post explains the controversy better than my post).
For those who don’t speak Russian or Ruby-on-Rails, I thought I’d translate the recent GitHub hack controversy.
The underlying issue is an "Insecure Direct Object Reference", #4 on the OWASP Top 10 list of most important web-application vulnerabilities. It means that that a hacker can change what's in the website database without having permission.
The cause of the GitHub hack was the toolkit/programming-language they used to build their site: Ruby-on-Rails. Ruby-on-Rails supports a feature known as "mass assignment". It means that hackers can add parameters to webrequests that don’t belong there, and they’ll be assigned to the object along with the normal parameters. In other words, your account might have a flag otherwise invisible to you like "admin=false". By including "user[admin]=true" in an otherwise innocent web request, you can give yourself administrator privileges and take over the site.
This "mass assignment" feature is pretty toxic, at least as far as cybersecurity goes. It’s one of those big features that make Ruby-on-Rails so easy to use in order to build websites. Fixing the security problem therefore makes it harder to program websites in Ruby-on-Rails, and would instantly break most existing websites built using the toolkit.
That’s why when Russian programmer Egor Homakov reported the "bug", it was rejected. The argument was that this is behaving by design, and that while it was dangerous, it was prominently described in the "Ruby On Rails Security Guide". There is a solution for programmers: "blacklist" values that should not be mass assignable, such as marking "admin" as something that causes a mass assignment to fail. In other words, it’s the owner’s responsibility to not shoot themselves in the foot, not the gun manufacturer’s.
Any cybersecurity professional knows this is wrong, but being Russian, Homakov’s English skills aren’t so good at arguing his point. So he used his hacking skills instead, and used the bug to hack into GitHub.
GitHub and Ruby-on-Rails are independent projects that are otherwise unrelated to each other. GitHub is a popular project hosting site, and it just so happens that one of the zillions of projects it hosts is "Ruby-on-Rails". On the other side, Ruby-on-Rails is a toolkit for creating websites, and it just so happens that one of the zillions of websites written with Ruby-on-Rails is "GitHub".
This gave Homakov a neat opportunity. He wanted the owners of the Ruby-on-Rails project to take him seriously, so what better way to do that than hack the very site hosting Ruby-on-Rails using the very bug he was talking about? He used the bug to hack into GitHub, and gave himself administrative control over the Ruby-on-Rails project. He used this hacked authority to then write a comment into the Ruby-on-Rails source code discussing the problem.
It took no time at all for GitHub to fix that one bug, by blacklisting the hacked value so nobody can repeat the hack. But GitHub can’t be sure that there aren’t more mass assignment problems in their source code waiting to be discovered. Given any complex website written in Ruby-on-Rails, there is a good chance you can eventually find a mass assignment bug if you try hard enough.
There are a few cybersecurity lessons here.
The first lesson is that when you own a gun that accidentally fires 1% of the time you pick it up, then you’ll eventually shoot yourself in the foot. The same is true of Ruby-on-Rail’s mass assignment: you’ll eventually shoot yourself in the foot. It’s inherently dangerous, you can’t consider it for your next big project until this bug is fixed -- and since fixing this bug will break all existing Ruby-on-Rails websites, I doubt that will ever happen.
The second lesson is that "blacklisting" doesn’t work. We’ve tried blacklisting known bad characters (like ') from SQL, and found it doesn’t stop SQL injection. We’ve tried blacklisting known bad characters (like <) from HTML, and found it doesn’t stop cross site scripting. You can’t expect programmers to correctly blacklist all variables that shouldn’t be set with mass assignment, because they’ll eventually forget one, a hacker will find it, and break in. Instead, you have to "whitelist" known safe variables, where the consequence of a programmer error is simply a bug in the website, not a hack.
The third lesson is that there is no good solution to the problem. Ruby-on-Rails already has plenty of what appear to be good solutions -- that fail. If you put "ActiveRecord::Base.send(:attr_accessible, nil)" in the file "config/initializers/disable_mass_assignment.rb", you will fix the problem the way it should be fixed. But while good for you, most programmers still won’t use it,and there will still be a pervasive problem with mass assignment. We’ve had an obvious solution to SQL injection for a decade ("parameterized queries"), but most programmers still don’t use them, so SQL injection is still the web application’s #1 problem. "Insecure direct object reference" will stay at #4, or even rise to #3, until the Ruby-on-Rails project makes a change.
The fourth lesson is understanding "ease of use". Mass assignment makes creating websites a lot easier. But it makes securing websites much harder. You lose more in security than you gain in ease-of-use of the toolkit. As the GitHub hack showed, if you are putting your site on the Internet, security isn't an option. You don't need to fix every security problem, you don't even need to fix everything in the OWASP Top 10. But if you ignore the the top 4, you are a fool.
Finally, this shows the benefit of irresponsible disclosure. Homakov possibly broke the law, or at least, behaved "unethically" according to many people’s definition. Yet, it was not malicious, and caused no harm (other than deserved harm to reputation). It was the level of "disclosure" needed to bring what I feel is necessary attention to the problem.
For those who don’t speak Russian or Ruby-on-Rails, I thought I’d translate the recent GitHub hack controversy.
The underlying issue is an "Insecure Direct Object Reference", #4 on the OWASP Top 10 list of most important web-application vulnerabilities. It means that that a hacker can change what's in the website database without having permission.
The cause of the GitHub hack was the toolkit/programming-language they used to build their site: Ruby-on-Rails. Ruby-on-Rails supports a feature known as "mass assignment". It means that hackers can add parameters to webrequests that don’t belong there, and they’ll be assigned to the object along with the normal parameters. In other words, your account might have a flag otherwise invisible to you like "admin=false". By including "user[admin]=true" in an otherwise innocent web request, you can give yourself administrator privileges and take over the site.
This "mass assignment" feature is pretty toxic, at least as far as cybersecurity goes. It’s one of those big features that make Ruby-on-Rails so easy to use in order to build websites. Fixing the security problem therefore makes it harder to program websites in Ruby-on-Rails, and would instantly break most existing websites built using the toolkit.
That’s why when Russian programmer Egor Homakov reported the "bug", it was rejected. The argument was that this is behaving by design, and that while it was dangerous, it was prominently described in the "Ruby On Rails Security Guide". There is a solution for programmers: "blacklist" values that should not be mass assignable, such as marking "admin" as something that causes a mass assignment to fail. In other words, it’s the owner’s responsibility to not shoot themselves in the foot, not the gun manufacturer’s.
Any cybersecurity professional knows this is wrong, but being Russian, Homakov’s English skills aren’t so good at arguing his point. So he used his hacking skills instead, and used the bug to hack into GitHub.
GitHub and Ruby-on-Rails are independent projects that are otherwise unrelated to each other. GitHub is a popular project hosting site, and it just so happens that one of the zillions of projects it hosts is "Ruby-on-Rails". On the other side, Ruby-on-Rails is a toolkit for creating websites, and it just so happens that one of the zillions of websites written with Ruby-on-Rails is "GitHub".
This gave Homakov a neat opportunity. He wanted the owners of the Ruby-on-Rails project to take him seriously, so what better way to do that than hack the very site hosting Ruby-on-Rails using the very bug he was talking about? He used the bug to hack into GitHub, and gave himself administrative control over the Ruby-on-Rails project. He used this hacked authority to then write a comment into the Ruby-on-Rails source code discussing the problem.
It took no time at all for GitHub to fix that one bug, by blacklisting the hacked value so nobody can repeat the hack. But GitHub can’t be sure that there aren’t more mass assignment problems in their source code waiting to be discovered. Given any complex website written in Ruby-on-Rails, there is a good chance you can eventually find a mass assignment bug if you try hard enough.
There are a few cybersecurity lessons here.
The first lesson is that when you own a gun that accidentally fires 1% of the time you pick it up, then you’ll eventually shoot yourself in the foot. The same is true of Ruby-on-Rail’s mass assignment: you’ll eventually shoot yourself in the foot. It’s inherently dangerous, you can’t consider it for your next big project until this bug is fixed -- and since fixing this bug will break all existing Ruby-on-Rails websites, I doubt that will ever happen.
The second lesson is that "blacklisting" doesn’t work. We’ve tried blacklisting known bad characters (like ') from SQL, and found it doesn’t stop SQL injection. We’ve tried blacklisting known bad characters (like <) from HTML, and found it doesn’t stop cross site scripting. You can’t expect programmers to correctly blacklist all variables that shouldn’t be set with mass assignment, because they’ll eventually forget one, a hacker will find it, and break in. Instead, you have to "whitelist" known safe variables, where the consequence of a programmer error is simply a bug in the website, not a hack.
The third lesson is that there is no good solution to the problem. Ruby-on-Rails already has plenty of what appear to be good solutions -- that fail. If you put "ActiveRecord::Base.send(:attr_accessible, nil)" in the file "config/initializers/disable_mass_assignment.rb", you will fix the problem the way it should be fixed. But while good for you, most programmers still won’t use it,and there will still be a pervasive problem with mass assignment. We’ve had an obvious solution to SQL injection for a decade ("parameterized queries"), but most programmers still don’t use them, so SQL injection is still the web application’s #1 problem. "Insecure direct object reference" will stay at #4, or even rise to #3, until the Ruby-on-Rails project makes a change.
The fourth lesson is understanding "ease of use". Mass assignment makes creating websites a lot easier. But it makes securing websites much harder. You lose more in security than you gain in ease-of-use of the toolkit. As the GitHub hack showed, if you are putting your site on the Internet, security isn't an option. You don't need to fix every security problem, you don't even need to fix everything in the OWASP Top 10. But if you ignore the the top 4, you are a fool.
Finally, this shows the benefit of irresponsible disclosure. Homakov possibly broke the law, or at least, behaved "unethically" according to many people’s definition. Yet, it was not malicious, and caused no harm (other than deserved harm to reputation). It was the level of "disclosure" needed to bring what I feel is necessary attention to the problem.
(Update: AT&T has fixed this by the next day, as described at the bottom of this post.)
In 2010, a few grey hat hackers (like weev) were arrested for downloading information about new iPad users that ATT had provided freely on its website. All the hackers did was download what ATT freely published. But the reason the FBI arrested and prosecuted the hackers was simply because while ATT published its subscriber information to the entire world, they didn't intend for people to download the entire database. They intended instead for people to just see their own data.
Reddit is reporting that ATT is doing something like this again. This time, they allow anybody to lookup phone-numbers of their subscribers using only the subscribers e-mail address. Simply go to https://www.att.com/olam/enterEmailForgotId.myworld, enter in somebody's e-mail address, and if they are an ATT subscriber, you'll get their phone number. The first page looks like this:
When you hit "Next", you'll get a page that looks like this:
The purpose is obviously to help those who have forgotten some piece of their information. They clearly don't intended for anybody to abuse this feature. But they do nothing to stop abuse.
But it's so easy to abuse. As a hacker, it's trivially easy to take a command-line browser like curl to grab webpages, and to use a pattern search tool like grep to extract useful information. I've written a bash script 'getatt.sh' that does this. (This is just a modified version of the script from the Reddit comments):
When you run getatt.sh john.smith@example.com, it will output a line of text that looks like:
To make use of this, hackers would have to know your e-mail address. Or, they can find e-mail addresses in other places. For example, a million accounts of the YouPorn porn site were hacked recently, revealing people's e-mail addresses. A hacker could easily write a script that extracts each of those e-mail addresses and run it through the script above. It'll be slow, it's making a million webqueries against a slow site after all, but a hacker could start the script before going to bed, and wake up with a database of phone numbers of people who visit YouPorn. (The above script gives you a taste of the hacker mentality, but they'd do something better/faster).
Of course, if they ran such a script, ATT would complain to the FBI, which would then break down their door and haul away their computers. This is a sad thing: the law shouldn't protect cases like this were they freely publish information, but then arrest you if you download it.
Update: As I blogged about on the previous ATT incident, the flaw here isn't one of the OWASP Top 10 website flaws. The solution isn't to fix how they do this, but to stop doing this. The flaw is #0 on the OWASP list: sheer stupidity.
Update: ATT has fixed this. It now responds by emailing your phone number, and the page below telling you this:
In 2010, a few grey hat hackers (like weev) were arrested for downloading information about new iPad users that ATT had provided freely on its website. All the hackers did was download what ATT freely published. But the reason the FBI arrested and prosecuted the hackers was simply because while ATT published its subscriber information to the entire world, they didn't intend for people to download the entire database. They intended instead for people to just see their own data.
Reddit is reporting that ATT is doing something like this again. This time, they allow anybody to lookup phone-numbers of their subscribers using only the subscribers e-mail address. Simply go to https://www.att.com/olam/enterEmailForgotId.myworld, enter in somebody's e-mail address, and if they are an ATT subscriber, you'll get their phone number. The first page looks like this:
When you hit "Next", you'll get a page that looks like this:
The purpose is obviously to help those who have forgotten some piece of their information. They clearly don't intended for anybody to abuse this feature. But they do nothing to stop abuse.
But it's so easy to abuse. As a hacker, it's trivially easy to take a command-line browser like curl to grab webpages, and to use a pattern search tool like grep to extract useful information. I've written a bash script 'getatt.sh' that does this. (This is just a modified version of the script from the Reddit comments):
echo $1,`curl -d "customerEmailAddress=$1" "https://www.att.com/olam/submitSLIDEmailForgotIdSlid.myworld" -silent| grep -Po '(?<=provided \()\d*'`
When you run getatt.sh john.smith@example.com, it will output a line of text that looks like:
john.smith@example.com,6782345678To make use of this, hackers would have to know your e-mail address. Or, they can find e-mail addresses in other places. For example, a million accounts of the YouPorn porn site were hacked recently, revealing people's e-mail addresses. A hacker could easily write a script that extracts each of those e-mail addresses and run it through the script above. It'll be slow, it's making a million webqueries against a slow site after all, but a hacker could start the script before going to bed, and wake up with a database of phone numbers of people who visit YouPorn. (The above script gives you a taste of the hacker mentality, but they'd do something better/faster).
Of course, if they ran such a script, ATT would complain to the FBI, which would then break down their door and haul away their computers. This is a sad thing: the law shouldn't protect cases like this were they freely publish information, but then arrest you if you download it.
Update: As I blogged about on the previous ATT incident, the flaw here isn't one of the OWASP Top 10 website flaws. The solution isn't to fix how they do this, but to stop doing this. The flaw is #0 on the OWASP list: sheer stupidity.
Update: ATT has fixed this. It now responds by emailing your phone number, and the page below telling you this:
I want to respond to the following tweet, but in more than 140 characters:
Microsoft is a heavy user of IDApro. This one time, while giving a presentation at BlueHat (Microsoft's internal cybersec conference), while an IDApro image of Microsoft code was on the screen, I asked "How many of you use IDApro?". Hundreds of people rose their hands -- many more than when I ask the same question at BlackHat. It was a bit scary. I'll bet that Microsoft is buy far IDApro's largest customer, far larger than the CIA or NSA, or the entire US government.
They have to, out of self-defense. When they update their software, sometimes third-party code breaks. They have to reverse engineer that code in order to figure out what's going on, then create a workaround.
Back in the day, my code (BlackICE) broke when they tried to release WinXP SP2. That's because in order to provide a seamless installation without reboot, my code did evil rootkit-like tricks in order to patch the stack while under heavy network load, patching functions in the driver with an atomic jump instruction on multicpu systems. I think we might've even patented the technique.
They had to reverse engineer my code with IDApro to figure out what the heck I was doing, then changed their own code so that my code would stop breaking.
There are still people at Microsoft who hate me for this, who still complain about how evil my code was for delaying the release of SP2. The legacy of this is that in Windows 7, they checksum kernel code to prevent changes. This isn't simply to protect against evil hackers trying to install rootkits, it's also to protect against evil hackers like me creating legitimate software that gives Microsoft's headaches trying to support.
Some at Microsoft wanted to sue me, because in order to patch their kernel, I had to do "reverse engineering" on Microsoft's code. But here's the thing: it's impossible to write code for Windows without some "reverse engineering". Whenever your code breaks because of some undocumented behavior in an API, and you have to figure out why it breaks, you are essentially "reverse engineering" the code. The EULA refers to reverse-engineering-to-replicate, which is far different than reverse-engineering-to-interoperate.
But of course, in order to ship SP2, Microsoft had to break our EULA and reverse-engineer my code in return. Maybe I should've sued them.
So far, I've given 4 presentations at Microsoft (Bluehat or otherwise) where I've popped up live IDApro of their own code, protected against their EULA by, among other things, DMCA provisions supporting reverse-engineering.
Because of their legal hassles with anti-trust/monopolistic practices, Microsoft divisions are independent. They don't get access to each other's source code. In order to get things to work, each division has to reverse engineer the code of other divisions.
I doubt that Microsoft is using IDApro to do evil things, like reverse-engineer competitors to replicate stuff. Such secrets would be impossible to keep, and if they wanted to do such things, they'd work at arms-length with shell-companies and contractors in Asia. But for good things, like getting stuff to work, they use IDApro heavily. They have to reverse third-party drivers, and third-party applications, to see what changes in Windows break things. They have to reverse engineer other divisions, because they don't get access to source. Finally, the blog post the above tweet mentions is about malware research. Of course, Microsoft uses IDApro on viruses as well.
Update:All this predates IDApro. I remember back in the 1990s having casual conversations with Microsoft people about how we all reverse-engineered Diablo 2 (in our free time, not work related). For a lot of Microsoft people, reading binary is as natural as breathing.
comex In which Microsoft posts an IDA screenshot of their own code? RT@dragosr: goo.gl/RT8wD
Microsoft is a heavy user of IDApro. This one time, while giving a presentation at BlueHat (Microsoft's internal cybersec conference), while an IDApro image of Microsoft code was on the screen, I asked "How many of you use IDApro?". Hundreds of people rose their hands -- many more than when I ask the same question at BlackHat. It was a bit scary. I'll bet that Microsoft is buy far IDApro's largest customer, far larger than the CIA or NSA, or the entire US government.
They have to, out of self-defense. When they update their software, sometimes third-party code breaks. They have to reverse engineer that code in order to figure out what's going on, then create a workaround.
Back in the day, my code (BlackICE) broke when they tried to release WinXP SP2. That's because in order to provide a seamless installation without reboot, my code did evil rootkit-like tricks in order to patch the stack while under heavy network load, patching functions in the driver with an atomic jump instruction on multicpu systems. I think we might've even patented the technique.
They had to reverse engineer my code with IDApro to figure out what the heck I was doing, then changed their own code so that my code would stop breaking.
There are still people at Microsoft who hate me for this, who still complain about how evil my code was for delaying the release of SP2. The legacy of this is that in Windows 7, they checksum kernel code to prevent changes. This isn't simply to protect against evil hackers trying to install rootkits, it's also to protect against evil hackers like me creating legitimate software that gives Microsoft's headaches trying to support.
Some at Microsoft wanted to sue me, because in order to patch their kernel, I had to do "reverse engineering" on Microsoft's code. But here's the thing: it's impossible to write code for Windows without some "reverse engineering". Whenever your code breaks because of some undocumented behavior in an API, and you have to figure out why it breaks, you are essentially "reverse engineering" the code. The EULA refers to reverse-engineering-to-replicate, which is far different than reverse-engineering-to-interoperate.
But of course, in order to ship SP2, Microsoft had to break our EULA and reverse-engineer my code in return. Maybe I should've sued them.
So far, I've given 4 presentations at Microsoft (Bluehat or otherwise) where I've popped up live IDApro of their own code, protected against their EULA by, among other things, DMCA provisions supporting reverse-engineering.
Because of their legal hassles with anti-trust/monopolistic practices, Microsoft divisions are independent. They don't get access to each other's source code. In order to get things to work, each division has to reverse engineer the code of other divisions.
I doubt that Microsoft is using IDApro to do evil things, like reverse-engineer competitors to replicate stuff. Such secrets would be impossible to keep, and if they wanted to do such things, they'd work at arms-length with shell-companies and contractors in Asia. But for good things, like getting stuff to work, they use IDApro heavily. They have to reverse third-party drivers, and third-party applications, to see what changes in Windows break things. They have to reverse engineer other divisions, because they don't get access to source. Finally, the blog post the above tweet mentions is about malware research. Of course, Microsoft uses IDApro on viruses as well.
Update:All this predates IDApro. I remember back in the 1990s having casual conversations with Microsoft people about how we all reverse-engineered Diablo 2 (in our free time, not work related). For a lot of Microsoft people, reading binary is as natural as breathing.
The spikey nature of traffic comes from social-networking. People's Twitter and Facebook update several times a minute. When something gets posted at the top, it'll scroll off the bottom a few minutes later. When somebody with a lot of followers links to my blogpost, I'll see a spike of traffic for as long as it stays visible, with traffic decaying quickly as the tweet scrolls downward.
You can see that in the graph of traffic related to my previous blogpost on the hacker group known as "#Anonymous". I've labeled the graph as to the source of the various spikes.
Traffic started on Twitter has my the post traveled through my social circle. Then, Reddit picked up the post in the /r/netsec group. Then somebody posted it to StumbledUpon. Then came the weekend. That's always a low period for blogposts: people spend most of their time on social networking during work hours, but not at night or on weekends. Then Monday, the post picked up internationally. The source of those incoming hits were mostly from foreign language news sites, as well as a Russian and Spanish social networking sites.
Like most sites, I have social-media bar. Mine looks like the following image (not the real bar):
The numbers explode during the spikes. The Reddit counter updated mostly just during the Reddit spike. The StumbledUpon counter updated mostly just during the associated spike.
Here is the graph a day later. In this we see two more very sharp pulses.
These correspond to two Tweeets from @YourAnonNews, a Twitter account with half a million followers. The time of the peaks correspond precisely to the time of the tweets, and the incoming "Referer" link clearly identifies the URL shortener string used only by @YourAnonNews.
This says a lot about @YourAnonNews, that while they have 500,000 followers, that their followers only see the Tweets for a short window before they scroll away.
For comparison, here is graph of what the Slashdot effect used to look like, where it would take hours instead of minutes for traffic to decay:
Conclusion
This leads me to edit Andy Warhol's famous comment that "In the future, everyone will be world-wide famous for 15 minutes". In the future of social-media like Twitter and Facebook, you'll be world-wide famous, but for only 15 seconds. You may hit the Twitter feed of a million people, but in a blink of the eye, you'll disappear again.
 |
| This is what you'd see if the DNS blackout were successful |
But the attack is no longer practical. It's such a common idea that Wikipedia has a page devoted to it. For something so obvious, defenders have spent considerable time devising solutions. There are many reasons why such an attack won't cause a global blackout.
Reason #1: active response
Typical hacks work because it often takes a day for the victim to notice. Not so with critical Internet resources, like root DNS servers. Within minutes of something twitching, hundreds of Internet experts will converge to solve the problem.
We've seen this response in action after major Internet worms (Morris Worm, Slammer, Blaster) or undersea cable breaks destabilized the Internet. Despite devastating temporary effects on the Internet, defenders were able to react quickly and mitigate the problem, so that most people never noticed.
The easiest active response is to blackout the sources of the offending traffic. Defenders can quickly figure out where the attacks are coming from, and prevent packets from those sources from reaching the root DNS servers. Thus, people might see disruptions for a few minutes, but not likely any longer.
Reason #2: diversity
There are 13 root domain servers (labeled A through M), managed by different organizations, using different hardware, software, and policies. A technique that might take out 1 of them likely won't affect the other 12. To have a serious shot at taking out all 13, a hacker would have to test out attacks on each one. But, the owners of the systems would notice the effectiveness of the attacks, and start mitigating them before the coordinate attack against all 13 could be launched.
Reason #3: anycasting
Anycasting is a tweek to the Internet routing table so that traffic destined for an IP address is redirected to a different local server. Thus, while it may appear that the "K" root DNS server has only a single IP address "193.0.14.129", in fact there are 20 machines with that address spread throughout the world. When I trace the route to the "K" server from Comcast in Atlanta, it goes to a server located at an exchange point in Virginia. If you do your own traceroute, you are likely to find a different location for the server.
 |
| Physical location of the IP address 192.0.14.129 |
 |
| Route from Comcast in Atlanta to 192.0.14.129 |
Reason #4: fat pipes
The root servers are not located on the edges of the Internet, but are instead located at nexus points on the Internet backbone where many links come together. Even using the "network amplification" technique described by #Anonymous, it won't overload the network connections leading to the root servers.
Such attacks might overwhelm the servers themselves, but here amplification is much less of a threat. Whereas the raw "bits-per-second" is the primary limiting factor for Internet links, "packets-per-second" is the primary limiting factor for servers. The amplification technique results is bigger packers, but not more of them, so amplification affects servers less.
Reason #5: gTLD servers
All a root server does is resolve the last part of the name, like ".com" or ".jp". It then passes the result to the "gtld-servers". That means while the servers are designed for millions of requests per second, they practically only serve a few thousand per second.
Indeed, the best way to cause a "global blackout" wouldn't be to attack the root servers themselves, but the "gtld-servers" the next level down, or even the individual domain-specific servers (like those for Google or Facebook) at the next level. If people can't get to their Google, Twitter, and Facebook, the Internet is down as far as they are concerned.
 |
| All root server does is resolve the ".com" portion of "www.facebook.com" |
Reason #6: caching [update]
Your don't interact with the root DNS directly. Instead, you ask your Internet provider (Comcast, Verizon, AT&T, etc.) to do it for you. They don't need to repeatedly ask the same question to the root servers every time one of their customers clicks on "www.facebook.com". Instead, they can remember the response from the first lookup, then use that response for the rest of the customers who ask. This is called "caching" the response. The amount of time they cache the response, before redoing the lookup, is known as the "time-to-live" or "TTL".
The TTL for domains like ".com" is a couple days [edited]. That means, in theory, that the root servers could be down for a while before anybody would notice.
In their missive, the #Anonymous hackers claim that companies like Comcast ignore the TTL, and instead cache the response for things like ".com" for less than a day. I don't know. Regardless, it's a race against time: #Anonymous has to keep the root servers unavailable long enough for the major Internet providers to timeout their caches, while fighting the defenders who are racing to block the attacks and make the servers available again.
(I added this point in response to Michiel Klaver's comments below. I didn't include it in my original post because I haven't tested myself the veracity of #Anonymous's claims that Internet providers don't cache the root responses for a long time).
Consequence
The #Anonymous hackers can certain cause local pockets of disruption, but these disruptions are going to be localized to networks where their attack machines are located, or where their "reflectors" are located. They might affect a few of the root DNS servers, but it's unlikely they could take all of them down, at least for any period of time. On the day of their planned Global Blackout, it's doubtful many people would notice.
Note: just because I say #Anonymous can't do it doesn't it mean it can't be done. Rather than a "brute-force" attack flooding the target, searching for weaknesses is a better approach. I think I might be able to do it, given 6 months. There are others who know DNS better who could find a weakness in less time.
[update] When the root DNS servers do come under attack, you'll want to check out this page from Team Cymru monitors the health of the root DNS servers. They repeated query all the root servers from several locations around the Internet and measure how long it takes for their queries to be answered.
[update] Mr. Dan "DNS" Kaminsky has some good points at this Forbes article: Anonymous Plans To Take Down The Internet? We're Being Trolled.
[update] Mikko Hypponen points to this 2007 article: "There are not 13 root servers.
[update] IRC conversation about #OpGlobalBlackOut: http://pastebin.com/n71BkMPi
More than four years ago, the UN website was hacked via SQL injection. They haven't fixed their problem since then, which I've pointed out over and over and over. This last week, #Anonymous hacked them yet again using the same technique. If, after 4 years, the UN still can't protect their website, it's unlikely that they ever will.
But SQL injection is the easiest of all bugs to fix: simply stop treating data as code (use parameterized queries instead). The difference between the correct way, and the wrong way, is obvious and impossible to miss. Most hacker attacks are hard to understand, and hard to fix, but SQL injection isn't one of those.
So why, after 4 years, has the UN failed to fix the problem? Here are the possible reasons I can think of::
In my experience, it's usually #3: even though this is by far the most obvious and easiest problem to solve, most web programmers still aren't smart enough to fix it. Web site developers treat code as magic spells: they know which incantations work, but they don't understand how they work.
But SQL injection is the easiest of all bugs to fix: simply stop treating data as code (use parameterized queries instead). The difference between the correct way, and the wrong way, is obvious and impossible to miss. Most hacker attacks are hard to understand, and hard to fix, but SQL injection isn't one of those.
So why, after 4 years, has the UN failed to fix the problem? Here are the possible reasons I can think of::
#1. They don't want to fix it; they just don't care if their website is occasionally hacked.
#2. They don't understand the risk of treating data as code.
#3. Their programmers aren't smart enough to fix the problem.
#2. They don't understand the risk of treating data as code.
#3. Their programmers aren't smart enough to fix the problem.
In my experience, it's usually #3: even though this is by far the most obvious and easiest problem to solve, most web programmers still aren't smart enough to fix it. Web site developers treat code as magic spells: they know which incantations work, but they don't understand how they work.
This leads to problem #1: organizations find it easier dealing with getting hacked rather than fixing the underlying problem. This is especially true of an organization like the UN, whose managers are even less smart than their programmers, and who don't have the ability to fire incompetent programmers.
This further leads problem #2: because it's so hard getting your programmers to fix the problem, group-think leads to a state-of-denial, where the entire organization convinces themselves either that there is no risk, or that nobody can fix the problem.
So, next year, I'm going to write another blogpost entitled "UN's website still vulnerability after 5 years", still vulnerable to the easiest security problem on the Internet.
Update: By the way, I'm not insisting that they should fix the problem. Their site doesn't appear to have anything sensitive on it, so getting hacked is a small problem. Although, I suspect, if their programmers were more competent and able to fix it, that they would then want to fix it. Or, said another way, competent programmers would never allow SQL injection in the first place.
Update: If you are writing a large project in C/C++, it's very hard to verify that it has no "buffer-overflow" problem. But, if you are writing ASP+SQL code, it's trivially easy to verify that you have no "SQL injection" problems in the code. SQL injection really is the most obvious and easiest cybersec problem to solve.
Android und iOS beherrschen die Smartphone - Welt Laut IDC wurden im ersten Quartal 2012 weltweit 152 Millionen Smartphones verkauft. Mehr als die Hälfte davon sind mit Android ausgerüstet, ein knappes Viertel iPhones mit iOS.
(heise)
Elton John Sänger Elton John wurde mit einer schweren Atemwegs erkrankung ins Krankenhaus eingeliefert – der Popstar musste sogar einige Konzerte absagen. Er entschuldigte sich bei den Fans.
(bunte)
SpaceX: Dragon dockt an die ISS an Die Nasa hat das Andocken der privaten Raumfähre Dragon an die ISS erlaubt. Das Manöver hat am frühen Freitag morgen begonnen und soll am Nachmittag abgeschlossen sein.
(golem IT)
Ubuntu 12.04 LTS (Precise Pangolin) zum installieren bereit.