Last Updated: 2010-01-05 22:35:02 UTC
by Toby Kohlenberg (Version: 3)
We are curious whether anyone else is seeing the sorts of issues like the one with Symantec we just reported. Have you seen problems with the change from 200* to 20**?
UPDATE 1: Johannes mentioned that DShield actually had problems due to a regex on incoming logs looking for 200[0-9], to prevent ridiculously future dates being sent in. He ended up fixing it early in the morning on Jan 1. Anyone else have stories to share?
UPDATE 2: We've had two interesting issues pointed out.
- The default cookie expiration in the Cisco CSM load balancer is set to 01/01/2010 so apps were being continuously rebalanced instead of getting a persistent connection
- German customers of Postbank are having problems getting cash out of ATMs due to a problem with the software running them handling 2010 dates: http://www.h-online.com/security/news/item/Problems-obtaining-cash-from-German-ATMs-Update-894801.html
UPDATE 3: Splunk has released an update to fix the parsing issue for the date/timestamps that use a two character year (such as 09 or 10 for 2009 and 2010 respectively) that fix the datetime.xml. Additional information available here.
UPDATE 4: We've got more and more of these rolling in. Thanks to everyone who is submitting these:
- Users of Invision Power Board are unable to create new blog entries
- Palm Pre WebOS seems to be having problems with its Exchange calendar sync
- Windows Mobile and maybe other cell phones are having issues. SMS messages sent in 2010 are being dated 2016
- SAP have detected a problem in the spool area which affects all customers in the world regardless of the SAP release and any support package level. As soon as the retention time of a spool request exceeds 2009/12/31 a wrong date 2100/01/01 is entered during creation of the spool request. As a consequence these spool requests will not be deleted anymore from the spool reorg jobs. Using the default retention period this affects all spool requests on each SAP system in the world created since 2009/12/23
- Arcsight - Perpetual license keys received before December 1st, 2007 still show a license expiration date of January 1st, 2010, in the ESM v4.0.x and v3.5.x Console. While the January 1st, 2010 expiration date is not enforced for perpetual licenses by the product, it has caused concerns and confusion. Customers who have upgraded to ESM v184.108.40.206 or v220.127.116.11 have encountered issues where their console connections have been rejected.
Last Updated: 2010-01-04 17:22:08 UTC
by Toby Kohlenberg (Version: 1)
Thanks to Derek to pointed us at this post from Symantec: http://www.symantec.com/connect/forums/official-status-sepm-definitions-stay-31-12-2009-last-updated-04-jan-2010 stating that Symantec Endpoint Protection Manager considers any definition update with a date newer than 11:59PM December 31 2009 will be considered out of date. They say they are working on a fix but are currently handling this by releasing new definitions with higher version numbers but the same date.
This is impacting:
- Symantec Endpoint Protection v11.x Product Line
- Symantec Endpoint Protection Small Business Edition v12.x Product Line
Last Updated: 2010-01-04 06:29:59 UTC
by Bojan Zdrnja (Version: 1)
Couple of days ago one of our readers, Ric, submitted a suspicious PDF document to us. As you know, malicious PDF documents are not rare these days, especially when the exploit for a yet unpatched vulnerability is wide spread.
The exploit for this vulnerability is similar to most other exploits: it uses heap spraying in order to redirect the execution to shellcode. The NOP sled in this case actually consists of SBB AL,0x1C and SBB AL,0x0C instructions which do nothing (SBB is Subtract with borrow, from the register AL, so it keeps subtracting two values until it reaches the shellcode). The 38 bytes shellcode can be seen below:
Now comes the interesting part. This is an egg-hunting shellcode: it starts at the memory address ((0x02020200 OR 0xFF) + 0x01) = 0x02020300) and compares content of every 4 bytes with 0x58905090. You can see that initially the attacker moves 0x5890508F into the EAX register, which then gets increased by one – this was probably done to evade detection.
This pattern (0x58905090) corresponds to instructions POP EAX, NOP, PUSH EAX, NOP. Now, once this pattern has been identified in memory, the egg-hunting shellcode passes execution to this, second stage shellcode.
What is interesting about this approach is that the second stage shellcode is included as a different object in the PDF document. While the object is marked as a color object and its contents are inflated, it looks as if it is corrupted: it does not contain any inflated streams. You can see the object and the deflation error printed by pdf-parser, an excellent tool by Didier Stevens whom I wish to thank for useful discussion while I was analyzing this malicious PDF document:
$ pdf-parser.py --object 3 --raw --filter Requset.pdf
obj 3 0
<</BitsPerComponent 8/ColorSpace/DeviceRGB/Filter/FlateDecode/Height 90/Length 13136/Subtype/Image/Width 60>>
FlateDecode decompress failed
The fact that the decompression fails does not matter – Adobe Reader will open the whole document (mmap it) into memory, including this "corrupted" object so the first stage shellcode will be able to find it and pass execution to it!
The second stage shellcode does something interesting as well. It parses the document name from the command line arguments and opens the PDF document directly. The reason for this is that the PDF document carries two embedded binaries! The first binary (SUCHOST.EXE, b0eeca383a7477ee689ec807b775ebbb) contains a PoisonIvy client which tries to connect to the host cecon.flower-show.org which was down when I analyzed the document. Luckily, this binary has a bit better (but still not good, some major AV vendors missing it!) detection on VT (here). This binary is embedded in the PDF document – we can see it at offset 0x0e65c:
$ hexdump -C -v ../Requset.pdf |less
00000000 25 50 44 46 2d 31 2e 36 0d 25 e2 e3 cf d3 0d 0a |%PDF-1.6.%......|
00000010 32 34 20 30 20 6f 62 6a 0d 3c 3c 2f 4c 69 6e 65 |24 0 obj.<</Line|
00000020 61 72 69 7a 65 64 20 31 2f 4c 20 39 34 37 32 33 |arized 1/L 94723|
00000030 32 2f 4f 20 32 36 2f 45 20 31 37 38 31 2f 4e 20 |2/O 26/E 1781/N |
0000e650 b4 b4 b3 88 8f a0 a0 c0 ca c3 88 8f c8 df 00 00 |................|
0000e660 84 00 00 00 87 00 00 00 7a 7a 00 00 c5 00 00 00 |........zz......|
0000e670 00 00 00 00 c5 00 00 00 00 84 00 00 8b 9a 31 8c |..............1.|
The binary is XORed with value of 0x85 so the first two highlighted bytes are actually MZ, which is where the executable starts.
The second binary (temp.exe, 980e40cacbc9f898bc08cb453fa2d6bb) was even more surprising. This binary drops a benign PDF document on the machine, called baby.pdf. This PDF document is then opened with Adobe Reader – it just shows a table and, according to the metadata in the document, has been built from an Excel document. This was done by the attackers to make the victim believe as if nothing happened, because the original exploit will crash Adobe Reader and this might make the victim suspicious about what happened.
Additionally, the PDF document contains everything it needs to fully exploit the victim's machine – it does not have to download anything off the net.
Not only was this a very interesting example of a malicious PDF document carrying a sophisticated "war head", but it also showed the length attackers are willing to go to in order to make their malware as hard to detect as possible, not only for the AV vendors, but also for victims.
If we are to judge the new year by sophistication the attackers started using, it does not look too good.
Last Updated: 2010-01-04 03:00:03 UTC
by Toby Kohlenberg (Version: 1)
The WASC (Web Application Security Consortium) has just released the second version of their Threat Classification document. It contains a list of all the classes of attacks and weaknesses they have identified as being relevant to web applications. Personally, I like using it to supplement developer education materials but there are a number of ways you can use it (they suggest a few here: http://projects.webappsec.org/Using-the-Threat-Classification)
I wholeheartedly encourage y'all to check it out: