2:00 PM -- In the beginning, there was application security.
All ports were open to the world and practically every application had holes in it. It was like the Wild West. Eventually application security became a big deal as more serious issues were uncovered and more commerce depended upon secure platforms.
Network security was next on the scene. It made sense to build a single choke point for all security needs. It was slick because it could see all the packets in transit to and from your servers, and turn off all access to anything that had a known hole in it. Those were the good times. Times have since changed.
Network security, in large part, had a huge role to play in creating the newest attacks. Network administrators rightly told their architects to build applications that could be tunneled over hypertext transfer protocol, while at the same time they would close down all access to any other unnecessary inbound services. Can you see the obvious flaw in their logic here?
Even still, aside from the occasional hole in IMAP or BIND, the world of computer security seemed to be calming down quite a bit with the advent of stateful packet inspection and security information management tools. Most of the holes at that time were against the security tools themselves, which most of the hardcore security folks felt was scraping the bottom of the barrel -- the last bunch of entry points to a secured network.
Traditionally every firewall allows one thing by default: outbound access to any Web server on earth. That Web server can either be under the attacker's control or have a cross-site scripting vulnerability in it. When a user inside a corporate LAN visits the malicious Web page, that Web page starts making requests to internal devices behind your firewall.
The first thing the malware does is attempt to locate any machine that responds. Once it does that it attempts to fingerprint things on the machine that might tell the attacker more (like what Web server itself it is running, which might have default issues with it or a particular outdated version of an open sourced package with remote file includes built into it). Using that as a steppingstone, the malware attempts to execute the command on the user on your corporate intranet's behalf. If the attack is successful the machine behind the firewall is compromised.
It has a higher chance of being successful than on the Internet because rarely do corporations patch up internal machines. I mean, why would a company bother to secure its intranet portal? It's just an intranet server and not Web-accessible, right? That's true in principle, but very wrong in practice.
As a side note, most companies almost always alias to http://intranet/YourCompanyNameHere, making the attacker's job extremely easy. This even shortcuts having to scan IP ranges, since it's an easy single name to guess.
After scanning a corporate intranet, the next step is to execute commands on the machines the malware does find for the eventual purpose of gaining access to internal machines. Those internal machines will most likely run a series of commands to gain higher and more permanent access to the machine that was compromised which then could communicate back to a command-and-control node over IRC chat in the same way all botnets do.
The corporate firewall is helpless to protect against this sort of attack. Researchers like myself and others are looking into clever ways to fix the issue, but for now, the only fix is to isolate users from all machines on the corporate LAN. Hopefully there will be much more on this to follow. In the meantime, a text-based world isn't looking so bad after all, huh?