David Dewy over at ISS keeps telling Tom that I should stop all this Web nonsense and "works on some big boy stuff." While I am very happy in Layer 7 right now, I am starting to poke around in the low level stuff.
I bumped into Sir Dystic at Tooron and Security Opus last week we reconnected from back in the early days of Interz0ne. We had some all round good times at the Metreon in SF playing Street Fighter 2 and drinking sake out of wooden cubes.
He then showed me some fun stuff that reboots, freezes, and exceptions in kern32.dll on a fully patch XP SP2 box. We got to talking, because we are pretty sure this can be done remotely. Not only remotely, but from visiting a webpage!
Anyway, this is a starting point to play catch up to Josh's NT knowledge.
So to settle all this craziness about disclosing Firefox 0day, I decided to call Six Apart's press office, as Mischa Spiegelmock claimed he works there.
A gal named Jane Anderson, who has a killer accent BTW, talked with me and here what I found out.
-Mischa does work for Six Apart -Mischa didn't tell them he was doing this -The company has contacted Mozilla, but Six apart has nothing to do with getting the issue (issues?) resolved -Any future information regarding this flaw (flaws?) will not be released/discussed by Six Apart -Six Apart believes in responsible disclosure -It is the understanding of Six Apart that the presentation was supposed to be funny, but people didn't seem to take it that way. How exact stack overflows in FF's JavaScript interpreter are funny was never really explained to me -Jane has be *very* busy for the last day or so and this is causing them some major issues
I thanked Jane for talking so frankly with me but truth be told, they need to fire this guy. Immediately.
Short and sweet: I can find out what you have been searching Google for from JavaScript. I can put this JavaScript on any site either because I own it (How much do you trust memestreamas.net?) or because I have a XSS vuln that lets me inject JavaScript in the site.
Think the AOL leakage... only for everyone on the internet.
Some fun use cases:
-HMO’s website could check if a visitor has been searching other sites about cancer, cancer treatments, or drug rehab centers.
-Advertising networks could gather information about which topics someone is interested based on their search history and use that to enchance their customer databases.
-Government websites could see if a visitor has been searching for bomb-making instructions.
Oracle: Oracle encourages independent security researchers to follow a 'responsible disclosure' policy. Researchers notify vendors about a vulnerability and do not publicly disclose information regarding the vulnerability until we have released a patch for it.
... which is all well and good under you realize that Oracle is horrible about patching security issues, regularly taking not weeks, not months, but years to release a patch. If Oracle thinks security researchers are going to wait years, they are mistaken. At that point, its irresponsible not to release a public notice.
Let's admit it—we're so accustomed to the idea of session state that we forget that session state is an artifice introduced with Active Server Pages (ASP) back in 1997
Let's admit it, Microsoft is so accustomed with dealing with morons and self promoting MVPs that they think everyone else will forget that Netscape introducted the idea of session state in 1994 with cookies.
Dino Esposito is a no talent ass clown who should be ashamed of himself. Too much MS koolaid = shitty journalism.
There are several security issues with having an Ajax enabled application. Some of them are traditional web security issues that are magnified because of Ajax, and some a new issues. Here are just a few. I refer you to my BlackHat presentation Ajax (in)Security for more info.
Old Issues: Issues:Ajax applications have a larger attack surface.
Results: Its easer to hack your webapp. Traditional applications have a relatively few number of forms or other parts that accept user input. We already do a poor job protecting these (just look at Full Disclosure any given week). Some web apps accept file format input, and we do a really bad job securing that input (see numerous PNG/JPG attackers, WMF, ZIP attacks, etc). Ajax increases yet a 3rd type of application inputs, Web services. Most Ajax requests are destin for a web service that woudln't exist if the app didn't use Ajax. As a whole, web services are rarely protected because most programmers don't think of these are inputs, they think of them as functions. This is really bad when retrofitting a traditional application to an Ajax application. Before, the web service or function was hidden inside your enterprise with no way for the client to directly call it. With an Ajax app, large parts of the applicaitons API are now publicly exposed and are rarely secured.
Issue: Ajax applications are very complex. They are written in multiple languages, the code must work on multiple platforms/OSes, and they are multi-threaded.
Results:Ajax applications are much harder to debug and test than traditional applications. JavaScript is highly dynamic, loosly typed, and can add new exection paths as well as edit current execution paths in a program. This means most JavaScript errors are runtime errors and its very hard to examine all possible paths the program will take. This, coupled with the the asynch nature of Ajax means most Ajax apps contain deadlocks and race conditions that can be exploited.
New Issues:
Issue:Your application straddles the network and exists on both the client and the server.
Results:Attackers can see data types, return types, function names, and program flow of your application by analyzing the plaintext JavaScript. While you should push not business logic to the client, most people do and Ajax Frameworks like CPAINT/"Atlas" make it easier to make this mistake by abstracting a control. Programmers don't know (and don't want to know) how much of a control is on the client and how much is on the server. CPAINT makes it very easy to "export" or "share" a PHP function so your client code can call it directly. I've seen apps in the wild that have a webservice you can send PHP or Perl to that simply get past to an eval statement.
Issue: Ajax is something that on the client, not the server. Websites cannot turn it on or off
Result: Ajax has amplified the damage XSS attacks. Ajax allows XSS to make hidden, asynchronous HTTP requests that the browser will automatically add the necessary cookies and HTTP auth to. The XSS has full access to response as well. Even sites like Yahoo's webmail that don't "use" Ajax per say can still be contacted by an HTTP request that Ajax makes. Ajax has directly lead to the creation of self propagating XSS worms.
Issue: The Server cannot tell the difference between a request made by the browser in response to a user event (clicking on a link) and a request made by the browser because JavaScript told it to.
Result: As a user, you cannot prove beyond a reasonable doubt that you did or did not issue an HTTP request. The effects of this in a financial application are frightening.
