In the name of “save planet”, “green atmosphere”, “green energy” slogans which are very subtle issues and should be continued for betterment of all living creature, I somehow sense companies making all efforts to increase their sales revenues. Being a wireless guy, I would provide at least one example to prove my nous.
Have you heard about “Clean Air Technology” announced by Cisco systems? If not, you may get yourself familiar to this new technology here.
http://www.cisco.com/en/US/netsol/ns1070/networking_solutions_package.html
http://www.youtube.com/watch?v=y0vcTlXifOs
The technology has been introduced to detect RF interference faced by wireless devices from Cordless phone, Microwave, Wireless Camera, Bluetooth devices etc. Cisco has designed an AP which contains a dedicated radio to detect interference in both 2.4 and 5 GHz bands. Additionally, it can also be used to do spectrum analysis.
In the next few paragraphs, we will analyze whether presence of a dedicated radio which comes at an additional cost and powered all the time is justified or not and does it really solve a problem. Does the RF interference problem clean air technology intend to solve real?
Rebuttal # 1: AP detects RF interference experienced by clients
In a typical WLAN deployment, one can imagine one AP serving several clients simultaneously. These clients could be spatially distributed around Access Point. In such scenario, it’s not necessary that RF interference experienced by a client is equally experienced by an AP. In fact it might also possible that AP never experiences RF interference while clients do.
Rebuttal #2: AP detects microwave, cordless phone and wireless camera
Microwave causes problem with 2.4GHz wireless communication. Normally, the location of this interfering device is known and if it cannot be re-located (e.g. Microwave operating in the neighbourhood, unlikely to cause interference but considering here for completeness) then a careful deployment of dual band AP near pantry area can solve the problem.
Even if we believe cordless phone causes degradation of wireless network throughput, do we really need high end AP to detect it and that too all over? It can be banned by enforcing right policy.
Wireless camera causes jamming on a channel. Again, problem arising from wireless camera can be solved by the use of dual band AP.
Rebuttal #3: Clean Air Technology equals Green Atmosphere
A dedicated radio powered al l the time just to detect sporadic interference doesn’t qualify to be green technology. What’s the use of a dedicated RF interference detection radio after you clean your air? Just think!
Conclusion
Instead of having a dedicated radio, present in all APs and powered all the time to detect RF interference, ideally such intelligence should be present in APs and clients. Some WLAN vendors are already making progress in this direction and adding RF interference detection capabilities in APs and clients. In long term wireless monitoring systems can also play important role by providing RF interference detection intelligence along with high value security solution.
Thursday, August 26, 2010
Employees carry smart phones; a data security threat silently entering into enterprises
Memories of old days of my employment are still afresh when I used to work for a big multi-national software company. The most uneasy moment that i still remember was crossing the physical security of the company. As per company policy, we were not allowed to bring in or take back any type of electronic media (CD, floppy etc.), self owned or company owned laptop. All bags entering office premises were cross examined by security personals. In this regard, the day when I went office without any handbag, gave me the most peaceful entry and probably virtually to the company as well. Only device that never bothered me was my less smart mobile phone hanging right-side in the belt.
Over years a lot have been changed. Those dummy mobile devices have evolved and became much smarter than ever and it would be not wrong if we call it mini personal computer. These smart phones are capable of storing gigabytes of data and can do personal laptop/desktop like computation in a fraction of time. Hundreds of such devices are brought inside enterprises daily and remain inside for several hours unmonitored.
Though these devices are trusted to be taken inside office premises to serve the personal need of calling by employees to their friends and relatives, it can also be misused to carry company’s confidential data. This tiny device come fully equipped to make network connectivity and can be connected to company’s private LAN without network administrator knowledge.
Most enterprise wireless LANs are secured using WPA2/802.1x security protocol which requires knowledge of domain name and password (certificate is optional for clients in PEAP). So employees can also configure their smart phones to make a connection with corporate LAN. Once the connection is done, user can access resources present on the network and siphon off confidential data.
In a large network enterprise, it’s very difficult for network admin to manage updated list of allowed MAC addresses of networking devices and hence white listing is hard to achieve. It’s difficult to monitor and contain employee carried mobile phones connecting to corporate network. NAC (Network access control) is also not going to help as user can bypass it by successfully authenticating with authenticating server.
Monitoring activity of smart phones inside office premises is increasingly becoming serious security problem. Lack of a reliable solution to contain the problem makes the situation even more alarming. This also opens opportunity for network monitoring system provider to develop innovative solution to manage tiny computers brought inside enterprises by their trusted employees.
Until then, be aware to be secure...
Over years a lot have been changed. Those dummy mobile devices have evolved and became much smarter than ever and it would be not wrong if we call it mini personal computer. These smart phones are capable of storing gigabytes of data and can do personal laptop/desktop like computation in a fraction of time. Hundreds of such devices are brought inside enterprises daily and remain inside for several hours unmonitored.
Though these devices are trusted to be taken inside office premises to serve the personal need of calling by employees to their friends and relatives, it can also be misused to carry company’s confidential data. This tiny device come fully equipped to make network connectivity and can be connected to company’s private LAN without network administrator knowledge.
Most enterprise wireless LANs are secured using WPA2/802.1x security protocol which requires knowledge of domain name and password (certificate is optional for clients in PEAP). So employees can also configure their smart phones to make a connection with corporate LAN. Once the connection is done, user can access resources present on the network and siphon off confidential data.
In a large network enterprise, it’s very difficult for network admin to manage updated list of allowed MAC addresses of networking devices and hence white listing is hard to achieve. It’s difficult to monitor and contain employee carried mobile phones connecting to corporate network. NAC (Network access control) is also not going to help as user can bypass it by successfully authenticating with authenticating server.
Monitoring activity of smart phones inside office premises is increasingly becoming serious security problem. Lack of a reliable solution to contain the problem makes the situation even more alarming. This also opens opportunity for network monitoring system provider to develop innovative solution to manage tiny computers brought inside enterprises by their trusted employees.
Until then, be aware to be secure...
Saturday, June 19, 2010
WEP, TKIP Declared Out…
If the fast spreading news on the Internet is to be believed, Wi-Fi alliance has decided to drop off WEP and TKIP encryption techniques from its certification criteria.
WEP was the only encryption techniques mentioned in the original IEEE 802.11 standard. Some flaws in the WEP encryption algorithm were discovered just after two years of release of WiFi standard and it was cracked in 2001. Since then several attacks on WEP have been published e.g. FMS attack, Korek attack, chop-chop attack, fragmentation attack, Aircrack-PTW attack, Caffe Latte attack etc.
TKIP was an enhancement over WEP. It was an attempt to provide better security to legacy WEP encryption capable devices and hence same RC4 technique with some modification was used in TKIP. The first and only attack on TKIP was published by Martin Beck and Erik Tews in 2008, five years after the release of TKIP specification for WiFi encryption. The attack was about injection of few small sized frames in the client to cause some disruption. It was not a key retrieving attack and unlike WEP, data privacy was guaranteed in TKIP.
The migration towards only-AES encryption mode will be done in stages over three years starting from 2011. From 2011, WiFi alliance will stop certifying APs with WEP or TKIP configuration. In 2012, wireless client devices will be axed for their support for WEP or TKIP. Starting from 2014, new WiFi devices which support only AES encryption will be certified. These requirements must be easily satisfied by device vendors by masking the disallowed encryption techniques just by applying software patch on the newly manufactured devices and if it happens, this will be a great move towards much needed secured wireless world.
A very interesting observation to note here is that the default configuration of most out of the box access points is “Open” which is a much bigger evil than WEP or TKIP. If a wireless LAN is operating in open mode all types of wireless attacks are possible e.g. data snooping, impersonation, unauthorized access to the network etc. The ideal move would be to support only one configuration in the Access Point and Client with the AES encryption as per the IEEE 802.11i and the IEEE 802.11w standard.
In short, the good (TKIP) and the bad (WEP) has been declared out but the ugly (Open configuration) will be continued to play!
WEP was the only encryption techniques mentioned in the original IEEE 802.11 standard. Some flaws in the WEP encryption algorithm were discovered just after two years of release of WiFi standard and it was cracked in 2001. Since then several attacks on WEP have been published e.g. FMS attack, Korek attack, chop-chop attack, fragmentation attack, Aircrack-PTW attack, Caffe Latte attack etc.
TKIP was an enhancement over WEP. It was an attempt to provide better security to legacy WEP encryption capable devices and hence same RC4 technique with some modification was used in TKIP. The first and only attack on TKIP was published by Martin Beck and Erik Tews in 2008, five years after the release of TKIP specification for WiFi encryption. The attack was about injection of few small sized frames in the client to cause some disruption. It was not a key retrieving attack and unlike WEP, data privacy was guaranteed in TKIP.
The migration towards only-AES encryption mode will be done in stages over three years starting from 2011. From 2011, WiFi alliance will stop certifying APs with WEP or TKIP configuration. In 2012, wireless client devices will be axed for their support for WEP or TKIP. Starting from 2014, new WiFi devices which support only AES encryption will be certified. These requirements must be easily satisfied by device vendors by masking the disallowed encryption techniques just by applying software patch on the newly manufactured devices and if it happens, this will be a great move towards much needed secured wireless world.
A very interesting observation to note here is that the default configuration of most out of the box access points is “Open” which is a much bigger evil than WEP or TKIP. If a wireless LAN is operating in open mode all types of wireless attacks are possible e.g. data snooping, impersonation, unauthorized access to the network etc. The ideal move would be to support only one configuration in the Access Point and Client with the AES encryption as per the IEEE 802.11i and the IEEE 802.11w standard.
In short, the good (TKIP) and the bad (WEP) has been declared out but the ugly (Open configuration) will be continued to play!
Saturday, June 12, 2010
Lessons from Apple’s WWDC Fiasco
If you haven’t heard about it, here is the condensed version of what happened on the opening day of iPhone 4G. The information has been gathered from various stories released on the Internet but the essence of all is same.
“Steve Job was trying to show the screen resolution and speed of the device by accessing a web portal that’s where the mishap happened. A completely saturated 2.4 GHz spectrum couldn’t distinguish between Steve’s new iPhone and hundreds of WiFi clients active at that location and hence the iPhone 4G was starved from getting wireless service.”
You may compare this scenario with a very heavily congested road. No matter what model or speed of the car is, one can not drive faster than the average speed of the traffic.
Could this have been avoided?
I am astonished to see every body (whether it’s WLAN infrastructure vendor or else) making claim that if Apple had used their solution or service, the problem would have never arisen. The way Ferrari can’t solve the very basic problem of congestion likewise iPhone 4G can’t solve the saturated link problem.
I have yet to see a solution which can accommodate hundreds of WiFi client devices or save 2.4 GHz from being saturated in the similar situation.
Yes there are solutions which could have raised alert on seeing too many devices operating in 2.4GHz band. Kudos to great Steve Job, he realized this very soon and requested his audiences to shutoff their WiFi warriors and saved his iPhone 4G demo!
If you are going to make such a crucial demo and planning to use WiFi you are bound to face the similar fiasco until you learn the lessons from Apple.
1. You ensure that there are not too many WiFi devices are operating in 2.4 GHz band. Its better to ask audience to switch of WiFi in the beginning.
2. If your device supports 5GHz band, better you use one channel in 5Ghz band
3. Always use security (WPA or WPA2 ) on your AP so that others can not connect to your device
4. Your demo environment should be free from Wireless DoS or jamming or at least it should be detectable
5. Have a WiFi expert not sales expert setup the WiFi infrastructure
“Steve Job was trying to show the screen resolution and speed of the device by accessing a web portal that’s where the mishap happened. A completely saturated 2.4 GHz spectrum couldn’t distinguish between Steve’s new iPhone and hundreds of WiFi clients active at that location and hence the iPhone 4G was starved from getting wireless service.”
You may compare this scenario with a very heavily congested road. No matter what model or speed of the car is, one can not drive faster than the average speed of the traffic.
Could this have been avoided?
I am astonished to see every body (whether it’s WLAN infrastructure vendor or else) making claim that if Apple had used their solution or service, the problem would have never arisen. The way Ferrari can’t solve the very basic problem of congestion likewise iPhone 4G can’t solve the saturated link problem.
I have yet to see a solution which can accommodate hundreds of WiFi client devices or save 2.4 GHz from being saturated in the similar situation.
Yes there are solutions which could have raised alert on seeing too many devices operating in 2.4GHz band. Kudos to great Steve Job, he realized this very soon and requested his audiences to shutoff their WiFi warriors and saved his iPhone 4G demo!
If you are going to make such a crucial demo and planning to use WiFi you are bound to face the similar fiasco until you learn the lessons from Apple.
1. You ensure that there are not too many WiFi devices are operating in 2.4 GHz band. Its better to ask audience to switch of WiFi in the beginning.
2. If your device supports 5GHz band, better you use one channel in 5Ghz band
3. Always use security (WPA or WPA2 ) on your AP so that others can not connect to your device
4. Your demo environment should be free from Wireless DoS or jamming or at least it should be detectable
5. Have a WiFi expert not sales expert setup the WiFi infrastructure
Thursday, June 3, 2010
Is Your Wireless Auditing Done Right?
WiFi is one of the newest networking technologies and hence auditing wireless networks is still a big challenge for auditors. It is mainly due to the unavailability of sophisticated solutions to cover all possible and realistic scenarios. More often than not the wireless network or security audits are done with the help of open source software/tools freely available on the Internet. These tools have some intrinsic limitations and hence do not always give answer to all the wireless auditing related questions. Due to the software limitations wireless auditing fail to ensure FIVE important wireless audit requirements are:
1. Presence of NO mis-configured, rogue or unmanaged wireless device on the trusted/authorized network
2. Presence of ALL authorized wireless device on the network Up and Running
3. Presence of the BEST wireless security configuration (e.g. WPA2/802.1x)for authorized wireless LANs
4. Presence of NO infected or rogue wireless client device
5. Presence of ALL wireless connection association logs for forensics purpose
Now we know what to see in the report when we get a wireless audit done next time !
1. Presence of NO mis-configured, rogue or unmanaged wireless device on the trusted/authorized network
2. Presence of ALL authorized wireless device on the network Up and Running
3. Presence of the BEST wireless security configuration (e.g. WPA2/802.1x)for authorized wireless LANs
4. Presence of NO infected or rogue wireless client device
5. Presence of ALL wireless connection association logs for forensics purpose
Now we know what to see in the report when we get a wireless audit done next time !
Sunday, December 13, 2009
WPA Cracking on Cloud
Yes, a cluster of about 400 CPUs could be used to test security of WPA-PSK protected wireless networks for only $17. WPA Cracker is an online cloud based key cracking service for penetration testers and network auditors who need to do security assessment of WiFi networks. WPA-PSK based WiFi networks are vulnerable to dictionary attack and takes several hours when run with a respectable size dictionary file. The online service would make feasible to test against 140 million word dictionary in less than an hour. You just need to upload a network capture file and start cracking and WPA Cracker will inform you the results within minutes.
It’s really great to see a bit of WiFi Pen testing as hosted service on Internet Cloud.
My question to the community: Isn’t it a right time to offer a complete package of WiFi security assessment/Pentesting on cloud?
Friday, September 4, 2009
A First Line of Defense against Cisco’s Over-The-Air-Provisioning (OTAP) Protocol Vulnerability
You may have heard that researchers at AirMagnet’s Intrusion Research Team have uncovered the vulnerability in Cisco’s proprietary OTAP protocol that allows an attacker to take control of an authorized light weight APs (LAPs).
Interestingly, the advisories that have come from both AirMagnet and Cisco have different severity level assigned to the reported problem. Also, the safeguards proposed in these advisories are either too involved or time consuming. For a network and security administrators, what matters is a first line of defense that can buy them some time to implement a real safeguard. But what is a real safeguard and how they can be implemented are also unclear to many.
In order to find an answer, I decided to do a self investigation of the OTAP vulnerability. I read a few docs which were relevant to Cisco’s OTAP protocol implementation:
Doc 1: Understanding Over−the−Air Provisioning (OTAP), Document ID: 100516
Doc 2: Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC), Document ID: 70333
Here are key findings of OTAP protocol implementation:
1. LAP uses Over−the−Air Provisioning (OTAP) feature to discover WLCs. LAPs support OTAP only when they have a full LWAPP Cisco IOS image.
a. Out−of−the−box LAPs are shipped from the factory with a stripped−down version of lightweight Cisco IOS® Software that is called the LWAPP Recovery Cisco IOS image and does not support OTAP.
b. Out−of−the−box 1510s and 1520 APs have a full image installed in flash. (See Doc 1)
2. OTAP process utilizes Radio Resource Management (RRM) neighbor packets. The RRM neighbor packets are transmitted without any encryption (See Doc 1)
3. The OTAP feature is enabled on a WLC by default. (See Doc 2). OTAP enabled on the controller indicates to the controller whether or not to respond to discovery requests with the OTAP bit set. It does not prevent the LAPs already joined to the controller from the transmission of the management IP address of the controller in the clear in RRM neighbor packets.
With this information available on OTAP protocol, I hope; now it would be much easier to make a judgment on AirMagnet’s and Cisco’s advisories or for that matter anybody’s advisory on this topic. Some of the frequently discussed queries are answered below:
I. Skyjacked LAP provides a direct access to a corporate WLAN
True.
II. OTAP vulnerability will simply cause Denial-of-Service (DoS) problem
False. A Skyjacked LAP can act like a rogue device physically connected to
a corporate LAN. Once skyjacked an attacker gets full control of a LAP and he
can open a backdoor entry to your corporate LAN.
III. Disabling OTAP feature can solve this problem
False.
IV. Only out-of-the-box LAPs are vulnerable
False. All LAPs (primarily 1100 and 1200 series) running full Cisco IOS®
Software are vulnerable.
V. My LAPs are Up and connected. Are they vulnerable?
Yes. The attack works whenever a LAP reboots. If your LAPs are up and running they are safe but reboot of a LAP can be observed in the network e.g. whenever you change mode of a LAP say from “local” to “monitor” (used in location based service, LBS) it reboots.
A First Line of Defense
Network administrators can stop vulnerable LAPs from getting hijacked by blocking LWAPP communication ports (UDP port no 12222 and 12223) in a network firewall.
• A WLAN customer with a locally deployed WLC system can block LWAPP Data and Control ports.
• A WLAN customer with a WLC present on WAN link (including REAP/H-REAP mode deployment) can apply firewall rule to allow communication on LWAPP Data and Control ports only with authorized controllers (WLCs) IP address.
Conclusion
Wi-Fi networks are known to have security flaws. Zero-day problem like “OTAP vulnerability” will keep on surfacing. If you are lucky you will find a first line of defense but what, if you fail to find one? Network compromise and huge Data loss Right! But the answer also depends on whether or not your WLAN deployment is equipped to protect against potential exploits of zero-day vulnerability. Use of an independent overlay Wireless Intrusion Prevention System (WIPS) adds that extra layer of security which prevents WLANs against any potential misuse.
Isn’t it a right time to think of an independent shell of security for WLANs? Choice is yours!
Interestingly, the advisories that have come from both AirMagnet and Cisco have different severity level assigned to the reported problem. Also, the safeguards proposed in these advisories are either too involved or time consuming. For a network and security administrators, what matters is a first line of defense that can buy them some time to implement a real safeguard. But what is a real safeguard and how they can be implemented are also unclear to many.
In order to find an answer, I decided to do a self investigation of the OTAP vulnerability. I read a few docs which were relevant to Cisco’s OTAP protocol implementation:
Doc 1: Understanding Over−the−Air Provisioning (OTAP), Document ID: 100516
Doc 2: Lightweight AP (LAP) Registration to a Wireless LAN Controller (WLC), Document ID: 70333
Here are key findings of OTAP protocol implementation:
1. LAP uses Over−the−Air Provisioning (OTAP) feature to discover WLCs. LAPs support OTAP only when they have a full LWAPP Cisco IOS image.
a. Out−of−the−box LAPs are shipped from the factory with a stripped−down version of lightweight Cisco IOS® Software that is called the LWAPP Recovery Cisco IOS image and does not support OTAP.
b. Out−of−the−box 1510s and 1520 APs have a full image installed in flash. (See Doc 1)
2. OTAP process utilizes Radio Resource Management (RRM) neighbor packets. The RRM neighbor packets are transmitted without any encryption (See Doc 1)
3. The OTAP feature is enabled on a WLC by default. (See Doc 2). OTAP enabled on the controller indicates to the controller whether or not to respond to discovery requests with the OTAP bit set. It does not prevent the LAPs already joined to the controller from the transmission of the management IP address of the controller in the clear in RRM neighbor packets.
With this information available on OTAP protocol, I hope; now it would be much easier to make a judgment on AirMagnet’s and Cisco’s advisories or for that matter anybody’s advisory on this topic. Some of the frequently discussed queries are answered below:
I. Skyjacked LAP provides a direct access to a corporate WLAN
True.
II. OTAP vulnerability will simply cause Denial-of-Service (DoS) problem
False. A Skyjacked LAP can act like a rogue device physically connected to
a corporate LAN. Once skyjacked an attacker gets full control of a LAP and he
can open a backdoor entry to your corporate LAN.
III. Disabling OTAP feature can solve this problem
False.
IV. Only out-of-the-box LAPs are vulnerable
False. All LAPs (primarily 1100 and 1200 series) running full Cisco IOS®
Software are vulnerable.
V. My LAPs are Up and connected. Are they vulnerable?
Yes. The attack works whenever a LAP reboots. If your LAPs are up and running they are safe but reboot of a LAP can be observed in the network e.g. whenever you change mode of a LAP say from “local” to “monitor” (used in location based service, LBS) it reboots.
A First Line of Defense
Network administrators can stop vulnerable LAPs from getting hijacked by blocking LWAPP communication ports (UDP port no 12222 and 12223) in a network firewall.
• A WLAN customer with a locally deployed WLC system can block LWAPP Data and Control ports.
• A WLAN customer with a WLC present on WAN link (including REAP/H-REAP mode deployment) can apply firewall rule to allow communication on LWAPP Data and Control ports only with authorized controllers (WLCs) IP address.
Conclusion
Wi-Fi networks are known to have security flaws. Zero-day problem like “OTAP vulnerability” will keep on surfacing. If you are lucky you will find a first line of defense but what, if you fail to find one? Network compromise and huge Data loss Right! But the answer also depends on whether or not your WLAN deployment is equipped to protect against potential exploits of zero-day vulnerability. Use of an independent overlay Wireless Intrusion Prevention System (WIPS) adds that extra layer of security which prevents WLANs against any potential misuse.
Isn’t it a right time to think of an independent shell of security for WLANs? Choice is yours!
Subscribe to:
Posts (Atom)