Droid & iOS wide open to MiTM

$alvador

$alvador

TD Member
the easy way is to just check to make sure you're connected to https:// with a cert signed by the expected CA. it looks like the most practical use of this exploit is to redirect DNS so that common sites like facebook.com get resolved to an IP under the control of de hax0r where they could have a web server set up with a clone of the facebook portal and if you try to log in then bam they've got your credentials. if the version is just http:// then it's an obvious fake, but some trusted CAs do issue free certs so it's possible to set up a totally fake site that reads as https://facebook.com and looks mad legit to anyone who doesn't check who it's signed by.
 
zackychuu

zackychuu

TD Admin / Wanker
Does that go the same for apps? Are we still at risk while using say the Facebook or Instagram app etc?
I actually rarely use my browser, just a few web searches here and there.

But yes, double checking the certificates is doable, thanks.
 
$alvador

$alvador

TD Member
the real threat of this trick is that it lets an attacker act as your router, which brings ssl stripping attacks into play. MiTM attacks can't normally do much damage if all the traffic is encrypted, but if that encryption is stripped then all the attacker needs is to see the response from the Facebook server, containing the security token used to authenticate your login, for them to be able to redirect you to a local server that uses the same token to trick the FB app into thinking it's connected to the legit FB server and trying to open a session with the attack server by sending it your credentials.

so possible, yes. probable? i have no idea, but the basic concept of this doubledirect attack is pretty powerful and these zimperium guys seem to think it's in widespread use.
 
$alvador

$alvador

TD Member
just following up on this since i rooted my new phone and mucked around with the settings. turning accept_redirects off isn't persistent, it resets to 1 (on) after reboot because it's set by the firmware.

so i figured a good workaround would be some sort of init script but this needs a bit of setup:

first you need the busybox binary for your architecture (ARMv7 typically)
then you need a script to set up init.d support: link

because the busybox binary is statically linked, it's just a matter of copying it to /system/app, and if you look at the shell script you'll see that it also requires symlinks in /system/app for "grep" and "run-parts" pointing to busybox.

once that is set up it's just a matter of running the script to get init.d support then placing the command linked in the OP into the init.d folder for it to be run at startup. Tested on Android 4.4 and it works nicely.

if you run into any "read only system" errors just need to type:

Code: 
mount -o rw,remount /system

when you reboot it resets to read only automatically so there's no need to manually do it.
 
You must log in or register to reply here.
Top