I’m sure if you’ve been paying attention to any of the tech/geek news blogs you’ve seen the attention given to the “COMPROMISING ELECTROMAGNETIC EMANATIONS OF WIRED KEYBOARDS” article. So you already know the buzz, and are probably all running out to build Faraday cages around your offices or workstations. But there really isn’t anything terribly new or ground breaking here. It’s simply a further spin on an old trick.

Anyone who can remember back might recall a little something about “TEMPEST”. It’s the codename given to compromising emanations (CE). This research dates all the way back to 1985 when the security risks of emanations from computer monitors was analyzed.

By no means do I want to take away from the research and proof of concept that Martin Vuagnoux and Sylvain Pasini have put together. I simply want to focus on the fact that a lot of us, especially those young in the tech and security fields, are forgetting some of the roots. We’ve already pointed out some other old-school hacks that are still relevant today. So while everyone is hardening their systems for super stealth ultra-sensitive attacks against their systems, let’s not forget where we came from, and proper education of old-school attacks deserves some attention as well.

The example I used to segue into this might not be the most stellar example of outdated attacks, as with technology growing, it might even become more of a common-day attack. But the fact that this goes way back, and technology is only making it easier goes to show – things that we think are out of reach today, aren’t  far from reach in the not-so-distant future.

So what do you think? What other areas of our past or even present do you think won’t hold any grounds for security in the not-so-distant future? What old-school hacks are still present today that many might be overlooking? Let us know in the comments…

The new “bad” is clickjacking where an attacker underlays a malicious web page under a legitimate one, and when you think you’re clicking on one thing, you’re actually clicking on another. We actually use this technique to make it easy to use our phpasndump tool (the Browse button is over top of the entry field so that when you click on it, you’re really clicking on the entry field).

There are multiple vectors of attack, including iframes, javascript, and flash. However, they all do the same thing. The article linked above talks about all of the different types and whether there is a patch available. However, the best defense is one that security people have been harping on for a very long time – disable javascript, disable java, and disable plugins (flash, silverlight, etc). That still leaves one vector open: iframes. Firefox’s NoScript extension can disable those for you (as well as selectively run javascript). This can cause problems for “normal” browsing however, as most of the web is highly dependent on javascript and flash. You’ll have to play with the settings and determine your best mix of usable vs “safe”.

James Madison University (JMU) held an open cyber defense competition on Saturday of this past weekend for all current or former students. A few of us here at Gemini had the opportunity to attend and participate as the attackers. It was a great experience for me as well as the students.
The students were faced with the scenario of being hired into an already existing IT infrastructure after the entire network team had previously been fired. With a tight deadline and the need to keep standard business operations running, they had to secure all computers/servers and continue to process ‘business requests’ as they came in. The students were given a one hour head start to secure as many devices as possible, and then it was free reign for us attackers.
All in all, most teams ended up falling to the majority of the same attacks or forms of penetration. The following is a list of the most common ways we were able to penetrate their systems.

• Default Passwords – Every team except one fell victim to this. Leaving at least one system or process running under the default admin account/password. Even though we were given the knowledge that all systems had been setup with the default password, this still gives the scenario of systems using blank passwords or ones that would be easily guessable.


• Running Older (vulnerable) Software/Processes – Two of the teams fell due to running an older version of Apache. We noticed this and exploited it right away. The remedy to this would have been patching or upgrading immediately.


• Installing Unknown Software – The teams were given a business task to install spam-blocking software on their e-mail servers. The software that was given to them contained a rootkit. At least three teams installed this, with two falling victim and the other noticing and taking down the mail server while it was fixed.


• Physical Access – We got a little mischievous during lunch as we knew the students would be away. We took a peek into their rooms to find unlocked screens. We took best advantage of this. Sure it was easier for us because we knew they would be out, and it was only one room over. But it only goes to show that even the smallest amount of time is enough to be compromised.


• Un-patched E-Commerce Site/Engine – The teams were running Zen-Cart as their e-commerce engine. It just so happens that a SQL injection vulnerability was disclosed only a few days prior the competition. All but one team failed to patch this vulnerability.


• Not finding the real problem – One of my coworkers got into a mini battle with one of the teams continually opening an SSH connection only to have it dropped. The team was noticing the process and simply killing it. This went on for a good while before we finally hosed the system. The team kept killing the process, but not recognizing the fact that we had our own account already on the machine, and that’s how we were continuing to maintain access.

Four out of the five teams took some major hits due to one or all of the above attacks. The one team that held the best did take hits for not maintaining proper services running at all times. In the end, it was clear this was the correct thing to do. They would take down a system completely, wait until the system was completely patched/upgraded and only bring it back up once they knew it was locked down properly.
All in all, it was a great learning experience for the students and for me. They learned what kind of real-life scenarios they could potentially face, and I got to ramp up on my pen-testing skills in a fun way. Kudos to all the teams that participated at JMU, and I hope to take part again sometime soon.

Your company creates a custom web application and deploys it live. I bet it went through some serious security testing, and even the development process had security in mind from the design stage right (it should have). So if all this effort is put into a custom web application, why isn’t the same being done for your company’s blog?

Blogs are nothing more than web applications. And unless you created your own blog engine from scratch, you are using some third party solution (Wordpress or TypePad). This means you’re trusting the software is free of any vulnerabilities and has been developed with secure coding techniques as well. It’s one thing to insist your developers use secure coding techniques but it’s a way different scenario when you’re dealing with third-party, Internet facing applications like blogs.

If you’re going to be using third party web applications that you cannot guarantee are secure (and you can’t) then you ought to be taking advantage of a web application firewall (WAF). A web application firewall can protect third-party applications just as easily as it can for custom developed applications, and in many cases it is actually a lot easier.

In a lot of companies blogs are the web face for the company (at least one could hope). It’s important to realize that thereare risks here, especially if it’s pulling the the most hits and getting the most attention. So stay protected – use a WAF!

Sonoma State University computer science professor George Ledin is teaching his students how to hack and creating controversy in doing it.

The companies that make their living fighting viruses aren’t happy about what’s going on in Ledin’s classroom. He has been likened to A.Q. Khan, the Pakistani scientist who sold nuclear technology to North Korea. Managers at some computer-security companies have even vowed not to hire Ledin’s students.

...

Ledin insists that his students mean no harm, and can’t cause any because they work in the computer equivalent of biohazard suits: closed networks from which viruses can’t escape. Rather, he’s trying to teach students to think like hackers so they can devise antidotes.

I’m surprised that such courses aren’t more prevalent and the backlash that Ledin (and potentially his students) will face. The best point of the article is made by Ledin himself,

“Why should we shy away from learning something that is important to everyone?,” Ledin asks. “Yes, you could inflict some damage on society, but you could inflict damage with chemistry and physics, too.”

When you base security on people’s ignorance, you just get ignorant people fighting clever criminals.

Telephones are unsecured, direct access conduits to your users and can traverse passwords, encryption, and any other fancy technical protections.

Many people are confident they won’t fall for the “you’ve just won a million dollars, give me your bank account information so we can transfer the money!!” type of scheme. If it’s too good to be true (as they say) it usually is.

Put people on the defensive and these tricks work a little better.

The phone rings, you pick it up, and the caller identifies himself as an officer of the court. He says you failed to report for jury duty and that a warrant is out for your arrest. You say you never received a notice. To clear it up, the caller says he’ll need some information for “verification purposes”-your birth date, social security number, maybe even a credit card number.

Social engineering works because people are the weakest link in security. Training to protect against these attacks in a work environment are difficult, especially to positions that require many phone calls. Employees caught off guard, stressed, or disgruntled are particularly vulnerable.

More technical details can be found at this excellent piece at Matasano Chargen.

Tiger and Leopard shipped with the Apple Remote Desktop agent (ARDAgent) is set UID as root. To make it worse, it supports AppleScript, and one of the actions it supports is “do shell script”. You can see where this is leading. This type of vulnerability (root access through a SUID root program) is one that I would classify as ancient. Most SUID root programs really look at the code and make sure they’re not doing something this stupid.

The solution is easy: if you’re not using Apple Remote Desktop, remove it, or chmod u-s it (removes the SUID bit).

However, this vulnerability does need local access, so it’s somewhat difficult to exploit unless you regularly leave your mac logged in at a coffee shop while you use the facilities.

What it does bring up is how much Apple is investing in secure development and security? If this (quite old style) vulnerability got through, what else would. Of course, Apple may not have any security employees old enough to remember these types of vulnerabilities. History, even of old systems and old vulnerabilities, is still useful for teaching students.

Core Security released details on three iCal bugs last week. What’s suspicious is that Apple hasn’t fixed them yet, despite being told in January. The bugs are relatively harmless if you have iCal configured correctly – ie. to not automatically parse invitations from Mail. Unfortunately, that’s not the default on Leopard. I’ve run into the same problem before, and I turned the “feature” off for other reasons.

There’s a bug in the ics parser that could potentially allow for remote code execution. Not good.

Any program that automatically opens up attachments from your mail reader -Mail, Outlook, Thunderbird, etc. SHOULD BE RECONFIGURED! The same goes for remote images. Any attachment should be suspect unless you know who it came from, and SPAM does not qualify as “knowing who it came from”.

This simple configuration/re-configuration can save you a lot of headaches in the long run, in addition to any known vulnerabilities floating around, you’ve closed off a vector for new ones.

Hackers pulled off an attack that had a physical effect when they found a way to post flashing images on an epilepsy forum. Some users of the site experienced migraines and “near-seizure reactions.”

The attack happened when hackers exploited a security hole in the foundation’s publishing software that allowed them to quickly make numerous posts and overwhelm the site’s support forums.

I remember learning in my computer ethics class about bad programming practices that led to physical injuries and even death. Lax security can have all sorts of effects, and when you see someone intentionally trying to bring physical harm to a group of people, you get an idea of the type of person we’re working against.

At the ToorCon conference in Seattle this past Saturday, Microsoft announced it would allow ethical hackers to test and probe it’s services.

In a first for a major company, Microsoft has publicly pledged not to sue or press charges against ethical hackers who responsibly find security flaws in its online services.

I personally think this is great news, and wish more larger companies would do the same. Far too often are valid security holes being found, and not reported in fear of repercussions, and those same holes are then exploited by real hackers for their own personal gain. We need a community more open to the fact that there are good guys out here who are trying to help.

Luckily it seems I’m not the only one with these views.

Katie Moussouris, a Microsoft security strategist, said she is pushing to get a provision added to a proposed standard that’s making its way through the International Organization for Standardization that would protect ethical hackers who responsibly disclose vulnerabilities in other companies’ websites. “If I get my way, it’ll be in there,” she said.