Some things are cross-culture it seems. Especially when it comes to trivial security mishaps.
So I’m at a PoS terminal in a large department store in Seoul and while I’m waiting for the register to ring up my order, I look at the touchscreen where I will be asked for my signature in a moment. I notice a little icon that looks like ’settings’. How can I not click on it?

Oh, it needs a password. Must be this PCI compliance thing everybody is raving about. And no, wiseass, 1-2-3-4-5 doesn’t work.

…But 1-2-3-4 does.

Yup. Unlocked.
Now I need to polish up my Korean to figure out what to do next. Suggestions?

Sorry for the full disclosure guys. And that includes all of you that now need to change your luggage combination.

How hard is it to get facts straight? I don’t expect vendors to admit they sat on a vulnerability for months without patching: it’s human nature to blame someone else:

Opera […] claims that it couldn’t replicate the issue at the time. According to the vendor, its attempts to obtain more information from the researcher at the time weren’t successful.

Of course, when dealing with vendors, it’s always “the dog ate my homework” and “I swear we couldn’t reproduce it until it became public”
But I’m puzzled on why a technical reporter would just happily accept what’s being shoveled at him. For one, he could have contacted us and asked…

Here’s what really happened: We notified Opera about this vulnerability back in May. We gave them the Proof-of-Concept, disassembly, explanation and vulnerability analysis. So saying they did not have the full information is far from the truth. We didn’t ask for anything in return (we never do) but I admit we were skeptical based on previous experience with reporting vulnerabilities to Opera.
Then came the Million dollar question; we were asked if it worked on the latest version of Opera, and we said we don’t know. Since last time I checked, no one here worked for the Opera QA team, so we didn’t feel it was our job to check it. The response was typical:
“We only fix issues that are relevant to the latest version of Opera”

Followed by the all-too-common:”the items provided only cause crashes they have no intention to fix them”.

I guess they meant “we won’t fix them unless you drop a 0-day and we get a call from a computer magazine”.The Vendors-against-full-disclosure will continue, no doubt. Tech writers, get your spines refitted please: if you’re not a part of the solution, you’re a part of the problem.

It’s amazing to compare how the Microsoft Security Response Center handles vulnerability disclosures versus how things were just 10 or 12 short years ago.

Here’s a typical disclosure process 10 years ago (based on a very true story):

Us: (sending an email to secure@microsoft.com) we’ve discovered a vulnerability in an office product. Here are the technical details. Can you confirm the issue and let us know when it’s patched?
Microsoft: Thanks for reporting, bla bla, we’ll get back to you soon

[about a week passes]

Us: Hi MSRC, any news about our office vulnerability?
[no reply]
[Sending a personal email to an MSRC friend to speed things up]
Microsoft: Oh, thanks for reminding us. We’ll check with the office team

[another few days pass]

Us: Hello? Anybody there?
Microsoft: Oh, yes. That vulnerability thing. Here’s what we decided: (a) It’s not a vulnerability. (b) it’s not a problem with the office product but with the world (or the RFC) (c) The office team can’t recreate it (d) even if the vulnerability was real, it wouldn’t be exploited in real world scenarios
Us: are you kidding us? Did you actually look at the sample code we gave you?
[a few days pass. We are pondering if to go complete full disclosure or give them time to digest]

Microsoft: Ok, this time we actually read your advisory and yes, it seems to work. But it’s just a denial of service. Nobody will ever exploit it because of … [something that heap spraying/DEP bypass/code mutation made look ridiculous about a year later]
Us: [starting the get mad] look guys. We sent you PoC code. You actually want us to write an exploit code for you?
Microsoft: yes, that would help convince our developers

[Us, spending time writing code so that Microsoft is convinced to fix their own products based on free information while wasting our precious time]

Us: here it is
Microsoft: oh, wow, it really does run code. Ok, we’ll fix it in the next release cycle which should be right after the democratic primaries of 2012.

Us: Ok, forget it. We’re going full disclosure

Microsoft: no, wait wait wait. We found your name on the world wide web and now realize you’re legit. Ok, we’ll fix it. Happy now? We might even mention your name in our advisory if/when that happens.

If it sounds familiar, that means you were disclosing vulnerabilities to vendors in the early 2000’s or late 1990’s. If you think I’m exaggerating, it’s only because you didn’t.

But here’s the amazing thing. Just a few years later, some radical changes started to happen. The big dysfunctional dinosaur that was MSRC became an efficient, friendly and if I didn’t know it, I would think it’s a different company altogether. Here’s a real recent discussion:

Us: Hello MSRC, here’s information about an office vulnerability
Microsoft: Hi, thanks for reporting. I checked the information, went over the sample code and have some technical questions [some intelligent questions here, basically they are doubting the findings but being really careful to check all the angles first]

[technical discussion continues for a couple of days with questions and answers going back and forth]

Microsoft: Ok, we get the picture now. Thanks for reporting. Here’s the guy that is going to be responsible for your case.
[a few days pass]
Microsoft: Ok, we now know it’s a […] vulnerability and not a […] one. We’ll pass it to the relevant team, just wanted to keep you posted
[further proactive updates and niceties continue until disclosure time. Credits, the end.]

What could have possibly caused this radical change that made MSRC focus on the technical side instead of the PR, not to mention being so research-friendly? New team? New procedures? Full disclosure forced them to see the truth? Too many beers at defcon finally showed them the light? Whatever they are taking, I wish they could spread some around. Most of the other vendors could use that. Yes, I’m looking at you Google.

I’ve spent a lot of time thinking about what to do with this one, and when I say a lot of time, I really mean just over 3 months now. I also informed Apple that I would be writing this article, and asked for an official quote from them, and also a rough date as to when the relevant patches would be disclosed.
I found this one by fuzzing Safari 5.0 on the night that it first came out, I was using Browser Fuzzer 2 (bf2)and then spent a while playing with it to see if I could turn this into more than just a Denial Of Service (DoS), unfortunately I wasn’t able to. This is not to say that it’s not possible to do so, I’m just not too sure on how to do it, it may very well be more than just a DoS with a few tweaks to the code.

I initially tried selling this one to ZDi, but their response to me was fair and to the point:

“Dear xyberpix

We have reviewed your recent case and discovered it was a duplicate of an issue we received in January of this year. We have also determined that this issue is likely non-exploitable. Due to this we are going to pass on the opportunity to pursue acquisition of this vulnerability information through the ZDI program.

Thank you for the submission and we look forward to your future work.

Regards,
The ZDI Team”

So, January 2010 and to date, this still has not been fixed by Apple! People give Microsoft and Adobe a hard time about their time to release patches, but seriously 8 months is really pushing it!

So I figured I’ll see what Apple has to say about this one, and sent it along to their product security team, asking if they were willing to reward vulnerability researchers for their time. I wasn’t asking for anything major at all, maybe the cheap iPad or even just a copy of Logic Studio 9 for my trouble. That’s really not too much to ask really is it? I didn’t have any high hopes though, and well here was their response:

“Hello Xyberpix,

When we address an issue in a Security Update, we give credit to the person who reported the issue to us.  However, Apple does not directly provide financial reward.”

Okay, fair enough, I didn’t go looking for bugs for financial gain, but it would have been a nice token nonetheless. I guess the fact that I’ve been a loyal Apple fan boy for close on 8 years now means nothing to them at all. I guess this is why I’m a firm believer in the No More Free Bugs movement, in the same sense though I can’t sit around idly and wait for what’s been over 3 months since I found this issue, and Apple has not released a patch yet!

Apple also came back to me stating that they had addressed this vulnerability in iOS 3.2 and iOS 4.0, well, erm, dunoo how to tell you guys this but, nope you didn’t. So being the nice guy that I am I sent them the relevant crash logs as requested. Their response was the following:

“Hello xyberpix,

Thank you for forwarding this issue to us.  We take any report of a potential security issue very seriously.

After reviewing the issue, it appears that this denial of service issue results in the unexpected termination of MobileSafari, but not of the host operating system or a system service.  For our internal tracking purposes, this will be classified as a “Crash / Hang” issue. Although we do not see additional security concerns, we do consider this to be an important issue, and are working with the engineering team to address it.

If you have reason to believe that the issue has ramifications beyond terminating Safari (such as terminating the operation of the host operating system or system service, or executing arbitrary code), we would appreciate the steps to reproduce this, or crash logs from when you observed it.”

I then replied asking about this issue on platforms other than iOS, namely Windows and OSX, to which I recieved the following response:

“Hello xyberpix,

The crash is still a security issue on platforms on which it has not been addressed.  So far, it has only been addressed on iOS.

For the protection of our customers, we ask that you do not disclose details of this vulnerability until it has been addressed on all platforms.

When we release an update to address this issue on other platforms, you will be credited for the vulnerability.”

Okay, so let me get this straight, this is not a security issue on iOS, it’s a crash/hang issue, which they have apparently addressed in iOS 4, and I had to bug Apple about the Windows and OS X Safari issues, even after I informed them that it was possible to crash Safari on all platforms, not just iOS? Something’s not quite right here…

When I asked for a rough timescale on when a patch for this is going to be released, I was given the following response:

“The following information should be considered confidential.  We are sharing this information as a status update on an issue you reported.  Please do not share this information with others.

This issue has already been assigned CVE-20xx-xxxx, when it was fixed on iOS.

The issue is currently planned for our next available software update.  I don’t have a date for you yet, but we will coordinate with you closer to the release of the udpate.
“

I completely understand confidentiality, but I also believe that security researchers should get more than just credit for discovering a vulnerability that Apple’s testers should have found in the first place.

Oh wait, it seems they did find it, but they just claimed to have fixed it, instead of actually fixing it, did I get that right?

My last attempt at contacting Apple was on the 2nd August 2010 to ask if they could please give me an official statement on this issue that I could include in this post, and if there was still no chance at all of getting some sort of reward for this finding. Their response was this:

“Hello xyberpix,

We do appreciate the time you took to find and report the issue to us.

As mentioned, it is not our policy to provide financial compensation for issues.”

I really don’t want this post to be taken the wrong way, yes I was looking for compensation for the vulnerability, but not thousands of dollars, just a little something to make the time spent on this one worthwhile. I also wanted to have an official statement from Apple on this one as to when they are likely to release a patch, neither of which they were willing to do. Personally I don’t feel that either of these things were too much to ask at all from a company that is growing in leaps and bounds each year.

If any Apple employee’s would like to discuss this one further with me, the case number for this issue is 111476071, and you have all my contact details.

As a matter of courtesy and security I will not be publishing the code for this DoS, as I do not believe that would be responsible, once a patch that works has been released by Apple, I will upload the code. I have also removed the CVE number and also the specific function that causes the crash.
I’m really looking forward to all your comments on this one people, as I’d love to hear your views.

Yesterday Apple released a security update that patches the Jailbreakme vulnerabilities to stop people Jailbreaking their Apple devices.

Okay, so maybe I’m looking at this the wrong way around, but it seems that when a vulnerability gets a lot of media attention, Apple work the backsides off to get this one patched. I understand that we are talking serious vulnerabilities here, but still. I’ve personally been in contact with Apple for a couple of months now in regards to a DoS vulnerability that I discovered, and still have no time line on when a patch for this will be released, so maybe all that’s needed is to turn this into some media hype, hmmm.

So the vulnerabilities that this patches are the following:

• FreeTypeCVE-ID: CVE-2010-1797

  Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

  Impact: Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution

  Description: A stack buffer overflow exists in FreeType’s handling of CFF opcodes. Viewing a PDF document with maliciously crafted embedded fonts may allow arbitrary code execution. This issue is addressed through improved bounds checking.

• IOSurfaceCVE-ID: CVE-2010-2973

  Available for: iOS 2.0 through 4.0.1 for iPhone 3G and later, iOS 2.1 through 4.0 for iPod touch (2nd generation) and later

  Impact: Malicious code running as the user may gain system privileges

  Description: An integer overflow exists in the handling of IOSurface properties, which may allow malicious code running as the user to gain system privileges. This issue is addressed through improved bounds checking.

A month ago I complained about Sonicwall and google brushing us off when we reported vulnerabilities to them. The good news: Sonicwall has since contacted us, acknowledged the problem and is now rolling out a fix.

Was I too harsh on Sonicwall? It was hard to get their initial attention, but once we did they cooperated in an exemplary way. I’m not fooling myself to think any researcher that will notify them of a problem will get the same level of attention, but obviously they do give a damn, and maybe security@sonicwall will be open for notifications from now on.

The friendly guys over at Sophos have been kind enough to release a protection tool to protect against the now famous Microsoft LNK 0-day vulnerability. Someone had to do it, it’s a shame it wasn’t Microsoft, but hey.
What this tool does is to replace the current Microsoft icon handler with the Sophos one, so it will check all shortcut (LNK) files before allowing them to run, what’s even nicer is that this tool is free, and you can download it from here.

Please note though that this tool does not protect you from  LNK files or targets stored on the local disk or PIF based exploits.

There’s also a video of the tool in action, which you can find on YouTube here.

UAE says privacy is a security risk.

US says openness is a security risk.

So it seems that Safari uses the details from your Address Book to AutoFill forms on web sites, this is enabled by default. In theory this is a great idea, until someone writes some malicious JavaScript to get these details passed to a hidden form without your knowledge. Looking through all the possible available fields in the Apple Address Book app, it really gets quite troubling. Name, Address, Job Title, Department, Anniversary. This could all be used nicely for a really fun Social Engineering exercise, or really help with an identity theft scam.

There is a PoC of this hosted here.

Personally I’d suggest disabling AutoFill in Safari’s preferences, better safe than sorry.

With all the talk about the Microsoft LNK exploit, it was only a matter of time before the guys over at camp Metasploit added the exploit for this one to the Metasploit Framework.

You can find the details for the module over here.

If you’re one of those types of people that want to have a look at the source code for this one, then you can cast your eyes on that right here.

To get this module into MSF, all you have to do is SVN up.

Have fun

I decided that it would be a good idea to publish summaries of MS’s patch updates on here each month, let me know your thoughts. I know that you can get these from MS directly, but I just figured that if you read SecuriTeam anyway, then here’s some more useful information for you.

My personal opinion on this one is that if there’s one patch you really should apply ASAP, then it should be MS10-042.
So without further ado.

MS10-042 (Critical - Remote Code Execution)

Vulnerability in Help and SupportCenter Could Allow Remote Code Execution (2229593)

This security update resolves a publicly disclosed vulnerability in the Windows Help and Support Center feature that is delivered with supported editions of Windows XP and Windows Server 2003. This vulnerability could allow remote code execution if a user views a specially crafted Web page using a Web browser or clicks a specially crafted link in an e-mail message. The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must click a link listed within an e-mail message.

MS10-043 (Critical - Remote Code Execution)

Vulnerability in Canonical Display Driver Could Allow Remote Code Execution (2032276)

This security update resolves a publicly disclosed vulnerability in the Canonical Display Driver (cdd.dll). Although it is possible that the vulnerability could allow code execution, successful code execution is unlikely due to memory randomization. In most scenarios, it is much more likely that an attacker who successfully exploited this vulnerability could cause the affected system to stop responding and automatically restart.
MS10-044 (Critical - Remote Code Execution)

Vulnerabilities in Microsoft Office Access ActiveX Controls Could Allow Remote Code Execution (982335)

This security update resolves two privately reported vulnerabilities in Microsoft Office Access ActiveX Controls. The vulnerabilities could allow remote code execution if a user opened a specially crafted Office file or viewed a Web page that instantiated Access ActiveX controls. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

MS10-045 (Important - Remote Code Execution)

Vulnerability in Microsoft Office Outlook Could Allow Remote Code Execution (978212)

This security update resolves a privately reported vulnerability. The vulnerability could allow remote code execution if a user opened an attachment in a specially crafted e-mail message using an affected version of Microsoft Office Outlook. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Have fun patching all, and please remember to test these patches in a non-production environment before applying directly to production environments guys and girls.

So The Piratebay has been hacked, and the hacker who did it has made off with the details of 4 million users on the site.

The details in question are usernames, e-mail addresses and internet addresses, this was all accomplished via a SQL injection attack.

The hacker in question here is of Argentinian origin, and goes by the handle of Russo, he mentions that he considered selling the data, but then decided to just go public to show that the Piratebay’s security wasn’t up to scratch.

This brings up a very interesting point though, as he could probably get a fair amount of money for these details if he was to sell them to say, oh I don’t know, the RIAA or the MPAA for example?

Even with all the problems that the Piratebay have had over the last few months, it still remains one of the largest bittorrent trackers on the Internet, and having the details of 4 million users is a really nice bounty to walk away with.

The cynic in me is half expecting most of these users to wind up with nice little letters from either the RIAA or the MPAA or both in the next few months, but I guess we’ll just wait and see.

The Piratebay was down for a while yesterday, with the following message posted on the site. “Upgrading some stuff, database is in use for backups, soon back again.. Btw, it’s nice weather outside I think.”

Yeah, upgrading some stuff, that’s a good one actually. Maybe Zone-h should change their defacement archieve title to something along the lines of “Upgrade Archieve”

On a side note though, it is interesting when hackers tend to go after sites that are helping to distribute copyright material. This also begs the question of, could he have been sponsored to do this, say under NDA, with a large sum of money from some 4 letter acronym? I’ll leave you with that thought, but if I was running a bittorrent tracker at the moment, I’d be a bit concerned…

So the last post that I wrote, and Aviram’s follow on post really got me thinking, unless you know where to sell software vulnerabilities or exploits, finding places isn’t really that easy at all. I knew about ZDI and VPC, but that was it really, and it took me ages to remember VPC.

So I spent some time Googling, and well that didn’t help me much to me honest. So I’ve decided to compile a list on here, with a subject that’s easy enough to search for.

So what I’m asking all our readers is that if you know of anywhere that buys software vulnerabilities legitimately, please let me know by leaving a comment and I’ll update the list here accordingly.

So without any further ado, here’s the definitive list of where you can sell those exploits and vulnerabilities that you worked so hard on discovering and writing.

Beyond Security

Zero Day Initiative (Tippingpoint)

Vulnerability Contributor Program (iDefense)

Global Vulnerability Partnership

Xyberpix described how difficult it is to disclose vulnerabilities to ZDI and iDefense. But even after you sold it, the process is just beginning. Sure, the researcher gets paid and he is free to resume his work, but the work us, the vulnerability coordinator, just begins.

We recently received 2 disclosures to our SecuriTeam Secure Disclosure program for Sonicwall and google vulnerabilities. We received sponsors for both vulnerabilities which means there is a commercial organization out there that was willing to pay the researcher for their efforts. That part ended well for the researchers.

Now both organizations want the vendors to patch up. Sounds easy, right? We are giving Sonicwall and google free information about security holes in their products, and want nothing in return except for them to fix it.

Well, it’s damn difficult.

Google is always difficult when it comes to security. When I reported an information disclosure vulnerability in google calendar they ignored me, then sent their PR person to say “it’s a feature”, then silently fixed it claiming it was never there. Dealing with google on security issues is like talking to a girl that speaks a foreign language. But more on that later - lets start with Sonicwall.

Wouldn’t you be expect security vendors to be more aware of security problems in their products? Well, for the last few weeks we’ve tried to bang every door, calling in personal favors to tell Sonicwall (for free, let me remind you) about a security hole in their product.
Why bang every door? Because they won’t talk to us since “we’re not Sonicwall customers”. We can’t open a support ticket and they won’t give “us” support. security@sonicwall? yeah, right. Even good friends couldn’t help. The system will not accept a report from non-customers.

I guess our only course of action is to pay Sonicwall money to let them know about their vulnerabilities. I wonder if that’s Sonicwall’s long term strategy for profit? BTW, if you work for Sonicwall and can help, please contact me - but keep in mind paying Sonicwall for telling them about their own security issues is not a part of our plan.

Back to google. The story there is simple and boring. It’s not a bug, it’s a feature. In fact, every browser has this problem, errm I mean feature. In fact, it’s been proven you can execute javascript on the chrome user’s browser so we’ll leave this open as well. If the stupid web app developers can’t solve this we certainly aren’t going to help them.
But why am I boring you with the broad strokes, go read the discussion:
http://code.google.com/p/chromium/issues/detail?id=46795. Nothing we haven’t seen with previous google security bug handling, just ask this guy.

Yes, it is 2010, and we are still talking about Vulnerability Disclosure to vendors. I guess next we’ll be arguing if heap overflows are exploitable.

Update: We were contacted by Sonicwall and the bug will be looked at. Hopefully security@sonicwall will start accepting submissions from non-customers.

So I’ve been sitting on an Apple vulnerability for over a month now, and I’m really starting to realise that maybe just sending the details to the Full-Disclosure mailing list and Exploit-DB.com is the right way to go about disclosing vulnerabilities and exploits.

I initially contacted ZDI to see if they would be at all interested in buying the exploit off of me, as I spent a lot of time researching and finding this one, and I’d like to get something for my efforts. I am a firm believer in the No More Free Bugs movement, I understand and appreciate what ZDI are doing, but the fact that it took them just under a month to get back to me, is really not good enough to be very honest. If they don’t have the researchers, then advertise worldwide, instead of just US only. I know I for one, would be happy validating bugs all day, and this is the the type of work that can be remotely.
Yesterday I also submitted the same information to iDefense Labs Vulnerability Contributor Program (VCP), who claim to get back to me within 48 hours, so we’ll see how that goes. I will update this post as and I when I know more.

I also took the off chance of mailing Apple directly, and asking if they offer any rewards for vulnerabilities that have been found, and if so what they would be. I don’t have high hopes on Apple offering anything, but to be honest, I would prefer to  disclose this one directly to Apple. They however  have paid staff to do this work on a full time basis on all their products, so why aren’t they doing it properly, and I feel that anyone else finding bugs for them, should be compensated appropriately. However, I e-mailed them yesterday and recieved an automated response, so we see how long it takes them to respond to me as well.

This may end up being a rather long post, but let’s see. I’m also expecting to see quite a few interesting comments on this post as well, so come on people.

UPDATE 30/06/2010:

Received a response from iDefense last night,and a request for more info. So just over 24 hour response time, which is brilliant, I’m really impressed so far.

Recieved a response from Apple, and if I would like any reward (aside from credit for the find), then I was informed that I should go through ZDI or iDefense.

Great news, Backtrack now has funding to move ahead with scheduled releases, and a roadmap moving forward up to Backtrack 5. You can view the roadmap here. It seems that the worlds leader in penetration testing training, namely Offensive Security is going to be funding the BackTrack Linux distribution’s development going forward. No need to worry though, BackTrack is still going to remain an Open Source distro.

Other news on this front is that the Exploit Database now has new EDB Research and Development teams that are actively working on vulnerability discovery and development, so watch this space for more news and good things to come. It’s also very worthwhile checking out the Exploit Database Blog.