A must read from security researchers Michele Orru' and Ty Miller:
BeEF - The Browser Exploitation Framework Blog: Revitalizing the Inter-Protocol Exploitation with BeEF Bind
maandag 5 november 2012
zondag 28 oktober 2012
Usage of different types of wireless encryption
There are no exact numbers known on the usage of encryption on wireless networks. I've found a recent report that describes how Sophos’ director of technology strategy James Lyne collected wireless information in London (a.k.a Wardriving). Actually it was Warbiking since he apperently drove through London by bike.
He found more than 1000 hotspots in London for every mile he drove. 25% of them had poor security. 9% of the access points he found have a SSID (Service Set IDentification) that was just a default value with no random element at all (e.g. default, linksys). The most interesting thing he discovered imho is that the situation in residential areas is often reasonable. However in streets with collections of small businesses the situation was worse. The report also states that often it is easy to identify at wich company a device belongs due to poor chosen SSID like 'Company X'. Access Points found at a coffeeshop often have no wireless protection scheme at all. The report advises us to only use them with a VPN- or SSH-tunnel if possible.
After some further research I've stumbled upon a very interesting project, that I've lost out of sight for some time, WiGLE (Wireless Geographic Logging Engine). WiGLE offers a Wigle Java Client and an Android application, that can be used to record WiFi-data while wardriving. This data is collected afterwards. Their webpage offers a page with statistics of their database. In 11 years time, almost 130.000 users have reported more then 77 milion unique wireless networks. With a population of 7 bilion persons that makes that for every 100 persons, their is one WiFi-network. In their stats we can see that 19.2% of the reported networks are encrypted with WEP and 25.9% have no encryption at all. But only 6.2% is reported with it's default SSID. Of course, the situation differs from 11 years ago, but two-third of all the networks in the database were added after 2010.
Comparing with the report from Mr Lyne it seems that the situation in london regarding wireless encryption is not as bad as it probably is in less populated regions. This might be “normal” as the impact of a vulnerable network in London will probably be much higher than an open wireless network in some deserted region.
He found more than 1000 hotspots in London for every mile he drove. 25% of them had poor security. 9% of the access points he found have a SSID (Service Set IDentification) that was just a default value with no random element at all (e.g. default, linksys). The most interesting thing he discovered imho is that the situation in residential areas is often reasonable. However in streets with collections of small businesses the situation was worse. The report also states that often it is easy to identify at wich company a device belongs due to poor chosen SSID like 'Company X'. Access Points found at a coffeeshop often have no wireless protection scheme at all. The report advises us to only use them with a VPN- or SSH-tunnel if possible.
After some further research I've stumbled upon a very interesting project, that I've lost out of sight for some time, WiGLE (Wireless Geographic Logging Engine). WiGLE offers a Wigle Java Client and an Android application, that can be used to record WiFi-data while wardriving. This data is collected afterwards. Their webpage offers a page with statistics of their database. In 11 years time, almost 130.000 users have reported more then 77 milion unique wireless networks. With a population of 7 bilion persons that makes that for every 100 persons, their is one WiFi-network. In their stats we can see that 19.2% of the reported networks are encrypted with WEP and 25.9% have no encryption at all. But only 6.2% is reported with it's default SSID. Of course, the situation differs from 11 years ago, but two-third of all the networks in the database were added after 2010.
Comparing with the report from Mr Lyne it seems that the situation in london regarding wireless encryption is not as bad as it probably is in less populated regions. This might be “normal” as the impact of a vulnerable network in London will probably be much higher than an open wireless network in some deserted region.
vrijdag 5 oktober 2012
HP uCMDB JMX-console CSRF
Some time ago, 13 september 2012, I contacted the HP SSRT (Software Security Response Team) because I found some serious problem in one of their products: uCMDB 9.0x (Universal Configuration Management Database). The security towards this HP uCMDB is crucial for an enterprise, since it can contain very sensible data like names of persons, infrastructure information, ...
The product contains a JMX-Console that exposes direct access to the Managed Beans (MBeans). This JMX-Console that is a standard part of any uCMDB configuration is vulnerable to CSRF. I reported this since additional users can be created via this JMX-Console, even integration users. Also a lot of other functionality is accessible via this JMX-Console.
After sending them 8 e-mails, with references to their deployment guides and release notes they still ignore the problem and their conclusion is that it's due to an installation of JBoss-server on the uCMDB system. I have no other choice then to warn uCMDB system administrators.
PoC
You can easily verify it with an iframe:
BeEF Module
A module for testing is available at BeEF project.
Advise
Finally, my advise towards uCMDB-administrators is to be extra careful when using the JMX-console. Make sure sessions are expired/invalidated before accessing other webpages.
The product contains a JMX-Console that exposes direct access to the Managed Beans (MBeans). This JMX-Console that is a standard part of any uCMDB configuration is vulnerable to CSRF. I reported this since additional users can be created via this JMX-Console, even integration users. Also a lot of other functionality is accessible via this JMX-Console.
After sending them 8 e-mails, with references to their deployment guides and release notes they still ignore the problem and their conclusion is that it's due to an installation of JBoss-server on the uCMDB system. I have no other choice then to warn uCMDB system administrators.
PoC
You can easily verify it with an iframe:
<iframe src="http://ucmdbhostname:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=UCMDB:service=Security%20Services&methodName=createIntegrationUser&arg0=1&arg1=testaa&arg2=testbb&arg3="
width="0" height="0" ></iframe>
BeEF Module
A module for testing is available at BeEF project.
Advise
Finally, my advise towards uCMDB-administrators is to be extra careful when using the JMX-console. Make sure sessions are expired/invalidated before accessing other webpages.
Abonneren op:
Posts (Atom)