Homework 4: Man-on-the-Side Attacks
www3.cs.stonybrook.edu
Homework 4: Man-on-the-Side Attacks
1–10 of 13 posts
Re: Homework 4: Man-on-the-Side Attacks
#2Re: Homework 4: Man-on-the-Side Attacks
#3It's a lot easier if you can cause the traffic to hijack to take a circuitous route through the Internet...
http://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/
or more recently:
http://research.dyn.com/2015/03/uk-traffic-diverted-ukraine/
Re: Homework 4: Man-on-the-Side Attacks
#4I see the site itself is using obsolete cryptography as per Google Chrome http://i.imgur.com/cF0SAmN.jpg
Don't know if its relevant to the submission :)
Re: Homework 4: Man-on-the-Side Attacks
#5I was at first excited about an undergraduate program that would have homeworks like this, then I saw the PhD tag.
Something like scapy is perfect for this, I'm not sure about the speed though.
Re: Homework 4: Man-on-the-Side Attacks
#6I was at first excited about an undergraduate program that would have homeworks like this, then I saw the PhD tag. Something like scapy is perfect for this, I'm not sure about the speed though.
Should be fairly fast still in low traffic volume mode. The challenge is doing at scale.
With low volume traffic, the code spends most of it's time blocked waiting for the next packet so the response is very quick.
With high volumes, especially high volume of small packets, the code can get seriously backlogged and even miss packets altogether if the raw interface isn't serviced fast enough.
H/W acceleration is needed to do this at backbone volumes.
Once upon a time (over 10 years ago) I was working in the field of high-volume NIDS and keeping up with (then blazing fast) GiGE LAN volumes was very challenging with the CPU alone back then. And that was with tuned rule sets / minimal pre-processors / no other I/O in the hot path.
Re: Homework 4: Man-on-the-Side Attacks
#7Ha, that's an interesting idea.
About 2 months ago -- for a presentation about being vigilant with your smartphone on public APs -- I implemented a toolkit that was essentially a man-in-the-middle/evil twin -- a single channel BSS analysis tool which allowed for broadcast and targeted deauth injection along with a probe request monitor, all in one interface, and a DNS spoofer in the other interface. I used HostAP for network spoofing. Its the simplest exploit but was very interesting building the demo and the kids enjoyed it!
This is another good little attack piece to shove in!
Re: Homework 4: Man-on-the-Side Attacks
#8I see the site itself is using obsolete cryptography as per Google Chrome http://i.imgur.com/cF0SAmN.jpg Don't know if its relevant to the submission :)
I would wager that the crypto settings are done by some central IT organization within the school. Experience would suggest that the CS professors think the sys admins are a bunch of amateurs, and the sys admins probably think the professors are snobs with no appreciation of cost and "real-world" applications.
Re: Homework 4: Man-on-the-Side Attacks
#9I was at first excited about an undergraduate program that would have homeworks like this, then I saw the PhD tag. Something like scapy is perfect for this, I'm not sure about the speed though.
I took the undergraduate version of this class (at Stony Brook), the homework assignments were similar (usually, just the graduate version with a slightly lower bar to success - I partnered with a grad student so I had to do the graduate version.)
Our assignments were (1) a toy implementation of RSA, complete with the ability to generate SSL certificates (so, ASN.1 encoding, etc) using only a bignum library and (2) implementing a known buffer overflow attack on an old version of sendmail. ( http://web.nvd.nist.gov/view/vuln/detail?vulnId=CAN-2002-133... )
https://web.archive.org/web/20140106173814/http://www.cs.sto...
Re: Homework 4: Man-on-the-Side Attacks
#10http://en.wikipedia.org/wiki/Man-on-the-side_attack
Comparison of MitM and MotS
Observe Inject Delete Modify
Man-in-the-middle X X X X
Man-on-the-side X X
Packet Sniffing X