mailing list archives
Re: IPP +SMB FTW
From: "Dave Korn" <dave.korn () artimi com>
Date: Fri, 17 Oct 2008 17:57:22 +0100
Dave Aitel wrote on 17 October 2008 16:43:
Some thoughts on the IPP vulnerability follow.
IPP!!!! :) :) :) Aww, now I'm getting all nostalgic for the good ol'
CodeRed days! </tip-o-the-hat to a.h.m.>
C.F. http://www.kb.cert.org/vuls/id/793233 as quoted below.
I like this quote:
"Block outbound SMB traffic
This and other vulnerabilities may be mitigated by blocking outbound SMB
traffic from your network to the internet."
Allowing it in /either/ direction is utterly nutso if you ask me...
2. Did some target have IPP set up as Non-Authenticated access?
It would make sense to open up as much non-authenticated access as you can
if you were running a honeypot. Then again, there have been plenty of
reasonably-successful worms that spread by guessing common u:p combinations to
get access to SMB file shares.
3. How would you discover something like this in the wild considering
that you can do HTTPS and possibly SEALED SMB/RPC?
Bet the attackers didn't bother. Only a very few seriously professional
types make the least effort to conceal their traffic.
4. How did the attackers find this?
My guess would be msrpc fuzzing the printer protocol found them the overflow
by malformed JOB_INFO2 struct, and then a bit of imagination was used to think
up a way to tickle it remotely by using IIS/IPP.
5. Is there a complexity limit for data flow and control flow after
which automated static analysis will fail but humans will succeed?
Well as I said in the last thread, I reckon there is, and I reckon it's a
whole lot closer to the "Hello World" end of the software-complexity spectrum
than it is to the IIS.exe end.
Can't think of a witty .sigline today....
Dailydave mailing list
Dailydave () lists immunitysec com