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 (http://ettercap.sourceforge.net/) or dsniff (http://www.monkey.org/~dugsong/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.

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)

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.

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.

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.

SSL MITM Attack of iLiad reader

Requirement: OpenSSL libraries (http://www.openssl.org) 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.


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)

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"


iptables –N nat (to make the iptables table nat)
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)

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.

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.

did you get my pm TadW?

ettercap only picked up UDP traffic.

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.

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

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!

deadite66, any news?

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

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.

<removed>

this looks the version information, i was hoping for a text file with the version and a download link :(

The eui64 is most probably a 64bit representation of the 6-byte MAC address of your iLiad's network interface. So it appears the MAC address is 00:16:7c:00:0x:xx.

Productid is probably there to identify that you have a iLiad ER-0100 device.

When you do a bit more with iDS, like a software upgrade, we'll have a lot more useful information.

guess we'll have to wait till the next update.

Yup ;)

i do forsee a problem though, ettercap expect the victim ip to be up where the iliad only turns on ethernet when connecting to ids.
so timing will be important and i may miss the update.

Good point.

Does the iLiad automatically start the update process when it connects to iDS and finds an upgrade? Or does it first inform you?

If it doesn't "warn" you first, you may want to avoid connecting to iDS unless you are really sure that there is a new upgrade available (which you would quickly find out about from others here on board). At the end timing could be a bit tricky to make sure Ettercap captures everything from the beginning.

2.4 i'm sure it just started updating could be different for 2.5 though

To get around this timing issue, use Ettercap to sniff via your iLiad's MAC address instead. So if your MAC address is 00:16:7c:00:0e:5e and your gateway IP is 192.168.0.10, use the following command:

ettercap -Td -L /tmp/logfile.log -M arp:remote 00:16:7c:00:0e:5e// /192.168.0.10/

Only make sure you start the prior you connect to iDS with your iLiad.

2.4 i'm sure it just started updating could be different for 2.5 though

2.4 will first advance to 2.4.10 via a flash at shutdown. Then 2.5, then packages for 2.5, then 2.6 ?

Has anyone successfully captured a 2.4 upgrade? Has anyone deconstructed the communication stream to see if it's susceptible to replay or what the handshaking is like? Is there anywhere else where discussion is happening on the results?

Has anyone successfully captured a 2.4 upgrade? Has anyone deconstructed the communication stream to see if it's susceptible to replay or what the handshaking is like? Is there anywhere else where discussion is happening on the results?

See my other thread. I captured os.gz but failed to capture fs.gz and then my filesystem were updated. I failed because I counted on renaming the files using /bin/mv, and the boot filesystem does not contain mv!

Has anyone already succeeded in sniffing the upgrade of 2.6?