Pwning the proxy

1. Pwning the proxy

2. Contents • Who are we? • What are we talking about ? • Internal proxy dangers • High speed bruteforcing • HTTP authentication headers – say what? • Case study, SARG gyaaaaar • Port scanning through misconfigured reverse proxies

3. Who are we? • Charlton Smith Loves Hooters Loves Teazers Loves Canada Regular presenter and trainer at international conferences. Senior Security Analyst at Telspace Systems • Dino Covotsos Loves the same things Charlton does. Regular presenter and trainer at international conferences. Founder and CEO of Telspace Systems

4. Who are we (Telspace Systems)‏ • Information Security Company – South Africa • Operating since 2002 • Giving back to the open source community – responsible reporting and disclosure (latest advisories)‏ • Speak at local (.za) and international conferences, such as Hack in the Box, SecTor and many others. • Provide worldwide training courses on high level topics

5. What are we talking about? • Why proxies? • What issues are brought about by Internal proxies, and proxy tools? • Social engineering factor • Examples of attacks used in penetration tests. We will also show a “0day” XSS (persistent) vulnerability in SARG • Quick and easy way to credentials, with local bruteforcing • What can we do to better protect our networks from these attacks?

6. Why proxies? • Proxies can control all HTTP traffic as well as other services traffic on a network. • Lots of sensitive information passes through proxy servers, such as credit card numbers, banking details, passwords and emails details. • Once a proxy server is compromised, a user can easily compromise a the network through eavesdropping. • Just as Swedish computer security consultant Dan Egerstad obtained and posted the usernames and passwords for 100 e-mail accounts used by the victims that used his proxy.

7. Why proxies? • Because , as you know, the major threat is from the inside of the company or organisation. • Ask yourself what percentage of attacks are from the inside? • Besides, it only really takes one user account to gain an entrance point to a network… (OWA/VPN/Proxy/local logins/ADSL etc – these help to different degrees)‏

8. Internal proxy dangers • Any services making use of some form of authentication provide a possible point of entry and enumeration of users. • Proxy authentication is no different. Once a user is authenticated he is granted access to the network. In addition, sometimes a user is ”automagically” provided proxy credentials once they have logged in to a PDC or similar (This works both ways ;) ). • Local proxys allow for high speed account bruteforcing.

9. Internal proxy dangers • We want quick attacks, fast access to multiple accounts. The attacker wants a quick entrance and exit. • The attacks can be done from a wireless network (or a compromised wireless network). Lets change our mac address and do some brute forcing… great… • In addition, How many times have we gained access to free wireless internet by finding an open proxy (pay for use internet access). • Boardroom surfing is common in Pentests, so are other areas, this allows for some basic time to launch the attacks on the proxy servers.

10. Internal proxy dangers • Many of the services that go with internal proxies allow for a number of other points of attack. • An example, SARG, which has had a buffer overflow vulnerability in the past • Credential theft is possible with a number of methods we will discuss. • Credential stolen from these methods can be used to further access on many other systems (N.B). • Oh, lets not forget about all the previous vulnerabilities with internal/external proxy servers. Including ISA, Squid and so fourth.

11. Internal proxy dangers • Even transparent proxies have their issues… SSO and so fourth allow access to browsing through a internal proxy as soon as a user signs on… via PDC etc… • So, that’s fantastic, let’s compromise just 1 login on the network (possibly via owa, social engineering etc)‏ • We can now browse and launch further attacks using your network. Anyway…

12. Proxy authentication • The user will first make a request, the proxy server will then return an error saying authorisation is needed to use the proxy. The error might look like something like this: X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0, along with some other information about authentication. • The user’s browser will then prompt for a username and password and this will then be encoded by the browser, and sent off to the server. • The password will be sent back to the server in the proxy-authorisation header. • Obviously if it is the correct password the user will be allowed access.

13. Proxy authentication • Authorisation response from user:

14. Internal proxy dangers • Bruteforcing local internal squid/ISA proxy accounts • Because the account is local, it can allow really quick password bruteforcing, depending on how you attack the authentication. • Often companies use single sign-ons, which means access to multiple severs/services can be gained very quickly. This allows for more entry points. • We have written a proof-of-concept script that identifies the type of authentication being used and the type of server, and attempts to bruteforce from there. • The script can use single username or multiple usernames from a wordlist.

15. Internal proxy dangers • Bruteforcing local internal squid/ISA proxy accounts • Logging systems for proxy servers often log different information and have different lockout policies in comparison to OWA and so fourth. • If they don’t…… fantastic, lets lock out user accounts or even the entire organisation. • Individually, This can aid in social engineering attacks to helpdesks (“Hi my account is locked out, please help”).

16. Internal proxy dangers • Coded in PHP. Windows and linux compatible. • Our “l33t” Proxy bruteforcer in action:

17. Internal proxy dangers • Source:

18. Social Engineering • Attacks don’t necessarily have to be very advanced. It’s often the simple things that get the best results. Users are easily fooled! • This trick works about 9 out of 10 times, and can be done locally or remotely. • It’s really simple. It works by tricking the user to visit a site, then by imitating the proxy login, the user is tricked into re-entering his proxy credentials.

19. Social Engineering • The username and password will then be stored. The user can be forwarded to another server or legitimate website after the attack is completed. Unknowingly having their credentials stolen. • So for example if you use this attack in conjunction with DNS rebinding(Kudos to Dan Kaminsky TM) or the new DNS spoofing vulnerabilities attacks like this can be very affective into tricking the user into giving you credentials • Many corporations in our testings have not applied the relevant patches to protect themselves from these attacks. • This obviously defeats any l33t encryption used by the proxy server. Hacker gains credentials.

20. Social Engineering • Fake login:

21. Social Engineering • There are a couple of ways to create the fake popup box. It can be done with client-side scripting (javascript).which will make a authentication box pop up. You can even create basic custom code to create one. • Another client-side attack method comes from using the pop up form-box, as it is not possible for a javascript prompt box to have more than one input field. A box resembling a login box is used, and the page then forwards the credentials to a script that stores the information.

22. Social Engineering • More information about dialog can be read up on this url: http://developer.yahoo.com/yui/examples/container/dialog-quickstart.html • This can be tricky in the sense that some knowledge of the users browser and themes installed on his browser. • However many times the user will still enter their credentials, due to human nature.. and they really wanna see the dancing monkeys.

23. Case Study • In this specific instance, we needed a login to a different web service running on the proxy server. We knew that the login to this service used SSL so a ‘man-in-middle’ attack was out of the question. • However, we did know that the service used cookies that stored passwords in MD5 hashs. • We decided to see what other services were running on the server.

24. Case Study • There weren't many services running, but we knew SARG was running on the box and generating reports on a daily basis. • Therefore, We decided to play around a bit with SARG and the sourcecode. • From here, we discovered that download.c doesn’t correctly remove html characters, allowing for a persistent XSS vulnerability. • As you know, Cross site scripting vulnerabilities can create havoc, even if they seem small (i.e. this will allow us another entrance point to the network).

25. Case Study • We could see that the server would place any file in the download listing if it ended in .exe (and many other extensions) even if the file did not exist (this is in the reports themselves). • This would mean that if we requested a URL with our XSS in it would be stored on the download page. • We sent the malicious XSS request (that would steal the admins cookies on the server), and waited for the SARG reports to be generated and for the admin to check the download listing. • We also crossed our fingers that the administrator was logged into the other service at the same time, which was running on the targeted box.

26. Case Study • Our script injecting our code:

27. Case Study • Source:

28. Case Study Bookah?

29. Account hijacking • Many proxy servers don't implement account restrictions, such as only allowing a single IP to access an account. • This can allow users to browse restricted sites under another users compromised accounts (which is done all the time). • Malicious downloads can be performed on other users’ accounts, i.e. lets try get someone in trouble… we’ve seen this being done before. • To fix this issue each account should be assigned an IP address restriction.

30. Scanning through reverse proxies • If the reverse proxy server is not correctly configured, a user could use GET requests to check for open ports behind the proxy. • In the same manner, this can allow for enumeration of hosts on the network. (i.e. GET requests for internal address)‏ • To detect if a website is behind a proxy server, a user can send a TRACE request. • This was placed in HTTP 1.1 as a debugging feature. It just tells the server to reply the contents just as it had received them. • Fortunately for us, this can be used to reveal a reverse proxy server.

31. Scanning through reverse proxies • If a server is behind a proxy the trace reply should look like this:HTTP/1.1 200 OKServer: Microsoft-IIS/5Content-length: 80TRACE / HTTP/1.1Host: www.example.comVia: 1.1 10.20.1.2

32. Scanning through reverse proxies • If the request is forwarded via a reverse proxy, the returned content should contain a header similar to one of the following: • “X-Forwarded-For” • “VIA” • “Proxy-Connection”

33. Scanning through reverse proxies • The usual request for a server through a proxy will look something like this:GET http://www.site.com:80/ HTTP/1.1 • In many cases you will be able to check internal hosts by sending the following request:GET http://192.168.0.1:80/ HTTP/1.1 • Now it is also possible to scan ports like this:GET http://192.168.0.1:21/ HTTP/1.1

34. Scanning through reverse proxies • We have written a tool for this, but a great tool already exists for this is, which is proxyScan. • The tool is written in Perl and contains funtionallity for not only enumerating hosts, but also doing the port scanning. • This is all done using the same methodologies explained before.

35. Scanning through reverse proxies

36. Scanning through reverse proxies • proxyScan.pl currently supports the following options: Options: -h --help this message. -v --verbose be verbose for debugging. -p --ports ports to scan for.Example: 80-90,8080-8090,443,23,22 -t --targets target hosts to scan for through proxy. Default is localhost. -o --timeout timeout in seconds to wait for a response. default is 2 seconds -d --delay delay in seconds between requests. Default is 0.5. -m --method request method (CONNECT/GET/OPTIONS/TRACE/etc)‏ Default is GET -x --proxy proxy server. default is localhost:8080

37. Scanning through reverse proxies.

38. Remediation • It is strongly recommended that basic authentication is not used for proxy authentication. • A strong complex password is essential. • Be weary of suspicious sites, and even machines on your local network that ask for your proxy username and password. Try check on another site if you are already authenticated. • People nee to be more careful with lockout policies. • Accounts should not be available to all users, only certain IPs should be able to access certain accounts.

39. Thanks • A huge thank you to SecTor for giving us the oppurtunity to present at this prestigious event. • All the sponsors and attendees of SecTor, if it wasn’t for you… • Ed Blanchfield (http://www.e-things.org/) – creater of proxyScan. • http://www.liquidmatrix.org/blog/ - For the feedback • Telspace Systems research team

40. Bibliography • http://developer.yahoo.com/yui/examples/container/dialog-quickstart.html • Proxyscan: http://www.e-things.org/download/proxyScan-0.3.tgz • Telspace systems: www.telspace.co.za

41. Bibliography Q & A Web: http://www.telspace.co.za Blog: http://0mghax.blogspot.com