Dailies
- Caoine
- Echoica
- Jina Bolton
- Lifehacker
- Overclockers Australia
- RiskAnalys.is
- Rory.Blog
- Schneier on Security
- Security Catalyst Community
- Security Ripcord
- Securosis.com
- Slashdot
- Whirlpool
Photos
Categories
- Books
- Computers
- Family
- Forensics
- General
- GTD
- Movies
- Music
- Profession
- Security
- University and Studies
- Web Development
Monthly archives
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- December 2006
- June 2006
- May 2006
- April 2006
- March 2006
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- February 2005
- October 2004
- September 2004
- August 2004
- July 2004
- June 2004
- May 2004
- April 2004
- March 2004
- February 2004
- January 2004
- December 2003
- November 2003
- October 2003
- September 2003
- August 2003
- July 2003
- June 2003
- May 2003
- April 2003
- March 2003
- February 2003
- January 2003
- December 2002
- November 2002
- October 2002
Search
Mitigating DoS with Employee Monitoring. What.
This article over on Computerworld Australia seems to have a couple of conflicting items that have been bugging me since I read it the other day. The article begins by mentioning potential changes to federal government legislation:
The changes will give employers power to intercept all Internet-based communications without consent, including e-mails and instant message (IM) discussions.
It’s at this point that all of sudden we go on a massive tangent, whereby the Attorney-General is saying that these legislative changes are a counter-terrorism measure, and that these changes could prevent breaches occurring:
…similar to the Estonian Denial of Service (DoS) attacks in which a 19 year-old hacker disabled the Web sites of banks, schools and the Prime Minister’s office.
Hopefully someone out there can explain to me exactly how allowing employers monitoring rights to their employees is a control against denial of service attacks? Or even better, how exactly a denial of service attack equates to a breach? Especially after they’ve done such a good job of defining what an Information Security Breach is in the “Draft Voluntary Information Security Breach Notification Guide“.
An information security breach occurs when personal information is exposed to unauthorised access, use, disclosure or modification as a result of a breach of an agency’s or organisation’s information security.
The only saving grace in the article was the comment from Nick Elsmore from SIFT where he states that these new laws will have minimal impact on businesses due to most enterprises having provisions for Internet monitoring within employee contracts. My experience in a few different enterprises has proven this to be the case.
Posted by Christian
Posted in: General
2 Comments »
25 April 2008
Don’s Windows Incident Response Script
Just had a quick play with Don’s Windows Incident Response Script and am very happy that someone else has put in the time and effort for something as useful as this, and then provided it for all. Some of the useful information it captures includes:
- User Account Information - Account name, Full name, SID, LocalAccount
- System Information - Hostname, manufacturer, OS Type, version, SP etc
- PreFetch File Information (this is AWESOME) - the metadata of about the last 128 programs that were executed
- Installed Software
- Windows Setup Log
- USBSTOR Registry Key
- Windows Firewall Exception List
- Log On and Off Events (if auditing is turned on of course)
- Event Logs
- Temp Internet Information
- Running Processes
- Active Network Connections (ahh netstat)
- Anti-malware logs (dependant on your AV vendor)
So yeah, go check it out.
Posted by Christian
Posted in: Computers, Forensics, Security
No Comments »
19 April 2008
Old School Biometrics Hacking And Enterprise Physical Access Control
While I really enjoyed the research performed by Matthew Lewis on his PoC biometric logger, or “BioLogger”, (white paper available from darknet here), I still think that the old-school method of hacking biometric systems is damn cool. 11 steps (with pictures) on how to capture someones fingerprint from a beer bottle. Fantastic!
But what I think Lewis’ research did highlight is something that I’ve thought for a long time, and that is that physical access control systems are more and more relying on network protocols for communication, and more often than not they do not implement security controls all that well. Whilst some of the vulnerabilities can be mitigated with network controls, in the constant drive to provide more accessible systems it is often not possible to apply ACLs to constrain traffic.
A good example is a common, enterprise access control architecture, fairly similar to that as demonstrated by Lewis. To allow the system to be scalable an access control server has to communicate with a number of access control panels. Usually this is facilitated by a TCP/IP accessible network to serial adaptor, or a terminal server. To provide client access to the system the access control server also has to be accessible by clients. Throw into the mix the fact that the client computer is usually accessing the access control server via a web browser (possibly even IE6). All of these channels provide a potential avenue to disrupt an access controls operations, or even to compromise confidentiality or integrity.

Most systems provide client access using HTTP channels, which as we know has a whole host of vulnerabilities, and usually because they assume the systems are being deployed in isolated networks don’t spend much effort in protecting themselves from exploitation. On the other hand, the network to serial adaptors are more often designed as a ‘dumb’ type of device, with management provided over archaic interfaces (such as Telnet), and not developed to withstand a DoS attack. What do you think would occur to a network to serial adaptor if it was flooded and therefore unavailable? The access control server would not be able to communicate with the access control panels, and therefore the doors. Records of building entry might be lost. Alarms might not be raised if doors are forcefully opened. Centralised control of doors is lost. Etc.
While in many environments these risks are mitigated through air-gaps in the network, the common theme occuring these days is integration. “We want the access control system to integrate with the HR system.” “We want our physical security operators to access the system from outside the building.” “We want to integrate the system with our corporate network for email alerting.” “We need our vendors to be able to provide remote diagnostics.” By providing these entry and exit points into these types of systems we obviously increase the risk of them being exploited.
There’s lots of things that can be done to reduce these risks, but I think this post is big enough for the moment.
Posted by Christian
Posted in: Security
No Comments »
5 April 2008