Attacks targeting proxy servers

Can a proxy be hacked?

Proxies are quite popular among users, especially among those who want to hide their real IP address or bypass blocking access to a web resource (by the owner or by government censorship).

Related article: Configuring programs and operating systems to work through a proxy

At the same time, thoughtless use of a proxy can lead to an unexpected result for you. For example, from the article “Proxy types, how to use proxy, how to check the quality of proxies”, you should have learned that there are proxies that are not anonymous by definition – they send the user's IP address in HTTP headers.

In the article “How to create and configure a Squid proxy server” we learned how to configure our own proxy servers, with access control by password and/or by IP address. The question may arise, how secure is the transmitted proxy server password? If the password can be intercepted and/or decrypted, then this can lead to the fact that unauthorized persons will use your proxy server.

I'm getting ahead of myself and say – everything is very bad with the transmitted password, it is transmitted almost in the form of plain text. Will using HTTPS proxy server help with password protection problem? What other attacks are possible against the proxy server? Looking ahead, I will say – everything is bad. Therefore, if you are setting up your proxies, then you should read this note and take action.

In short, all problems with the security of proxy servers go back to Basic and Digest authentication, which is usually used on them; and HTTPS proxies are no safer in this regard. Therefore, it is recommended to start with the article “How to hack HTTP Basic and Digest Authentication”.

Man-in-the-middle attack against proxies

Objective: to check to what extent the proxy server is susceptible to password interception, and also to check how secure the HTTPS proxy is. Check the possibility of downgrading the connection through the proxy server from HTTPS to HTTP.

To do this, we will perform a man-in-the-middle attack against a test computer where the user is using a web browser connecting through a proxy server. Similar risks arising from a man-in-the-middle attack can be when using public Access Points; Access Points without passwords; on the exit nodes of the Tor network that record traffic; when traffic passes through any network nodes looking for unencrypted data, including through the nodes of Internet service providers.

So, to see the difference, on the test machine, the web browser is configured to use only an HTTP proxy (and HTTPS requests go directly and are not of interest to us).

To perform a man-in-the-middle attack, we will use bettercap. See also the article “bettercap 2.x: how to install and use in Kali Linux”.

Launch bettercap:

sudo bettercap

We look at the available devices on the local network and launch their automatic detection:

net.show
net.probe on
net.show

The test computer has an IP address of 192.168.1.34, we launch an ARP spoofing attack against it, due to which the victim computer will consider that now the attacker's machine is the gateway (router) and the victim's computer network traffic will be routed through the attacker's computer:

set arp.spoof.targets 192.168.1.34
arp.spoof on

Let's set up saving traffic to the http-proxy.pcap file (for further analysis) and start sniffing:

set net.sniff.output /home/mial/http-proxy.pcap
net.sniff on

Let's wait until any site is opened on the test computer through a proxy server.

Let's open the http-proxy.pcap file in Wireshark and use the following filter:

http.proxy_authorization

You can see the string passed as plain text:

Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn\r\n

The web server uses Basic authentication, from the article “How to hack HTTP Basic and Digest Authentication” you can remember that the passed string is the username and password from the proxy server, encoded in Base64.

To decode, use the following command:

echo cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn | base64 -d

Output:

proxy_user:LkdfLl5kj7Leg

In this line, proxy_user is the username and LkdfLl5kj7Leg is the proxy password. That is, despite the complexity of the password, it is very easy to intercept and decrypt it.

Now on the test computer in the web browser, we remove the HTTP proxy settings and enable the HTTPS proxy. The idea is that HTTPS implies encrypted connections and, perhaps, the password will not be transmitted in the plain text.

We configure to save the captured traffic to the https-proxy.pcap file, for this we restart sniffing:

net.sniff off
set net.sniff.output /home/mial/https-proxy.pcap
net.sniff on

Let's open the https-proxy.pcap file in Wireshark and use the filter again:

http.proxy_authorization

As you can see from the screenshot, the HTTPS proxy also transmits the password in plain text.

There is a difference between HTTP and HTTPS proxies, but not in the authentication process – in any case, the password is transmitted in plain text.

To clearly see the difference between HTTP and HTTPS proxies, let's use bettercap filters. In Wireshark, you can see the line:

Transmission Control Protocol, Src Port: 54882, Dst Port: 18008, Seq: 1060, Ack: 13141, Len: 414

That is, the port of the proxy server is 18008. In the screenshots above, you can see the IP address of the proxy server.

To filter only requests through a proxy server, set the appropriate filter (for the setting to take effect, we need to restart sniffing):

net.sniff off
set net.sniff.filter "host 157.245.118.66 and port 18008"
net.sniff on

This is a request through an HTTP proxy server:

That is, the attacker can see everything – what data is transmitted and what is received, cookies, logins and passwords – absolutely everything.

And this is a request through an HTTPS proxy server:

That is, from the transmitted data, the attacker can only see the name of the remote host and the User-Agent of the user, the rest of the data is encrypted.

But in any case, in each request a string is transmitted containing the login and password from the proxy, which the attacker can intercept:

Proxy-Authorization: Basic cHJveHlfdXNlcjpMa2RmTGw1a2o3TGVn

That is, there is no need to downgrade the connection through the proxy server from HTTPS to HTTP to intercept the password from the proxy.

To stop the attack correctly, run the commands:

net.sniff off
arp.spoof off
exit

How to protect against interception of the proxy server login and password

1. Never use Basic authentication

If you are setting up a proxy server yourself (see the article “How to create and configure a Squid proxy server”), then do not use HTTP Basic authentication, use HTTP Digest authentication instead.

With Digest authentication, the password is never transmitted in plain text. But at the same time, it should be remembered that hashes and other data are transmitted in the Authentication Digest in the form of plain text, by intercepting which one can brute-force password. Therefore, the password must be quite complex.

2. Use a VPN instead of a proxy server

As you can see in the screenshots above, the nodes through which your traffic passes (for example, your ISP) can see a lot of the requests you send. This problem can only be solved by full traffic encryption that a VPN can provide. When using a VPN, an eavesdropper can only see a stream of encrypted, completely unreadable data between your computer and the VPN server.

For authentication, VPN servers use keys and a mechanism that prevents the interception of user credentials.

See also: How to set up OpenVPN server and clients

Wireshark filters to analyze traffic through a web proxy server

Since “proxy” is a generic name for many technologies and software, not all Wireshark filters with the word “proxy” in their name are applicable to web proxies.

For example, the PROXY filters page https://www.wireshark.org/docs/dfref/p/proxy.html contains filters, none of which apply to web proxies.

The page https://www.wireshark.org/docs/dfref/s/socks.html contains filters for SOCKS proxies, also not applicable for web proxies.

These two filters, although they should (as the name suggests) relate to HTTP proxies, did not find anything in my tests:

http.proxy_connect_host
http.proxy_connect_port

Let's consider Wireshark filters for analyzing traffic through a web proxy server (HTTP and HTTPS proxy).

This filter will show requests from the proxy for HTTP Digest authentication:

http.proxy_authenticate

This filter will show the credentials sent by the client to the proxy server for authorization:

http.proxy_authorization

Show requests made through a proxy server (HTTP CONNECT method):

http.request.method == "CONNECT"

Since web proxies use HTTP Basic and Digest authentication to authenticate users, you can use the appropriate Wireshark filters. All authentication sessions (BASIC/DIGEST/NTLM):

http.authorization

HTTP Basic authentication only:

http.authbasic

HTTP Basic only authentication with specific credentials:

http.authbasic == "LOGIN:PASSWORD"

Digest Authentication Request from Proxy:

http.proxy_authenticate contains "Digest"

User response sent to the proxy server with information for Digest authorization:

http.proxy_authorization contains "Digest"

See also: Wireshark Filters

Online brute force proxy credentials

The methods described for Basic and Digest are applicable to brute-force login and password, so for details, see the section: How to Brute-force HTTP Basic and Digest Authentications.

Cracking proxy password hash

The methods for cracking proxy server hashes are the same as described for Basic and Digest:

• How to crack an HTTP Basic hash
• How to crack the HTTP Digest hash

Is it dangerous to use other people's proxies?

If you are using proxy servers from “good people” whose IP and port number were just found on the Internet, then you need to be absolutely clear about the risks of this.

First, all data transmitted in clear text is visible to the proxy owner. It was in this simple way that many of the password databases from social networks were collected. Now, when many sites have switched to HTTPS, cybercriminals can only see from the transmitted data: 1) the name of the host to which the request is made; 2) IP address of the user who made the request. And again, the data transmitted in plain text is fully visible.

Secondly, unencrypted traffic transmitted through someone else's proxy can be modified in any way: inserting ads, executing attacks, and so on.

By the way, everything said in this section applies to paid proxy servers (if you paid someone for a proxy, this does not mean that he cannot filter passwords from your traffic or simply be interested in what you are doing).

And this also applies to public (and paid too) VPN servers. In the comments to one of the articles, one tried to convince me that “VPN traffic is encrypted”. Yes, it is encrypted, right up to the moment when it comes to the VPN server, and on the VPN server it is decrypted. And everything that is transmitted in plain text is available to the VPN server for analyzing and extracting passwords and other data.

When using other people's proxies and VPNs, you need to understand that their main “providers” are hackers who filter interesting data from your traffic, and information security specialists who investigate hacker attack methods and their targets.

If you pay for a proxy or VPN, this does not mean that all of the above cannot happen on them, no matter what is written in the user agreement.