Showing posts with label web site security. Show all posts
Showing posts with label web site security. Show all posts

Sunday, March 4, 2007

Popular Blog Software Cracked

A successful attack was made on the WordPress 2.1.1 download. The attacker modified the files theme.php and feed.php. These modifications created a backdoor which would allow a user to gain privileged access to any server running WordPress 2.1.1.

All users have been requested to update immediately to WordPress 2.1.2. Users who access updates through the Subversion repository were not compromised.

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.

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:

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.

Friday, February 9, 2007

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 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™.

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

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