Wednesday, February 28, 2007

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.

Tuesday, February 27, 2007

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)

Friday, February 23, 2007

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)

Wednesday, February 21, 2007

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)

Sunday, February 18, 2007

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.

Wednesday, February 14, 2007

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:


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)

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) )

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)

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)

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

Monday, February 12, 2007

Securing the Corporate Network When There is No Perimeter

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

Microsoft Security Response Center Blog

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 .

Turning Your Typo into Profit

Have you noticed what happens when you mistype the name of your favorite web site? As reported by Daniel Wesemann at the Internet Storm Center this is not an accident, this is a profit center.

A few sites like go where intended – Type in 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™.

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 “” 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

3. Deter the pharmers with protection against defacement, cross-site scripting and man-in-the-middle attacks

Wednesday, February 7, 2007

Another Attack on DNS Root Server Infrastructure

For those of you who need more information, Wikipedia has a good article on why DNS root servers are important to everybody.

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:

Picture 1: (2/6 17:00 UTC - 19:00 UTC)

As you can see in this reporting period, two of the thirteen servers are still experiencing significant load. The following picture shows the effect of the attack from its beginning:

Picture 2: (2/6 08:00 UTC - 2/7 08:00 UTC)

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.

For the Internet, we can thank the very good folks at RIPE .

Monday, February 5, 2007

Web Site Security Affects You

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 South East Asia, but I like this idea of Hackistan (more on this later).

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 China was failing under load. Get the irony? The bad guy’s computer was crashing because he had too many victims phoning home.

This hacker was not after fame. No vandalism or political messages, the web sites continued to operate as normal. By the way, I don’t consider people like this to be hackers… this person is a crook, a perpetrator after your login, passwords, credit card info – anything and everything he could get, so he could sell your identity or rip you off directly.

Solution? Simple:

  1. If you have a computer, keep it patched and use a personal firewall.
  2. 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.