AutoRun disabling patch released
Microsoft released a patch to correct the "disable autorun registry key" enforcement.
http://support.microsoft.com/kb/967715
Updates are offered for the following OSes:
* Microsoft Windows 2000
* Windows XP Service Pack 2
* Windows XP Service Pack 3
* Windows Server 2003 Service Pack 1
* Windows Server 2003 Service Pack 2
The US Cert released an announcement stating that "Microsoft Windows does not disable AutoRun properly" back on January 20th.
http://www.us-cert.gov/cas/techalerts/TA09-020A.html
"Disabling AutoRun on Microsoft Windows systems can help prevent the spread of malicious code. However, Microsoft's guidelines for disabling AutoRun are not fully effective, which could be considered a vulnerability."
The Conficker worm spreads via autorun and we have run several diaries about autorun issues.
Conficker -> http://isc.sans.org/diary.html?storyid=5695
PictureFrame malware -> http://isc.sans.org/diary.html?storyid=3817
PictureFrame Malware2 -> http://isc.sans.org/diary.html?storyid=3807
UPDATE: A reader (Thanks Michael) wrote in saying that he was using xp home edition and was unable to follow the directions in microsofts KB article about using gpedit.msc to create a group policy. He is correct. XP home can't run gpedit.msc. XP home users need to follow the "How to selectively disable specific autorun features" steps. I recommend you modify the NoDriveTypeAutoRun value to 0xFF. That should disable autorun on ALL drives.
Targeted link diversion attempts
It's always hard to convince people of how easy well targeted attacks penetrate trough our defenses. Examples help in educating, but in the case of targeted attacks these aren't so easy to find and report on.
Imagine you're the webmaster of an unnamed educational institute (no it's not SANS, -unfortunately- as it would mean we would not need to obfuscate parts of the message) and you got this in your inbox this morning:
From: webmaster[at]umich.edu <webmaster[at]umich.edu>
To: [webmaster]
Subject: changing domain
Dear webmaster
of the website http://[your website]/
We`re writing to you, because our web address http://www.umich.edu/
will be switched off in a couple of weeks.
We would be grateful if you could change the link on your site
[your page with a link to www.umich.edu]
to our new website http://www[dot]umich-edu[dot]com/
We wish to thank you for your help.
Yours faithfully
Peter Premhuber
So what's the goal of this, no self-respecting webmaster would fall for this I hear you think. Well... let's look at that target website: aside of an added white border, it looks like it's the real site out there.
In fact looking at the source code all that is there right now is :
<html>
<head>
</head>
<body>
<iframe src="http://www.umich.edu/index.html" width="100%" height="100%" frameborder="0" scrolling="auto"></iframe>
</body>
</html>
A "framed" version of the real site
What's the goal here:
To get enough incoming links to a website from authoritative sources so the hacker's site gets relevance in search engines. and well after that, your guess is as good as ours as to what they'll put in that iframe instead or in addition to the real website.
Looking at the .com domainname: it was registered on "05-feb-2009" and if hosted in Turkey ...
Building defenses so our people don't fall for targeted attempts like these is hard. It requires a tremendous amount of awareness to catch this on an individual and consistent basis.
Trying to make sure our websites don't fall prey to this low tech link hijacking isn't easy either as most of it happens well outside our perimeter, the best we can hope for is detection and then react to it.
Is this new, nah of course not, but it's easy enough to find tracks of these perps if you search for the name they used to sign the message with, you find they tried before to divert links pointing to:
- http://Newcastle.edu.au/ to http://www[dot]Newcastle-edu[dot]com/ in October 2008
- http://www.uga.edu/ to http://www[dot]uwa-edu[dot]com in November 2008
with virtually identical messages.
So what's on those two older domains today? Well, it seems it's a blog using wordpress as a CMS and using German text, which is interesting as those reporting this to us were form Germany as well [shared with permission]
I guess they're still waiting to get traffic and payload.
How well did this diverting of links actually work ?
- http://www[dot]Newcastle-edu[dot]com/ had 7 incoming links in a Google link search
- http://www[dot]uwa-edu[dot]com had one incoming link in a Googe link search
It's hard to tell how high their success rate is based on this, but it's also clearly not zero either. Esp. not if you look at source code like:
<a href="http://www[dot]newcastle-edu[dot]com">www.newcastle.edu.au</a>
--
Swa Frantzen -- Section 66
Preview/Iphone/Linux pdf issues
ISC had a few readers write in to let us know that the recent PDF/JBIG issues were cropping up on other platforms. The one that caught my attention was Preview on OS X. So off I went to begin to verify those claims, this is a dirty list of the notes that were produced. I do NOT consider myself a OS X debugging expert, so please do keep that in mind if you spot any errors.
What I have found so far (very limited testing!!), all of this requires more testing and verification by third parties!
1. I do not know at this time if the below described conditions are exploitable. I do not have the time to get that deep into these issues, nor the patience to learn OS X internals. My intuition tells me that they may in fact be exploitable given enough "fu" is applied to the problem, but this ultimately is not for me to decide or judge. I present the below information as is.
2. I edited the crash logs for your own sake (they can be a bit long).
3. Notice how the library names are the same between OS X and Iphone? That is a bad part of streamlining things into one codebase. The positive is that it should only require a few simple fixes, and a whole lot of testing/verification before we see a patch!
4. Compared to other phone operating systems Iphone has a fast patch development/deployment turnaround.
OS X:
Preview.app
- Preview does crash when attempting to view a PDF with a malformed JBIG2 stream in it.
Finder.app
- Finder crashes when using coverflow and browsing to a directory that contains a PDF with a malformed JBIG2 stream when the PDF file is "pre rendered". (This means you have to "flip to" the pdf file in question)
- Actual application that is crashing appears to be Quicklookd, which appears to crash three times while attempting to render the PDF file. See below for details.
Iphone (testing not completed yet):
- Iphone applications appears to crash when viewing PDF files with Malformed JBIG2 stream.
- Tested using Discover WEBDAV file manager for file transfer/viewing. It appears based on crash logs that the same vulnerable library is used on OS X/Iphone.
OS X Console log:
First test run
2/25/09 2:51:42 AM Finder[360] [QL ERROR] quicklookd crashed while thumbnailing file://localhost/Users/XXXXXXX/research/malware/pdf/test-1.pdf
2/25/09 2:51:42 AM com.apple.launchd[173] (com.apple.quicklook[584]) Exited abnormally: Segmentation fault
2/25/09 2:51:44 AM com.apple.quicklook[653] "obj" not found while reading object (1035, 0).
2/25/09 2:51:44 AM com.apple.quicklook[653] missing or invalid cross-reference stream.
2/25/09 2:51:44 AM com.apple.quicklook[653] invalid stream length 1314; should be 8325.
Second test run (done to test quicklookd/Finder interaction):
2/25/09 3:15:50 AM ReportCrash[774] Formulating crash report for process quicklookd[773]
2/25/09 3:15:50 AM Finder[669] [QL ERROR] quicklookd crashed while thumbnailing file://localhost/Users/XXXXXXX/research/malware/pdf/test/test-perl.pdf
2/25/09 3:15:50 AM ReportCrash[774] Saved crashreport to /Users/XXXXXXX/Library/Logs/CrashReporter/quicklookd_2009-02-25-031548_alud-mac.crash using uid: 1181403460 gid: 178763599, euid: 1181403460 egid: 178763599
2/25/09 3:15:50 AM com.apple.launchd[173] (com.apple.quicklook[773]) Exited abnormally: Bus error
2/25/09 3:15:50 AM com.apple.launchd[173] (com.apple.quicklook) Throttling respawn: Will start in 8 seconds
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] "obj" not found while reading object (1035, 0).
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] missing or invalid cross-reference stream.
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] "obj" not found while reading object (1035, 0).
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] missing or invalid cross-reference stream.
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] "obj" not found while reading object (1035, 0).
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] missing or invalid cross-reference stream.
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] "obj" not found while reading object (1035, 0).
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] missing or invalid cross-reference stream.
2/25/09 3:15:50 AM [0x0-0x59059].com.apple.finder[669] invalid stream length 1314; should be 8325.
2/25/09 3:15:52 AM ReportCrash[774] Formulating crash report for process Finder[669]
Quicklookd Crash Log (edited):
*this is just one of the three crash samples*
Date/Time: 2009-02-25 02:53:20.317 -0500
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread: 4
***REMOVED CONTENT***
Thread 4 Crashed:
0 libJBIG2.A.dylib 0x05f69fc6 JBIG2Stream::readSymbolDictSeg(unsigned int, unsigned int, unsigned int*, unsigned int) + 1106
1 libJBIG2.A.dylib 0x05f6756f JBIG2Stream::readSegments() + 805
2 libJBIG2.A.dylib 0x05f671ce JBIG2Stream::reset() + 180
3 libJBIG2.A.dylib 0x05f67009 read_bytes(void*, void*, unsigned long) + 247
4 com.apple.CoreGraphics 0x03895fcd jbig2_filter_refill + 43
5 com.apple.CoreGraphics 0x036ad76c CGPDFSourceRefill + 303
6 com.apple.CoreGraphics 0x036ad0c0 CGPDFSourceSetPosition + 217
7 com.apple.CoreGraphics 0x037813bf chain_skip_bytes + 114
8 com.apple.CoreGraphics 0x03665cd3 img_decode_read + 375
Finder Crash log (edited):
Date/Time: 2009-02-25 02:53:22.463 -0500
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000008
Crashed Thread: 10
***REMOVED CONTENT***
Thread 10 Crashed:
0 libJBIG2.A.dylib 0x1e32dfc6 JBIG2Stream::readSymbolDictSeg(unsigned int, unsigned int, unsigned int*, unsigned int) + 1106
1 libJBIG2.A.dylib 0x1e32b56f JBIG2Stream::readSegments() + 805
2 libJBIG2.A.dylib 0x1e32b1ce JBIG2Stream::reset() + 180
3 libJBIG2.A.dylib 0x1e32b009 read_bytes(void*, void*, unsigned long) + 247
4 com.apple.CoreGraphics 0x04946fcd jbig2_filter_refill + 43
5 com.apple.CoreGraphics 0x0475e76c CGPDFSourceRefill + 303
^
Based on the console logs it would appear that once quicklookd fails three times then Finder attempts to render the documents its self. Which of course leads to the inevitable crash.
Iphone crash log:
Process: Discover [399]
Path: /var/mobile/Applications/A398765FA-12BC-4B8C-F379-3B7396929D14/Discover.app/Discover
Identifier: Discover
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2009-02-24 22:35:31.530 -0500
OS Version: iPhone OS 2.2.1 (5H11)
Report Version: 103
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x7f873d28
Crashed Thread: 0
Thread 0 Crashed:
0 libJBIG2.A.dylib 0x33c95ab0 0x33c92000 + 15024
1 libJBIG2.A.dylib 0x33c98580 0x33c92000 + 25984
2 libJBIG2.A.dylib 0x33c99cb8 0x33c92000 + 31928
3 libJBIG2.A.dylib 0x33c9a904 0x33c92000 + 35076
4 libJBIG2.A.dylib 0x33c9bde4 0x33c92000 + 40420
5 libJBIG2.A.dylib 0x33c9c1b0 0x33c92000 + 41392
6 libJBIG2.A.dylib 0x33c93684 0x33c92000 + 5764
7 com.apple.CoreGraphics 0x3116ad38 0x30ff3000 + 1539384
8 com.apple.CoreGraphics 0x31036540 0x30ff3000 + 275776
9 com.apple.CoreGraphics 0x310363a8 0x30ff3000 + 275368
10 com.apple.CoreGraphics 0x310acf44 0x30ff3000 + 761668
11 com.apple.CoreGraphics 0x31069174 0x30ff3000 + 483700
12 com.apple.CoreGraphics 0x31009fa8 0x30ff3000 + 94120
13 com.apple.CoreGraphics 0x3105c3d4 0x30ff3000 + 431060
***REMOVED CONTENT***
0x33c92000 - 0x33c9cfff libJBIG2.A.dylib ??? (???) <18132af22c5e64d522d708f030990fe9> /System/Library/Frameworks/CoreGraphics.framework/Resources/libJBIG2.A.dylib
For those who think iphone exploits can't be written I suggest you read the following web page.
securityevaluators.com/content/case-studies/iphone/
Linux based viewers:
(coming soon! feel free to send in your own)
Adobe flash player patch
A few readers wrote in to point out the fact that adobe released a new flash update today. It looks like this update fixes a few security related issues outlined in APSB09-01 (link below). Please feel free to write in if you find other write up's on these vulnerabilities.
Associated CVE numbers and acknowledgments:
- CVE-2009-0519 - Roee Hay
- CVE-2009-0520 - Javier Vicente Vallejo
- CVE-2009-0114 - Liu Die Yu
- CVE-2009-0522 - Eduardo Vela
- CVE-2009-0521 - Josh Bressers
Adobe APSB09-01
http://www.adobe.com/support/security/bulletins/apsb09-01.html
Idefense write up on CVE-2009-0520
http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=773
Adobe Acrobat pdf 0-day exploit, No JavaScript needed!
So there is a brief blog post linked below that highlights the fact that the new adobe PDF vulnerability can be exploited without the use of JavaScript. This is obviously really bad news for anyone who is responsible for protecting environments where PDF's are present. I think what a lot of people will find is just how prevalent JBIG2 streams are in "run of the mill" PDF files that are floating around their systems. This means that simply looking for JavaScript + JBig streams in PDF files is not going to do you much good moving forward.
All of the current observed samples are still utilizing JavaScript; this will NOT be the case moving forward!
Let me repeat again. YOU DO NOT NEED JS TO MAKE THIS EXPLOIT WORK. The JavaScript method employed by these attacks is "tried and true" when it comes to creating the right conditions for a reliable exploit.
***I have not been able to verify secunia's claim independently at this point in time. (I would love to be able to verify this)
Secunia article
http://secunia.com/blog/44/
Now on to the important part of this post.
14 Days left before the patch is out.
Comments