MITM Labs/Bettercap Over Wifi - Revision history

Admin: Admin moved page MITM Labs/Bettercap SSL Over Wifi to MITM Labs/Bettercap Over Wifi

2016-08-29T09:31:24Z

Admin moved page MITM Labs/Bettercap SSL Over Wifi to MITM Labs/Bettercap Over Wifi

← Older revision	Revision as of 09:31, 29 August 2016
(No difference)

Admin: /* Sniffing HTTPS with HSTS Bypass */

2016-08-22T21:21:13Z

Sniffing HTTPS with HSTS Bypass

← Older revision		Revision as of 21:21, 22 August 2016
Line 371:		Line 371:

	==Sniffing HTTPS with HSTS Bypass==		==Sniffing HTTPS with HSTS Bypass==

	~~This page covers HSTS in more detail: https://www.bettercap.org/docs/proxying/http.html~~

	The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.		The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.
Line 379:		Line 377:

	The sheep's request for <code><nowiki>http://wwwqwerty.google.com</nowiki></code> is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original <code><nowiki>https://www.google.com</nowiki></code>. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.		The sheep's request for <code><nowiki>http://wwwqwerty.google.com</nowiki></code> is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original <code><nowiki>https://www.google.com</nowiki></code>. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.

			Video of implementation: https://www.bettercap.org/docs/proxying/http.html

	==Future Work==		==Future Work==

Admin: /* Sniffing HTTPS with HSTS Bypass */

2016-08-22T21:20:43Z

Sniffing HTTPS with HSTS Bypass

← Older revision		Revision as of 21:20, 22 August 2016
Line 376:		Line 376:
	The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.		The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.

	For example, the link <code>https://www.google.com</code> would be stripped to <code>http://www.google.com</code> and the subdomain modified to <code>http://wwwqwerty.google.com</code> or something similar. The google.com domain will not have a subdomain entry defined for wwwqwerty, and so there will be no reason for the domain to respond and insist the sheep use HTTPS.		For example, the link <code><nowiki>https://www.google.com</nowiki></code> would be stripped to <code><nowiki>http://www.google.com</nowiki></code> and the subdomain modified to <code><nowiki>http://wwwqwerty.google.com</nowiki></code> or something similar. The google.com domain will not have a subdomain entry defined for wwwqwerty, and so there will be no reason for the domain to respond and insist the sheep use HTTPS.

	The sheep's request for <code>http://wwwqwerty.google.com</code> is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original <code>https://www.google.com</code>. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.		The sheep's request for <code><nowiki>http://wwwqwerty.google.com</nowiki></code> is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original <code><nowiki>https://www.google.com</nowiki></code>. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.

	==Future Work==		==Future Work==

Admin: /* Future Work */

2016-08-22T21:19:37Z

Future Work

← Older revision		Revision as of 21:19, 22 August 2016
Line 369:		Line 369:

	[[Image:SecureConnectionFailed_InadequateKeyUsage.png\|500px]]		[[Image:SecureConnectionFailed_InadequateKeyUsage.png\|500px]]

			==Sniffing HTTPS with HSTS Bypass==

			This page covers HSTS in more detail: https://www.bettercap.org/docs/proxying/http.html

			The page describes the HSTS attack, a modified version of sslstrip that has a greater probability of success. The way it works is, it changes secure https links to insecure http links, and additionally, it modifies the link subdomain to something random, so that there will be no "forwarding" requirement from the domain to change to https.

			For example, the link <code>https://www.google.com</code> would be stripped to <code>http://www.google.com</code> and the subdomain modified to <code>http://wwwqwerty.google.com</code> or something similar. The google.com domain will not have a subdomain entry defined for wwwqwerty, and so there will be no reason for the domain to respond and insist the sheep use HTTPS.

			The sheep's request for <code>http://wwwqwerty.google.com</code> is destined for the gateway, but it reaches the attacker first - where it can be modified into something that will, in fact work, like the original <code>https://www.google.com</code>. Now that it is the attacker establishing the connection, an encrypted HTTPS tunnel should be set up by visiting the https site.

	==Future Work==		==Future Work==

Admin: /* why use old stuff */

2016-08-22T21:08:55Z

why use old stuff

← Older revision		Revision as of 21:08, 22 August 2016
Line 326:		Line 326:
	===why use old stuff===		===why use old stuff===

	Okay, you're probably wondering: why am I ~~using~~ tools ~~that were~~ presented ~~at Defcon 9~~, ~~when we~~'re now ~~at Defcon 24?~~ Just look at the browsers in this presentation: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf		Okay, you're probably wondering: why am I focusing on old tools? This stuff was presented in 2009, it's now 2016. Just look at the browsers in this presentation: https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

	The reason I'm covering this is, the tools still work, the principles still apply, and HTTPS can still be broken.		The reason I'm covering this is, the tools still work, the principles still apply, and HTTPS can still be broken.

	Breaking HTTPS ''used to be easy,'' back in the days of ~~Defcon 9~~. You could download Moxie's tool and away you went. Back then, browsers were dumb. Back then, browsers looked like this:		Breaking HTTPS ''used to be easy,'' back in the days of 2009. You could download Moxie's tool and away you went. Back then, browsers were dumb. Back then, browsers looked like this:

	[[Image:RetroBrowser.png\|200px]]		[[Image:RetroBrowser.png\|200px]]

	Now we have smarter browsers, more sophisticated mechanisms, and 15 years of security fails and other lulz to improve HTTPS. However, there are still ways to defeat HTTPS (they just require deeper knowledge and more specialized tools). While the particulars of the attacks have evolved, having tools for dealing with certificate security mechanisms is still useful.		Now we have smarter browsers, more sophisticated mechanisms, and 7 years of security fails and other lulz to improve HTTPS. However, there are still ways to defeat HTTPS (they just require deeper knowledge and more specialized tools). While the particulars of the attacks have evolved, having tools for dealing with certificate security mechanisms is still useful.

	===whaddya mean===		===whaddya mean===

Admin: /* Wrap-Up */

2016-08-22T20:10:02Z

Wrap-Up

← Older revision		Revision as of 20:10, 22 August 2016
Line 387:		Line 387:

	Basically, creating an HTTP tap is easy. Breaking HTTPS is harder.		Basically, creating an HTTP tap is easy. Breaking HTTPS is harder.

	~~=Wrap-Up=~~

	~~==Results==~~

	The results of this lab were a bit ambiguous. On the one hand, bettercap performed extremely well relative to ettercap. It was a fast MITM attack. On the other hand, bettercap was not able to capture several plaintext credentials that I tried. Additionally, MITM of SSL is increasingly difficult with modern browser technologies.

	~~==Workflow Improvements==~~

	~~I can't think of any workflow improvements for this attack type, given the ease with which bettercap operates. It could not be made easier.~~

	~~==Conclusions==~~

	~~An excellent new tool.~~

	~~The MITM ARP poisoning to sniff HTTP traffic worked like a charm.~~

	~~The MITM ARP poisoning to sniff encrypted HTTPS traffic did not work so great.~~

	~~Next step: follow up with [[SSLStrip]]~~

	~~Then [[SSLSniff]] - null prefix attack~~

	=Flags=		=Flags=

Admin: /* Sheep Booty */

2016-08-22T20:09:37Z

Sheep Booty

← Older revision		Revision as of 20:09, 22 August 2016
Line 383:		Line 383:

	The answer is: it depends.		The answer is: it depends.
			* If you're ARP poisoning, it's very easy to capture HTTP traffic, see cookies, see certificates being exchanged for secure connections, and sniff plaintext traffic for goodies like login credentials. [[Bettercap]] is your tool.
			* If you're interested in going after the good stuff, the HTTPS connections, you'll want to step your game up. Use [[Bettercap]] for the ARP poisoning, and use [[SSLSniff]] for managing the forged certificates. Then use your imagination to create the certificates. More here: [[Certificates]]

	~~If you're ARP poisoning~~, ~~it's very easy to capture~~ HTTP ~~traffic, see cookies, see certificates being exchanged for secure connections, and sniff plaintext traffic for goodies like login credentials. [[Bettercap]]~~ is ~~your tool~~.		Basically, creating an HTTP tap is easy. Breaking HTTPS is harder.

	~~If you're interested in going after the good stuff, the~~ HTTPS ~~connections, you'll want to step your game up. Use [[Bettercap]] for the ARP poisoning, and use [[SSLSniff]] for managing the forged certificates. Then use your imagination to create the certificates~~.

	~~More here: [[Certificates]]~~

	=Wrap-Up=		=Wrap-Up=

Admin: /* Step 6: Sheep Booty */

2016-08-22T19:33:25Z

Step 6: Sheep Booty

@@ Line 370: / Line 370: @@
 [[Image:SecureConnectionFailed_InadequateKeyUsage.png|500px]]
-==Step 6: Sheep Booty==
+==Future Work==
-ummmm... browser history? oh, and cookies.
+There is a lot of potential to explore the use of sslsniff with funky certificates. This is the most viable attack vector at present.
 =Wrap-Up=

Admin: /* Certificates: */

2016-08-22T19:28:21Z

Certificates:

← Older revision		Revision as of 19:28, 22 August 2016
Line 209:		Line 209:

	</pre>		</pre>

			Note that while we could simply copy and paste this when it comes time to send the sheep our own certificate, we would not have the private key corresponding to this public certificate, so we would have no way of decrypting communications with the sheep using this certificate.

	==Sniffing HTTPS with Bettercap (Meh)==		==Sniffing HTTPS with Bettercap (Meh)==

Admin: /* Step 3: ARP Poisoning */

2016-08-22T19:25:32Z

Step 3: ARP Poisoning

← Older revision		Revision as of 19:25, 22 August 2016
Line 101:		Line 101:
	==Step 3: ARP Poisoning==		==Step 3: ARP Poisoning==

	Now you are ready to carry out the ARP poisoning attack with [[Bettercap]]. It's important to note that Bettercap has significantly better performance with MITM attacks - there was absolutely no sign of lag or fishy behavior running a MITM with Bettercap, whereas it was painfully obvious something funny was going on when using Ettercap to conduct a MITM.		Now you are ready to carry out the ARP poisoning attack with Bettercap. It's important to note that Bettercap has significantly better performance with MITM attacks - there was absolutely no sign of lag or fishy behavior running a MITM with Bettercap, whereas it was painfully obvious something funny was going on when using [[Ettercap]] to conduct a MITM.

	This command will spoof a single sheep, according to the scenario we outlined above:		This command will spoof a single sheep, according to the scenario we outlined above: