Stolen Laptop Recovery with LogMeIN - Round 2

PC World has David Krop's story of laptop recovery using LogMeIn. I've discussed a couple of similar stories involving a laptop and an iPhone previously, as well as the case for remote control software, and this is another example of a laptop that was not properly secured being used by a new user while remote login software was on.

The buyer of the stolen laptop is quoted, saying "I didn't care whether it was stolen, I buy stolen stuff all the time. I don't care... If I can save $600, I'll do it.". While he may not have learned a lesson, the owner of the stolen laptops did, noting that he won't leave the laptops unattended, that he takes only one with him, and that he uses passwords and remote tracking software now.

What You Do on Facebook Can Cause You Harm is True For Criminals Too

Jonathan G. Parker of Fort Loudon, Pennsylvania was arraigned on a burglary charge after he forgot to log out of Facebook on the computer at a house that he had robbed.

We're all busy telling our users that what they do on Facebook can cause them problems in the future, but this is a slightly more direct example...

Making Web Application Security Controls Repeatable

Raul Siles recently posted a useful reminder as his ISC diary post - "Review the security controls of your Web Applications... all them!". He used the problems described by Ryan Barnett that were found in Yahoo's web API as an excellent example of this rule. Both posts point to a common problem in applications that I see - the loss of established controls in new code and new functionality.

One way I've been working to help fix this in an organization that hasn't developed a comprehensive software develoment lifecycle or broad QA process is to build a multi-step process to handle security flaws found in an application. Typical steps are:

1. Determine whether the problem is unique to the application, or if it is a flaw that is likely found in other applications, either current or future.
2. If it is more than a one time problem, design a common library or technique to handle the problem.
   
3. Assess the severity of the problem, and apply the fix to other applications if the risk is determined to be high enough to justify the effort. If not, add the fix to the queue for the next update to those applications.
4. Re-test the application to verify that the fix works.
5. Document the library and ensure that the rest of the team is aware of it.
   

One of the best things about this sort of process is that developers start to think about problems in a much broader context. Recently, I've seen two of the developers I work with frequently stop during a meeting and ask out loud "I wonder if that applies in application X too...". That thought process usually ends up in modifications to their standard application libraries which means that problems I saw once tend not to come back across their entire group.

How are these vulnerabilities discovered? A web application vulnerability scanner - WebInspect in this case - provides most of the vulnerability testing. Manual testing, while often deeper and more likely to find corner cases for vulnerabilities doesn't scale as well into an environment with limited resources and a large number of applications. Automated testing systems are also great to help cover some gaps in skillset. As Jeremiah Grossman points out, they may simply cover low hanging fruit, but that can be very valuable.

Do you have a unique or creative internal process to make sure that your organization keeps web application vulnerabilities from recurring?

Brazilian ATM Skimmer Installation Video

LiveLeak has great footage of an ATM skimmer being installed in Brazil, as well as the police arrest that followed. Note - LiveLeak itself may be not safe for some work environments due to adult ads.



The first few seconds are a quick lesson in how easily these skimmers can be attached.

Security Humor: Indiana State Government Ponzi Scheme Education

Google text ads can sometimes be a bit humorous as seen in this example:

I knew there was a reason that our budget wasn't as bad as those in other states. Of course, I wonder if the Secretary of State also teaches advanced Ponzi schemes...

EDUCAUSE's 2009 Video and Poster Contest Winners

EDUCAUSE has announced their 2009 security video and poster contest winners. They can be viewed at: http://www.researchchannel.org/securityvideo2009/. Previous years can be accessed from the main EDUCAUSE contest site.

The videos produced for this contest are typically aimed at students, but often address topics that are relevant to the general populace.

This year, I particularly liked the Cyber Security Awareness video by Nathan Krochmal, and Lenae Boykin's 10 Most Common Passwords is quite well done. In previous years, Adam Stackhouse's Laptop Theft video has been a big hit.

As with the videos and other materials created each year for this contest, colleges and universities can use these videos as part of their education and awareness campaigns. They're a great way to add spice to typical student security awareness and education videos, and they've helped to inspire some of our staff and faculty awareness efforts as well.

SMB2 - Breaking Windows From Afar

Creative Commons Attribution License Photo courtesy Justus Hayes / Shoes on Wires / shoesonwires.com

Announcements have been making the rounds about vulnerabilities in Windows Vista and Windows 7's implementation of SMB, SMB2. As posted on Full Disclosure, this version of SMB "SRV2.SYS fails to handle malformed SMB headers for the NEGOTIATE PROTOCOL REQUEST functionnality.", which results in a remotely initiated crash for any Vista or Windows 7 machine with exposed SMB services.

Older versions of Windows, including 2000 and XP are not affected, as they do not use the new SRV2.SYS driver.

Another good reminder that SMB shouldn't be exposed on workstations in general, and that if it must be available, that it should be locked down to prevent access beyond your local trusted networks or workgroup.