SHOCKER – The FBI says Wi-Fi Hotspots are Insecure!!!

It’s hard to believe, but the FBI has recently announced that Wi-Fi Hotspots might not be secure.

I read it here, so it must be true… 😉

In a way I am glad to see public notices like this. Maybe if the FBI draws attention to the problems, average people will pay attention to the solution. Of course, their mitigation suggestions include the “keep your computer patched, use firewall and encryption” routine.

The sad part is that you can do all of these things and still fall victim to a number of security issues such as dns poisoning, DHCP spoofing, social engineering and a myriad of other problems. I guess that is a perfect reason why we push so hard for average folks to use our HoneyPoint:Network Trust Agent product. At less than 10 bucks, it adds yet more capability and ease of use to protecting even non-technical users when they are on untrusted networks, including wi-fi.

Public networks are likely to remain unsafe for users who are not vigilant for a long time to come. Firewalls and patches can help keep them safe, but until they make better decisions about information security and can resist many of the basic attacks that leverage social engineering and the like, free wi-fi will likely be a cyber-wild west for a while longer.

If you want to hear more about protecting mobile users against public network threats, drop us a line. Until then, we will wait to hear from the FBI. Maybe they can help us get the word out that there is help available for wi-fi users.

CA Content Mgr DoS, Unspecified WebSphere Issue

A denial of service vulnerability has been reported in CA eTrust Content Manager. This vulnerability can also be exploited to compromise a vulnerable system. The vulnerability is caused due to boundary errors in certain FTP requests that could result in a stack based buffer overflow. The vulnerabilities are reported in CA eTrust Secure Content Manager 8.0.
CA has provided a patch for this issue.

Also, an unspecified vulnerability in IBM WebSphere Application Server has been reported. Very little details are available regarding this vulnerability. IBM has released fix pack 17 to address this issue (whatever it is).

Are Your Disaster Recovery Plans Ready For A Disaster?

One Data center just found out that theirs wasn’t, and a lot of their customers were also caught with no backup servers, only relying on the Data center’s disaster recovery. On Saturday ThePlanet Data center experienced an explosion in their power room that knocked approximately 9,000 servers offline, effecting over 7,500 customers. ThePlanet was unable to get power back on to those servers for over a day, due to the fire department not letting them turn the backup power on.

Two separate issues can be seen from this, one, the Data center’s disaster recovery plan failed to recover them from a disaster. While quite unlikely to happen, an explosion in the power room can happen, as seen here, and they were not prepared for it. Perhaps they could have worked with the fire department during the disaster recovery policy creation to identify ways that backup power could be served while the power room was down. Or possibly with 5 Data centers (as ThePlanet has) they could have had spare hot servers at the other sites to send backups to. We don’t know the details of their policy or exactly what happened yet, so we can only speculate ways that the downtime could have been prevented.

Secondly, many customers found out the hard way to not rely on someone else’s disaster recovery plans. These sites could have failed over to a site at another Data center, or even a backup at their own site, but they weren’t prepared, assuming that nothing could happen to the Data center their server is at.

The lesson learned from this mistake is that disasters happen, and you need to be prepared. No disaster scenario should be ignored just because “it’s not likely to happen”. So take a look at your plans, and if you host at a Data center, if your website is critical make sure there is a backup at a separate Data center or on your own site.

Time to Play Some Offense…

To quote, Allan Bergen, it sure looks like it might be “time to play some offense”…

Not surprising to me, I read today that the primary security concern of IT managers is the inside threat. It doesn’t surprise me because I have been working on educating organizations for several years about the seriousness of the insider threat. In fact, I would suggest that there are very very few threats that are NOT insider threats. Why? Because there really is no inside or outside. Thanks to disruptive technologies and evolved attacker capabilities – just about everything is exposed to attack. Just ask some of the recent vendors who were compromised in high profile “PCI-related” cases how well they feel that their “perimeter security” protected them…

The truth is, there are three powerful things that can be done to combat modern attacks, whether internal-based or executed by attackers half a world away.

1. Implement and enforce data classification – Know where your critical assets are, how they move around your environment throughout their lifecycle and then use tools like access controls, encryption and integrity verification to make sure that they are protected. Use logging analysis and event management to detect issues and make sure all of the controls, including role-based access controls, are HEAVILY and PERIODICALLY tested.

2. Embrace enclaving – Enclaving is like defense in depth throughout the whole network. Establish proper need to know boundaries, then build enclaves of security mechanisms around the data. Don’t build networks that trust user workstations with access to databases and other servers, segregate them with firewalls, detection mechanisms and access controls. Build as much security for the users as makes sense, but design the environment so that if users make bad decisions (which they will) and get popped – so what! Client side exploits and malware are only a concern if users have access to inordinate amounts of data. The problem is making sure that you get your controls and practices tight enough to limit the exposure that user compromise presents. That alone should go a LONG way toward minimizing your risk if done properly.

3. Move up the security stack to Threat Management and Risk Assessment – Use processes like risk assessment as a factor in business decision making. Security can truly empower business, but you have to let security teams stop being the “patch patrol” and “net cop” and let them get to actually helping you manage risk. They have to be able to identify threats, model threats and understand attacks and exposures. That requires education, dependable tools and upper management support. Encourage your security team to mature and begin to take real-world risk into consideration. Help them to resist the cult of the arcane technical security issue…

Of course, MicroSolved can help you with all three of these areas. We have the experience, insight and expertise to help you build effective enclaves and design data classification systems that make sense. We can help your team find security assessment goals that make more sense and provide ongoing assessment to keep them focused on the real-world risks. Our HoneyPoint products can help them model threats, frequency of attacks, understand the capability and intent of attackers and even give them deep insight into proactive risk metrics that they can leverage for “more science than academic” metrics of risk measurement. All of these things help your organization protect against the insider threat. All of them are available today.

The bottom line is this – if you are an IT manager looking to defend against the insider threat – give us a call. Together we can apply these strategies and others that your organization may need to effectively manage their risk and protect their assets.

At MicroSolved, we think differently about information security. So should you.

Apple Releases Security Update

If you’re running an OS X version below 10.5.3 it is time to upgrade or install security update 2008-003.
This update fixes multiple issues that could result in system access, security bypass and privilege escalation, DoS, Cross Site scripting and a number of information exposure issues.

The original advisory is available at: http://support.apple.com/kb/HT1897

Snort Issues In Case You Missed Them and Malicious SWF

In case you missed it last week, Snort seems to be suffering from a problem with odd TTL values, which could allow an attack to get by Snort without detection. 2.8.1 has been released and includes the fix for the issue. Users of Snort should upgrade as soon as possible or apply the following workaround until they can update:

/From iDefense/

In the snort.conf file, set the ttl_limit configuration value to 255 as shown below.

preprocessor frag3_engine: ttl_limit 255

This will set the allowable difference to the maximum possible value, and prevent fragments from being dropped.

/End iDefense Content/

Also, SANS is talking about malicious SWF files that have been found online. Looks like they are using some encoded images that can cause some issues with what may be a previously known flash player vulnerability. Advise your users to be wary of flash enabled sites that they would consider “untrusted”. Of course, your milage may vary with this one, but at least awareness might help….

Lastly, as refresher, if you are a Notes/Domino user, it might be a good idea to check out patches that have been released lately. There have been a number of issues in the last few weeks and we are seeing an increase in Domino fingerprinting on some of our non-US HoneyPoints. Looks like quick scans for names.nsf and a couple of other common Notes files. So far though, we have not seen any attacker activity out of the norm, but it may be the precursor to an attack or other activity. Just an FYI…

What is “Defensive Fuzzing”?

Since the release of HornetPoints with the newest version of HoneyPoint Security Server, I have been getting a lot of mail asking about “defensive fuzzing”. I thought I would take a moment and talk a little bit about it and explain a bit about its uses.

Defensive fuzzing is a patent-pending approach to network, system and application defense. It is based on the idea of using techniques from “fuzz testing”, but applying them against incoming connections in a defensive manner rather than as a test mechanism for known software. The idea is that attacker tools and malware probably fail to meet established best practices for software development and thus, are likely to have issues with unexpected input just as normal professionally developed software does. Further, “defensive fuzzing” lends itself to using fuzzing techniques as a protective mechanism to cause attacker tools, malware and other illicit code to abnormally terminate. Basically, by fuzzing incoming connections to a HornetPoint (which should have no real world use, thus all incoming connections are illicit) we can terminate scans, probes, exploits, worms, etc. and reduce the risk that our organization (and other organizations) face from these attacks.

For those of you who might not be familiar with fuzzing, you can read more about the basics of it here. However, keep in mind, that defensive fuzzing applies these techniques in new ways and for a protective purpose rather than a software testing process.

HornetPoints simply embody this process. They can be configured to fuzz many types of existing connections, emulating varying protocols and applications. For example, targeting spam and relay scanners can be done by implementing the SMTP HornetPoint. It listens on the SMTP port and appears to be a valid email relay. Instead, however, it not only captures the source and traffic from the spammers, but also fuzzes the connection as the spam is sent, attempting to terminate the spammer scanning tool, bot-net client or other form of malware that is generating the traffic. Obviously, success rates vary, but our testing has shown the process to be quite effective against a number of tools and code bases used by attackers today.

That is just one example and many more are possible. For more information about defensive fuzzing or HornetPoints, please leave us a comment or contact us. We would be happy to discuss this evolution in security with you!

Lotus Domino Cross Site Scripting and Buffer Overflows

At least two injection attack vectors have been discovered in IBM’s Lotus Domino Web Servers versions 6.x, 7.x and 8.x. These can lead to a stack based buffer overflow which may allow remote code execution and Cross Site Scripting attacks that can allow the execution of arbitrary HTML and script code. We recommend that you update your web servers as is appropriate.

The original advisories can be viewed at:
http://www-1.ibm.com/support/docview.wss?uid=swg21303057

and

http://www-1.ibm.com/support/docview.wss?uid=swg21303296