IOS Rookit: running hacked binaries certainly places you at risk!
ge at linuxbox.org
Tue May 27 16:12:31 CDT 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
>>>>>  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
>>>> 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
>>>> 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.
>> 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
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.
More information about the NANOG