Printable View
Greeting's
It seems that Microsoft missed out on an exploit... The exploit now conformed by Microsoft will be addressed in future but with an uncertain time frame..
While the maximum damage that can be caused by this is limited to DoS.. It still needs to be addressed.
For now the only work around is BLOCKING PORT's 135-139 and 445..
Here is the link :
http://blogs.technet.com/msrc/archiv...28/443837.aspx
http://isc.sans.org/diary.php?storyid=1471
Shouldn't those ports always be blocked?
Hey Hey,
MsMittens: from home probably, in fact most ISPs are prolly blocking them for you... but in a corporate environment.. especially with file sharing and so on.. .prolly not..
Btw for those of you that missed it... This was the original email yesterday...
There were one or two follow up emails as well. There's at least one more public exploit (besides the one above) for MS06-035 that's causing this DoS...Quote:
After furiously patching since last week for catching up with MS06-040, we discovered that a old exploit for MS06-035 (again or still) works on a number fully patched systems including Windows 2003 Server, Windows XP and Windows 2000.
The exploit that works is: http://milw0rm.org/exploits/2057
All our tested systems (8 total) except one went into reboot after being hit with the exploit above. All tested systems have been patched with the latest available patches from Microsoft as of today, August 14th, 2006 4:00 PM MESZ, using both the standard Windows Update function and applying patches by hand.
Explicit download of KB917159 patch, applying it and reboot, with no result. I carefully checked the version of the srv.sys binary according to http://www.microsoft.com/technet/sec.../ms06-035.mspx and found it to be correct, meaning the patch should be applied correctly.
My only conclusion at this time is that the Microsoft delivered patch for MS06-035 does not work. Can anyone confirm this behaviour?
Thanks,
Frank
This is regarding MS06-035, CVE-2006-1314
Peace
HT
Why would a company have public internet access to those ports? Would it not be more common to block access that way or use VPN for access? Yes, I can see internal networks having it and the risk being there but common sense would dictate it not being accessible to the general internet at large.Quote:
MsMittens: from home probably, in fact most ISPs are prolly blocking them for you... but in a corporate environment.. especially with file sharing and so on.. .prolly not..
I'm not talking public access... Generally those ports are blocked... read any "Remote" that Microsoft puts out.. they say to block ports 135-139 and 445... quite often when it doesn't even affect those ports... it's part of their standard "legalese" these days.Quote:
Originally posted here by MsMittens
Why would a company have public internet access to those ports? Would it not be more common to block access that way or use VPN for access? Yes, I can see internal networks having it and the risk being there but common sense would dictate it not being accessible to the general internet at large.
I'm talking about internal access... Internal Employees are one of the biggest risks these days... they bring in a virus or worm written for MS06-035 (not saying there is... but hypothetically)... it begins to spread.. suddenly all the machines the admin things they've patched start crashing...
And in my opinion the home user should usually take parts of the advisories with a grain of salt... I consider MS more of a corporate company than a end-user company... the advisories usually target corporate work arounds and mitigation.. 95% of the stuff that comes out is already protected against by ISPs and househould Router solutions..
True. I wonder how many companies have host-based firewalls on each host to prevent spreading (not just between internal networks but within a network).
That would be an interesting question to have answered by people... The two corporate environments I was in prior to this didn't.. they both had say the built in XP firewall turned off...Quote:
Originally posted here by MsMittens
True. I wonder how many companies have host-based firewalls on each host to prevent spreading (not just between internal networks but within a network).
What mailing list was that from HT?.Quote:
Originally posted here by HTRegz
Btw for those of you that missed it... This was the original email yesterday...
Cheers
BugtraqQuote:
In most cases corporates have those ports open accross their networks as they are used for authenticating to domain controllers and accessing file server shares and what nots.
Ideally the ports should be locked down by host based firewalls to only be allowed between specific servers and the workstations that use those servers, but in many situations the configuring of that sort of setup seems to require too much work in a lot of peoples minds :/
The ports that should be locked down are 135, 137-139 and 445. These ports are common knowledge, or should be, to most people who have dealings with firewalls or the configuration of them.
The stream of viruses that made use of RPC and LSASS vulnerabilities should have taught just about everyone about these ports a long time ago :)
Hey Hey,
The patch for MS06-035 is completely unrelated to this vuln... It was discovered by a researcher at Core by mistake..
Here's his very long email regarding the subject.
Peace,Quote:
Mailslot bug (MS06-035)
vs.
non-Mailslot bug(MS0?-???/CVE-2006-3942)
This is the story of a yet unpatched bug which is not a 0-day.
Time line:
2006-07-12 - MS06-035 Published by Microsoft [1]
2006-07-12 - "Windows Mailslot (MS06-035) DoS" module
released to IMPACT customers
2006-07-13 - We realized (too late) that it was a different bug [2]
2006-07-14 - We got in touch with Microsoft
2006-07-19 - Public exploit released by cocoruder [3]
(frankruder_at_hotmail.com)
2006-07-28 - ISS released their advisory [4]
2006-07-28 - Microsoft acknowledged the bug [5]
2006-08-14 - Today - We publish and advisory [10] and this email
---[ Intro ]
Last month's patch Tuesday started with a nice challenge: A remotely
exploitable code execution kernel bug for most Microsoft's OSes (most
supported Windows). As my job is to write exploits, I jumped to that as
soon as I could (which was latter than what I liked because we were
closing a new version of our product). I got something working in a
short time, sent it to QA to test and released before the end of the
day... I was truly amazed... to only find out, a little bit later, that
I had accidentally found a different (yet unpatched today) bug.
In this pseudo-advisory I will describe the Details of this new bug, the
process of how I [also] "discovered" it, and why I think it's not
exploitable (only to be proved later by someone else that I'm a moron)
---[ MS06-035... I think ]
For a long time I've been waiting for a remotely exploitable kernel bug
to try to exploit. It was a tough challenge, at least for me, as I've
never before worked on such a beast. I jumped immediatly to
Microsoft's advisory's [1] "Vulnerability details" section to find what
I expected: NOTHING. Just a general description, as in most advisories
lately, which can't, in any way, be used to prove or disprove the
existence of the bug, nor to decide how high in the priority list this
patch should be put:
"There is a remote code execution vulnerability in the Server driver
that could allow an attacker who successfully exploited this
vulnerability to take complete control of the affected system." [1]
Uhm... if the information is not under "Vulnerability details", where
may it be? I think I need to take even more English lessons, because I
thought "details" meant "detalles", oh well... let's read all the
advisory just in case...
After reading Microsoft's advisory I continued with TippingPoint's [5]
and Pedram Amini's blog [7] to happily find a few more details. Let me
summarize what I knew then:
. Mailslot ==> SMB
. Kernel Heap overflow
. Code execution is possible (why would Microsoft over-rate it?)
. SRV.SYS (Server driver)
. Port 445 (from advisory's Workarounds section)
. First class mailslot (whatever it means)
What do I know about Mailslots? the basics, probably a little bit more,
but surely not enough. Let's see if Impacket [11] has something for
Mailslots:
$ cd Impacket-0.9.6.0
$ grep -i mailslot *
$ grep -i mailslot */*
$ grep -i mailslot */*/*
$ grep -i mailslot */*/*/*
grep: */*/*/*: No such file or directory
... mmmm... nothing... now what? After quickly sending Pedram an
email to congratulate him and HD for their finding (and, of course, cry
for some help), I sat down to read CIFS' specification [12] once again.
I searched for the word "mailslot" to only find it in one section
describing the format for Mailslot Write transactions. Nice! Lets try
the fuzzing approach, lets create a Mailslot request with a lot of data!
So I opened my Ethereal and my Python interpreter, booted up a VMware
with Windows, went through the automatic "Win-R, cmd, ipconfig". Got
VMware's IP address and continued typing:
from impacket import smb
s = smb.SMB('*SMBSERVER','10.0.1.44')
s.login('','')
tid = s.tree_connect_andx(r'\\*SMBSERVER\IPC$')
s.send_trans(tid,
'\x01\x00\x00\x00\x00\x00', r'\MAILSLOT\LANMAN', '', 'A'*1000)
BOOM! The vmware crashed!
What? Wait a second...
At this point I thought "How stupid I am! I should have
tested this before! just sending a big packet crashed it!" And I'm one
of those who 5 years ago thought "first generation fuzzers are not going
to find too many bugs any more"... stupid me!
"Ok. Got a crash, it's a kernel bug... no, no, it's a remotely
exploitable kernel heap overflow bug... it's quite unlikely I will be
able to do anything better than a simple Denial of Service for quite
some days. So I better focus on writing down the documentation. I will
send right away a working version to QA so we can try to ship it today".
Thought and done. Documentation written, typos fixed, some extra packets
added just in case, QA approved it for "Early release" mode...
"Nice! we tested it against most Windows VMWares we have, it crashed
them all in the first try. And we shipped it all in a single day! I was
not really expecting this, I'm more used to spending a few days per bug
until I have a QA-approved shippable version"
- "Hey Kelya! lets ship it! it's done, QA approved it!"
(Kelya's my boss)
- "Sure... Ok, it's shipped now. Have you tried against a patched
box?"
- "Nop... 'cmon, It's not my job to test MS' patches!" [8] [9]
(thanks aazubel!)
- "Oh well... let me see... My box is patched, throw it against it"
- "Ok, going... (double-click), gone"
- "Eh! wait a second... Got a crash and dump, let me see if the
box's really patched"
- "Yeah, it must be still unpatched, I'll try someone else's box"
- ...
- "I think we may have found something else... pass me the memory
dump to debug it"
And so the second part of the story begins.
---[ MS0?-??? - CVE-2006-3942 - the new bug ]
- "Let's go home now. Tomorrow we'll verify it and talk to Ivan so
he gets in touch with Microsoft about this new issue"
- "Ok, I'll try to debug it and figure out what's going on"
The new bug, as explained by ISS' advisory [3], is due to a NULL
pointer dereference, and I firmly believe that it's not exploitable. As
I said, I will quite likely be proved wrong on this, but I'll try to
give my reasons:
The crash is actually inside __imp___wcsnicmp, when the string
"\\MAILSLOT" is compared to a NULL pointer. The following code, from
ExecuteTransaction(), is where wcsnicmp() is called from.
SRV.SYS:0002f487: push 9
SRV.SYS:0002f489: push "\\MAILSLOT"
SRV.SYS:0002f48f: push dword ptr [eax+24h] <-- [eax+24] is NULL
SRV.SYS:0002f492: call ds:__imp___wcsnicmp <-- Crash Inside (tm)
SRV.SYS:0002f498: add esp, 0ch
SRV.SYS:0002f49b: test eax, eax
SRV.SYS:0002f49d: jnz loc_2f4aa
SRV.SYS:0002f49f: push esi
SRV.SYS:0002f4a0: call _MailslotTransaction@4 <-- not reached
SRV.SYS:0002f4a5: jmp loc_20bf6
SRV.SYS:0002f4aa:
Apparently, for some reason, our packet made [eax+24h] be NULL,
which forced something like:
wcsnicmp(0, "\\MAILSLOT", 9);
Which obviously crashes.
After some tests, I found out that the only thing that mattered
here, is that no NUL should be sent after the "Mailslot name". And in
fact, 'A'*1000 is not necessary, and the mailslot name doesn't really
have to mean anythin. So, the following python script should still
trigger the bug:
-----
from impacket import smb
s = smb.SMB('*SMBSERVER','10.0.1.44')
s.login('','')
tid = s.tree_connect_andx(r'\\*SMBSERVER\IPC$')
s.send_trans(tid, '\x01\x00\x00\x00\x00\x00', 'cuchicuchi','','')
-----
- "Kelya, Ivan: I'm pretty sure this is a different thing... it's
not related to mailslots, it's not related to a buffer overflow,
and apparently, it's not exploitable for code execution"
- "Uhm... Ok, I'm getting in touch with MS to let them know. You
should have tried it against a patched box before releasing."
- "I know, but we were in Early Release mode, and we were too
worried testing the exploit to stop and test if Microsoft's patch
really worked."
- "Take some time to see if it's exploitable or not, I'll talk to
Microsoft"
- "Sure! I have already started!"
I believe this is not exploitable for code execution, and I know
stating this is pretty much like putting a loaded gun in my mouth. My
decision tree for that is:
. Either it crashes in wcsnicmp(). In which case it's only a Denial
of Service.
. Or it doesn't crash in wcsnicmp().
. The string begins with "\\MAILSLOT", and it becomes a
MailslotTransaction() where it may find another bug, but not
this.
. The string doesn't begin with "\\MAILSLOT", in which case
ExecuteTransaction() returns with an error message.
Evidently this is a new bug, not related to the processing of
Mailslots and even not strictly related to Named Pipes [3], but to
SMB_COM_TRANSACTION SMB messages (0x25) instead.
So, we were in the process of talking to Microsoft when three
interesting things happened:
. A few customers sent us emails saying that we should get in touch
with Microsoft because the exploit was too effective DoSsing
patched and unpatched boxes.
. An exploit for the very same bug was published, producing exactly
the very same traffic as our exploit, bit by bit. And also falling
in our same mistake of believing it was a Crash for MS06-035. [4]
. ISS published an advisory a few days latter stating that, given
the public exploit, they have independently discovered this new
bug. [3]
Microsoft publicly acknowledged the situation [6] after the advisory
was published. All the information available says that they are
currently working in a patch for the issue and that they have "...not
observed or received any reports of the PoC being used to actively
attack systems", what kind of confirms that the availability of Proof of
Concept code has nothing to do with the bad people doing bad things.
---[ Concluding ]
. Yes, there is a public exploit for a yet unpatched bug. This time
it's just a DoS situation unless somebody proves me wrong (which is
simpler than proving I'm right).
. No, even when there's a public exploit, an advisory and a note by
Microsoft acknowledging the bug, your box is not being DoSsed all the
time.
. Advisories with almost no technical details are bad: They do not
provide enough information to let users decide how serious the
condition is in their specific situation, quite often lead to the
accidental discovery of new bugs (this is not the first time I've seen
it). And more important (for me), they make my everyday task of
writing exploits harder :-)
. Microsoft is already working on fixing the issue. They are trying to
target Noveember for a release.
. In the meanwhile, filtering ports 135-139 and 445 from the outside is
pretty much your only choice... Unless somebody comes out with a home
made patch for SRV.SYS. I haven't checked, but I wouldn't be surprised
if this could be triggered on UDP, as most standard MAILSLOT
transactions are made over UDP.
. We tried targeting a Windows Vista beta 2 build 5381, and it didn't
crash. So Vista MAY be safe.
. Only a few days ago, after we finally closed a new release of CORE
IMPACT (v6.0), I could go back and work on the original MS06-035. I
got again in touch with HD Moore and Pedram (Thanks again guys!), and
they passed me some clues, but I'm still working on getting
something working :-(
take care, be safe
gera
[1] http://www.microsoft.com/technet/sec.../ms06-035.mspx
[2] http://cve.mitre.org/cgi-bin/cvename...=CVE-2006-3942
[3] http://xforce.iss.net/xforce/alerts/id/231
[4] http://www.milw0rm.com/exploits/2057
[5] http://blogs.technet.com/msrc/archiv...28/443837.aspx
[6] http://www.tippingpoint.com/security...SRT-06-02.html
[7] http://pedram.redhive.com/blog/2006-07-11/
[8] http://jsgreen.tamu.edu/Not%20my%20job%20award.jpg
[9] http://www.funnysnaps.com/possum2.jpg
[10] http://www.corest.com/common/showdoc...&idxseccion=10
[11] http://oss.corest.com/projects/impacket.html
[12] http://www.snia.org/tech_activities/...1p00_FINAL.pdf
HT
I dont know a lot about thse ports, I am on my home system and they are closed all time (firewall). HOwever HT, May i ask you How do you get thet info in an EMAIL??? If it is subscribed to some mailing list of website then which site is it??? I also want such updates on the security...Quote:
Originally posted here by HTRegz
Hey Hey,
MsMittens: from home probably, in fact most ISPs are prolly blocking them for you... but in a corporate environment.. especially with file sharing and so on.. .prolly not..
Btw for those of you that missed it... This was the original email yesterday...
There were one or two follow up emails as well. There's at least one more public exploit (besides the one above) for MS06-035 that's causing this DoS...
Peace
HT
Please do not flame by telling me to find...I tried...all of them are forums..not some officila mailing list which keeps me updates with this type of holes.
Thanks.
I got it from the same spot I got the last one... Bugtraq..Quote:
Originally posted here by jockey0109
I dont know a lot about thse ports, I am on my home system and they are closed all time (firewall). HOwever HT, May i ask you How do you get thet info in an EMAIL??? If it is subscribed to some mailing list of website then which site is it??? I also want such updates on the security...
Please do not flame by telling me to find...I tried...all of them are forums..not some officila mailing list which keeps me updates with this type of holes.
Thanks.
If you can't find legit mailing lists for security you're seaching wrong
SecurityFocus has a shitload of them... including Bugtraq...
Dave Aitel runs DailyDave
There's FD (Full Disclosure)
The guys at Linuxbox.org have a bunch on Privacy, Fuzzing, Phishing, Botnets, Etc
Secunia has regular mailings...
There are tons of them.... AO even has a link to them on the sidebar.
Peace,
HT
Hmmmm..... I think I was really seraching th wrong side. Thanks for that.