I finally got my Black Hat presentation materials in, beating the deadline by just a few hours. I’m co-presentating with Keith Jones of Jones, Rose, Dykstra & Associates .  We’re talking about ”insider” attacks and the challenges faced by investigators in tracing such attacks to their origins (presentation title: Smoke ‘Em Out).  Like all my other presentations, this one too, revolves around real and almost real cases that we have responded to. “Almost” because the cases are not public knowledge and have  been altered just enough to protect the identities of those involved; except ours ofcourse. Enough said about my talk.

For those who are interested, I plan on attending the following sessions-

Dan Kaminsky’s talk - his talks are always great

Jeremiah Grossman’s presentation - a must attend for those interested in application security

Kris Kendall (a good friend of mine) and Jamie Butler’s talk – these are two of the sharpest reverse engineering dudes. I have to believe they will have some eye-opening stuff.

Joanna Rutkowska’s speech, if I can get in the room

Adam Laurie’s presentation - because I’ve always missed his presentation on RFID haX0ring

David Coffey & John Viega’s talk  - a very pertinent topic, especially for the manager-types

When it’s not Black Hat, it will be Black Jack….at cheap hotels  :)

-Rohyt

This morning the story that caught my eye was a Slashdot link about CallerID Spoofing to be Made Illegal.

`(1) IN GENERAL- It shall be unlawful for any person within the United States, in connection with any telecommunications service or IP-enabled voice service, to cause any caller identification service to transmit misleading or inaccurate caller identification information, unless such transmission is exempted pursuant to paragraph (3)(B).’

You can read the full text about it here: http://thomas.loc.gov/cgi-bin/bdquery/z?d110:s.00704:

During the last couple years I’ve made use of the Telespoof.com’s caller ID spoofing service during telephonic social engineering engagements. Spoofing caller ID is something a motivated attacker will do to look more legitimate. I’ve also seen an occasion where spoofing the caller ID could fool certain PBX systems into direct access into voice mail boxes.

Do I wish it was technologically impossible to spoof caller ID? You bet I do, it would make avoiding political fund raiser calls much easier. I know better, the bad guys will still spoof caller ID knowing that it will be virtually impossible to get caught. This means my customers who want authentic social engineering phone calls won’t get the total package and won’t know their true risk.

The downside to this law is only the bad guys will be spoofing caller ID. This will also put companies like telespoof.com out of business.
The upside is that it looks like Skype will be legally obliged to transmit caller ID. This is good news for people who have purchased Skype-IN phone numbers and whish it would transmit something other than +000000

More about Skype and caller ID here: http://share.skype.com/sites/en/2007/05/caller_identification_for_skyp.html

-higB

Build that trans-continental security bridge!

While pen testing applications for one of my clients,  I found that all the security issues I identified had the same 2 or 3 systemic causes. I made “strategic recommendations” – security training for developers and a security-aware SDLC, to name a couple. Months later, I went back to the same company, this time to test a bunch of other applications. The outcome wasn’t too different – same systemic problems. Once again, I emphasized the trend to my client. He told me that the applications were developed offshore, so my strategic recommendations from the last review were “impractical”. What could my client do to fight this negative trend?

Over the years, I’ve had several discussions on this topic with security gurus, software developers working in offshore companies, and some folks at the receiving end of insecure code. The situation is best described by the everybody, somebody, nobody and anybody joke. In short, no one has taken the initiative on the security front. What can everybody do?

Firstly, the outsourcers need to be willing to PAY FOR SECURITY. Yes, security doesn’t come free. This shouldn’t really be an issue given the tremendous savings realized by offshoring. But don’t just pay for security, demand it contractually. Just like you define performance metrics that the applications should meet to be accepted, define and enforce security metrics. Ensure that the terms of the contract are enforceable in a jurisdiction in your country (the outsourcer’s country). Suing the development company in their country will be a frustrating and futile endeavor at best!

Secondly, find out what measures your offshore partner takes to protect your data, to educate their developers on security, and to implement security in the SDLC. Remember, an ISO audit doesn’t cover all these areas.

Now for the offshore development company – use security as a competitive advantage. The last time I said this to some friends of mine who work as developers in India they said “We need VP approval to add even an optional line item in a proposal”. We all know what that means.

If you want to hear more on this topic, you can hear the recording of a webcast I did with Watchfire:

https://www.watchfire.com/securearea/seminararchives.aspx?id=253

-Rohyt

I was doing some security research this morning and was quite alarmed to find out that SECURITY VENDORS are vulnerable to CSRF. DarkReading has the story here: CSRF Bug Runs Rampant

Being a curious person I thought I’d try to find some CSRF vulnerabilities of my own. I was shocked to find out that the most used search engine was vulnerable to CSRF! Using this vulnerability a malicious attacker can force people search for the word “balls” without explicit permission.
Normally blog.phishme.com believes in responsible disclosure and would never release a 0-day. Due to the urgency of this threat and details that must be disclosed to communicate about it we thought it best to forgo waiting 30 days for a vendor response. Due to the widespread use of google.com this information should be communicated immediately. Blog.phishme.com will be releasing 0-day proof-of-concept code in the advisory below:

———————————
Date: 6/28/2007
Advisory #: PHME-2007-01-BALLS
CVE #: CVE-NO-MATCH
06/28/2007 Vulnerability discovered on google.com
06/26/2007 blog.phishme.com releases advisory and POC 0-day code.

{ Introduction }
The popular internet search engine, “Google“, is vulnerable to cross site request forgery (CSRF) attack. This vulnerability would allow an attacker to force victims to search for the term ‘balls’.
Due to this class of exploits being relatively new, we suspect that there are other strings an attacker could force a search on, but we only tested the first thing that came to mind. Other search engines may be vulnerable but were not tested.

{ Risk }
blog.phishme.com used STRIDE and DREAD to classify this vulnerability as Medium Rare Risk.
This attack requires the attacker to know how to send URLs via instant messaging, email, or online forms.

• Alternate attack method #1: An attacker could call the victim and ask them to type the URL into their browser.
• Alternate attack method #2: An attacker could get a bumper sticker printed and affix it to their car. A curious victim would see this URL on the bumper sticker and type it in a browser when they get home.

{ Fix / POC code }
There is no fix or workaround at this time. A fully patched system running anti-virus and a firewall can still fall victim. Until this vulnerability closed, internet users all over the world may be forced to search for ‘balls’.
In the meantime, blog.phishme.com offers up steps users can take to safeguard themselves forceful balls searching. Please be aware that attackers are crafty so we might not be able to cover every potential vector.

• Users of google should be skeptical of email subjects that read: “Dude, you really have to check out this link, after that deep conversation we had last week I think this would really interest you: http://www.google.com/search?hl=xx-hacker&q=balls
• Internet users of google should be skeptical of instant messages or internet forums that read: “I was thinking about your problem and I think I found you the answer on this website: http://www.google.com/search?hl=xx-hacker&q=balls
• myspace.com users should be skeptical when their friends post a message that reads: “I’m glad you had a good time at my barbeque, here is that chocolate dessert recipe you wanted: http://www.google.com/search?hl=xx-hacker&q=balls

{ Advanced Exploitation }

Savvy internet users may not fall for the forceful ball search CSRF attack. Members of the security community would be even harder to trick. Crafty attackers may obfuscate this attack to evade IDS.

Demonstration POC Code:
Normal CSRF method: http://www.google.com/search?hl=xx-hacker&q=balls

Advanced IDS evasion Obfuscation method: http://www.google.com/search?hl=xx-hacker&q=%42%41%4C%4C%53
I will now demonstrate this attack in a skype chat room full of security experts in the fields of penetration testing, secure coding, and incident response:

{ Conclusion }

This is a damaging attack that may take some time to fix. Internet users should proceed with caution.
———————————

End Advisory.

* Google lawyers, this is a joke, don’t get excited.

I didn’t come up with the joke in the title but I nearly turned blue from laughing so hard while watching the now famous SNL TSA Security skit. (Catch it on YouTube if you haven’t seen it yet: http://www.youtube.com/watch?v=ykzqFz_nHZE)

If your job requires you to fly often, then you probably have some complaints about the TSA and security checkpoint lines. It’s probably the number one conversation between strangers at airports these days. Everybody can commiserate while swapping ridiculous stories.

If your job is to analyze and test security, then you probably have even more to say about the “appearance” of security vs. real security. One of best security minds blogs about airport security quite often: (Bruce Schneier http://www.schneier.com/cgi-bin/search/search.pl?Terms=tsa&Realm=blog )

Recently my Tartar Control Whitening Crest with Scope toothpaste was confiscated. This toothpaste must rank high on the banned substance list because it’s both a liquid and a gel (according to the label http://www.crest.com/products/liquidGels.jsp) I was quite distraught because this toothpaste is one of the most important tools for a security consultant. I’m trying to keep airports safe; instead of carrying both mouth wash and toothpaste, I can maintain minty freshness (and whiten teeth) in one compact package.

The problem is that the net weight is 4.6 ounces which is 1.6 ounces over the dangerous toothpaste limit. I didn’t think that was a problem because someone with a GED could use their eye-sight and see through the clear container noticing that I only had a third of this wonderful stuff left. WRONG! — I protested, it didn’t matter. “We go by what the container says sir” —

While later sitting down to tie my shoes on the Dulles airport people mover I looked up to notice what appeared to be a rather large gerber or spyderco knife clipped to the hip of an airport employee.

I wonder if I made friends with this guy if he could hook me up with some toothpaste. (Liquid or gel preferred.)

–higB

Windows password complexity can often be misleading. A “complex” password may be hard to guess without reaching the account lockout threshold, but not necessarily hard to crack. On a recent engagement, I found that the password complexity policy and account lockout policies were set as recommended. The passwords had to be 8 characters long (at a minimum), alphanumeric and have at least one special character. With an account lockout threshold of 3, that’s a hard to guess password.

Now, crackability is a different issue. I ran into a 12 character long domain administrator password – alphabets, numbers, special characters, et al. How hard do you think that was to crack? It took the better part of 5 minutes. Let me caveat the following discussion by saying that the Windows domain in question did support LM hashes, making the job considerably easier.

I ran the password through ophcrack, using the built-in alphanumeric Rainbow Table. 20 seconds later, I had the first 7 characters of the password staring me in the face.

LM hashes can be cracked as two separate 7 character chunks. The first 7 characters in this case had no special characters – 1 numeral and 6 characters, and so the rainbow table got ‘em.

Next, I took this 7 character password segment and fed it into the dictionary file for John the Ripper and let it rip. On returning from a short bathroom break I found that the other 5 characters had cracked even though they had 2 special characters in them.

I know the weakness created by supporting LanMan hashes isn’t news to security pros, but to date I still see it supported in nearly every organization I assess.

The point I’m trying to drive home is a 12 character “complex” password may be hard to guess, but not necessarily hard to crack depending on its composition and hashing algorithm. Since LM hashed passwords behave like 2 separate passwords, when setting Windows passwords make each 7 character chunk complex with special characters, numbers and alphabets. Or even better don’t support LM hashes; set the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LMCompatibilityLevel registry key to a value greater than 1. The counter argument to the second countermeasure is “But I have Windows 9x machines to support (that need LM)”. If that is the case DSClient.exe, from Microsoft can alleviate that problem. Better still get rid of those antiquated machines.

A fantastic book about passwords by Mark Burnett: Perfect Passwords

A great book on Windows security by Roger Grimes: Professional Windows Desktop and Server Hardening (Programmer to Programmer) (Don’t let the title fool you, this is a book for administrators, not programmers.)

–Rohyt

Welcome to http://blog.phishme.com – the home of rand(security)and technology discussions.

We will use this blog to comment on topics like cool phishing ploys, IM and its privacy implications, hacking cars, and bashing on (or bowing to) the latest application hacks. Security geeks and a love of technology go hand in hand so expect some commentary on general tech too.

We plan to post here at least once a week, so keep us on that RSS radar or keep visiting!

Thanks,

The Intrepidus Group Team

http://intrepidusgroup.com

Phishme.com was created by the Intrepidus Group.

Intrepidus Group is a leading provider of information security consulting services. To learn more about our company and our services, please visit our main site.

http://intrepidusgroup.com