alice and
bob are
f**ked
jasonross
narcissism
• i work here 
• i play here 
• i malware
intro to mitm
traditional mitm techniques
• arp spoof/poisoning
– dsniff / ettercap / cain
• dns poisoning
– dns-mre
• 802.11 tricks
– karma/airbase
• dhcp exhaustion
– scapy / metasploit (digininja’s mods)
problems with mitm
• can be painful to maintain
• arp poisoning is problematic
• encryption!
• passive capture is fun, but may not be enough
painful
maintenance
• iptables works well
• but managing long lists of rules is a pain
• and you still have to do something useful with
the traffic you intercept
maintenancewindow!
arp poisoning isn’t ideal
• busy networks will kill the poisoning host
• it’s likely to get noticed
• even when it works, it’s fickle
• odds are in favor of the network
crypto ftw sucks
• few tools dynamically handle certs
• ones that do are generally passive listeners
(sslsniff)
• those that do manipulate traffic & dynamically
handle certs don’t do well if the traffic is not
HTTP (burp)
pics or it didn’t suck…
data capture is fun
mucking with packets is better
• mobile app testing requires more than passive
capture.
• why just watch wifi traffic, when you could be
injecting client side exploits into the streams?
• could using mitm help social engineering?
enter mallory
mallory is
• a tcp mitm proxy
• that supports fuzzing
• and tcp stream editing
mallory is not
• burp
• terribly well supported
• necessarily stable
how to get mallory
• bitbucket.org/IntrepidusGroup/mallory
– install ubuntu
– run the mallory install script
– done.
• download the minimal vm image, and run the
update script for that (deprecated)
licensing
• python foundation software license v2
• except the gui. that’s gpl3
some familiar challenges
• have to get traffic to the mallory host
– pptp
– gateway box (virtual or otherwise)
– traditional mitm techniques already covered
but now you can do stuff easily
• pause the streams (tcp/udp)
• manipulate packets (manually, or via rulesets)
• create modules to deal with unknown
protocols…
• then muck with that data
recent changes to mallory
• gui vastly improved
• configuration moved to gui
• rules / mucking syntax made much better
• many rules / mucking bugs fixed
stuff i’ve done
• created the install / update scripts
– for the vm image
– for standard ubuntu iso installs (10.10 & 11.04)
• completely redesigned the directory structure
– made it *nix-ish
– for great justice!
• added random shell scripts / minor code tweaks
common problems
• rules gui is confusing
• protocols configuration is confusing
• traffic doesn’t show up in the stream
solutions
• think backwards
– need to have a rule before you can edit it
• uncommented protocols get handled by the
protocol handler, not the tcp debugger
• yeah, that sucks
demo!
endgame
mallory
pwns!
mallory support
• bitbucket issues tickets
• google group
• twitter
• intrepidusgroup.com/insight/mallory
[stop]
• @rossja
• algorythm@gmail.com

Alice and Bob are Eff'd

  • 1.
  • 2.
    narcissism • i workhere  • i play here  • i malware
  • 3.
  • 4.
    traditional mitm techniques •arp spoof/poisoning – dsniff / ettercap / cain • dns poisoning – dns-mre • 802.11 tricks – karma/airbase • dhcp exhaustion – scapy / metasploit (digininja’s mods)
  • 5.
    problems with mitm •can be painful to maintain • arp poisoning is problematic • encryption! • passive capture is fun, but may not be enough
  • 6.
    painful maintenance • iptables workswell • but managing long lists of rules is a pain • and you still have to do something useful with the traffic you intercept maintenancewindow!
  • 7.
    arp poisoning isn’tideal • busy networks will kill the poisoning host • it’s likely to get noticed • even when it works, it’s fickle • odds are in favor of the network
  • 8.
    crypto ftw sucks •few tools dynamically handle certs • ones that do are generally passive listeners (sslsniff) • those that do manipulate traffic & dynamically handle certs don’t do well if the traffic is not HTTP (burp)
  • 9.
    pics or itdidn’t suck…
  • 10.
  • 11.
    mucking with packetsis better • mobile app testing requires more than passive capture. • why just watch wifi traffic, when you could be injecting client side exploits into the streams? • could using mitm help social engineering?
  • 12.
  • 13.
    mallory is • atcp mitm proxy • that supports fuzzing • and tcp stream editing
  • 14.
    mallory is not •burp • terribly well supported • necessarily stable
  • 15.
    how to getmallory • bitbucket.org/IntrepidusGroup/mallory – install ubuntu – run the mallory install script – done. • download the minimal vm image, and run the update script for that (deprecated)
  • 16.
    licensing • python foundationsoftware license v2 • except the gui. that’s gpl3
  • 17.
    some familiar challenges •have to get traffic to the mallory host – pptp – gateway box (virtual or otherwise) – traditional mitm techniques already covered
  • 18.
    but now youcan do stuff easily • pause the streams (tcp/udp) • manipulate packets (manually, or via rulesets) • create modules to deal with unknown protocols… • then muck with that data
  • 19.
    recent changes tomallory • gui vastly improved • configuration moved to gui • rules / mucking syntax made much better • many rules / mucking bugs fixed
  • 20.
    stuff i’ve done •created the install / update scripts – for the vm image – for standard ubuntu iso installs (10.10 & 11.04) • completely redesigned the directory structure – made it *nix-ish – for great justice! • added random shell scripts / minor code tweaks
  • 21.
    common problems • rulesgui is confusing • protocols configuration is confusing • traffic doesn’t show up in the stream
  • 22.
    solutions • think backwards –need to have a rule before you can edit it • uncommented protocols get handled by the protocol handler, not the tcp debugger • yeah, that sucks
  • 23.
  • 24.
  • 25.
    mallory support • bitbucketissues tickets • google group • twitter • intrepidusgroup.com/insight/mallory
  • 26.

Editor's Notes

  • #3 if you need notes for this slide, you suck.
  • #4 there’s alice and bob they want to talk to each other. because they’re friends. mallory hates them both. she’s got a plan. if she can jump into one of their conversations, she can cause all kinds of problems.
  • #5 there’s a number of techniques for accomplishing man-in-the-middle attacks. here’s a list of the more common ones, and some of the tools that can be used to perform them. * arp spoofing tricks other machines on the network into thinking you’re the gateway host. this results in the attacking host acting as the router for the network. because it is the router, all packets can be intercepted. * dns poisoning can be used to inject an attackers ip address into the answer section of a dns query. this results in a victim host believing the attacker’s IP is the correct address for, say, paypal.com * 802.11 tricks typically involve setting up a rogue AP. wireless clients connect to the AP, resulting in the attacker again acting as a gateway device and router, able to intercept all traffic from the victim machine. * dhcp exhaustion is generally performed by sending a flood of dhcp request packets, and accepting all resulting dhcp offers until the dhcp server pool has been entirely consumed by the attacking machine. more complicated versions attempt to send dhcp release packets for existing hosts, in an attempt to knock them off the network. once all dhcp addresses are owned by the attacker, it can send out dhcp replies to new requests and assign addresses from the pool it now owns. the result once again is that the attacker becomes the gateway device for the victim machines.
  • #6 details in the next few slides
  • #7 you’ve just become the router on a network with somewhere between 50 and 150 hosts. you need to intercept specific traffic, monitor it, and potentially manipulate the data being sent between the client and server. how do you do that effectively? *hint*: manually adding iptables for everything you want + managing a crapton of netsed regex statements is not effective.
  • #8 when you arp poison a network, it’s essentially you vs. every machine on the segment. because each machine is trying to respond to arp requests with valid information as you’re trying to respond with bogus information, there’s a dramatic increase in the total amount of traffic. additionally, any success is limited, as the valid arp data is constantly being sent by the legit hosts.
  • #10 using cain, i arp poisoned my whole network (a /24, with 6 live hosts) i then checked email using imaps, and both twitter and gmail over https. the end result was that, while cain captured the certs, the connections weren’t successfully intercepted. worse, in the case of the twitter connection, cain was able to snarf the twitter information, but it was completely wrong.
  • #11 remember tjx and heartland, from back before anti-nony-lulzsec made everyone forget about actual hacking by releasing a tsunami of dox? they are examples of what can happen when someone just passively captures data (crypted or plain). then there’s the obligatory “hipsters sitting in starbucks” credentials theft scenario. whatever.
  • #21 code tweaks: updated a lot of files to work with the new directory structured changed the codebase to use native set() instead of python Sets module