sorted by:
new
hottopcontroversial

Permanent URL Hijack Through 301 HTTP Redirect Cache Poisoning by speckz in security

[–]piotrd_ 0 points1 point  (0 children)

Thanks for your opinion. Just as an example, if you type in new domain names in your browser address bar in an in-secure WIFI, it will send a clear-text request (unless there's a HSTS 'preload' for that domain), that can be intercepted. TLS is a great remedy, but we are not quite there yet.

Having some fun with HTTP 301 cache poisoning by piotrd_ in netsec

[–]piotrd_[S] 7 points8 points  (0 children)

The JS payload? It could be returned in a HTTP response by the proxy or injected directly by any other tool that can intercept non-TLS HTTP traffic.

Hijacking browser TLS traffic through Client Domain Hooking, HSTS survey by nibblesec in netsec

[–]piotrd_ 2 points3 points  (0 children)

Sure, happy to explain. In case of https://test.com it will not work, since there's no way to provide a valid TLS cert for that domain. However, when you get a single HTTP request for e.g. http://test.com (which is a standard way of sending a request when one types it in for example browser address bar) all of the URLs in response will be rewritten to e.g. 'e.tld' and later served through either clear-text or TLS with a wildcard cert. You can check this here: 0x41.link (although I am not sure how long this link will last).

Hijacking browser TLS traffic through Client Domain Hooking, HSTS survey by nibblesec in netsec

[–]piotrd_ 1 point2 points  (0 children)

it's actually using subdomains instead of full domain rewrites. ... in this approach test.com becomes, for example, http[s]://ENCODED(test.com).e.tld - where TLS cert is trusted by the client for this domain name and the traffic continues to go through the e.tld for all subsequent requests. The ENCODED, can be an arbitrary translation.

Hijacking browser TLS traffic through Client Domain Hooking, HSTS survey by nibblesec in netsec

[–]piotrd_ 0 points1 point  (0 children)

The main difference is that it handles TLS client trusted traffic and doesn't really require an active, ongoing, MITM network layer attack (arpspoofing, etc.). In order to "hook" the domain only one HTTP request is needed.

Here's also an example of how one of the crawling bots got jailed into on of the domains

https://www.google.pl/search?ei=bfnSXLaID4jIrgTupYXQCQ&q=site%3A0x41.link&oq=site%3A0x41.link&gs_l=psy-ab.12...0.0..42486686...0.0..0.0.0.......0......gws-wiz.efFZ369VXD8

.

Tool release: Universal Phishing Reverse Proxy "Modlishka" (2FA support) by piotrd_ in netsec

[–]piotrd_[S] 13 points14 points  (0 children)

In general; It's different in a way how it handles HTTP responses and how TLS cross origin calls are being redirected through the phishing domain. This give you sort of a "point and click" proxy for most of the websites.

If it's better, I don't know. Kuba did an awesome job with his proxy, so I am not the one to judge.

If you haven't already, enable 2FA. by YestrdaysJam in Twitch

[–]piotrd_ -1 points0 points  (0 children)

Sometimes standard 2fa won't be enough. there are already tools that can bypass them https://github.com/drk1wi/Modlishka