Monday, May 24, 2010

The Security Bloggers Network

Rich Mogull of Securosis recently published a blog post entitled Is Twitter Making Us Dumb? Bloggers, Please Come Back. Rich summarizes his experience starting a blog and shares his perspective on the diminishing amount of blogging. Alan Shimel who runs the Security Blogger Network quickly followed up with his own post.

I too have noticed that my RSS reader is not nearly as full as it once was. Many of the resources I have today in my RSS Reader came from the Security Bloggers Network after stumbling upon it several years ago. The blogs I was introduced to through the SBN opened up a new world for me. I was introduced to thoughts and opinions from every corner of the security community. Many of which I had never considered.

When I started my own blog about a year ago, it never occurred to me to even join. In retrospect, it may have been lack of confidence, as I was not sure what I was going to write about. I just knew that there were some thoughts I needed to rant about and blogging seemed like a logical medium. But I quickly found blogging to be an rewarding experience and I am currently backlogged with so many ideas for posts, I have enough material for the remainder of the year.

So I am proud to announce, I am a new member of the Security Bloggers Network. If you have a blog, I recommend you consider joining. If you do not have a blog I ask you to consider starting one, as it can be a rewarding experience to both the author and the reader, alike.

Monday, May 3, 2010

Why Hackers make the Best IT Support Professionals

This is a thought that I have had brewing for some time and I will attempt to not rant too much.  Throughout my IT career, I have been watching many IT Support professionals immediately go for a quick fix to technology issues. This is not to say a quick fix isn’t always warranted. The constant barrage of support issues, end users broad siding you as you attempt to grab lunch, and evolving technology is indeed a challenge. I feel your pain. I've been there, I've done that, and I still do it on a daily basis. The beating support people take can cause even the most saintly to lose his/her patience.

However, I feel the trend of the quick fix, seems to be worsening. In InfoSec, the quick fix is often used in conjunction with FUD (fear, uncertainly, and doubt) to sell those magical products with blinking lights that are going to make the latest attack vectors just magically disappear. The problem with this concept is the same in all subsets of Information Technology, however. How many of us have told colleagues, friends, and family to reboot as a solution to an issue? How many of us have told them to do so more than once for the same issue? See the quick fix is not really a fix at all, it is procrastination.

I like to think that we as IT Professionals, whether desktop support, enterprise architects, coders, or InfoSec pursued our career because we all had the common love of technology. Many of us have the inquisitive nature that would rival any scientist. This makes us all brothers and sisters alike. The inquisitive nature that I felt when powering on my TI99-4A in 1981 is still with me today. This is why I chose this career.

Some of the most inquisitive people I have met while working in IT have been those who have self dubbed themselves "hackers". These are not the "hackers" the media would have you believe are hijacking your wireless and stealing your digital valuables. These are self proclaimed geeks who love computers. They are not always InfoSec professionals. They may work on a helpdesk, as a systems administrator, or at the local Radio Shack. They enjoy taking things apart and putting them back together in ways that improve the technology. See hackers understand the concepts of efficiency and availability.  These concepts are the foundation of supporting any business. It is what our employee’s pay us our salaries for, regardless of the subset of IT we may fall under.

Efficiency and availability is not about reboots and resets. It is about getting to the root of an issue, learning from it, and improving the system(s) from what you have learned. So take the time to understand the technology issues you come across. It can be fun and productive. If you are not feeling the love for your technology career of choice, then ask the hacker working at the local Radio Shack if he or she is willing to trade careers with you. I suspect they would jump at the chance.

More Experiments with Master File Table Timestamps

I had an anonymous comment on my Tampering with Master File Table Records post referencing the Timestomp utility available in Metasploit. Timestomp is an anti-forensics utility used to change the date/time metadata stored in the $Standard_Information Attribute of the Master File Table. I experimented with the utility prior to the previous post but had some issues getting it to run properly on Windows 7. Moreover, Timestomp does not edit the $File_Name Attribute (MACE) values. The commenter does point out and interesting workaround noted on the Timestomp wiki however.

Moving a file post manipulation with Timestomp copies all four of the $Standard_Information Attribute time values to the $File_Name Attribute Attribute values. Once moved, you must change the SI attribute values again. Staying with using the existing tools available on Windows 7, I tested using the Move-Item Cmdlet.
CD C:\Windows\System32
New-Item malicious.dll -type file
(get-item malicious.dll).creationtime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item malicious.dll).lastaccesstime=$(Get-Date "02/11/10 07:30")
set-date -date 02/11/10
set-date -date 07:30:00
rename-item malicious.dll notmalicious.txt
Move-Item notmalicious.txt C:\Users\Public\
CD C:\Users\Public\
(get-item notmalicious.txt).creationtime=$(Get-Date "02/11/10 07:30")
(get-item notmalicious.txt).lastwritetime=$(Get-Date "02/11/10 07:30")
(get-item notmalicious.txt).lastaccesstime=$(Get-Date "02/11/10 07:30")
I verified again by carving the $MFT out and using analyzeMFT to parse the contents. The following is the output of the $MFT record for our malicious file verifying that all eight date values have been edited;

Rob T. Lee also recently posted some research he has been doing on Windows 7 $MFT timestamp entries. His findings to date seem to support the aforementioned behavior. It will be interesting to see what additional behavior he finds. Keep the comments coming!