From: Darby Weaver (ccie.weaver@gmail.com)
Date: Mon Jan 26 2009 - 12:37:58 ARST
Remember - it's not the IOS that they are trying to take advantage of...
It's the underlying "C" Code... And Cisco has done a pretty good job of
checking IOS's before we can run them - so much that if they are incorrect
our devices crash and tell us quickly enough.
On 1/26/09, Darby Weaver <ccie.weaver@gmail.com> wrote:
>
> I'll go read the article again - I think they said their technique has a 1
> in 100,000 chance of success. If they had a chance... any true chance...
> we'd have a new exploit by now in the wild.
>
> They did find a way to smach the stack.
>
> Anyone ever read "Smashing the Stack for Fun and Profit" by Adelph1 a long
> long time ago.... maybe 30 years ago now... It was true then, and it has
> not changed now to my knowledge. Anyone ever seen any router, switch,
> firewall, pv, server etc. not crash yet? Buffer Overflows are an
> intersting reality. The trick is using the buffer overflow to apply
> leverage to a system and gaining privilged access.
>
> http://insecure.org/stf/smashstack.html
>
> "*Smashing the Stack for Fun and Profit*." Phrack Magazine 7, 49 (1996):
> File *...* IEEE Transactions on Software Engineering 14, 10 (October *1988
> *): 1462-1477
>
> *Abstract:* On the evening of 2 November 1988, someone infected the
> Internet with a worm program. That program exploited flaws in utility
> programs in systems based on BSD-derived versions of UNIX. The flaws allowed
> the program to break into those machines and copy itself, thus infecting
> those systems. This program eventually spread to thousands of machines, and
> disrupted normal activities and Internet connectivity for many days. This
> report gives a detailed description of the components of the worm...
>
> Buffer overflow - History
>
> In 1988, the Morris worm used a buffer overflow in a Unix program called
> fingerd to propagate itself over the Internet.
>
> Later, in 1995, Thomas Lopatic independently rediscovered the buffer
> overflow and published his findings on the Bugtraq security mailing list
> [1], which caused a wave of new security relevant buffer overflows to be
> found. In 1996, Elias Levy (aka Aleph One) published in *Phrack* magazine
> the paper "Smashing the Stack for Fun and Profit"[2], a step-by-step
> introduction to exploiting stack-based buffer overflow vulnerabilities,
> which caused a wave of new buffer overflow exploits to be written *[citation
> needed]*.
>
> Then, in 2001, the Code Red worm sent specially crafted packets to machines
> executing Microsoft Internet Information Services (IIS) 5.0*[citation
> needed]*, triggering a buffer overflow and yielding full administrative
> privileges to the worm. (HTTP servers typically must have administrative
> privileges to use the standard TCP port 80; IIS5 did not drop its
> administrative privileges after using them.) Following in 2003, the
> SQLSlammer worm compromised machines running Microsoft SQL Server 2000 by
> sending specially crafted packets to those machines and allowing execution
> of arbitrary code...
>
> This is what they are trying to do to the IOS...
>
> If they (whoever they are??? - maybe the guys actually engaged in trying to
> "test it" - what a concept) could actually have exploited the IOS - Bet your
> beans none of us here would be sleeping till we actually resolved and
> stopped the "15 Minutes of Fame" by this latest attack...
>
> Therefore: THEY ARE BLOWING SMOKE UP SOMEONE'S.... REAR PARTS... :)
>
> Sorry guys - I call em as I see em...
>
> I love Security and the guys who pay the guys to come tell we need more
> security that costs "x" to by and "y" to maintain and very rarely gets the
> attention it deserves or costed after someone "did the right thing" and
> crossed off a box on some checklist.
>
> 1. Manageable Networks - Common Sense Security...
>
> 2. Logs - When did it change?
>
> 3. Backups - What Changed?
>
> 4 Accountability - Yes - we can track every single keystroke you or anyone
> else types in a Cisco IOS-based Device.
> 5. Infinistream - aka Dude!, What's my network devices been doing and who's
> been doing for at least 30+ days if you watched everything... think how long
> you'd have FORENSIC EVIDENCE if you only watched your network devices - you
> know like management traffic.... Hmmm....
>
> 6. Control-Plane Awareness - Dude! What's a "control-plane" and where can
> I buy the remote controller to fly it anyway?
>
> It's an interesting concept...
>
>
> The cure: Common Sense Security and Management Tools that are well...
> Manageable - RANCID.
>
> An excerpt:
>
>
> Eureka! Less than a dozen tries and we found the magic numbers. If xterm
> where installed suid root this would now be a root shell.
>
>
> Small Buffer Overflows
> ~~~~~~~~~~~~~~~~~~~~~~
>
> There will be times when the buffer you are trying to overflow is so
> small that either the shellcode wont fit into it, and it will overwrite the
> return address with instructions instead of the address of our code, or the
> number of NOPs you can pad the front of the string with is so small that
> the
> chances of guessing their address is minuscule. To obtain a shell from
> these
> programs we will have to go about it another way. This particular approach
> only works when you have access to the program's environment variables.
>
> What we will do is place our shellcode in an environment variable, and
> then overflow the buffer with the address of this variable in memory. This
> method also increases your changes of the exploit working as you can make
> the environment variable holding the shell code as large as you want.
>
> The environment variables are stored in the top of the stack when the
> program is started, any modification by setenv() are then allocated
> elsewhere. The stack at the beginning then looks like this:
>
>
> <strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp>
>
> Our new program will take an extra variable, the size of the variable
> containing the shellcode and NOPs. Our new exploit now looks like this:
>
> ....
>
> On the first try! It has certainly increased our odds. Depending how
> much environment data the exploit program has compared with the program
> you are trying to exploit the guessed address may be to low or to high.
> Experiment both with positive and negative offsets.
>
>
> Finding Buffer Overflows
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> As stated earlier, buffer overflows are the result of stuffing more
> information into a buffer than it is meant to hold. Since C does not have
> any
> built-in bounds checking, overflows often manifest themselves as writing
> past
> the end of a character array. The standard C library provides a number of
> functions for copying or appending strings, that perform no boundary
> checking.
> They include: strcat(), strcpy(), sprintf(), and vsprintf(). These
> functions
> operate on null-terminated strings, and do not check for overflow of the
> receiving string. gets() is a function that reads a line from stdin into
> a buffer until either a terminating newline or EOF. It performs no checks
> for
> buffer overflows. The scanf() family of functions can also be a problem if
>
> you are matching a sequence of non-white-space characters (%s), or matching
> a
> non-empty sequence of characters from a specified set (%[]), and the array
> pointed to by the char pointer, is not large enough to accept the whole
> sequence of characters, and you have not defined the optional maximum field
>
> width. If the target of any of these functions is a buffer of static size,
>
> and its other argument was somehow derived from user input there is a good
> posibility that you might be able to exploit a buffer overflow.
>
> Another usual programming construct we find is the use of a while loop
> to
> read one character at a time into a buffer from stdin or some file until
> the
> end of line, end of file, or some other delimiter is reached. This type of
> construct usually uses one of these functions: getc(), fgetc(), or
> getchar().
> If there is no explicit checks for overflows in the while loop, such
> programs
> are easily exploited.
>
> To conclude, grep(1) is your friend. The sources for free operating
> systems and their utilities is readily available. This fact becomes quite
> interesting once you realize that many comercial operating systems
> utilities
> where derived from the same sources as the free ones. Use the source d00d.
>
>
>
>
>
>
>
>
> On 1/26/09, Bogdan Sass <bogdan.sass@catc.ro> wrote:
>>
>> Darby Weaver wrote:
>>
>>> I read the article... FUD.
>>>
>>> While I totally agree to patch and keep devices up to date. They have to
>>> date succeeded in exploiting a 1700 and a 2600 series router with
>>> outdated
>>> IOS code.
>>>
>>> They admit to something like 1 in 100,000 chance of even getting close
>>> enough to attempt an exploit... really...
>>>
>>>
>> Unfortunately, the pdf is not quite clear on this - from what I
>> understand, they are saying that _current_ exploits have about a 1/100,000
>> chance. What they are trying to point out is that it is (at least
>> theoretically) possible to increase that chance using their methodology.
>> How much is that increase? Not sure (and I don't think they have an
>> accurate aproximation either).
>>
>> Everyone knows any OS can be exploited by using a buffer overflow to pop
>>> the
>>> stack. It's practically a given.
>>>
>> From what little I can remember from my programming classes, this is not
>> "a given". All input should be checked to make sure that it doesn't overflow
>> the existing buffer.
>> While i agree that it is very difficult to do this for each and every
>> single buffer in an operating system (and this is why buffer overflow
>> vulnerabilities are still being found in most OSs), "it happens to everyone"
>> doesn't equal "it is a given" :)
>>
>> It's easier to insert a rogue router into a network and advertise
>>> incorrect
>>> routing information than it is to pop the stack and gain root on the
>>> Cisco
>>> IOS...
>>>
>>>
>> There are always easier attacks - and most of the time, those attacks
>> involve the human factor (it's always easier to get the password from a
>> post-it note than to brute-force it :P ). But this is not the point here :)
>>
>> --
>> Bogdan Sass
>> CCAI,CCSP,JNCIA-ER,CCIE #22221 (RS)
>> Information Systems Security Professional
>> "Curiosity was framed - ignorance killed the cat"
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:40 ARST