Wednesday, February 28, 2007
One of the victims has provided their analysis of the attack and their lessons learned. Important reading for any web site developer.
My thanks to the Internet Storm Center for providing a channel for this information.
I blogged on this earlier.
Tuesday, February 27, 2007
We arrived at the target floor. We knew there were cameras everywhere. If they saw us in this area, we’d only have a few minutes before guards arrived. Our next stop was the fire suppression closet.
Now the challenge: we had to build our device. We worked by light reflected through a four-by-eight-inch window. As people left for home, they passed our closet, but we remained undetected.
Part 4 of 7, (to be continued)
We waited 40 yards from a garage exit. We could see the guard shack, but the patrol was out of sight. We waited until a distraction caused the guards to look the other way. We dashed for the ramp. We couldn’t avoid the sensors, but hoped that after a night of false alarms ours would be ignored. We had to get inside the Garage quickly. A car came down the ramp as we dashed up. This might fool the guards on the motion camera; they’d see the car, but not us. Did the driver see us? We were past him in a blink on the blind side, but one look in the mirror would be all it took.
Up the ramp and into the garage. There was another camera straight ahead. Two seconds to pass the camera, we would show for a few frames on a bank of sixteen monitors. Then into the fire escape. The team climbed past the public areas quickly and silently, before the guards could reach the stairwell. We listened for the sound of pursuit while our hearts pounded – tough work for computer jocks.
Part 3 of 7, (to be continued)
Friday, February 23, 2007
The security chief would wait in his office hoping to hear the good news. He wrote on our passes that they were good for one night only. Trust is carefully measured.
Catching us would be good news. It would inform our client that his system beat us. However, our job was to deliver an honest assessment of his security risks. Idiots are caught every day.
Wednesday, February 21, 2007
It’s Friday, for the second time.
We left Asia yesterday and are a few hours past the International dateline, traveling parallel to the
We had been a team off and on for the last ten years -- C programmers, UNIX kernel engineers, and now a tiger team paid to sneak into secure data centers.
As trained security consultants, our clients paid us to break in -- with the full knowledge of our employer, the company’s security chief -- but without the knowledge of site security.
We’re going to turn south soon. Home is ahead. We have been away for two weeks, carefully planning and arranging to perform the task that took less time from start to finish than the remainder of our flight.
During that time, we analyzed the building and planned the technical part of our attack. We determined the systems that needed our backdoor. We carefully arranged our timing with the security chief; he knew we were coming, but his staff did not. This was a test. Were they as good as they thought they were?
Part 1 of 7, (to be continued)
Sunday, February 18, 2007
There are three basic types of authentication, often called “factors.”
- Something you know
- Something you have
- Something you are
Many users, however, do not change their default password issued by the router manufacturer, Ramzan said. According to a separate informal study conducted by
Examples like this are reason #12 for why I hate passwords. Vendors, including ATM machine vendors, continue to ship all of their devices with the exact same administrator password. The problem is not that the device has a default password. The problem is that every device (e.g. Linksys router) has the same default password. When you are building devices that dispense cash or connect to the Internet, this practice is unacceptable. Where I differ from Ramzan, is that I believe the responsibility lies with the router manufacturers not the users. The manufactures must stop this practice of using default passwords.
Security research has analyzed this area for ages. The manufacturers have no excuse for continuing to ship products that are insecure from the start. Here are a few of the available solutions:
- Use the device serial number, or the last four digits of the serial number as the initial password. This works for home or
SOHOrouters (only visible to the owner) and ATM machines (located behind a locked panel)
- Prompt the owner for a new administrator password. Make it easy, any four digits (PIN) will suffice as long as the device resists password cracking.
- Add another factor. Ship ATM machines with a “manager” ATM card (chain it to a holder behind that locked panel). Network devices could include a soft token with their installation software. This soft token would also simplify setting up wireless devices with WPA-2 security.
- Use challenge response questions instead of a password. Ask the user three questions out of a pool of thirty, then select one question each time the user needs administrative access. While this will not work for the ATM machine, it is fine for network access.
I hope that someone out there at Netgear or Linksys is watching, because they are responsible for this problem. If finding out that your broadband router is an open door to your home network is not bad enough, I’ll leave you all with this very educational video on door locks, which shows that your front door is wide open too.
Wednesday, February 14, 2007
A prime example of this problem is MySpace, which has been hit by the same vulnerability six times because it has not properly stopped attackers from entering malicious text through stripping. In providing a consumer benefit, MySpace has made its site far more dangerous to those very same consumers.Attackers at MySpace are using the MySpace tools to introduce exploit code into a MySpace web page. MySpace is responding by attempting to delete the offending code from the content.
As RSnake notes, this has led to an oscillating conflict between the MySpace web coders and the attackers. It looks something like this:
Submit(Post_html) where Post_html equals:
>html start ... [embedded exploit] ... html end<
Defender (server side of submit function)
Post_html = Strip_Exploit(Post_html)
This conflict oscillates because after each improvement the Defender makes to the “Strip_Exploit” logic, the Attacker adapts her efforts to defeat the system. To get out of this situation, the defender needs to change the rules.
There are many ways to solve this problem. I’ll delve into two examples: with “stripping” the Defender could iterate over the data until clean; another solution is to use Substitution instead of Strip.
Example 1: Defender using strip
Clean( Strip_Exploit(Post_html) )
Recursion prevents the attacker from passing a nested embed attack through the Strip function. As an alternative to recursion, the defender could iterate through a loop until the exploit code is gone:
Set Post_html to Strip_Exploit(Post_html)
Another solution is to replace the exploit code with a safe substitution. For example, if the offending code is “Crake” then replace each instance of Crake with “Oryx.” It is vital that the replacement text is the same length or less than the length of the exploit text – otherwise, the attacker may discover a method to overflow the buffer you are using to contain Post_html.
Example 2: Defender using substitution
Set Post_html to Replace_Exploit(Post_html)
Meanwhile, I recommend you disable scripting when you browse a page at MySpace.
Monday, February 12, 2007
Do not try and bend the spoon. That’s impossible. Instead, only try to realize the truth … There is no spoon – Spoon Boy, The Matrix
Early computer security thinking taught that computer security followed the patterns of Physical Security. The object was to create a secure perimeter and then strictly control ingress/egress through a few gateways. Early pen-testing often-included attempts to gain physical access to a facility or specific system because everyone “knew” that physical access always trumped computer or network security.
Following those principals, every reasonable security architect specified firewalls, locked doors and CCTV to safeguard their systems. These elements became part of the “building code” for any secure facility.
Dear Readers, it’s time we updated our building code. We’ve had our digital Earthquakes and Hurricanes. This architecture of hardened perimeter and gateway firewall is obsolete. Today’s mobile devices carry threats and bad behavior directly onto your core network. Wireless and p2p are everywhere and the botnets, malware and Trojans ride in on port 80 and masquerade as harmless web surfing.
Today’s security architect must design and implement processes across their network comprehensively and with proper attention to every server, desktop, laptop, dormant virtual machine and wireless enabled device. Use automation to protect against flash-threats and Warhol worms. Use malware and behavioral analysis to detect Spear Phishing, targeted Trojans and command-and-control networks.
The new building code for networks requires endpoint security. The building specification for endpoint security includes but is not limited to:
- Continuous vulnerability and patch management
- Malware protection and host integrity
- Policy enforcement and compliance validation
- Policy and behavior based Pre and Post network admission control
- Continuous performance and security monitoring
There are many products in this space. I recommend being wary of complexity and forklift upgrades. Look for products that simplify operations and solve real IT problems along with improving security.
Friday, February 9, 2007
I did want to note that this month, the Thursday before the Second Tuesday is actually the second Thursday of the month. That will be the case for March as well.
We sometimes get people who associate the Advance Notification with the first Thursday of the month, so I wanted to remind folks that it’s actually tied to the second Tuesday, the release day. So, if you have any reminders for today’s notification for March tied to the first Thursday of March, you’ll want to update them to March 8 2007: which is when we’ll make the next Advance Notification.
If that isn’t perfectly clear to you, I recommend further reading.
One item is clear, this will be an important patch event for most Microsoft users. There are a fair number of Critical and Important patches for core operating system and application elements. It would be nice to know which CVE are being addressed .
A few sites like www.gogle.com go where intended – www.google.com. Type in www.googe.com and you end up at Go Daddy. Just a little while ago, my browser would have shown me, “Cannot find server or DNS error.” Now on my Dell system, most of my mistakes take me to a customized Dell/Google results page. Being redirected to a search engine might seem innocuous, but this is actually a real bad thing™.
- As Daniel points out in his blog entry these redirect sites create an opportunity for the pharmers and phishers
- Some SSL/VPN software relies on the standard DNS behavior to redirect you to your companies internal servers
- Getting redirected to an unexpected site can be very embarrassing, in this instance Bell South users were redirected to porn sites and who can forget when www.whitehouse.com was an explicit porn site?
These are all a form of hijacking. How bad is this? Just last year a Phisher was targeting Wells Fargo customers with a “welsfargo” URL. Wells Fargo has registered the domain “welsfargo.com” but has not redirected the domain as Google did with Gogle. The folks at Wells Fargo need to correct this lack.
If you have an e-commerce or popular web site then you need to protect yourself and protect your customers:
1. Register the confusingly similar domain names and configure their DNS records to point to the correct site
2. Monitor all of your domain records and DNS servers for failure or compromise
Wednesday, February 7, 2007
Every time you type a URL, or click on a link in your web browser a DNS server directs your computer’s browser to the right server on the Internet. For performance reasons, you usually use the DNS server on your local network or one provided by your ISP. Your local DNS server relies in-turn, on other DNS servers in a tree-like hierarchy. Ultimately, all DNS servers rely on the smooth functioning of the thirteen DNS root servers.
An attack on the root servers is an attack on the fundamental structure of the Internet. It’s the DDOS equivalent of a doomsday device. This the sort of thing a villain like Ernest Blofeld would attempt; it could be the action of a sociopath, the prelude to a grand attempt at extortion, the test of an info-weapon or an act of war.
Fortunately, as noted by John Crain, this type of attack has become much harder to pull-off. However, Harder ≠ Impossible. The current infrastructure can handle an enormous load, but there are limits. The picture below shows the situation at 11:00 AM PST:
As you can see, the attack hit server ‘’G’’ and ‘’L’’ the hardest. The red spikes indicate an average probe failure rate exceeding 90%.
Most likely, this attack will not affect you directly. It is a lot like a solar flare’s effect on radio communications – there’s a lot more noise in the system today and don’t be surprised if you notice a slightly different “feel” to the Internet today.
The lesson here?
Performance monitoring is often a leading indicator to an attack on your computer infrastructure. It is important to understand your baseline performance and monitor the systems you rely on for any significant deviation from baseline.
Monday, February 5, 2007
1987 - Mitnick invades system at Santa Cruz Operation. Santa Cruz police travel to Los Angeles to search apartment where call coming into SCO originates. ( …) Mitnick's representation bargains felony charge down to misdemeanor. Sentence: three years probation.
At SCO, Mitnick found his way in via “war-dialing” onto a UNIX system. Did he crack root? No, root on this system had no password at all… Kevin wasn’t after SCO, he wanted UNIX source so he could get even deeper into Ma Bell’s computers.
20 years later, another hacker discovers a system they can access, only this guy isn’t after big business, he was after YOU.
Last week, Websense discovered that several Super Bowl related web sites had been hacked. According to news reports, these systems were compromised on or before January 26, but engineers at the affected sites were not alerted until February 2nd. For a period of a week, a malware package installed on the victim web server attacked every visitor to the site.
You might not discover “Hackistan” but Hackistan wants to discover you. I intend no offense to my friends from
The crooks are making the Internet their own. Gone are the days when Kids broke into systems to prove their l33t skill, the game is all about money now. And the money is getting very very big.
We can only guess how many systems this attack affected. Enough however, that it appears that the malware server in
- If you have a computer, keep it patched and use a personal firewall.
- If you have a web site, monitor the hell out of it.Find someone who will watch your web site and the entire infrastructure it relies on. Don’t settle for a once a quarter/month scan. Find someone who looks at your web site the way the hackers do. Pay them to check it now and check it every day, 365 days a year. This is not a choice any more.