IOS Rookit: running hacked binaries certainly places you at risk!

Tue May 27 17:23:34 UTC 2008

On May 27, 2008, at 12:02 PM, Gadi Evron wrote:

> On Tue, 27 May 2008, Jared Mauch wrote:
>>
>> On May 27, 2008, at 8:42 AM, Alexander Harrowell wrote:
>>
>>>> An alternative rootkit ? Privilege level 16 used by the Lawful  
>>>> Intercept
>>>> [12] feature could be abused to do some of this too. Or the other  
>>>> way
>>>> around: use a "patched" IOS to keep an eye on Law Enforcement's  
>>>> >operations
>>> on the router as privilege level 15 doesn't allow it and the only
>>>> alternative is to sniff the traffic export.
>>> The combination of rootkits and specially privileged Lawful  
>>> Intercept
>>> functions is a very dangerous one. This was precisely what was  
>>> exploited in
>>> the now-legendary and still unsolved Vodafone Greece hack.
>>
>> Perhaps the above should be simplified.
>>
>> Running a hacked/modded IOS version is a dangerous prospect.
>>
>> This seems like such a non-event because what is the exploit path  
>> to load the image? There needs to be a primary exploit to load the  
>> malware image.
>>
>> *yawn*
>
> I guess we will wait for the next one before waking up, than.

You seem to be missing the point and I'm concerned that wasting my  
time attempting to educate you and others on this topic is fruitless,  
but I will attempt the impossible.

Surely you should insure your devices are secured and audit their  
security.  Attack vectors change over time.  This case is easily  
mitigated against if Cisco shipped signed binaries and the platform  
performed this validation.  That's not something unique, but something  
that is unavailable today.

I state again: Running any random code will certainly put you at risk,  
this continues to be the case for routers in the same way as it is for  
the millions of infected PCs.

I await information on the remote router exploit path and the  
mitigation strategy you allude to in your above bait.  Without  
compromising the router in the first place, either physically by  
swapping the image media (hard drive, flash of varying varieties) or  
remotely with some unnamed and perhaps unfound 0-day exploit, the  
strategy outlined in this thread is not a viable one.

Anyone following a set of "sane" practices, (watching those flash/disk  
inserted/removed messages in your syslogs and doing image validation  
will help mitigate the risk).  There's alternate cases that have not  
been outlined here that could prove to be more problematic and cause  
you to do some incident response but I will not outline those in this  
public forum.