Tag: proxy

Proxy Protocol Verification

Any circuit level tunneling through a proxy server such as SOCKS or SSL, will allow most protocols to be passed through a standard proxy gateway. Whenever you see a statement like this, you should remember that it implies that the protocol is not actually understood but merely transparently transmits it. For instance, the popular tunneling protocol SSL is able to tunnel virtually any TCP based protocol without problem, it’s often used to add some protection for weak protocols like FTP and Telnet.

But it can create a little bit of a headache for a proxy administrator. Not only can all sorts of protocols be allowed access to a network but often the administrator has no knowledge of the contents due to encryption. There are some short terms solutions which will provide a limited amount of protection - for example blocking access based on port numbers. That is only allow specific ports to be tunneled such as 443 for HTTPS, 636 for secure LDAP. This can work well but remember some advanced security programs like Identity Cloaker allow the configuration of the port, allowing protocols and applications to be tunneled on non standard ports -a bit like a proxy unblocker . It is therefore not an ideal solution and one that cannot be relied upon in the longer terms to keep a network and proxy secure.

The obvious solution of course is to utilise a proxy server that can verify the protocol that is being transmitted. This requires an awful lot more intelligence built into the proxies but it is possible. It does require a bigger overhead, it does make the proxy server more expensive and perhaps more complicated and trickier to manage. However without this sort of intelligence or something similar you will get the possibility of an FTP session being set up through an SSL tunnel for example.

In some ways proxies already do some of this, and protocols that are proxied rather than tunneled at the application level cannot be exploited like this. Examples include HTTP, FTP and even Gophur cannot be used to trick entry, simply because there is no ‘dumb’, direct tunnel the proxy understands and will only relay legitimate responses.

Identity Systems - Distributing Authentication and Authorization

Any identity system which is automated needs some way of both creating and distributing authorization and authentication assertions. One of the most famous is of course Kerberos, which has it’s own methods for dealing with this requirement. However many digital systems are now starting to use SAML - the Security Assertion Markup Language - it’s becoming the de facto security credential standard.

SAML of course uses XML as a standard to represent security credentials, but it also defines a protocol for requesting and receivfing the credential data from an authority services (SAML based). One of the key benefits to SAML is that using it is pretty straight forward, this fact alone has increased it’s usage considerably. A client will make a request about a subject through to the SAML authority. The authority in turn makes assertions about the identity of the subject in regards to a particular security domain. To take an example - the subject could be identified by an email address linked to it’s originating DNS domain, this is just one simple example though.

So what exactly is a SAML authority? Well it is quite simply a service (usually online) that responds to SAML requests. These SAML requests are called assertions. There are three different types of SAML authorities which can be queried - authentication authorities, attribute authorities and policy decision points (PDPs). These types of authorities all return distinct types of assertions -

  • SAML authentication assertions
  • SAML attribute assertions
  • SAML authorization assertions

Although there are three different definitions here, in practice most authorities are set up to produce each type of assertions. Sometimes in very specific applications, you’ll find an authority that is designed to only produce a specific subset but this is quite rare especially in online applications - although they’re sometimes used as proxy authorisation - see this. All of them contain certain elements however like IDs for issuers, time stamps, assertion IDs, subjects including security domains and names.

Each SAML attribute request will begin using a standard syntax - <samlp:Request…..> - the content then would refer to the specific parts of the request. This could be virtually anything but in practice it’s often something straight forward like asking which department or domain an email is associated with.

Source : Sam Wilkin - IT Consultant

 

Capturing Authentication Credentials

There are many issues with using proxy servers, however one of the biggest concerns is those which use basic authentication. It is extremely important that a proxy configured with such authentication does not forward the Proxy_Authorization: header to any origin server. If this happens it is a simple task to intercepts this header, gain access to the user’s name and password and ultimately access to the proxy server itself. Basic Authentication does not involve encryption so they are transmitted in clear text so are exceptionally vulnerable.

 

It might be that this user name and password allows minimal rights however there is a much bigger issue. Many users, will reuse their username and password for other functions. The password that allows minimal access to an unimportant proxy server will often allow access to the users email, online banking and Paypal account. Identity thieves always value usernames and passwords of any sort even on unimportant services like forums, the reality is that they often allow access to more important services.

Although you can stop authentication credentials for the proxy being forwarded on, this does not apply to usernames and passwords intended to the final destination. In fact this is the reason many hacked proxies are made available online by hackers - they want to intercept your credentials. This is why people who constantly searching for new proxies are putting themselves and their personal data at great risk. They may think that they saved themselves a few bucks by relaying their connection through an Australian proxy to watch ABC iView, but in reality they may actually find their bank account cleared out by the administrator of the server.

In reality there is no practical solution to protecting your data via an untrusted proxy server. Even using SSL does not completely help as there are various MiM attacks on SSL sessions which can be implemented if you can manipulate the connection via a proxy server. The only solution is to never use a third party untrusted proxy server for anything

Source : http://www.theninjaproxy.org/tv/a-fake-uk-ip-address/