Saturday, May 28, 2011

Hackers breached U.S. defense contractors (Reuters)

(Reuters) - "Unknown hackers have broken into the security networks of Lockheed Martin Corp (LMT.N) and several other U.S. military contractors, a source with direct knowledge of the attacks told Reuters. "

"They breached security systems designed to keep out intruders by creating duplicates to "SecurID" electronic keys from EMC Corp's (EMC.N) RSA security division, said the person who was not authorized to publicly discuss the matter." Reuters

Here's another link to a similar story from the Taipei Times


Monday, May 23, 2011

Remove Character From Bash Variable


 Sometimes, it is the little things that take an extra few minutes to find on the Internet that really slow you down...

Remove the first character from a bash variable:
VAR=${VAR#?}

Remove the last character from a bash variable
VAR=${VAR%?}

Friday, May 20, 2011

Rename Perl script on the Mac



I love Linux and BSD. I also love my Mac. I really like the user interface, and the underlying BSD roots. (Insert generic Mac fan-pitch)

There are a few things which drive me NUTS about the BSD underpinnings of the Mac, though. MacPorts is a great step in the direction of bringing better Linux/BSD program onto the Mac platform, but it doesn't always have everything you need (And it's pretty slow). The most recent annoyance is the lack of the 'rename' linux command, my favorite of which enables me to bulk rename files based on a regular expression. Yes, I could hack together an awk or bash script to do this each time, but (like Matt), I like simpler == better.

So, when I ran into this issue yesterday, I decided I had enough. It turns out that the rename linux command that I like (based on regular expressions, not some other more simplistic syntax shipped with Redhat) is just a perl script.

So, I found the script on one of my Ubuntu servers (prename), slapped it into /usr/local/bin, and away I went. Much easier than some other custom compiling Mac solutions.

Wednesday, May 18, 2011

Android and the long-lived authToken



I was very disappointed to hear about Android sending long lived (~2 weeks) auth tokens in the clear for Google services...very similar to the Facebook/Firesheep issue. There are a few writeups, but the research was originally done by Ulm University (http://www.uni-ulm.de/en/in/mi/staff/koenings/catching-authtokens.html).

This specific vulnerability is addressable by server-side changes to enforce SSL when exchanging the tokens. I'm glad to hear that Google is moving forward on fixing this side of things. People are also saying it's only exploitable via WiFi, but I wouldn't be surprised to hear some type of 3G snooping as well.

BUT, this brings up major concerns that the Operating System versions for Android are so fractured, and ultimately are controlled by the wireless providers. Even though the latest version of Android don't exhibit this behavior, the mobile phone companies continue to drag their feet pushing the updates. This is akin to vendors which only support IE6...they drag their feet because they can. I think larger customers need to push back that we need prompt patching (or the ability to self-update!)

Saturday, May 14, 2011

Splunk For Dummies

Splunk can be instrumental when it comes to aggregating and correlating data. However, like any tool there is a learning curve involved. Migrating away from Linux command line tools and learning something new when you're already pressed for time can slow the learning process. I've included a tidbit below that will help you get your data into splunk as quickly as possible.

Use the Sinkhole:
/opt/splunk/var/spool/splunk

Any data you move to this directory will be indexed by splunk and the original log files deleted. No modifying a GUI or adding a listener. Simply getting the data in splunk so that it can be searched quickly. Enjoy!

Tuesday, May 10, 2011

Chrome Falls, Maybe

VUPEN's recent announcement about a possible Chrome flaw has to make everyone say - HEY! Where's the Beef? In a video. Lame. Give us PoC code or keep your mouth shut. I understand security research and selling discoveries. I don't understand selling them and then bragging about your discovery with half-assed details and a video. Sell and shut the hell up to allow your customers to get the full value for their cash. I'd be rather miffed if I were your customer _and had intent_ to use the vulnerability. Responsible disclosure is always an option...

The claim in the advisory:
... we have now uncovered a reliable way to execute arbitrary code on any default installation of Chrome despite its sandbox, ASLR and DEP.
Good find VUPEN! Gratz on taking down Big G's Chrome! Your advisory looks like a Jedi Mindtrick though - "We have the vulnerability you're looking for". Again, I ask you "Where's the Beef, good sirs?" And while you're at it, please explain your intent behind disclosing without Proof of Concept code and lack of vendor contact.

Thursday, May 5, 2011

Interesting Bredo Phish..



Sending MTA: 183.7.110.61, Wed,  4 May 2011 08:31:43 +0000 (UTC)
From: FBI <info87644@fbi.gov> (not real, duuh)
Subject: You visit illegal websites
Body: Sir/Madam,we have logged your IP-address on more than 40 illegal Websites. Important: Please answer our questions!The list of questions are attached. pj  aom  vf
Guess what's attached... Document.zip (9a2bb7c1cfd069e4db5e7d46dadce561) containing document.exe (bd3648a60c4c4760db19bba544c2e8d2)


I found this one interesting because most messages attempting to spread a Bredo variant have been something regarding undeliverable UPS, DHL, or FedEx packages, or your credit card was just billed $700.. Now, you get notified that the FBI wants you to fill out a survey to explain your web browsing habits. Nice change of pace. :)

So sad that this works still.

Tuesday, May 3, 2011

The Cyber Security Conundrum


Ever wonder why cyber security is so hard?
Ever wonder why we deserve more money, resources, etc.?

The graphic above (borrowed) is a simple representation of why defending a network is so much more difficult than penetrating it. Yea I said it, (rebuttals are welcome)! Above we graphically demonstrate the massive landscape within cyber security. The volume of things we support, run, maintain and analyze within a cyber security program on a daily basis is extraordinary. As the capability stack continues to grow (i.e. Data Loss Prevention, Phishing Excercises, <enter new buzzword here>) we must also continue to maintain the cutting edge technology of previous days with a finite set of resources. Meanwhile, an adversary just needs one exploit or an oblivious user to jeopardize the Confidentiality, Availability, or Integrity of the entire operation.        

So when you feel like the chips are stacked against you, they are. So don't dwell and keep fighting!

Monday, May 2, 2011

Blue Coat Partners With FireEye

Last week two of my favorite companies Bluecoat and FireEye announced a partnership. The highlights are below:

"The integration enables malicious domains to be automatically shared from the FireEye MPS to Blue Coat ProxySG appliances, allowing administrators to implement a block/deny policy to stop all attempted connections to such domains and provide logging for customizable reporting specific to the defined categories. Administrators can customize categories and policies to deal separately with zero-day infection URLs and callback URLs. For zero-day, infection URLs, for example, customers can create a policy that refers end users to a coaching page that informs them a drive-by download was blocked. For the callback URL policy, the end user could be alerted that their machine was previously infected and to immediately take remediation steps.  The technical integration works seamlessly and adds significant value to organizations."

This is significant for me as I have done some work in the past at trying to get these two technologies to work together. One such example is a script to scrape certain snort rules (within the FireEye MPS) for domains so that I could feed them to Blue Coat. Use caution with this one as FireEye has some rules for domains that you may not want to block.

I am always in favor of vendors stepping up to create and support a stable solution as opposed to some scripts I hacked up to make my life easier. Hopefully the vendors will do a decent job and not charge an arm and a leg to their customers who already pay top dollar for these technologies!

Sunday, May 1, 2011

A Little About Luck...

Luck is when opportunity meets preparation. - Pete Lopez (professor de Monzy)