You check your email and receive a suspicious file and your antiviral scanner didn’t throw any flags so you wonder, is it safe to open? There are some things you can do when you get a possible virus that not only helps you, but the entire security community as well.

1. Surf to http://www.virustotal.com and upload the possible virus. VirusTotal then scans the file using numerous antivirus programs to determine which ones detect the file as a virus and which do not.

Now if none of them detect it as a virus, this doesn’t necessarily mean its safe to open, but at least you’ll know for sure if VirusTotal does detect it. Another site that offers a similar service is http://virusscan.jotti.org

2. Review the binary with your favorite “strings” type program, which grabs any text out of a binary for you to view. You might use strings from Unix/Linux or BinText for Windows, or even some editors. Be very careful not to execute the file, but examine it for strings. Keep on the look out for things like registry keys that execute commands, networking calls, URLS, etc. This isn’t 100% effective, since some information could be encoded or encrypted inside the binary code. Note that you might also need to use an unpacker on the binary to do this. Try this before hand with known good tools and get some practice with both unpackers and strings-type utilities.

3. Lastly, if both of the previous steps show nothing, you might also consider setting up a test machine or a virtual VM image and run the possible virus in that test environment, but this is not recommended for the faint of heart or techinically unsavvy. For the average user, uploading it to VirusTotal and then deleting it would be enough. Tools like wireshark that capture incoming and outgoing packets would provide valuable insight in an investigation of this sort. Some malware is smart and won’t immediately begin sending data as soon as it starts, but will delay its actions to fool investigators into thinking it is benign, so be aware.

4. For those of you who are more advanced with code and development, or those looking to become more advanced, you could also investigate the use of a debugger or other reverse engineering tools. If so, it is beyond the scope of this article, but check around the Net – there are many articles dedicated to these tools and techniques.

These are merely basic steps and ideas. Each step requires skills and additional practice that new users or less advanced users may not have. When in doubt, simply delete. If the file was sent to you by someone you know personally, play it safe and call them.

So, try these at your own risk. Your mileage and paranoia may vary…

They put an exploit in, they put a patch out, they put an exploit in and users turn themselves about… You get the idea (sorry, I know it’s bad)…

IE users (and Microsoft) are having a particularly bad couple of weeks. First the VML issue became critical and widespread, with all the associated user confusion of the work-arounds and such. Microsoft then releases an out-of-cycle patch, only to be one-upped by attackers who almost immediately release a reworking of a formerly DoS attack into yet another remote code execution bug in IE.

As with VML, this new “old” bug is likely to be widespread and adopted into various bot and browser vulnerability frameworks. Basically, continuing to make it even more unsafe for users to browse the web at large than before…Blah, Blah, Blah… Just as before, repeat – because apparently “that’s what it’s all about”.

😉

In the meantime, while we wait on patches for this latest IE exploit, do the usual. Try and educate users about safer browsing choices, reinforce the idea of enclave computing with your management team, harden your browsing environment as much as possible and make sure IDS/IPS signatures and AV/Spyware signatures are up to date.

Oh, and if you have time, learn the hokey pokey dance. It’s helpful at weddings and looks like it might be a good skill to have for the coming months!

The CEO of my company (MicroSolved, Inc.) recently returned from a trip to Aruba, in which he was forced to endure the ban on liquids and gels on airlines. While patiently complying with the wishes of the TSA inspectors, he began to wonder if the additional inconvenience was worth the minimal decrease in security risk that the average airline customer would experience. Upon his return, he did a little research about the current rates of injury or death when performing everyday tasks, such as flying, driving, swimming in your backyard pool, and walking in the rain.

While the research revealed some very interesting facts regarding the risk involved with performing these everyday tasks, it prompted me to ask a different question. Our CEO was interested in knowing if the inconvenience was worth the reduction in risk. I asked whether the inconvenience was worth it at all. Did it even work?

I immediately began to think about how we got to the point we currently find ourselves, in regards to Anti-Terrorism and Information Security. Can we find a way to tie Anti-Terrorism measures and Information Security measures together to get an idea of whether the Anti-Terrorism measures can ever be effective?

When thinking of Information Security, the first thing that comes to mind is one despicable word: Signatures. Nearly every school of thought that has been bought into by security professionals involves the use of signatures to detect an attack. Your Anti-Virus relies on signatures to identify malware. Your Intrusion Detection/Protection devices rely on signatures to identify attacks. Your spware/adware detection devices rely on…you guessed it…signatures.

Signatures have proven to be quite effective…AFTER THE INITIAL ATTACK. The problem is that someone or something would have to have already seen the attack, in order to create an accurate signature. This holds true with today’s current Anti-Terrorism strategy. Think about just about every strategy that has been put into place to identify (or protect you from) a terrorist attack. We don’t implement bans on “liquids” until AFTER someone has already seen that particular method. We don’t restrict the use of metal silverware on a plane until AFTER someone has used a butter knife to hijack a plane.

There is a portion of the Information Security community (me included) who believe that we have already lost the war against malicious attackers. Of that portion of the community, several of us firmly believe that we are at a crossroads in what Information Security is now and will be in the future. A couple of us believe that it is now time to recognize that the good guys have lost the war and it is now time to pull back and focus our efforts on securing the critical data and leaving the users to their own devices.

There is a term floating around out there that speaks directly to this school of thought: Enclave Computing. Whereby, we would attempt to begin to identify the critical information that needs to be protected. Once we have identified the critical information, we move it to a secluded part of the network , or “enclave”, and wrap controls around it that dictate who and what has access to the information. We give the user base everything that we can give them for protection, but we don’t care about what happens to their boxes. We don’t care if they get compromised, because no critical information is stored on the machine. If one of their machines gets compromised, it becomes a turn-and-burn situation. That machine gets imaged and is back in operation in less than an hour. The information, being secluded from the compromised host, remains secure.

Now, I’m not condoning the thought that the government needs to consider leaving the citizenry to their own devices. I, a former US Marine, am absolutely certain that the War on Terrorism is something we can and will win, not to mention that we HAVE to win it. What I am afraid of is that we don’t know HOW to win. If we keep following the path of relying on signatures to protect our citizens and their information, as the War of Information Security has shown, we will lose.

As a country and an industry, we need to get back to our roots. We need to rely on that ingenuity that Americans so proudly brag about. We need to find pre-emptive solutions to defending our country and her information. I don’t know what the answer is to waging the War on Terrorism. I do know that MSI is using that “American Ingenuity” right now to create solutions to help us defend our information. What forward thinking organization will be the one to break new ground in providing a realistic method of waging the War on Terrorism?

One final, albeit scary, thought that remains just as true for National Security as it does for Information Security is something that the President has been quoted when saying that our enemies “only have to be right once; we have to be right 100 percent of the time”

For several days we have been monitoring the explosion of the VML 0-day for Internet Explorer. It has become clear that this is a significant exploit.

Attackers began almost immediately to spread and improve the exploit once it was published. It was quickly included into several vulnerability and exploit tools. It took a suprisingly short amount of time for the incidents to begin to pop up around the Net.

The fact that Outlook is also vulnerable added to the fuel of the underground, as attackers with all kinds of motives began their assaults. They continue, even as I write this.

The exploit is ugly and dangerous. It has multiple attack vectors, including web and email, and attackers have refined the code until they now have the capability to do proper version checking and adapt the exploit to a variety of platforms.

Currently, some AV vendors have been less successful in defending against this problem than others. Many AV vendors are working hard to keep up with the ever changing set of binaries that the exploit examples download after the exploit runs. We all know this is admirable, but a losing battle. Truly resourceful attackers will grab code that is in no database, and even basic attackers will be able to modify existing tools to bypass the rudimentary checks many vendors are using.

In the meantime, the workaround is continuing to be used and refined as well. If you can get by without VML, unregister the DLL to protect yourself and your organization. Security teams should be making this decision quickly, as it may already be too late.

The last we heard, Microsoft is scheduled to release the official patch on Oct. 10. This means there is still plenty time for attackers to identify, target and exploit users around the world. The work around may be the best defense until the patch becomes available.

Stay tuned to your normal security intelligence sources for more information as it becomes available. Check out WatchDog if you are looking for such a source. It is available FREE from http://www.microsolved.com/watchdog

In many of the conversations I have been having lately with InfoSec managers, some of them seem to have forgotten some of the basics of our relationship with attackers. They seem to have forgotten some of the basic tenents of security and they certainly don’t seem to be aware of Murphy’s Law.

So, let’s review a couple of items – just for refresher.

The first item is that attackers control the pace, not defenders. They are in control of when attacks occur, where they occur and how serious they are. Now we, as defenders, have some capabilities here to try and make sure we have minimized the impact of these incidents – but we have NO CONTROL over the timing, pace or location. Those items belong to the attacker.

Second, attackers will focus on your weaknesses, not your strengths. That is simply what smart attackers do. If you build all of your defenses and post your armies of cyber soldiers to brace for a full frontal assault, it is likely that a smart attacker will flank you. This is elementary in warfare, and it is a real and vital part of InfoSec too. You have to allow for defenses that embrace your assets and not just protect the obvious issues. You have to be ready for defending the subtle assets and locations too. Gone are the days, if they ever really existed, of attackers impaling themselves on your firewall and IDS/IPS in mass. Today, attackers are more subtle, more evasive and target things deeper in your territory. Things like users, client-side vulnerabilities and remote access points are juicy targets for today’s attacker.

As for Murphy, InfoSec managers need to remember, attackers will exploit timing issues without concern. They will leverage the fact that you are down a headcount, that your entire staff is at a week of training, that your budget does not have room for the sudden purchase of a security tool to combat a new threat. Attacks will come at the worst possible moment, so you might as well plan for them. Got a merger coming up, or an important period of business in the run for the end of the year? If so, it would be wise to ensure you preserve some resources for possible incidents and attacks. Murphy says they are just likely to happen when you need them least.

Again, I know these seem pretty basic, but they are truths of security and defense. They are universal, uncaring and painful if you have to learn them the hard way. So, build them into your plans and be ready to explain them to other management. The more you study them up front, the less they can harm you down the road.

RFID is the crest of an approaching wave of ubiquitous computing, a trend where small computing devices will be everywhere in your daily life. Manufacturers rushing to be first to market designed them to be cheap and to consume very little power. In the process, they sacrificed good security practices like strong encryption and proper privacy protection. Researchers at RSA and Johns Hopkins Information Security Institute are calling the RFID security protections “inadequate” and have demonstrated several ways to crack the devices. Another group at Vrije UniversiteitAmsterdam have created proof of concept viruses that would spread from one RFID tag to another effortlessly. How can something so high-tech be so fraught with security holes? RFID as implemented now in the lower-priced tags is a pandora’s box which has already been opened.

One of the more interesting uses of hacked RFID technology is when a man copied his hotel key’s RFID signature into the electronic price tag on a tub of cream cheese and opened his hotel door with the food container. Anyone with the right hardware and software could alter the price of every RFID tag in a warehouse or store to scramble them or swap them, due to poor encryption and other design flaws. As these devices grow in popularity, they will increasingly become a hot target for thieves and organized crime. RFID will soon be integrated into everyone’s passport which is sure to draw the attention of terror organizations in search of low-hanging fruit. These RFID tags aren’t just being used in experimental labs, no, they are in production in cars, hotels, toll lanes, and more. If a society is going to rely this heavily on a technology, shouldn’t it be secure?

Sacrificing security for cost in this case will cost the world more than the few cents they saved per chip. The short-sightedness of some RFID designers has set the stage for what could be one of the biggest disasters to hit ubiquitous computing. The problem is that the public knows nothing about the subtle nuances of what is needed for secure RFID, and manufacturers don’t feel any pressure to make their chips secure if their competitor doesn’t have to. Governmental standards should be enacted requiring strong encryption for these tags because the industry has failed to regulate itself in this regard. Consumers need to educate themselves about the power of and problems with RFID and how it can affect their own life. Ultimately, good security always comes back to user education.

Ruby on Rails has seen wide adoption since its introduction. It is a very powerful platform for rapid prototyping and develppment of web-based applications ranging from the trivial to the complex. Up until now, it was also thought to be very secure.

Now, all of that may change. As I write this, a very serious vulnerability has been identified in RoR. While the Rails management team have released a patch to RoR that they have termed a “mandatory upgrade” , it should be considered very likely that some group of attackers may have already been aware of the issue. As such, careful inspection of logs and such should be performed for any and all RoR applications.

Given the wide range of applications deployed on RoR, organizations using it should be paying very careful attention and applying the upgrade as soon as possible.

Attackers have long focused on web applications as a primary target. We have seen wide scale attacks against many other web platforms from PHP to the Horde framework. Now some of that attention may shift to RoR. I, for one, hope it can handle the pressure…

I have been hinting that something big was coming for a few weeks now, and it is finally time to talk about it.

The big news is the release of MSI’s first enterprise security product – HoneyPoint.

HoneyPoint is designed as a direct response to the pain that I have been hearing about from network security folks for several years now. That pain is the general failure of network-based Intrusion Detection and Intrusion Prevention systems (IDS/IPS) to live up to the hype that surrounds them. Over the years, the idea of IDS has grown from a simple system of matching packets against a few signatures to a much larger beast.

Today’s IDS and IPS systems are broken. Most depend on signatures (be that against network packets or system & application logs). They compare the current traffic or events against that signature base and make a decision about the malicious intent of the traffic or events they are seeing. This was a great idea, to be sure, but it has largely failed to reach the promises vendors have been making for nearly a decade. There are simply too many signatures, too many nuances of traffic, networks have become too complex for effective IDS management and there is too much noise on modern networks for the signature-based approach to remain fully viable.

Now, before every IDS/IPS vendor in the world calls to tell me about their latest technology or technique to auto-tune, establish relevant baselines or use traffic patterns instead of signatures, I want to simply say this. Great! Good for you. But, I am not interested in hearing much about it. The current idea of IDS/IPS simply does not work. It is broken. Period.

Another reason why I say that is this – I have spent the last year talking directly with IDS/IPS users and hearing about their pain. They are spending way too much time tuning, updating and managing their IDS/IPS solutions. Even those that outsource their management, say they still spend way too much time working on false positive events or tracing issues that turn out to be nothing or worst of all, fighting against bot-nets, client side exploits, zero-day issues and other items that their detection systems failed to identify or stop. To put it simply, as one person did for me, they are “spending more time on managing the IDS than they are on responding to the 10K and more alerts it gives them each day.” To add insult to injury, of these 10K alerts – the majority of them turn out to be false positives.

Since threats are evolving and pushing into the organization at a much deeper level than the perimeter, and every trade magazine and security visionary is telling security teams to switch to enclave computing and begin to take an asset-centric approach to security, that is exactly what security professionals are doing. The problem is, they are finding that traditional IDS/IPS solutions are really not meeting the needs of securing the internal network in a meaningful way.

Thus, the paradigm shift that is HoneyPoint. The idea is an old one. The implementation is new. The idea of honeypots goes back a long way. They are essentially based upon the idea that if you create artifical systems or services on your network, an attacker will not know if what they see is real. The idea is that in order to determine what is real, they will have to probe and attack all of the visible targets. In doing so, they will, in more cases than not, probe a honeypot – thus alerting security folks to their presence. Obviously, the more honeypots, the higher the likelihood of their being probed instead of a real system.

This is the basis for HoneyPoint. We use it to make our systems offer services across the network that appear to be vanilla and homogenous. Imagine a big 10×10 grid of light sockets. If you had a light bulb and were asked to screw it into some of the sockets in the board, but some of the sockets were real and would light the bulb, while others would set off an alarm – how would you go about identifying which ones were real and which were alarms? You might carefully examine them, but if they all look similiar, the only way to know would be to try them.

That is exactly what we do with HoneyPoint. We dialate ports across our systems with similiar appearing services, and then wait for attackers to try and figure out which ones are real and which ones are HoneyPoints. Just by doing what attackers do – that is, probing the network and services they find – they fall into our trap and alert us to their presence. Once identified, they can be quickly isolated and shut down by network security staff.

The most beautiful part of all of this is the lack of false positives and signatures. Since the services offered by the HoneyPoints are not real, there is absolutely no reason at all for anyone to be using them. That means that ALL TRANSACTIONS WITH A HONEYPOINT ARE REAL EVENTS. Since the HoneyPoints key in on the idea that a transaction has occurred, and not what it was; they have no need for signatures (thus, no need to update and tune them). They simply capture the traffic they see, identify the source and alert the console of the event. Simple. Easy. No muss, no fuss – no additional management. The alerts from the console system can then be handled by the security team as an incident.

Alerts can be delivered via email, SMS (with a gateway), syslog or Windows Event logs. The console and HoneyPoints run on Win32, Linux/UNIX and OS X. Given their flexability, they can emulate thousands of services ranging from complex HTTP applications to RFC compliant implementations of your chosen mail platform. The variations are as flexible and endless as your imagination.

The HoneyPoint solution is built upon the idea of “deploy and forget.” HoneyPoints need only be installed and configured one time (leaving more time for vacations). They then operate as services or daemons (depending on OS) and simply wait for attackers to probe them. They have miniscule file sizes and memory demands, meaning you can run thousands on an average workstation size system with little impact, should you so desire. We suggest that you deploy them across your enterprise on your existing systems. No new hardware is needed.

Take a few minutes and visit the HoneyPoint web site at: http://www.microsolved.com/honeypoint for more information. Take it for a spin by filling out the form and get your FREE 90 day trial.

I think you will quickly come to understand why we are so excited and why security teams from many of our customers are telling us we have changed the way they think about securing thier environments!

Thanks for reading and for being patient while we brought HoneyPoint to life. I think once you use it, you’ll agree – it was well worth it!

MSI is pleased to annouce that we will be moving soon to our new offices. We intend to do so in the next couple of weeks. The new building is located on the West side of Columbus and is a major upgrade for us in terms of space and useability.

Stay tuned for announcements on the new address, but the phone numbers and web presence will remain the same – of course.

Thanks for your patience the last few weeks and in the coming days while we prepare for and execute the transition. Blog entries have been and will likely be slower while we pursue the move.

Thanks to everyone who has helped make this possible and who has worked with us to prepare!

I have been getting a few emails asking why I have been so quiet and where the podcast is.

The podcast has been delayed a bit, sorry for that. I am working on it. Maybe within a week or two I will have it ready and then can get an idea on how often we will do them.

In the meantime, I have been so quiet because I am working on a pretty major project. Stay tuned in the coming weeks for a large announcement from us about a very cool new software product we are about to release. I am very excited, and I think you will be too.

In the meantime, Neil and Troy have been carrying the blog traffic, and I have been continuing to write over at security.itworld.com. Check out my article this week for some insight into why I think IDS/IPS solutions are failing us.

Stay tuned, I promise it will be very interesting…