iLiad Sniffing the iDS connection

[TadW]

Has anyone yet tried to sniff the traffic when the iLiad connects to iDS? I know it's SSL-protected, but with a MitM attack using tools like Ettercap or dsniff you should be able to deal with it.

Sniffing the traffic, we could then find out - for instance - how the iRex does remote flash upgrades.

[ali]

Originally Posted by TadW

Sniffing the traffic, we could then find out - for instance - how the iRex does remote flash upgrades.

Essentially we know that - it stores packages in some directory, and they're executed from start.sh / do_updates.sh on reboot. So this doesn't help if the OS is screwed, as it doesn't really reflash. (I assume you were thinking about that)

[TadW]

True it wouldn't help to fix a dead iLiad (for that we'd probably need to find out how to boot the iRex connected via usb and lan to some BootP/TFTP server).

But if you capture the ids connection, you might find out other interesting things. For instance, what data is exactly being transferred to the server. Or, how does the flash file(s) look like? By capturing the flash file(s), one could find out the structure of the flash - and then we could perhaps disect it and write custom flash files.

[TadW]

I also posted this elsewhere in this forum, but in case someone is looking for specific information how to sniff the traffic from your iLiad, here the info again:

Let's assume:

• your router has the IP 192.168.0.1 and acts as the gateway
• your iLiad has the IP 192.168.0.10
• your laptop has the IP 192.168.0.11

Then use the following Ettercap commandline to log all traffic between your router and the iLiad:

ettercap -Tq -L /tmp/logfile.log -M arp:remote /192.168.0.1/ /192.168.0.10/

If iDS uses a secured connection (over SSL), you'll have to do some extra work to import the certificate into Ettercap.

[arivero]

Originally Posted by ali

Essentially we know that - it stores packages in some directory, and they're executed from start.sh / do_updates.sh on reboot. So this doesn't help if the OS is screwed, as it doesn't really reflash. (I assume you were thinking about that)

This is partly right, partly wrong. The 2.4 miniupdate stored a package with a new waveform and then a script in rc.d/ so it was executed.. at shutdown!

Then the 2.5 update did the designed update method, running from the script in /old-root (the initial run). This script runs instead of "init" when the machine starts-up, and then it chroots and switches into init. The script checks for the presence of files in the update directories and for the raising of a pair of flags somewhere in the hardware.

[TadW]

SSL MITM Attack of iLiad reader

Requirement: OpenSSL libraries to support SSL and TLS

To sniff a HTTPS connection with Ettercap, we must set up two separate SSL tunnels. Essentially we first ARP poison the iLiad and the gateway (as described earlier), then intercept the iLiad's SSL request, and present it with our own certificate. When the iLiad accepts the certificate, ettercap establishes an SSL tunnel from the device to itself, masquerading as the iDS server. It then establishes a second SSL tunnel to the real web server, with itself as the SSL client.

1. We have to create our SSL certificate (if your installation of Ettercap didn't do it already for you):
   
   

   openssl genrsa -out etter.ssl.crt 1024 
   openssl req -new -key etter.ssl.crt -out tmp.csr
   openssl x509 -req -days 1825 -in tmp.csr -signkey etter.ssl.crt -out tmp.new
   cat tmp.new >> etter.ssl.crt
   rm -f tmp.new tmp.csr 
   cp etter.ssl.crt /usr/local/share/ettercap (path can differ depending on your installation of ettercap)

2. Edit /etc/etter.conf, and do the following important changes:
   • ec_uid=0 (otherwise Ettercap cannot access your iptables rules needed to establish the forwarding)
   • further down the config file, uncomment the firewall rules that apply to your sniffing host. For instance, if you run Linux with iptables (most likely), uncomment as in the following example:
     

     #---------------
     #     Linux
     #---------------         
     
     # if you use ipchains:
        #redir_command_on = "ipchains -A input -i %iface -p tcp -s 0/0 -d 0/0 %port -j REDIRECT %rport"
        #redir_command_off = "ipchains -D input -i %iface -p tcp -s 0/0 -d 0/0 %port -j REDIRECT %rport"
     
     # if you use iptables:
        redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
        redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

3. iptables –N nat (to make the iptables table nat)
4. start sniffing as explained before:
   • ettercap -Tq -L /tmp/logfile.log -M arp:remote /192.168.0.1/ /192.168.0.10/ (here: router = 192.168.0.1, iLiad = 192.168.0.10)

[deadite66]

would the iliad see the cert as coming from irex?
the mitm attacts i've seen depended on the victim accepting the certificate without properly checking it.
i tried an ssl proxy program but the iliad wouldn't accept the certificate.

[TadW]

Yeah it would see it as coming from the iRex. Why don't you test it by sniffing another PC and then running a HTTPS site. You will get a message that the certificate is not valid (because our fake is not signed e.g. by Thawte), but if you look at the details of the certificate, you see its the one that's originally coming from the server. If you want to make the attack perfectly undistinguishable, you'd have to use a signed certificate.

I don't exactly know how you tried an ssl proxy program on the iLiad.

[deadite66]

did you get my pm TadW?

ettercap only picked up UDP traffic.

[TadW]

I PMed you back. You must make sure to give Ettercap root privileges, or it won't be able to tune your firewall for the necessary forwarding rules. See point 2 above.

[deadite66]

arggg, i made somechanges but the forums wont let me post them.

"server made a boo boo" error :/


hmm, ok will have to do it this way.
http://ghostpilot.dyndns.org/etterlog.txt

[Alexander Turcic]

Originally Posted by deadite66

arggg, i made somechanges but the forums wont let me post them.

"server made a boo boo" error :/


hmm, ok will have to do it this way.
http://ghostpilot.dyndns.org/etterlog.txt

Sorry about that, the content of your etterlog file hit our intrusion detection. If you have this problem again, try zipping it first. Thanks!

[TadW]

deadite66, any news?

[deadite66]

only this http://ghostpilot.dyndns.org/etterlog.txt so far, well i seem to have sniffed the time sync from the ids.

[TadW]

Looks very good to me. Hope the instruction was a bit useful, too

Now it's getting more interesting to see what's going on when you e.g. update the device. You could easily catch the entire content of the update and save it to an external file.