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

Tue May 27 21:12:31 UTC 2008

On Tue, 27 May 2008, Jared Mauch wrote:
>
> 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.

Then you'd use the memory or manipulate the validation. It's a cat and 
mouse game the same as any other. I disagree with you there, although 
these are certainly good steps for Cisco to take.

> 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.

I allude to nothing, Jared.

> 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.

Thanks for clarifying these points. I am concerned about how far current 
methods can take an operator trying to detect badness.

 	Gadi.