Important Update to Super Bowl web site hack

Super Bowl Infection - Analysis of One Break-in

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.

Hidden in wait

As we waited, we had time to think and review the plan. To us, the world’s greatest hackers are an unknown. No one knew their names and no one would know their faces. The celebrities in the paper are not the best. For tonight, we had to be the best. Otherwise, our faces would be on tape, and we would just be more bad boys who’d been caught.

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.

We’d examined the company’s card key system and checked it on the Web. Card key systems are everywhere and they almost all use the same operating methods.

Part 4 of 7, (to be continued)

Outsmarting the motion detectors

We waited until the building was mostly empty. We knew this business, this client. Their operations were 24/7. We arrived in the early evening and had already examined the ground and the building plans in detail. We knew our route. The weather had been perfect: rain with wind. This would mask the infrared, mess with the ultrasound. Still, we knew we had to be quick, and our timing had to be good.

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)

Get out of jail free cards

In the hotel, we met with our client. He gave us two “pass” cards. We joked that the cards said, “Let these guys go, but scare them first.” We knew the procedure. The guards would call the police before calling their boss. The police had guns.

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.

Part 2 of 7, (to be continued)

Penetration Testing

It’s Friday, for the second time.

We left Asia yesterday and are a few hours past the International dateline, traveling parallel to the Aleutian Islands. Sunrise is ahead of us. Our moonlit challenge is behind us.

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?

The motion sensors, cameras and guards were on one side. Our skill, technical experience and creativity were on the other. Our job was to determine if the physical security and technical safeguards would be enough to keep us from breaching the physical security of their data center and creating a backdoor to the Internet.

Part 1 of 7, (to be continued)

I Hate Passwords #12

There are three basic types of authentication, often called “factors.”

• Something you know
• Something you have
• Something you are

Passwords, ATM cards and fingerprints are examples of these factors. There are many good techniques for putting these authentication methods into practice. Probably the most familiar two-factor method is the ATM card with PIN.

'Drive-by Pharming' Attacks Potential Threat to Broadband Users

Many users, however, do not change their default password issued by the router manufacturer, Ramzan said. According to a separate informal study conducted by Indiana University, up to 50 percent of home broadband users are susceptible to this attack.

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:

1. Use the device serial number, or the last four digits of the serial number as the initial password. This works for home or SOHO routers (only visible to the owner) and ATM machines (located behind a locked panel)
2. 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.
3. 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.
4. 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.

MySpace (in)Security

I'm in Chicago, listening to United's hold music (95 minutes and counting), catching up on my DarkReading.

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:

Attacker

Submit(Post_html) where Post_html equals:

>html start ... [embedded exploit] ... html end<

Defender (server side of submit function)

Clean(Post_html) {
    If Found_Exploit(Post_html)
        Post_html = Strip_Exploit(Post_html)
    Post-to-Web(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(Post_html) {
    If Found_Exploit(Post_html)
        Clean( Strip_Exploit(Post_html) )
    Else
        Post-to-Web(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:

While Found_Exploit(Post_html)
    Set Post_html to Strip_Exploit(Post_html)
Repeat
Post-to-Web(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

While Found_Exploit(Post_html)
    Set Post_html to Replace_Exploit(Post_html)
Repeat
Post-to-Web(Post_html)

Meanwhile, I recommend you disable scripting when you browse a page at MySpace.