This is one of Johnny’s most “famoustest” talks ever, and this is the evolution, which Johnny presents to audiences all over the world! Now it’s available as a video exclusively to Informer subscribers! Enjoy!
The link and password to the video are:
[private]
Link: http://vimeo.com/4616236
Password: n0techh@ck
[/private]
Google docs network was vulnerable to PDF re purposing attacks. The vulnerability was disclosed to Google with a discretion. This is done to mitigate the risk . Google has worked over it and patched it with in a period of 5 days. The Google doc has been refined and support for adobe plugin is removed.
The user security is the prime issue because millions of user were at risk if this attack persisted in the open environment. Integrated accounts were more susceptible as certain credentials could be used to access other accounts.
Thanks to Google for considering the recommendation and changing the working behavior of specific components at risk.
The detailed advisory is released here:
[private]
http://www.secniche.org/gmd_hijack/gc_hijack.xhtml
PDF: http://www.secniche.org/gmd_hijack/advisory_gmail_google_docs_pdf_repurposing_attack.pdf
[/private]
WARNING – POSSIBLE IMMATURE CURSING AHEAD. OK *ACTUAL* IMMATURE CURSING, WTF…
Well, apparently it was a real popular thing to give away a couple of 0day exploits, so more 0day is being given away! Again this is from the good old days at BindView when your buddy SN was on the RAZOR team.
[private]
There should be two like last time, so I will give away the first one real quick. I found this from a TODO list of mine from August of 2003. It simply reads “buffer overflow in netware smb authentication” and a few lines down says “large user name in nw smb auth, dos only?” That is all I have to go on. If I were really inspired I guess I could get out my box of drink coasters, erm sorry my box of old software no one ever uses, set up a NetWare server in a VM circa 2003 and start whacking away. But since I don’t want to terrorize Novell’s four remaining customers, I will let bygones be bygones.
No that one is rather lame, so here is a better one…
Todd Sabin. You know him, you love him. PWDump2 was his baby and laid the groundwork for numerous other hash dumping routines. He is a mad coder and knows Windows stuff like nobody’s business. If you’ve ever used Wireshark and looked at Windows DCE RPC decoded, you are looking at Todd’s handywork. Interesting Todd fact – instead of using some reverse engineering tool that performed a disassembly a la IDA Pro, Todd wrote his own. In LISP. The fucker is nuts.
Well Todd found a number of security issues while he was working at BindView, all properly reported to Microsoft. However Microsoft didn’t always issue a patch or fix Todd’s issues. This is one of those issues that Microsoft eventually patched but didn’t tell anybody about.
The bug, reported to Microsoft in the summer of 2004, impacted NT, 2000, XP, and 2003 versions of Windows. It seems a remote attacker could hijack RPC session handles and use them with no further authentication. Use an admin’s RPC session handle and you could have some fun with altering all kinds of things like user account permissions, registry keys, etc. You get the idea. Bad stuff.
RPC servers use something called “context handles” to represent handles to objects. So if an admin wants to change something, they get the context handle for that object they want changed, the RPC server impersonates the requester and checks permissions. The permissions are recorded with the handle, and later in the conversation permissions for the handle are checked as it does its thing. So you can see where this is headed.
Ironic part – on page 271-272 of “Writing Secure Code” (1st edition, written by very bright MS employees) it states in the section “Don’t Rely on Context Handles for Access Checks” to well, not rely on context handles for access checks, which is exactly what this flaw is all about.
So here are the steps to be evil:
Sweet, huh? Yeah I know, I think Todd fucking rocks too.
Oh sure you say, TCP connection hijacking could do the same thing. Well SMB signing defeats those types of attacks, but not this one. Bitchin’. The final sweetness is that all the attacker needs is minimally anonymous access.
So this sounds serious. It was, Microsoft said it was very serious to them. However (there always seems to be a however) this would require a massive amount of code changes — tons of subsystems would have to be touched. So Microsoft decided not to go the individual patch route. Like last time, Microsoft knew BindView RAZOR did not release vuln info unless it had patch info from the vendor.
I asked Todd about this recently and he told me Microsoft apparently did patch things, but no one was told about this. Todd’s guess was it went into XP SP2, some service pack for 2003, and probably some rollup patch for 2000. So XP and 2003 are good, 2000 possibly good, and NT is more than likely as fucked as the people who are still running a non-supported OS. You’ve gotta love those silent patches!
Ok, in Microsoft’s defense here, it probably did impact a ton of various servers and subsystems, and quite frankly there could have been other interesting examples of similar misplaced trust issues to be found in these same subsystems that Microsoft didn’t want people finding. So they fixed it and did not tell anyone (shame on you MS), but they at least shoved it into service packs which they knew would get loaded up for security reasons. Plus, all the reverse engineers are less likely to do binary diff analysis against pieces from a service pack than an individual patch, since there would be multiple security and even non-security updates to the various components, and it would be really fucked up to start looking for needles in that haystack. Granted, they now have at least one idea on where to look…
If you run into Todd somewhere, buy him a beer. He deserves it.
-SN
[/private]
This paper sheds light on the modified approach to trigger web attacks through JavaScript protocol handler in the context of browser when a PDF is opened in it. As we have seen, the kind of security mechanism implemented by Adobe in order to remove the insecurities that originate directly from the standalone PDF document in order to circumvent cross domain access. The attack is targeted on the web applications that allow PDF documents to be uploaded on the web server.
[private]
Due to ingrained security mechanism in PDF Reader, it is hard to launch certain attacks. But with this technique an attacker can steal generic information from website by executing the code directly in the context of the domain where it is uploaded. The attack surface can be diversified by randomizing the attack vector. On further analysis it has been observed that it is possible to trigger phishing attacks too. Successful attacks have been conducted on number of web applications mainly to extract information based on DOM objects. The paper exposes a differential behavior of Acro JS and Brower JavaScript.
http://www.secniche.org/papers/SNS_09_03_PDF_Silent_Form_Re_Purp_Attack.pdf
[/private]
First come first serve…here’s the Maltego license key that’s good for 155 days:(see below). Not working anymore ? You should have been checking the site more regularly. Can’t see the license key? Subscribe to the site and donate some money to those that really need it. Just do it.
RT
[private]
0654-7205-3800-0900-5999-1
[/private]
The following is a pre-release of a blog post by Simple Nomad. It contains colorful sailor language — not descriptive nautical seafaring prose, but low-brow unnecessary pirate cursing. Proceed at your own risk. Arrrr!
Not one, but two 0days surpressed from the BindView RAZOR days….and I am letting them go now.
The ugliness, the ugliness of a stupid flaw you cannot control, one that will get you cool points but at the same time make your life miserable. Imagine finding a flaw that affects multiple vendors — major vendors — and no one wants to do anything to fix it.
[private] You work on it at a company that has a policy that prevents you from releasing the bug info since there is no patch. Release it anyway? Well, work will be pissed off, especially since they partner with one of these major vendors and do not want to piss off said partner. On top of that, it will cause your basic shitstorm among Internet users. And even have a direct input on your inbox with a metric fuckton of spam and scams. Oh that will get it fixed, most certainly, but you will be considered a complete asshole of a prick jerkwad deluxe. You go to CERT, and guess what, they run into the same fingerpointing that you do. It is “the other vendors fault, not ours.” And it is 2004 – the dotcom bubble has burst, and you are trying to justify that ridiculously high salary, and all your hacker friends are getting into that whole “responsible disclosure” thing.
Fuck it, BindView got sold off, at the end no one gave a shit about the RAZOR team. And it has been almost five years, plenty of time for vendors to silently patch. Disclosure time.
Discovered by yours truly in mid 2004, this was a gem of a bug. Imagine being able to bypass not only anti-spam and anti-virus products, but in some cases bypass IDS/IPS systems as well. Over a well known and usually open port on the firewall. Sweet. Before we get to the bug, a bit of explanation about the bullshit behind not releasing it.
As you might have guessed, this involves email since anti-spam was mentioned. An email message could be constructed that bypassed normal anti-virus scanning of incoming email. Many vendors were affected, so a couple of the major ones were contacted (if memory serves, since I no longer have the original emails, it was Trend Micro and McAfee, or someone like that). “Yes you are correct” they say, “we can be bypassed this way, however we can do nothing to detect it since our flagship product runs on Exchange and Microsoft will not give up the right API calls we need to update our engine.” Same thing for anti-spam.
So Microsoft is contacted. “Not our problem” they say, “we are not going to create additional libraries that use internal API calls that don’t exist but could also expose us to having our intellectual property copied.” Besides, the vendors apparently had to pay extra for what access to the APIs they currently get, and some were not even paying for those (they reverse engineered around them), so Microsoft had no incentive to write more APIs. The biggest disadvantage? All of these companies are aware of the BindView RAZOR team bug release policy — no advisory unless the vendor has a patch. So they all blamed each other and all say “we won’t patch.” Getting CERT involved did not help, they were told the same thing, knowing BindView would not release an advisory. CERT could not release anything independently as they need a vendor or vendors to blame, and they all blamed each other.
Isn’t the security industry wonderful?
The bug is ever so simple. Create an email message, stick in a huge X-* header, like X-Testing: VeryLongStringHere. You get the idea. Now end the message before adding a message body. That’s the trick. What happens is interesting. This is a completely invalid email message, and the X-Whatever spills into the area in an Outlook client that the message body is displayed. So you send the VeryLongStringHere thing with the EICAR test virus string on the end, no anti-virus is triggered, and you get the EICAR test string clearly visible in the message window. Why? Because the existing (at the time) APIs Microsoft gave the vendors did not allow for scanning of anything other than the body of a message, so if you stick stuff in the headers it is not scanned. The vendors could pay for APIs that allowed for inbound scanning and outbound scanning (some only would choose inbound), but no one had APIs to scan headers. Microsoft would not give them up. The vendors said Microsoft should fix Outlook to not display header info to the end user in the area where the message was, Microsoft said they did not handle invalid email and were following RFCs. Whine, whine, whine.
The main thing was this evil header message, although it actually lead to another bug. The easiest method to create it was to telnet into port 25 on a box running Sendmail and doing the whole MAIL FROM and RCPT TO thing manually, and shoving in a huge X-Header, followed by QUIT. Boom off it went on to its destination, an Exchange server with a waiting Outlook client to view it. The telnet-to-port-25 trick did not work in going directly to Exchange though. Why? More exploring found another bug…
Sendmail had an issue in handling headers, creating the mangled message. A very LARGE header caused a crash. What was the issue? A damned heap overflow. OMGWTF. I had a nice remote AV bypass, but now I had a heap overflow in Sendmail. Both port 25, which is ALWAYS open in the firewall. However I was told by BindView to stop working on the Sendmail bug.
The Sendmail flaw was never pursued to see what all was possible with it, as BindView said we would not publish details on it anyway as it could possibly lead people to figure out how to do the AV bypass thing. It was reported to Sendmail as is, they saw the potential implications and (according to them) did not even see if it was exploitable, they just assumed it was and they fixed it (quickly and without a bunch of crap, Eric and Claus were whom I worked with and they rocked it). Anyone with a bit of rev engineering skills could have figured out what was up, but no one did, or didn’t say anything publicly.
As a side note, the Sendmail folk thought that Microsoft should fix handling of the non-RFC compliant messages that were sticking the EICAR test virus into the message body in Outlook, being that Sendmail had tons of patches to correct problems caused by other mail systems, simply because they knew it would make life easier for the sys admins. Wow, what an attitude, caring about the users. This is the main reason I still use Sendmail to this day — they actually give a shit.
So the main bug in AV was surpressed. And a second bug, a potential remote code execution bug in Sendmail was surpressed as well. The funny part? I was trying to screw up the way Outlook handled the X-Message-Away header, thinking I could get a nice client overflow, and found two other bugs instead.
So there you have it. A tale of two bugs, and a small bit of insight into the politics of bug hunting. [/private]
The Informer is a fund raising effort run by Hackers For Charity. It is designed to give subscribers a “backstage pass” to the world of Information Security. 100% percent of the proceeds go into our food program in East Africa, designed to stand in the gap for children that are waiting for help from major aid organizations. Click here to learn more about the Informer, and thanks for considering helping out.
