Damn you Adam Shostack! Damn you! [shakes fist] :-)

I knew I shouldn't have introduced you two at Black Hat! :-)

From:
Date: Nov 26, 2007 11:52 AM
Subject: [Full-disclosure] To Hell With Georgia
To: full-disclosure@lists.grok.org.uk

UGA may have beaten Georgia Tech this year in football but just
listen to what their website has to say:

http://www.uga.edu/cgi-
bin/ldap?name=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%27%54%6F+%4
8%65%6C%6C+%57%69%74%68+%47%65%6F%72%67%69%61%27%29%3C%2F%73%63%72%6
9%70%74%3E&submit=Go&ouo=%3Duga&searchtype=cn

I've URI-encoded the injected script as to not spoil the surprise
(benign XSS).

Go Jackets!!!

-George P Burdell

To the Georgia Tech Alumni on Memestreams. What's the good word? To Hell With Georgia!

PS: It looks like George never got the message that Hushmail isn't so secret...

What's the good word?

RegEx Validators are handy for implementing Whitelist input validation so it pays to see what they actually do under the covers.

    try
    {
        Match match = Regex.Match(controlValidationValue,
            this.ValidationExpression);
        return ((match.Success && (match.Index == 0))
            && (match.Length == controlValidationValue.Length));
    }
    catch
    {
        return true;
    }

A final thing that caught my eye was the try ... catch ... block. If the Regex.Match() call throws an exception, the validator returns true indicting the input is safe. This means in event of an error, the validator fails open instead of failing closed! Deciding when applications/appliances/software/hardware/structures should fail open or fail closed is way beyond the scope of this post and the answer is almost always circumstantial based on the individual situations. Quick, should firewalls fail open or closed? Fail open? Well then an attacker knocks out your firewalls and its open seasons on the FTP servers and Samba shares inside your organization. Fail closed? Thats a nifty DoS you built into your network infrastructure now isn't it? when should input validation fail open or fail closed? Again depend, but my gut tells me it should fail closed more often than it fails open.

More web sec people read Memestreams than read the SPI Labs blog. I'm not really sure what to make of that. :-)

ASP.NETRegEx Validators fail open? WTF?

I knew it was only a matter of time before I had to start filtering out poorly written and technically incompetent XSS "0day" posts on WebAppSec. I just hoped it would have lasted a little longer.

This attack is known as 0day because it has just been reported to public and this is first day of public vulnerability, and 0day means 'published.'

... [sigh]

There is so much wrong with this sentence my head might just explode.

That's quite an image, isn't it? It's ISS CEO Tom Noonan holding a silver bullet, announcing the Proventia IPS product in the October 2003 issue of ISS' Connect magazine. Raise your hand if you think IPS or anything else ISS has produced is a silver bullet. No takers?

I don't mention this to criticize ISS, specifically. Rather, I'd like to emphasize the importance of proper frames of reference when considering security.

HAHA! I've enjoyed Richard Bejtlich's humor for a while now, but this was too good not to post.

Kidding aside, Richard raises a good point that nothing in security is a silver bullet. Not an application, not a WAF, not WebInspect, not security as a service, nothing. Security must be layered, composed of many and varied products and defenses. Anyone who says otherwise is a charlatan.

Silver Bullets and the Network Werewolves

A September court document from a federal prosecution of alleged steroid dealers reveals the Canadian company turned over 12 CDs worth of e-mails from three Hushmail accounts, following a court order obtained through a mutual assistance treaty between the U.S. and Canada. The charging document alleges that many Chinese wholesale steroid chemical providers, underground laboratories and steroid retailers do business over Hushmail.

... uhhhhh... ... Must go now. [begins shredding]

Hushmail uses industry-standard cryptographic and encryption protocols (OpenPGP and AES 256) to scramble the contents of messages stored on their servers. They also host the public key needed for other people using encrypted email services to send secure messages to a Hushmail account.

The first time a Hushmail user logs on, his browser downloads a Java applet that takes care of the decryption and encryption of messages on his computer, after the user types in the right passphrase. So messages reach Hushmail's server already encrypted. The Java code also decrypts the message on the recipient's computer, so an unencrypted copy never crosses the internet or hits Hushmails servers.

In this scenario, if a law enforcement agency demands all the e-mails sent to or from an account, Hushmail can only turn over the scrambled messages since it has no way of reversing the encryption.

However, installing Java and loading and running the Java applet can be annoying. So in 2006, Hushmail began offering a service more akin to traditional web mail. Users connect to the service via a SSL (https://) connection and Hushmail runs the Encryption Engine on their side. Users then tell the server-side engine what the right passphrase is and all the messages in the account can then be read as they would in any other web-based email account.

The rub of that option is that Hushmail has -- even if only for a brief moment -- a copy of your passphrase. As they disclose in the technical comparison of the two options, this means that an attacker with access to Hushmail's servers can get at the passphrase and thus all of the messages.

Hushmail Spills it to Feds

And while over 2/3 understand that Ajax applications have an increased attack surface, many of the comments showed that some people believe Ajax security is just about an increased attack surface.

Let me assure you, if Ajax Security was only about an increased attack surface two things would have happened:

1. Addison Wesley won't have asked me to write a 500 page book about it
2. Bryan and I would have finished a long time ago :-)

There are many issues surrounding Ajax Security and hopefully this piece will help people see the bigger Ajax Security picture.

A little peak into some of the many topics we cover in Ajax Security, our book on all things Ajax.

Hopefully this little taste shows you that there is far far more to Ajax Security than some JavaScript eye candy and an increased attack surface. Developer, QA professional, and hacker alike will all find Ajax Security an enormously powerful resource to help design, build, test, and hack Ajax applications.

Ajax Security is more than an Increased Attack Surface

Friends and relatives of Stacy Peterson, 23, say her disappearance is suspicious.

Her husband of four years, Bolingbrook police Sgt. Drew Peterson, 53, reportedly has told police his wife said she was leaving him for another man, and police are not treating the disappearance as a criminal investigation.

...
23 - 4 = 19
53 - 4 = 49

Since when do cops get trophy wives 30 years their junior? And that doesn't even including dating. They got married when she was 19, so they started dating when she was what, 18? 17?

[checks story] Hmmm I could have sworn this would have taken place in the South.

Trophy Wives and the Blue Wall of Silence

"Ajax Security is a remarkably rigorous and thorough examination of an underexplored subject. Every Ajax engineer needs to have the knowledge contained in this book - or be able to explain why they don't."
-- Jesse James Garrett, Father of Ajax

Best. Praise Quote. Ever.

Jesse James Garett: Buy Ajax Security Book

K Said:

Just ran across this...

Any chance it makes the baby jesus' crying less acute?

Well, this sure scares me: http://saja.sourceforge.net/security/

I need to look at this but here are my thoughs so far.

The "Function" security sounds a lot like nonce on the system calls. Ok, so no one can access you system calls unless they are using your application, but most of hte Ajax stuff I'm focusing on is exploiting the application inside the context of the application (i.e. tampering with variables while its being used, control flow modification, data leakage, etc). This "you can only access the callback if you are really using the application" approach doesn't sound promising because it doesn't really address the problem, it attempts to limit access to the problem.

The emulating SSL with JavaScript is just damn scary. We have a whole chapter about hacking and securing mashups and aggregates like NetVibes, Facebook, etc in Chapter 11, Web Mashups and Aggregators, in our book Ajax Security. Here we point out that this implementing crypto in JavaScript is a bad idea. In fact, here is the text from the book:

Another popular aggregate site, PageFlakes, tries attempts a different solution: using asymmetric key encryption (also known as public key encryption). In public key encryption, the key used to encrypt the data is different than the key to decrypt the information. Thus PageFlakes uses a public/private key pair and embeds the public key in the web pages it sends to the client. Client-side JavaScript uses RSA to encrypt sensitive data before transmitting it to back to the server. This allows data to be securely sent from the client to PageFlakes by essentially emulating parts of an SSL connection on top of an HTTP connection. However this is not a good solution because it only solves half the problem because. Only the web server has a public/private key pair allowing secure communication in a single direction form the client to the server. There is no way for the server to communicate back to the client. You cannot pre-seed the client-side code with its own public/private key pair because that would be transmitted to a user’s web browser unencrypted over standard HTTP. An attacker would simply intercept it. The public/private key pair for the client would have to be generated on the client. JavaScript does not have a random number generator that is suitable for cryptographic functions. It might be possible for JavaScript to use a Java Applet’s cryptographically secure random number generator for key generation, but some browsers do not allow Applet’s to access these secure libraries. This whole approach does not even matter if malicious widgets that are not properly jailed. They could simply hook the JavaScript code and steal sensitive data before it is even encrypted using this convol... [ Read More (0.2k in body) ]

SAJA, and the smoking of the crack