pseudo-flaw.net

If you are planning on going to ShmooCon next year (February 15-17, 2008 in Washington, DC) and haven't already acquired your tickets, the 2nd round of ticket sales is December 1st (tomorrow) at Noon EST.

If the 2nd round is anything like last year (actually this year on 1/1), it will be insane. The Early Bird tickets were completely gone in the first five minutes. I jumped in the fray as soon as registration opened and by the time I was done entering my info, there were only four Early Bird tickets remaining. Anybody that was still sleeping off their hangover from the night before or in the least bit groggy missed out. Some people also had their tickets sold out from under them while they entered the credit card data. They thought they were getting a $75 ticket but ended up with $150 one.

Well this year, the ShmooCon ticket sales have been updated to address the situation. Now one of each type of ticket is reserved for five minutes after the order process is started. Apparently the number that you can purchase are still unlimited, which means that some strategy is required to get the type of ticket you want. If you haven't started the order process before a multiple ticket purchaser completes the process, you will miss out. So unless you want to end up like a whiny preteen rolling the dice on eBay, make sure you are within the first 250 people as soon as ticket registration opens (and that would be the first 100 for you cheapskates looking for $75 tickets).

What if you are gunning for the $300 "I Love ShmooCon" ticket (because you really, really want that free T-Shirt). Paradoxically, you need to be within the first 10 people to start the order process. Since one type of ticket is reserved for each person, the hordes of people trying to get Early Bird or General Admission tickets quickly exhaust the supply of available "I Love ShmooCon" tickets. This is further aggravated as the other types of tickets are sold out and people repeatedly refresh the order process to see if any previously reserved tickets are added back to the pool.

So, what should you do to make sure that you can get the "I Love ShmooCon" ticket? Start the order process early. Really early. Like 11:55 AM early. Because there is currently a time skew of five minutes on the registration server. This is easily noticeable from the fact that the time at the bottom of the registration page is dynamically updated when the page is refreshed:

And since hammering on the registration page is pretty lame, why not use a simple shell script instead:

#!/bin/sh

host=www.shmoocon.org

echo "$host/cart/ "`printf "HEAD /cart/ HTTP/1.0\r\nHost: $host\r\n\r\n" | openssl s_client -connect $host:443 -quiet 2>/dev/null | grep ^Date`
echo "my date: `date -u`"

# eof      
      

Who knows how long this might last, but it was that way on November 1. By looking for a slight competitive advantage, you can be sure to get in early and get your coveted "I Love ShmooCon" ticket before they are all gone.

Personally, I made sure to get my ticket on November 1st to avoid all the craziness. Even then, Early Bird tickets probably only lasted twenty minutes. But I may just stop by this time just to see how frenzied the action is.

If you are on the fence about going, ShmooCon is definitely worth it. Go to ShmooCon.

At the end of October, the Tor project released updated Vidalia bundles that addressed some insecurities in the Privoxy configuration that existed in versions prior to 0.1.2.18. I posted the following brief advisory to the or-talk mailing list at the time:

Versions of the Vidalia bundle prior to 0.1.2.18 install Privoxy with
an insecure configuration file.  Both Windows and Mac OS X versions
are affected.  The installed 'config.txt' file ('config' on Mac OS X)
had the following option values set to 1:

  - enable-remote-toggle
  - enable-edit-actions

Additionally, on Windows the following option was set to 1:

  - enable-remote-http-toggle

Malicious sites (or malicious exit nodes) could include active content
(e.g., JavaScript, Java, Flash) that caused the web browser to:

  - make requests through the proxy that causes Privoxy filtering to
    be bypassed or completely disabled

  - establish a direct connection from the web browser to the local
    proxy and modify the user defined configuration values

The Privoxy documentation recommends against enabling these options in
multi-user environments or when dealing with untrustworthy clients.
However, the documentation does not mention that client-side
web browser scripts or vulnerabilities could be exploited as well.

It should be noted that using Tor is not a prerequisite for some of
these attacks to be successful.  Users of Tor may be at greater risk,
because malicious exit nodes can inject content into otherwise trusted
sites.

In order to allow time for people to upgrade, additional attack
details and sample code will be withheld for a couple of days.

That "couple of days" got stretched to nearly a month since I decided to hold off until Firefox 2.0.0.10 was released. But, full details and sample exploit code are now available. Enjoy.

Want a fake blog hack as part of your viral marketing campaign?

Cool. Just make sure to blame it on WordPress. Because that would be the most plausible explanation.

Al Gore 0wned ... WordPress to Blame? I guess getting owned through WordPress is becoming a rite of passage for bloggers the world over. And the general attitude of "it's just a blog" is simply not sustainable in the long run.

Was this the work of a mass exploiter or a targeted attack? As we've seen with past incidents, the mass exploiters don't care and sometimes don't even realize the value of the target. When scanning the entire net, the perceived value of the target is generally irrelevant. Maybe you care if it is a .edu or .gov, but typically it is just another box. If a site is vulnerable to a widely known exploit, then somebody, somewhere will own the site and use it -- whether that is to hawk pharmaceuticals or pwn crunchies.

Still, it is good to see that somebody gets why this is a big deal. From the article, Roger Thompson, CTO of Exploit Prevention Labs: I think we're a bit lucky it's not shooting exploits.

Firefox 2.0.0.10 has been released.

Included in the update is a fix for the window.location race condition security vulnerability that I discovered. By abusing the race condition, it is possible to spoof referer values. This is a pretty powerful technique when performing cross-site request forgery (CSRF). The only challenge is that an alert, confirm or prompt modal dialog needs to be displayed for the race condition to be exploitable. That is where some social engineering skills may come in handy.

A more detailed discussion and demonstration.

Mozilla Firefox exhibits an odd quirk when loading file: URI values that specify host components. When retrieving the data, the host portion is ignored. But when determining the origin of the data, the host is taken into account when displaying document.domain and location.host from JavaScript. RFC 1738 describes the file URL.

Download a simple demo and try it for yourself (source).

Although there are not any readily apparent attacks that can be implement from within Firefox, it suggests that there is a general confusion about the difference between what content is retrieved and how and where it is retrieved from. A quick test shows that Safari behaves the same as Firefox, but Internet Explorer attempts to treat the host as part of a UNC path. Opera treats the host as a UNC name, but Access Violates on the re-launch without host name.

Bug hunting at trust boundaries can be very fruitful.

As a follow up to my You got your JAR in my JPEG post, I've added an online demonstration. The corrupted JAR is hosted as a JPEG image on googlepages.com. The image is specified as JAR archive for an applet. When the applet is loaded, it attempts to connect back to the googlepages.com server and then submits the response back to this server.

Try out the corrupted jars demonstration.

In case you missed it, a few weeks ago the Light Blue Touchpaper blog got popped because of a WordPress vulnerability. Don't feel bad; you may have blinked.

What makes this notable is that Steven J. Murdoch followed up by pointing out the obvious. Yes, WordPress authentication and cookie handling are atrociously bad. But it appears a slight omission was made in the Solution section:

- QUIT USING WORDPRESS

Seriously. Could it be anymore clear?

Oh, and one more thing. Ignoring the apparent flaws in this approach, assume P is your password and MD5(P) is stored in the database; to authenticate, P is submitted, and MD5(P) is computed and compared to the stored database value. Doesn't that mean that if P is submitted in clear text and is sniffed or captured, the value can simply be replayed for any future authentication session? That's pretty bad, right? If you agree, then consider that P is actually MD5(password).

From Murdoch's potential fixes:

The problem occurs because it is easy to go from the password hash in the database to a cookie (i.e the application of MD5 is the wrong way around). The simplest fix is to store MD5(MD5(password)) in the database, and make the cookie MD5(password). This still makes it infeasible to retrieve the password from a cookie, but means that it is also infeasible to generate a valid cookie from the database entry.

So, if I can get my hands on your cookie, not only can I attempt to log in, I may also be able to get your real password. Depending on which you consider more likely, XSS or SQL injection, maybe WordPress isn't going the wrong way after all.

Besides n3td3v and Dr. Neal Krawetz (neal@krawetz.org), Joey Mengele has had a pretty good run on Full-Disclosure in 2007. One of my favorite moments came when there was yet another lame "hash" disclosure and Mengele totally pwned it.

Now, a few months later, we get to see the full advisory posted on GNUCITIZEN by Adrian Pastor. In case anyone forgot about the original advisory, the point is carefully clarified: By the way, part of this advisory got leaked some time ago on FD, but I am publishing it as a formal release ...

So the moral of this story is if you don't have a sense of humor, then maybe you should just get off Full-Disclosure.

Well, another Firefox focus file stealing bug has been reported. Let's see. That took a little over a month since the problem was supposedly resolved in Firefox 2.0.0.8.

Originally reported to Bugzilla by "tha featurizer" based on http://www.0x000000.com/index.php?i=479.

Firefox 3 can't come soon enough. The focus issue should finally be resolved given that the text entry box on the File input element is no longer accessible. That is probably less than desirable from a usability perspective, but I think the security implications definitely override any usability concerns.

I've submitted a sample exploit to Bugzilla. Once the exploit is made public I'll post an online version.