[104873] in North American Network Operators' Group
RE: IOS Rookit: the sky isn't falling (yet)
daemon@ATHENA.MIT.EDU (Fred Reimer)
Thu May 29 09:18:18 2008
Date: Thu, 29 May 2008 09:18:07 -0400
In-Reply-To: <Pine.LNX.4.62.0805282319080.19352@linuxbox.org>
From: "Fred Reimer" <freimer@ctiusa.com>
To: "Gadi Evron" <ge@linuxbox.org>, "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
This is a multipart message in MIME format.
------=_NextPart_000_0000_01C8C16C.E7B7F2C0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
The conversation shifted to breaking MD5 because it was mentioned that one
way to prevent the installation of cracked IOS images was to include some
sort of DRM or trusted computing chip in new hardware, and have Cisco sign
their IOS images (supposedly even the boot EEPROM). This wouldn't be DRM in
the sense of DVD's, where they don't want everyone to be able to decode the
disk, so must come up with some scheme where they provide the decryption key
that is itself decrypted with a private key which all of the DVD players
have the public key for, hence could be relatively easily broken (just
extract the public key from the player, which was what was done for HD-DVD.
In other words, attacking the crypto scheme instead of the algorithm. Cisco
would presumably want everyone to be able to read the file, just sign it
with their private key. So how do you sign an IOS image? Most crypto
schemes work by generating a MD5 hash of the data, and then signing the MD5
hash, not signing the whole IOS image, which would be encrypting the whole
thing. Decrypting an IOS image sized data block with the RSA algorithm
would presumably take too long, so just the hash is signed. If the signed
hash matches the hash you compute when loading the image it's a good image,
so the boot ROM would load the code. Once loaded, it would check the
signature (of the hash) on any new boot ROM loaded so that attackers could
not use that vector.
For what it's worth, encrypting the whole file is still not normally done by
encrypting with the RSA public key of the destination. Rather, another
symmetric protocol is used, such as 3DES or IDEA or something, and they key
for that protocol is encrypted with RSA. The private key in this case would
be located... on the new Cisco hardware. So, much like breaking HD-DVD
crypto scheme this could be broken also. However, I don't think it is the
goal to encrypt the IOS code, just ensure that it is valid code from Cisco,
so an appropriate hash should do just fine.
So the only easy way to attack this is the MD5 hash. We have a know
plaintext (the IOS code) and the hash. It is not trivial to be able to make
changes in the code and maintain the same hash value, but there has been at
least limited success in doing so. If they can change the code and fiddle
with the help text in some obscure feature no one regularly uses and
generate the same hash then viola, access.
That's how we got onto breaking MD5.
However, if there is a known vulnerability, to however few people, in IOS
where there is a buffer overflow or something else where remote code can be
executed, this presumably could overwrite the IOS code running on the box
and bypass the code-checking hardware. It may not be possible to replace
the boot ROM, because presumably the new hardware would check the ROM code
hash before loading it and also presumably the ROM code does not have quite
as much text messages that can be changed to generate the same hash value,
thereby bypassing the security checks. So in this scenario rooted IOS would
only exist transiently; a reboot would load the known good code again (or
brick the box if "bad" ROMMON were burned).
Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697
> -----Original Message-----
> From: Gadi Evron [mailto:ge@linuxbox.org]
> Sent: Thursday, May 29, 2008 12:21 AM
> To: Steven M. Bellovin
> Cc: nanog@nanog.org
> Subject: Re: IOS Rookit: the sky isn't falling (yet)
>
> On Thu, 29 May 2008, Steven M. Bellovin wrote:
> > On Wed, 28 May 2008 10:37:05 +0100
> > <michael.dillon@bt.com> wrote:
> >
> >>> So let's see - if you had a billion CPUs in your botnet, and
> >>> each one could go at a billion to the second, you still need
> >>> 2**69 seconds or 449,235,776,528,695 years. Not bad - only
> >>> 10,000 times the amount of time this planet has been around,
> >>> so yeah, that's the way they'll attack all right.
> >>
> >> I didn't say that. I said that they are starting with an IOS image
> >> in which there are some small number of bytes which they can
> possibly
> >> change and still have a functional image. So it is likely that they
> >> will brute force that by computing an MD5 hash on all variations of
> >> those few bytes. It's like winning the lottery, you only *NEED* to
> >> buy one ticket. No matter how slim the chances are of bad guys
> winning
> >> that lottery, it is no excuse for ignoring the possibility that an
> >> MD5 hash check may not be proof that you have an original image.
> >>
> > Did you even look at Valdis' arithmetic? It *won't work*. It isn't
> > "likely" that they'll try anything with that low a chance of success.
> > As for "no matter how slim the chances" -- if you want to have even a
> > vague chance of succeeding before Sol turns into a red giant, you're
> > going to have to devote enormous resources to the project.
> (Actually,
> > I don't think you can succeed even then, not by brute force -- there
> > aren't a "small number of bytes" that can be changed, you can
> introduce
> > "random" "typographical" errors in error messages for the SNA stack
> or
> > some such, and if you're doing a brute force pre-image attack on MD5
> any
> > bit is as good as any other.) Let's put it purely in economic terms:
> > which is a better way to invest your effort, building a machine (or
> > botnet) with many billions of processors and still having no
> plausible
> > chance of winning, or -- as you yourself suggest -- getting the HVAC
> > contract for the data center. Or putting back doors in the chips.
> Or
> > bribing or blackmailing coders. Or breaking into the vault where
> Cisco
> > keeps its master RSA key. Or funding a vast research effort on
> > cracking MD5 before it's replaced by SHA-512. Or *something* even
> > vaguely sane, because brute-forcing MD5 isn't physically possible.
>
> I don't understand how this disucssion got to breaking MD5 to begin
> with?
> The whole point was that the results will be manipulated due to the
> rootkit messing with the test, no?
>
> Gadi.
>
> >
> > --Steve Bellovin, http://www.cs.columbia.edu/~smb
> >
------=_NextPart_000_0000_01C8C16C.E7B7F2C0
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0jCCAlow
ggHDoAMCAQICEE/N8u+Cjf1akAnPH3Rf2m8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDEyMjIxMjcyN1oXDTA5MDEyMTIxMjcy
N1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSZnJl
aW1lckBjdGl1c2EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFAAtjFvwayIA70SOY
SunlDptyQhb1DviV+LHKOcX5MadLk2NANpODodUvSUb2AgwAqOkCv7cEEMVTAtYaupWbqtyTSTC8
/T8+mmKwBFgci1PmQrkfE30vneHVuylH2n/lKE4vbLXDFKpcIvqSE8SkgAxQFF2+npog2Uxase9t
6QIDAQABoy8wLTAdBgNVHREEFjAUgRJmcmVpbWVyQGN0aXVzYS5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQAHcmBSgreS/FopWMmY+jGgR8IMk07AxNIyvszC1+EqT5GN8CB+BOrr
ePcfIajM/1s/jVJhl7GN/wbKx39vcRFLdTMWfYwRWXJfJFk9C7NBp5QmpUaVxi/q0BFTC9l25BnB
13sv24vIsjSCGif979xFZpwEdP+UZ4U9xfqG+Ps32jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIC+DCCAvQCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEE/N8u+Cjf1akAnPH3Rf2m8wCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwNTI5MTMx
ODA2WjAjBgkqhkiG9w0BCQQxFgQUJIvEGfU+Y2TV7LXb297TT00vRXIwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBPzfLvgo39WpAJzx90X9pvMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhBPzfLvgo39WpAJzx90X9pvMA0GCSqGSIb3DQEBAQUABIGAIAwKvfx0Xztv4qGuyv65/yCm
GoCNzu6dpr0AtYYiLmGf9EBmqYb+Ywv42jWkO8Oymv0sFaWBJpmWI/+fRs46BrPaBdnMS67Ok0ne
UN8EX7zHbJllQkAWooJsWm9Wl9PbTJMO+utWQEAKKD+FtkCe9Pjdgou2KzsELCaDBq+e17kAAAAA
AAA=
------=_NextPart_000_0000_01C8C16C.E7B7F2C0--
