I have been quite busy the last weeks, even thought I managed to enjoy a one week vacation in the middle and even post an entry. Currently I am on a short sick leave, it is that season again. Fortunately it isn't that bad, but affects the ability to think properly.
Seems that the Security Bloggers Network feed is dead, a replacement is being worked on. Too bad, I've enjoyed reading SBN a lot, some good blogs in here. Probably one of the most interesting things I've read about lately is the takedown of McColo ISP which cut spam nearly by 50%. During the weekend it came back alive to send large amounts of data to Russia. We might start seeing a rise in spam again.
November 19, 2008
November 7, 2008
WPA TKIP broken... or not?
This is an update to yesterdays blog entry. I rarely update entries but this must be updated. Turns out that that the attack is not as serious as first reported, but anyways it is a vulnerability. Read more here.
Original post:
I heard some rumors of the topic just a while ago and now ran into some online press articles, for example here. Eric Tews and Martin Beck has made advances in breaking WPA TKIP encryption. The attack is not done with a dictionary attack but combining a mathematical method with tricking the wireless router into sending large amounts of data.
It means that there is an actual concrete attack against WPA TKIP existing that has nothing to do with your initial key length and dictionary attacks, but is a problem in the protocol itself. The end result of the attack is that the TKIP key is broken in about 12-15 minutes and communication from the router to the connected device is revealed (but not vice versa).
Mitigation based on current cracking time could be to set the wireless router to change the temporal keys in a reasonable short time (if such option is available in the router). This probably helps until there are more advances in cracking the TKIP key.
Another option is to move to WPA2 pre-shared key mode which uses CCMP instead of TKIP. Only problem is that not all devices support WPA2 and a WPA2 capable router apparently falls back to WPA in such cases where a legitimate client uses only WPA.
Lets see what other research arises from this, probably the cracking time will decrease and maybe the communication can be broken the other way too (client->AP) if reasonable amount of traffic can be generated.
Original post:
I heard some rumors of the topic just a while ago and now ran into some online press articles, for example here. Eric Tews and Martin Beck has made advances in breaking WPA TKIP encryption. The attack is not done with a dictionary attack but combining a mathematical method with tricking the wireless router into sending large amounts of data.
It means that there is an actual concrete attack against WPA TKIP existing that has nothing to do with your initial key length and dictionary attacks, but is a problem in the protocol itself. The end result of the attack is that the TKIP key is broken in about 12-15 minutes and communication from the router to the connected device is revealed (but not vice versa).
Mitigation based on current cracking time could be to set the wireless router to change the temporal keys in a reasonable short time (if such option is available in the router). This probably helps until there are more advances in cracking the TKIP key.
Another option is to move to WPA2 pre-shared key mode which uses CCMP instead of TKIP. Only problem is that not all devices support WPA2 and a WPA2 capable router apparently falls back to WPA in such cases where a legitimate client uses only WPA.
Lets see what other research arises from this, probably the cracking time will decrease and maybe the communication can be broken the other way too (client->AP) if reasonable amount of traffic can be generated.
October 23, 2008
Devices having web interface
One entry at SecuriTeam caught my eye and brought up memories. The entry was about getting persistent XSS via SNMP to different routers web interface. When people began talking about hacking small ADSL/WLAN routers some years ago I also decided to take a look at my old D-Link WLAN router.
I noticed that when you had DHCP clients, the device actually listed the hostname on the web interface. I don't remember if it was static or dynamic client but that is not so important. I was able to provide a custom hostname which of course contained some Javascript code and it was happily rendering on the web interface. I also noticed during my testing that you can actually crash the device by providing a too long hostname, so while working on one issue I actually found two. Also depending on the HTML you inject, you can render that particular part of the web interface unusable, causing a persistent denial of service situation. It was possible to fix it but it required a hard reset of the device to get back on track.
As I nice guy I of course informed D-Link about the problems found. But anyways, as embedded devices mostly use a web interface to present data from other enabled protocols, using these other protocols to attack the web interface is definitely possible if there is no proper input/output validation in place.
Nothing new, just good ol' memories :)
I noticed that when you had DHCP clients, the device actually listed the hostname on the web interface. I don't remember if it was static or dynamic client but that is not so important. I was able to provide a custom hostname which of course contained some Javascript code and it was happily rendering on the web interface. I also noticed during my testing that you can actually crash the device by providing a too long hostname, so while working on one issue I actually found two. Also depending on the HTML you inject, you can render that particular part of the web interface unusable, causing a persistent denial of service situation. It was possible to fix it but it required a hard reset of the device to get back on track.
As I nice guy I of course informed D-Link about the problems found. But anyways, as embedded devices mostly use a web interface to present data from other enabled protocols, using these other protocols to attack the web interface is definitely possible if there is no proper input/output validation in place.
Nothing new, just good ol' memories :)
October 14, 2008
Log management
Now that Anton Chuvakin left LogLogic, it made me think about log solutions in general. Basically I was thinking about a log management solution and what I would like it to be, for a small and maybe mid-size business. LogLogic and other players in the area are probably more suitable for large businesses with lots of data to log, but would probably work as well.
Mainly I was thinking of easy navigation and keeping the system as simple as possible. The ideas I have are simple but features would add complexity. Also the gathering of logs would add complexity in some of the log sources.
You would have different sections for different type of logs; firewall log, operating system log, application log, webserver log, database log, ids/ips log and so on. Each section would have the assets that produce the log and you could either get X amount of last entries in the category or drill down on a specific asset. In the asset view you see latest logs and could dig into a vulnerability assessment report or latest IDS events regarding the asset. In the IDS section there could be a possibility to correlate against the attacked service if the vulnerability assessment format allows some parsing. The system could even do filtering or highlighting based on some specific values which would give a view of interesting log entries across the whole log data available.
You would also be able to search for specific terms in a broad or finetuned manner, however it could be accomplished. The gathering and sorting of the log data would require some planning on how to do it and there would also need to be automation on log rotation (how long to keep logs, how old logs would get compressed and so on). Maybe even some kind of user management system should be in place, e.g. what assets/log group a person is allowed to see, and so on.
Not sure if something like this already exists, but I'm a little bit tempted to begin a small project on this (yeah, I know... I still got unfinished ones hanging around), as the concept isn't that difficult if we talk about small volume data. It would just require some careful planning. The ideas I was rolling around would however require some hacks that either work well or are prone to errors, but require modifications on the asset side.
Anyways, it is good to play around with ideas, even though the log management concept isn't anything new. You never know what you end up with.
Mainly I was thinking of easy navigation and keeping the system as simple as possible. The ideas I have are simple but features would add complexity. Also the gathering of logs would add complexity in some of the log sources.
You would have different sections for different type of logs; firewall log, operating system log, application log, webserver log, database log, ids/ips log and so on. Each section would have the assets that produce the log and you could either get X amount of last entries in the category or drill down on a specific asset. In the asset view you see latest logs and could dig into a vulnerability assessment report or latest IDS events regarding the asset. In the IDS section there could be a possibility to correlate against the attacked service if the vulnerability assessment format allows some parsing. The system could even do filtering or highlighting based on some specific values which would give a view of interesting log entries across the whole log data available.
You would also be able to search for specific terms in a broad or finetuned manner, however it could be accomplished. The gathering and sorting of the log data would require some planning on how to do it and there would also need to be automation on log rotation (how long to keep logs, how old logs would get compressed and so on). Maybe even some kind of user management system should be in place, e.g. what assets/log group a person is allowed to see, and so on.
Not sure if something like this already exists, but I'm a little bit tempted to begin a small project on this (yeah, I know... I still got unfinished ones hanging around), as the concept isn't that difficult if we talk about small volume data. It would just require some careful planning. The ideas I was rolling around would however require some hacks that either work well or are prone to errors, but require modifications on the asset side.
Anyways, it is good to play around with ideas, even though the log management concept isn't anything new. You never know what you end up with.
October 13, 2008
Bluetooth sniffing and cracking WPA-PSK
Seems that people really look to find information on how to crack WPA-PSK and how to sniff bluetooth traffic. I thought of posting something about these, especially because there has been some new information on bluetooth sniffing and cracking WPA and I rather want people hitting here than on the old posts.
The cool stuff: Bluetooth sniffing. This is accomplished with flashing a cambridge silicon radio equipped bluetooth adapter which can be flashed with the firmware from Frontline (which sounds suspiciously illegal). Too bad that my DBT-120 dongle hardware version is B4 and not C1, so I can't try it out just for own educational purposes. I actually recall the dongle reverting back to old information after the device was unplugged.
The WPA cracking stuff: Elcomsoft has increased the cracking speed to 100 times faster with using two NVidia GPUs. Does this pose a real threat to WPA-PSK and the "you're good to go with a 20-char passphrase"? I doubt that if you're just a home user. Seems also that others think somewhere along the lines, but I am not a math guy so I do not know the actual figures and time it would actually take. Does someone have actual figures how this would compare to earlier situation? Even if it would be a risk, just add a few characters and it becomes obsolete again. I use all the available space for the WPA-PSK key so I don't feel worried (63 chars).
The cool stuff: Bluetooth sniffing. This is accomplished with flashing a cambridge silicon radio equipped bluetooth adapter which can be flashed with the firmware from Frontline (which sounds suspiciously illegal). Too bad that my DBT-120 dongle hardware version is B4 and not C1, so I can't try it out just for own educational purposes. I actually recall the dongle reverting back to old information after the device was unplugged.
The WPA cracking stuff: Elcomsoft has increased the cracking speed to 100 times faster with using two NVidia GPUs. Does this pose a real threat to WPA-PSK and the "you're good to go with a 20-char passphrase"? I doubt that if you're just a home user. Seems also that others think somewhere along the lines, but I am not a math guy so I do not know the actual figures and time it would actually take. Does someone have actual figures how this would compare to earlier situation? Even if it would be a risk, just add a few characters and it becomes obsolete again. I use all the available space for the WPA-PSK key so I don't feel worried (63 chars).
Subscribe to:
Posts (Atom)
