Almost all companies, be it a giant multinational or a small startup consisting of just a small team, needs to secure their confidential data. And they do, more or less. They use all the traditional ways of protecting their data, install firewall softwares, anti-virus and anti-malware packages. They buy expensive sophisticated hardware that claims to guard their data while they sleep peacefully at night. But are they really secure? Do these companies realize their weakest link in the chain?Yes, it’s the users. No matter how much you invest on different softwares and hardwares for security, it’s useless until and unless the users are aware of how to use them. They must be guided properly and provided with all the knowledge, as to what they must do on their end, and how much are they responsible for keeping the company’s data secure and private. And it’s not only the IT people and the system administrators who are responsible. It is the responsibility of each and every user of the company, be it in management or sales or any other department.
The softwares and the hardwares used to protect the organization, are just dumb machines, with no intelligence of their own. They follow simple rules what they are programmed to follow and don’t see anything above it. Moreover they are made by humans only, which means that they are limited by the intelligence of the person, or the team who designed it. It is quite possible that more intelligent people or a group of people exists, that can see the flaw of that security mechanism and exploit it. That’s why they say that no system is 100% secure.
Here we are going to see a demonstration of an ignorant and careless user who, ends up losing his sensitive information to the attacker, even though the company he works is well protected by firewalls and anti-virus softwares.
THE SCENARIO
The victim is in a company which has all kinds of security mechanisms. They have firewalls installed at their company’s gateway. All workstations are running windows operating system. They have anti-virus software installed at all their workstations. The victim has a Gmail account, which is SSL enabled. The gateway is the company’s DHCP server and DNS server. All the company’s workstation are behind the firewall and NAT.
The attacker has setup a server that will form the base machine of the entire attack. This machine is having a public IP and is unknown to the company’s firewall, and so not blocked by it.
The attacker’s aim is to get the victim’s Gmail account password. So he will be using a Man-in-the-Middle attack on the victim to get his password.
This whole attack is a step-by-step process. So let’s now look at the first step.
DNS SPOOFING
Everyone relies on DNS for web browsing and so does the victim. The first step needed to perform a MitM attack is to redirect all the victim’s traffic to the attacker’s server. This can be achieved by DNS spoofing. The attacker will alter the victim’s primary and secondary DNS address into his server’s address. In this way whenever the victim’s wishes to open any website, his DNS query will reach the attacker every time. Now not only will the attacker know about all the websites he surfs but also he can provide the victim with any DNS response as he wishes. In this case the attacker will provide him with his own server’s address. But how can he spoof the victim’s DNS addresses?
There exists a host file [11] in windows that contains a list of IP addresses of certain domain names. This file is first checked for the IP address of any domain name that the user wants. If it contains the address, it does not need to look any further. Now the attacker can go ahead and try to plan to spoof some of his desired entries in the host file, but that would simply give the attacker control over a small list of websites that the victim surfs. He needs even greater control.
In windows we can run a command in the command prompt that can change the primary and secondary DNS address of the computer [1]. It is -
netsh interface ip set dns name="Local Area Connection" static a.b.c.d
netsh interface ip add dns name="Local Area Connection" a.b.c.d index=2
The name=“Local Area Connection” is the default local network adapter name in windows machine which no one bothers to change. The IP address a.b.c.d is the attacker’s IP address. Now the attacker can put these two commands in a batch file with extension *.bat. So you just have to double click the batch file in order to execute these commands. But the attacker still has to make the victim run this file.
The attacker will now use another trick known as exe binding [2]. What he does here is that he binds this batch executable file with any other executable setup file of any legitimate software. He can also bind this file with any image, pdf, mp3 or even movie file. This way he can bind it with the movie clip of the latest upcoming film or an mp3, and email it to the victim. So as soon as the victim opens this file, those two commands will run in the background and the DNS address will be changed without even him noticing.
The user will rely on the anti-virus in his computer to catch any suspicious file, but the anti-virus won’t catch those commands as they are normal commands and not any kind of harmful virus or Trojan. So the user is likely to open that file.
Now the first step is successfully completed. The attacker now has spoofed the victim’s DNS and all his DNS queries will be sent to the attacker’s server. It’s time for the attacker to perform the second step.
SETTING UP THE PROXY.
The attacker now has all the victim’s DNS queries. In order to further exploit this, the attacker will need to setup a proxy server. What he will do is that, he will respond to all the DNS queries from the victim with his own IP address. So no matter what website the victim wants to surf, it will be pointed to the attacker’s server only. So the attacker needs to setup a software proxy in his server, which will communicate with the actual server that the victim wants to communicate, and send response and request back and forth between the victim and the actual server. In this way the attacker has now successfully performed the MitM attack on the victim computer. He can now monitor all his activity passively or can even tamper with it to his will. The victim doesn’t even have the slightest of idea about what’s going on.
But here’s another problem- the attacker needs to crack the victim’s Gmail’s Password, and all of the communication with the Gmail is via the SSL channel which is encrypted. So even if the attacker can now monitor that communication, he won’t be able to figure out the password.
SSL BACKGROUND
SSL (or changed to TSL now) is a way creating a secure channel over insecure network for data communications. SSL can work over HTTP, SMTP, IMAP, FTP and many other such protocols.
Figure 2. SSL Working
The process shown in Figure 2, basically works as follows
1) The client browser connects to http://mail.google.com on port 80 using HTTP.
2) The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
3) The client connects to https://mail.google.com on port 443.
4) The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
5) The client takes this certificate and verifies it against its list of trusted certificate authorities.
6) Encrypted communication ensues.
2) The server redirects the client HTTPS version of this site using an HTTP code 302 redirect.
3) The client connects to https://mail.google.com on port 443.
4) The server provides a certificate to the client containing its digital signature. This certificate is used to verify the identity of the site.
5) The client takes this certificate and verifies it against its list of trusted certificate authorities.
6) Encrypted communication ensues.
If the certificate validation process fails then that means the website has failed to verify its identity. At that point the user is typically presented with a certificate validation error and they can choose to proceed at their own risk, because they may or may not actually be communicating with the website they think they are talking to. A proper web browsing client will warn the user of a certificate problems if any of the following are not true [5]:
• the certificate has been signed by a recognized certificate authority
• the certificate is currently valid and has not expired
• the common name on the certificate matches the DNS name of the server
THE FINAL ATTACK
Now the attacker has two ways to perform his final attack.
One way it could be done is when the victim tries to open Gmail website with simple http. Soon as that is intercepted by the attacker, he would continue to communicate with the victim in plain text, but communicate with the Gmail server with https. So the attacker would be doing all the formalities of exchanging the certificates and all on the behalf of the victim, but with the victim he would use http connection only. This way he could easily get the victim’s Gmail password. Here the victim wouldn’t notice much difference other than the http (instead of https) showing in the URL.
But what if the victim does not start his communication with http but directly opens https? In such a case the attacker would have to perform the following.
The attacker will now setup a software server that is capable of creating spoofed certificates (a software tool named DeleGate [8] can be used here).
So when the victim tries to connect to Gmail and asks for a valid certificate, the attacker will send him a spoofed certificate. Following this, will be a warning generated in the client’s web browser for an unrecognized certificate. Studies and researches show that majority of users ignore such a warning by the browser and decide to continue further [6] [7]. So does our victim. Now all communications between the user and the attacker will be done by the public key send by the attacker to the victim. But the attacker will communicate with the legitimate key given by the Gmail server on behalf of the victim.
Figure 5. Delegated- a closer look [9]
All activity and web browsing experience from the victim’s perspective would be very smooth except for the initially certificate warning, which has been happily ignored by him.
CONCLUSION
So finally after following a series of steps, the attacker successfully got the Gmail password of the victim. Here we saw how the attacker first spoofs the victim’s DNS address. Then he sets up a proxy server and let the victim communicate on the internet via his server, performing a Man-in-the-Middle attack. Then even though the victim’s communication is supposed to be via a secure channel, the attacker gets his Gmail Password.
So finally after following a series of steps, the attacker successfully got the Gmail password of the victim. Here we saw how the attacker first spoofs the victim’s DNS address. Then he sets up a proxy server and let the victim communicate on the internet via his server, performing a Man-in-the-Middle attack. Then even though the victim’s communication is supposed to be via a secure channel, the attacker gets his Gmail Password.
The above scenario is not limited to only this kind of attack. This is just a small demonstration out of many other possibilities. Attacks like these can be tailored in order to fulfill the requirements of the attacker. Here we have just shown that the attacker gets the Gmail password of a company user, but it could also be modified a little and performed in order to get other sensitive information.
This attack just proved that despite of the best efforts and expenditure done by the organizations to secure their company, it’s finally the user’s responsibility that plays a major role in the overall security of the organization. Every user in the organization must be properly educated about such security issues, what role they must play and their responsibilities to the overall company’s security.
REFERENCES
[1]http://tweaks.com/windows/40339/configure-ip-address-and-dns-from-command-line/
[2]http://paragtyagi.blogspot.com/2011/09/how-to-bind-exe-files-to-keep-your.html
[3]http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html
[4]http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
[5]http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480
[6]http://news.cnet.com/8301-1009_3-10297264-83.html
[7]http://static.usenix.org/events/sec09/tech/full_papers/sunshine.pdf
[8]http://www.delegate.org/delegate/
[9]http://www.securitytube.net/video/1782
[10]http://support.isoc.net/Page.aspx/117/hosts.html
[2]http://paragtyagi.blogspot.com/2011/09/how-to-bind-exe-files-to-keep-your.html
[3]http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part4.html
[4]http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part2.html
[5]http://www.sans.org/reading_room/whitepapers/threats/ssl-man-in-the-middle-attacks_480
[6]http://news.cnet.com/8301-1009_3-10297264-83.html
[7]http://static.usenix.org/events/sec09/tech/full_papers/sunshine.pdf
[8]http://www.delegate.org/delegate/
[9]http://www.securitytube.net/video/1782
[10]http://support.isoc.net/Page.aspx/117/hosts.html
Contact : mufaddal@rawbytes.com
No comments:
Post a Comment