Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

When TLS Hacks You - SSRF Exploitation Technique- 257

Joshua MadduxPosted 5 Years Ago
  • Server Side Request Forgery (SSRF) is where an attacker can force a request made on the internal network. The most exploitable case is when you can get the data to be returned, including stealing AWS metadata, mapping the network or anything else.
  • Blind SSRF is when you cannot actually see the data, but the request is being made. Additionally, there are some other limitations, such as the request type being made (PUT, for instance won't work as well), the content type being returned and so on. This attack is a complete compromise via a single HTTPS call.
  • In the past, protocols such as gopher have been exploited. Additionally, platform specific parsing bugs are sometimes used (SNI injection) to smuggle arbitrary bytes (Orange Tsai).
  • Abusing TLS renegotiation or key reuse, we can coerce newline based protocols (running locally) to do whatever we want. The TLS data, such as session keys and things, can be used to smuggle data in later. The session caching looks for the hostname, scheme and port (generally), not the IP address.
  • The second time this request is made, the DNS server (we control) changes the DNS IP address! This attack is known as DNS rebinding. Because the DNS server has changed its IP address AND the TLS session has been saved, we can interact with local services by setting this to something like localhost.
  • Several fields, of the TLS connection, allow us to smuggle calls to other services, such as memcache, hazelcast, SMTP, FTP, Syslog and some other services. Some others, such as Redis and SQL, were not to be exploitable. The craziest part, is that this attack is also possible from the browser with IMG tags!
  • When can this technique be used? First, you need a SSRF vulnerability. Secondly, the client needs to cache TLS sessions (Java, Google Chrome, WebKit, Curl, iOS, Android and Axios all cache these connections, while Python Requests and Firefox do not). Thirdly, a target must be known and attackable on the local network. Fourth, output TLS connections must be allowed (essentially, firewall does not block them).
  • There is more work to be done! Different attacks, such as NAT pinning, internal HTTP servers and DoS's, which all were not discussed here.