My first day in Dubai, I went to lunch with one of the executives of the Telco.  During our lunch, I asked him how they manage encrypted connections.  He explained that they were currently getting ready to deploy a solution to solve that.  The infrastructure was being upgraded to decrypt all SSL sessions and parse the data as required.   Aside from opening my eyes to the difference in privacy between North America and the Middle East from a privacy perspective, I found it interesting that SSL decrypting was so easily available.   Previously, I had seen software that law enforcement used for this purpose.  I myself had done it for clients using available tools during a engagement.  But these tools were designed more for targeted surveillance, not mass scale.  Like all technology, it improves and gets less expensive over time I guess.

Today, there are many more companies in North America and abroad that either have deployed SSL decrypting capabilities or are in the process of doing so.  Security, diagnostics, audit and legal requirements to know what is coming and leaving their networks and being able to log and trace back data transmissions to the originator are some of the reasons.  One driver is Data Leakage Protection (DLP), currently a very ‘hot’ topic with many new vendors jumping on the opportunity with solutions.  In order to look for data leakage, you need to see past any encryption that might be present.  Cisco, Bluecoat, PaloAlto, Fortinet are just a few companies that offer products for SSL decryption.

With Google deploying encryption for Gmail and more recently searching, plug-ins such as the EFF Firefox plug-in to help secure your communications, companies are feeling more and more concerned about what data is coming and going.  What worries me is that all these security, legal and audit requirements companies face are actually not helping them in the long run.   If these companies are decrypting SSL sessions that egress and ingress their network, you can be sure that other companies are doing the same to theirs.  The net result is that everything is decrypted and no one has any privacy.

Next time you connect to your bank, doctor’s office, insurance company, Gmail or any site and see secure indications from your browser similar to these

along with the companies re-assurances that the site is secure, keep in mind things may not be as they appear – today even more so than yesterday.

Do you deploy any type of decryption on your network?  If it is deployed are you aware of it?

photo credit

There is a need to ensure audit compliance across the entire banking infrastructure.   From a financial perspective, compliance with the various audits is a must if you wish to stay in business.  Of course, my background is in network security.  Network security is not the same as auditing.   Although I have not met anyone that would say if you pass a particular set of audits you are secure, I have noticed across the audit industry in general there seems to be a unstated understanding that if you do pass audits you are secure or more secure than if you don’t.

Passing an audit does not mean you are secure.  Here is one of a few, but simple examples I have come across.  One of the audits requires that your entire internal network has address translation from inside to outside.  Effectively, the idea is that if I as a outside user browse to http://michaeldundas.com, that address would appear to the requester as 216.240.0.43.

From the quick diagram above, you can see how the client thinks that it is directly connected to 216.240.0.43/32, and it is.  Based on the audit requirement of having complete address translation with the untrusted Internet, you would have to configure a device that would convert the IP address the client has, to a different IP address.

The second diagram shows a router configured with Network Address Translation (NAT) to convert the IP address in both directions.  In this way the client does not know the real IP address of the server.   Any attack that you could do without NAT, you can do even if NAT is there.  Anyone that is active in attacking servers knows this.  It offers no additional security, just extra work.

Auditing does have its place and is necessary.  Complying with audit requirements for many industries is not an option and your staff must understand that.  But don’t let yourself or your staff be fooled into thinking audits make you more secure.  Audits help but they are not a substitute for good and proper security.   Passing an audit does not mean you are secure.

I was talking to a individual recently who was involved in an investigation.  They assumed that by using a proxy, the target site would not have an IP address or any other data logged that could link them to the target site.  I explained this is false assumption and why, but it got me thinking about others that may be in law enforcement or corporate security conducting investigations and feel comfortable they are hidden via a proxy service when they are actually exposed.

If a target site wants to detect you, there are many ways it can accomplish this easily, and often they obtain identifying information unintentionally.  Here is a quick and simple example I put together.  First, I shutdown all the servers and clients on my home network except a single computer and the gateway.  On the gateway, I captured all the traffic entering and leaving the network. Next, I configured Firefox to use a SSH proxy.  SSH has the ability to emulate a SOCKS4 or SOCKS5 proxy.  A side note to using SOCKS4 or SOCKS5 is DNS is not proxied.  This is not a concern for this particular investigative scenario, but could be a concern for other investigations, so it is important to be aware of that issue should it become a concern during an investigation.

Firefox was configured to proxy via Socks 5:

Next, I visited a site that hosted the latest Britney Spears video entitled ‘3′.  The page load is shown below.

The initial page loads along with the embedded video player.  Up to this point, the logs show that the packets are ingressing and egressing via the configured proxy server only which is our desired behaviour.

The communication as shown above between the proxy server and the client continues until the video player application loads.  Once the player loads, it first does a DNS request for the the video service.

The player then directly connects to the video service bypassing the proxy at this point you have been identified.   This continues as the audio and video is streamed to the client.

Keep in mind that you may already have been identified through the proxy itself.  It is entirely possible and likely that the website or player has transmitted other information about your system within the RTMP stream itself or even HTTP.  The problem stems from the fact that these embedded objects are in fact executable programs that can bypass the browser and other system settings.

If you are involved in an investigation where you don’t want to be detected by the target, do not assume that by using a proxy you are safe from detection.  There are ways to avoid detection in this way, but they require more sophisticated network and client configuration.  Regardless of your setup and configuration I would suggest always capturing the data transmitted and received.  Even if you don’t analyze every packet, it provides a detailed log of what actually was transmitted and received allowing you to go back and verify if necessary.