ICMP Covert Channel for IOS

I wrote a quick-and-dirty covert channel via ICMP for IOS routers.

The channel in question isn't super covert. It's all in plaintext and is quite noisy because it only delivers a single byte of message payload per ping. But it gets messages from routers to the listener via pings, and that was the objective. I expect it to be useful when diagnosing IPSec issues behind unknown overload NATs.

It lives here.

Invoke it on a router like this:

Router#tclsh flash:sender.tcl <target> testing 1 2 3

It will then send 14 pings (13 for the characters in 'testing 1 2 3' plus an <EOM> terminator) to the target machine.

The listener functions as a packet sniffer, so it requires root access. It prints out a line per incoming message, preceded by the sender's IP address:

# /tmp/listener.py 

192.168.5.5 testing 1 2 3

Inspecting SCEP enrollment traffic

SCEP is a protocol which facilitates client enrollment with a Certificate Authorities (CA), delivery and renewal of certificates and delegation of identity verification from a CA to a trusted Registration Authoritie (RA)

A project I'm working on requires me to generate a Certificate Signing Request (CSR) on behalf client which doesn't exist yet, and deliver of those requests to the CA via an RA that I'm building. I'll then set aside the certificate and keys for installation onto the client system when it becomes available.

It seemed like ripping apart a request from a real client, as delivered by a real RA would be a good place to start, so that's what I did. I set up a CA (R1), an RA (R2) and a client (R3), performed the enrollment and captured the traffic between the R2 and R1.

There's a nice diagram detailing how a client delivers its  to a CA on this Cisco page, so have a quick peek at the breakdown listed under Client Enrollment there.

A CSR delivered by an RA (rather than the client) is similarly encapsulated, except that both of the PKCS7 functions are performed by the RA (with the RA's private key), rather than the client.

Cisco's diagram looks fairly straightforward, but it took me a while to work out the handful of openssl incantations that follow.

The first step was to collect the data delivered over HTTP using a sniffer. The RA's HTTP GET request looks like this:

 /cgi-bin/pkiclient.exe?operation=PKIOperation&message=MIIJUwYJKoZI...etc...  

The value of the message field is a few KB of URL encoded text, so the first step was to snag that text, stick it in a file I called RA->CA.raw

The text is URL encoded, so a quick substitution restored the newlines, '+', '/' and '=' characters to their usual form, leaving behind a nice base64 encoded file with 64 characters on each line. I saved it as RA->CA.b64

Decode that base64 data to its binary form:

 chris$ base64 --decode 'RA->CA.b64' > 'RA->CA.bin'  

The result is a PKCS7 signedData blob in DER format. You can browse the ASN.1 info for the request I'm working on here. This blob will have the certificate of the signer included.

In a client -> CA request, the client uses his own certificate to sign re-enrollment requests, and uses a self-signed certificate to bootstrap the initial enrollment. In this case (RA -> CA), the data is signed by the RA, so it's the RA's certificate that's included. You can see it at offset 1116 in the ASN.1 parser  linked in the previous paragraph.

Let's extract the RA's certificate:

 chris$ openssl pkcs7 -inform der -print_certs -in 'RA->CA.bin' | openssl x509 -out RA_cert.pem  

And let's have a look at it:

 chris$ openssl x509 -noout -in RA_cert.pem -issuer -subject  
 issuer= /CN=CA  
 subject= /OU=ioscs RA/unstructuredName=R2/serialNumber=4279256517  

The message was signed by the RA and we have that certificate. The RA's certificate was signed by the CA and we don't have that one. We're going to need the CA's certificate in order to extract the payload of this PKCS7 signedData bundle, because without it the trust chain is incomplete so the message won't validate. The CA in this case is a Cisco IOS router. Export the certificate in PEM format:

 R1(config)# crypto pki export ROOT-CA pem terminal  

Save the resulting text in CA_cert.pem and validate/extract the payload from the PKCS7 signedData blob sent by the RA to the CA:

 chris$ openssl cms -inform der -verify -CAfile CA_cert.pem -in 'RA->CA.bin' -out 'RA->CA.payload1'  
 Verification successful  

Great. Now we've got the payload from the PKCS7 signedData blob. What's in there? Another PKCS7, of course. This time it's envelopedData (encrypted). ASN.1 decoder.

This data is encrypted with the CA's public key, so only the CA (holder of the corresponding private key) can read it. We need the CA's private key. Export it from the CA:

 R1(config)# crypto key export rsa CA pem terminal 3des mypassphrase  

Save the resulting text (just the bits between the begin/end private key markers) in CA_key.3des. Strip the passphrase for sanity's sake. This is a test environment after all!

 chris$ openssl rsa -in CA_key.3des -out CA_key.pem -passin pass:mypassphrase  

Now we can use the CA's private key to decode the message sent to the CA:

 chris$ openssl cms -decrypt -in 'RA->CA.payload1' -inkey CA_key.pem -inform der -out 'RA->CA.payload2'  

So... What's in this RA->CA.payload2 file? Back to the ASN.1 decoder... Holy cow, it's a Certificate Signing Request!

 chris$ openssl req -in 'RA->CA.payload2' -inform der -noout -subject  
 subject=/unstructuredName=R3/serialNumber=4279256517  

Next steps for me are to run all of these steps backward so that I can deliver such a package to a CA for signing, but without having a real client or RA system. I'll start by generating keys, then a CSR, then encrypting the CSR, signing it with an RA's certificate, etc...