Packet re­di­rect­ion on

Er­min Kre­ponic ex­plains the prin­ci­ples of clas­sic packet redi­rect­ing, us­ing a man-in-the-mid­dle at­tack to cir­cum­vent a web­site’s de­fences.

Linux Format - - CONTENTS - Er­min Kre­ponic is an IT ex­pert and Linux en­thu­si­ast with a pas­sion for trou­bleshoot­ing net­work-re­lated prob­lems. He does not sleep much.

This ar­ti­cle is all about sslstrip and ARP spoof­ing. At­tack­ing wire­less net­works is about much more than just crack­ing the au­then­ti­ca­tion keys. There are a lot of other tech­niques that can be used, es­pe­cially on public Wi-Fi where you can au­then­ti­cate with­out any prob­lems.

Once you’re au­then­ti­cated then you’re able to lis­ten to all the traf­fic on that net­work. More likely than not, how­ever, that traf­fic will be en­crypted and prob­a­bly won’t be all that much use to you. You’ll be able to see which IP ad­dresses are vis­it­ing what web­sites, but you won’t be able to see any­thing of real value to an at­tacker.

The prob­lem is HTTPS, which en­crypts your web traf­fic. Lo­gin cre­den­tials ought to all be trans­mit­ted via HTTPS, which means they can’t be in­ter­cepted. The pro­gram sslstrip con­verts HTTPS con­nec­tions to HTTP ones, ef­fec­tively strip­ping the en­cryp­tion. If this suc­ceeds, then all pack­ets will be trans­mit­ted in the clear and you’ll be able to see any user­names and pass­words that peo­ple on the net­work are us­ing to log in to web­sites, just as you would if those web­sites weren’t us­ing HTTPS.

This tu­to­rial as­sumes we’re work­ing with Fe­dora. We’ll need two tools for this: sslstrip and arp­spoof. The lat­ter is for ad­dress res­o­lu­tion pro­to­col (ARP) spoof­ing, in which we con­vince the router of our as­sumed iden­tity so that it sends us the pack­ets sent to it by the user. We then strip the en­cryp­tion and re­trans­mit the pack­ets to the router, which then sends the pack­ets to the in­ter­net.

In­stall the re­quired pack­ages (all com­mands in this tu­to­rial need to be run as root ) with the fol­low­ing com­mands: # yum in­stall sslstrip # yum in­stall dsniff

On most other dis­tros the sec­ond pack­age is called arp­spoof, and if you’re us­ing the hacker-tai­lored Kali dis­tro, then both of th­ese are al­ready in­stalled.

By re­trans­mit­ting the in­ter­cepted, sslstrip- af­fected pack­ets back to the router, the at­tacker is com­mu­ni­cat­ing with the vic­tim via HTTP, so ev­ery­thing is sent in the clear. This is a text­book Man in the Mid­dle (MitM) at­tack.

This at­tack isn’t going to work 100 per cent of the time. Some­times it de­pends on the tar­get browser ( In­ter­net Ex­plorer is likely to be more sus­cep­ti­ble than Fire­fox or Chrome) and some web­sites such as PayPal and Face­book have taken steps to make im­ple­ment­ing the at­tack dif­fi­cult.

Yet be­cause peo­ple tend to re­cy­cle cre­den­tials across web­sites it’s pos­si­ble that de­tails har­vested on a less-se­cure site can be used on one where our at­tack fails. We ad­vise hav­ing one set of pass­words for sen­si­tive sites – banks, email, social me­dia, any­thing that knows your ad­dress – and one set of pass­words for less-sen­si­tive sites, such as fo­rum ac­counts. Re-use be­tween less-sen­si­tive sites is prob­a­bly fine, and cre­den­tials are un­likely to be lifted (with the tech­niques we present here) from the likes of Paypal, so the worst-case sce­nario here is that a cou­ple of your fo­rum ac­counts are com­pro­mised. Hack­ers prob­a­bly have no in­ter­est in th­ese.

Mount­ing the at­tack

We first need to con­fig­ure our ker­nel to for­ward pack­ets: # echo 1 > /proc/sys/net/ipv4/ip_­for­ward

Next we need to tell ipt­a­bles to re­di­rect pack­ets ap­pro­pri­ately: # ipt­a­bles -t nat -A PREROUTING -p tcp --des­ti­na­tion-port 80 -j RE­DI­RECT --to-port 8080

The sslstrip pro­gram will lis­ten on port 8080, so this will for­ward pack­ets des­tined for web­servers (port 80).

Now we need to find a tar­get. This ar­ti­cle as­sumes that a Win­dows 8.1 vir­tual ma­chine is run­ning on the net­work, but in

prac­tice any­thing can be used. Don’t at­tack a ma­chine with­out per­mis­sion. In prac­tice you’d scan the net­work first, which you can do with the well-known nmap util­ity: nmap 192.168.1.1/24 Our tar­get VM is at 192.168.1.100, so nmap re­sponds: Scan­ning 192.168.1.100 [1000 ports] Dis­cov­ered open port 80/tcp on 192.168.1.100 Dis­cov­ered open port 443/tcp on 192.168.1.100

We’ll need three ter­mi­nal win­dows open for this at­tack: two to mount the ac­tual at­tack and one to mon­i­tor the re­sults. We’re going to con­vince the router that we’re the Win­dows 8.1 VM and at the same time con­vince the Win­dows 8.1 VM that we’re the router. Our ARP spoof­ing at­tack is car­ried out as fol­lows (here we’re as­sum­ing the at­tack is be­ing car­ried out over a wire­less in­ter­face named wlp2s0 : # arp­spoof -i wlp2s0 -t 192.168.1.100 -r 192.168.1.1 The -t ar­gu­ment is the tar­get ma­chine and the -r ar­gu­ment is the de­fault gate­way. This redi­rects all of the vic­tim’s traf­fic to our at­tack ma­chine. Be­cause we en­abled for­ward­ing with ipt­a­bles ear­lier, the vic­tim ma­chine’s con­nec­tiv­ity will be un­af­fected, ex­cept that web traf­fic will be in­ter­cepted by sslstrip, which we now run: # sslstrip -l 8080

sslstrip will out­put a bunch of gib­ber­ish once it starts in­ter­cept­ing traf­fic, so it’s eas­ier to fol­low the logs in our third ter­mi­nal win­dow with: # tail -f sslstrip.log

Now in the tar­get ma­chine open both In­ter­netEx­plorer and Fire­fox. Some­times the at­tack will work in one browser but not the other. Of­ten it won’t work in ei­ther, but let’s not worry about that. In a real-world sce­nario you’d have to wait for your at­tacker to start brows­ing the web here. Try vis­it­ing

https://gmail.com in In­ter­netEx­plorer. If the at­tack works, then sslstrip should in­ter­fere with the traf­fic so that the page is served over HTTP, which you can check by look­ing at the URL bar. This def­i­nitely won’t work with newer browsers, but for our slightly con­trived tar­get ma­chine it does.

En­ter some made-up de­tails, say FAKE for both user­name and pass­word, into the lo­gin form and hit Sign in. The sslstrip log should spew lots of data, be­gin­ning with some­thing like: 2017-01-07 00:01:02,345 SE­CURE POST Data (ac­counts. google.com) But some­where in amongst the gib­ber­ish there should be some­thing like: ...checkedDo­mains=youtube&Email=FAKE&Passwd=FAKE which shows the at­tack has been suc­cess­ful. On our tar­get ma­chine this at­tack didn’t work in Fire­fox or Chrome, but the cur­rent Net­mar­ket­share sur­vey shows that about 18 per cent are still us­ing some ver­sion of In­ter­netEx­plorer, so it’s not un­re­al­is­tic to sup­pose this will work some­where. Af­ter all, many in­sti­tu­tions are slack at ap­ply­ing se­cu­rity up­dates and force users to use cer­tain ter­ri­ble pro­grams for legacy rea­sons. We saw sim­i­lar suc­cess slurp­ing lo­gin de­tails for Face­book from In­ter­netEx­plorer. While the sslstrip at­tack didn’t work with ma­jor sites on other browsers, it doesn’t mean the same is true for other sites.

De­feat­ing sslstrip

Note that the web­sites them­selves aren’t serv­ing HTTP lo­gin pages, they’re trans­mit­ted to our at­tack ma­chine via HTTPS and we send them to the tar­get over HTTP. So mit­i­gat­ing against this from the server side is much more com­pli­cated than just serv­ing HTTPS pages only.

The best way is to use HTTP Strict Trans­port Se­cu­rity (HSTS). Once im­ple­mented, the server will send an ex­tra header over HTTPS con­nec­tions which spec­i­fies a max-age flag. This is a du­ra­tion (mea­sured in sec­onds) af­ter the first ac­cess for which the site will be as­sumed to be HTTPS only. Thus, so long as our vic­tim’s first visit to the site pro­ceeds un­tam­pered, any sub­se­quent at­tempts to view the page over HTTP will cause the browser to com­plain.

Another de­fence is to train users to al­ways look for the s in https:// or, fail­ing that, the friendly green pad­lock. But users are fickle some­times. The HTTPS Ev­ery­where browser ex­ten­sion does a good job of stop­ping this at­tack dead and is gen­er­ally a good thing to have en­abled as part of a healthy web brows­ing reg­i­men.

arp­spoof will tell you about all the fake ARP mes­sages it emits to dupe our mark into think­ing that we’re the net­work gate­way.

At­tack­ing Win­dows 8 and In­ter­net Ex­plorer might seem like shoot­ing fish in a bar­rel, but peo­ple do still use th­ese (ter­ri­ble) things.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.