Cloud computing may not be as secure as you would like to believe…Vulnerabilities in Azure Part 1

What is “Cloud Computing” you may ask… That is simple, it is using other people’s hardware!

You are renting space on their servers, using their internet connection, using their switches. There is nothing amazing about “The Cloud”, other than you do not own the equipment, you cannot control the physical servers, switches, etc.. Your “Cloud” is only as secure as the company you are hosting your servers/software/services with.

I forewarn you, this post is long. The first part of this article is about a white paper that I wrote about Azure possibly being susceptible to MITM/DOS attacks. The second part will show you how insecure Azure is… in the fact that You can see Virtual Machine Names, IP address and more, using common, easily obtained software…(SEE Part 2!)

Utilizing two free software programs, I was able to get information that anyone with time and inclination could use to do other attacks, not just the MITM / DOS attacks listed below.

How it all started…

Microsoft was giving away free 30 day trial of Windows Azure. I decided I would check Azure for vulnerabilities, so I ran a few test before my trial was up, and this is what I found.

The following white paper I sent to Microsoft at the end of June 2013. After almost two months, Microsoft emailed me back on 8-21-13 and stated “The team came back to me and confirmed that they have DHCP guards in place for v6 and v4 and confirmed that their IPv4 filtering prevents MiTM attacks started from arp spoofing.“

So Windows Azure is NOT vulnerable to Man in the Middle attacks nor Denial of Service Attacks… WELL there Is another problem, which you will see in Part 2…

___________________________________________The Paper _______________________________________________

Concept by:  Daniel Stinson                                    Date: 6-27-2013                               

Windows Azure may be susceptible to Man in the Middle attacks as well as IPv4/ IPv6 Denial of Service attacks from a Virtual Machine residing inside of Azure.

Please note that these attacks were not tested against any machines in Azure, I am showing that from within a virtual machine residing on Azure that it may be possible. No exploits have been run so this is merely a concept paper. This paper is to show that it may be possible, the attack is untested.

I created a clean Microsoft Server 2008R2 virtual machine using a 30 day Windows Azure trial. I installed free software called Evil Foca – 0.1.2.0 on this virtual machine, to check to see if the program was able to see other servers in proximity to the new virtual machine.

I ran the software to see if there were any “Neighbors”, and I was amazed at how many connections that were discovered. The program showed other servers and routers (with IP & MAC address’) that were located near the virtual machine.

I DID NOT run the exploits, however I am certain that MITM (Man in the Middle) and IPv4 & IPv6 DoS (Denial of Service) attacks could be run against these other connections in Azure.

The below image shows active connections close to the virtual machine that were discovered. (full list is presented on the last page)

As you can see in the above screenshot, other connections were discovered. If you add targets in any of the attacks, you are given the option to select your target from the list.

 Types of attacks that could be run against target connections:

 

 

MITM IPv6

-Neighbor Advertisement Spoofing

The attacker sends to their victims fake ICMPv6 Advertisement packets in order to cause that any traffice goes through your IP address.

-SLAAC

The attacker sends to their victims fake ICMPv6 Advertisement packets in order to cause that any traffice goes through your IP address.

-DHCPv6

-The computer acts as a rogue DHCPv6 server, configuring IP Address and DNS Server from clients.

 

MITM IPv4

The attacker sends to their victims fake ARP packets in order to cause that any traffic goes through your IP address.

 

-DHCP ACK Injection

The computer acts as a rogue DHCP Server, configuring the clients to connect to your IP address as gateway.

 

  

DoS IPv6

-SLAAC DoS

It consumes 100% of CPU creating network adapters through SLAAC protocol unit the computer is completely frozen

 

  

DoS IPv4

-Invalid MAC Spoofing

It assigns an invalid MAC address to an IP poisoning his ARP cashe, so the target will lose connection with any arbitrary computer

 

DNS hijacking or DNS redirection

Is the practice of redirecting the resolution of the Domain Name System names to other DNS servers.

Used in conjunction with MITM attack.

  

Connections discovered in Windows Azure from a freshly made clean Virtual Machine:

(MAC and IP Address)

00155D36C783	00155D36C78F	00155D36C79B	00155D36C7A9	008CFA0BA734
100.86.166.3	100.86.166.16	100.86.166.29	100.86.166.45	100.86.166.170
00155D36C782	00155D36C790	00155D36C79C	00155D36C7AC	008CFA0BCB42
100.86.166.2	100.86.166.17	100.86.166.31	100.86.166.48	100.86.166.180
A44C11350741	008CFA0BA0AC	00155D36C79D	008CFA0BC1E6	008CFA0BD456
100.86.166.1	100.86.166.20	100.86.166.32	100.86.166.50	100.86.166.190
00155D36C784	00155D36C791	00155D36C79F	008CFA0BEA18	008CFA0BDE8E
100.86.166.4	100.86.166.18	100.86.166.34	100.86.166.60	100.86.166.200
		fe80::fc4e:cb8e:311b:3fff
00155D36C785	00155D36C792		008CFA0BE584	008CFA0BD46A
100.86.166.5	100.86.166.19	00155D36C79E	100.86.166.70	100.86.166.210
		100.86.166.33
00155D36C787	00155D36C793		008CFA0BC1F4	008CFA0BB28E
100.86.166.7	100.86.166.21	00155D36C7A0	100.86.166.80	100.86.166.220
		100.86.166.35
00155D36C788	00155D36C795		008CFA0BD0AE	008CFA0BA0A0
100.86.166.8	100.86.166.23	00155D36C7A2	100.86.166.90	100.86.166.230
		100.86.166.37
00155D36C786	00155D36C794		008CFA0BBEBC	00155D36C7A3
100.86.166.6	100.86.166.22	00155D36C7A1	100.86.166.100	fe80::8df1:61e7:666a:4236
		100.86.166.36		100.86.166.38
00155D36C789	00155D36C796		008CFA0BC440
100.86.166.9	100.86.166.24	00155D36C7A4	100.86.166.110	00155D36C7AA
		100.86.166.39		fe80::99fb:133b:3fea:dd97
008CFA0BAD5C	00155D36C797		008CFA0BE0F0	100.86.166.46
100.86.166.10	100.86.166.25	008CFA0BD8A8	100.86.166.120
		100.86.166.40
00155D36C78A	00155D36C798		008CFA0BDCD8
100.86.166.11	100.86.166.26	00155D36C7A5	100.86.166.130
		100.86.166.41
00155D36C78C	00155D36C79A		008CFA0BDAD2	Routers
100.86.166.13	100.86.166.28	00155D36C7A6	100.86.166.140	A44C11350741
		100.86.166.42		100.86.166.1
00155D36C78D	00155D36C799		008CFA0BE1EE
100.86.166.14	100.86.166.27	00155D36C7A7	100.86.166.150
		100.86.166.43
00155D36C78E	008CFA0BB872	00155D36C7A8	008CFA0BC33C
100.86.166.15	100.86.166.30	100.86.166.44	100.86.166.160

__________________________________________END_______________________________________________________

Now I did not run these exploits, as I did not want to disrupt any Microsoft services, nor did I want a visit from any law enforcement agencies.

Was Windows Azure susceptible to these attacks? I’ll never know for certain, as the ticket was open for a almost 2 months… That was plenty of time to fix the issue.

Was I paid a “bounty” by Microsoft? Nope.

Would I let Microsoft know about another vulnerability if I found one? Probably not…

Would I put my companies data in Windows Azure? Probably not…

Would I use Azure for testing and penetration testing? YES, Yes I would…

See Part 2 for more about Windows Azure and “Cloud” computing…

Buy me a coffee!