Lynn's Cat is Out of The Bag
While Black Hat may have torn out paper pages, the PDF of Michael Lynn's
presentation, "The Holy Grail: Cisco IOS Shellcode and Exploitation
Techniques," lives on. Given the amount of attention this thing has gotten,
mirrors and links to it are now all over the place.
Responsible disclosure or not, there is no excuse not to upgrade IOS if you
haven't recently. Details on this are provided in today's ........(look a the
Cisco IPv6 Advisory.
Cisco has released the above advisory stating that all un-upgraded IPv6
configured routers are vulnerable to DOS and possible shellcode execution. According to Cisco:
all Cisco devices running any unfixed version of Cisco IOS
code that supports, and is configured for, IPv6. A system which supports IPv6,
if not specifically configured for IPv6, is not affected"
Additionally an example of Cisco shellcode was recently brought to our
attention that DOES work against the versions stated in the code. It is against
an old integer overflow vuln via the HTTP service. While this code is a couple
of years old, it is still an example of what is possible. Please don't ask me
for a link to it. It's publicly available for those who look & I'm not into
having to defend linking to 3v1L code.
As I said earlier, there is no excuse not to upgrade IOS if you haven't
Log Juggling Courtesy of US Congress
I have a pet peeve. Oh, ok...alot of pet peeves. I'll try to stay focused on
one at a time. Timezones...what a silly idea. "We'll hold that conference call
at 1500." AM or PM? What TZ? What month? When do you change to Daylight Saving
Time? When do I? And the the US Congress decides that moving little black
pointers on a white and black disc on my wall will save oil. I've got a better
idea. When the sun is at the zenith over some uninhabited point in the middle
of the Atlantic (allright - the Pacific), we'll call it 0000 hours.
Everyewhere. Argue about it all you want, it's like changing to the metric
system. It works and there is no more ambiguity.
*poof* Oh, I was dreaming. We are governed by peoples (yea, peopleS. Lot's of
different groups of people, worldwide) who believe that we are too stupid or
intolerant of change to make that work. Now, in steps the US legislators, who
further think that - well, I don't know what they think. They have decreed,
though, that as of this year, the parts of America that do the DST shuffle will
hold off until November 30th, and then "spring ahead" again a month earlier,
too. See for House of Representatives Bill 6 and all the gory details. I used tinyurl since the real URL is a mess. Why does this matter to a security geek like me?
One of the great annoyances I have to regularly deal with when corellating logs
from various systems is clock sync and the lack thereof. A few months ago I
spent a fair bit of time putting together a bunch of Perl just align the
timestamps from boatloads of files from various systems, and found that we were
dealing with things like ±18000 seconds from boxes with or without proper TZ
settings. In other cases we had DST (Daylight Saving Time) vs non-DST systems
off by roughly 3600 secs.
Once we got all the boxes in question mapped to their offsets, it was a simple
matter of running the collected data through the scripts using our uber-l33t
host/logtype/offset matrix (down, Ed!). We had built enoug fudge factor in to
cope with clock drift, so we didn't need to redo the offset numbers more than once.
Jump ahead to November 1, 2005. What the h4ck! Some systems will need a shift
by 3600 seconds again! The machines that didn't get the "I'm sure it's coming.
Just wait" Microsoft/Novell/*n*x patch will stand out as the only ones that
didn't hold off. They will all be at GMT-0500, when everything else will still
be basking in the sunshine of -0400.
Cool! This may very well be the first US Government legislated aid to patch management! Just watch the timestamps of outgoing email & sick the local admins on 'em. Maybe they should legislate a new time shift every second Tuesday of the month. :-p