Some of the best security solutions come from people who have a passion for security and want to make the Internet a better/safer place. We started SecuriTeam as a place for people like us, who want to read security information that was collected, processed and edited. The OSVDB team wanted to answer the need for a standard, open catalog of information. Nmap, nessus, snort and many many other useful tools and projects were all passions that turned into something millions of security professionals use regularly.

And then there’s the money. Most of these projects need money to keep on going. The people behind them need to pay the bills. Sometimes just a little ad or sponsorship is enough, and other times the writers want to be compensated for their hard work and make a living (or get rich) from the project they gave so much time and energy to.
This is where the lines get blurry: Fyodor insists on keeping nmap open source and non-commercial. Tenable closed nessus in a very controversial move and SourceFire is able to carefully do the open-source/commercial tango with snort. In Beyond Security, we have a constant struggle on how to keep the commercial products and the community services separate, but in synergy. I don’t even know if we’re doing it right (but god knows we’re trying).

But other times the line isn’t blurry at all. Like watching a train wreck in slow motion, we are regularly seeing how a good project morphs into a twisted corporate disaster. PCI-DSS is probably the best example.
PCI-DSS started with the good idea of forcing web sites to check themselves for security holes on regular basis, a notion initiated by the credit card companies in an honest attempt to improve the security of web sites (since they had the most to lose; credit card fraud hurts the issuer no matter who ultimately pays for it). But this good idea went to bad and then to worse as the PCI-DSS went completely commercial - on one hand the organization wanted as many vendors to sign up for their PCI-DSS certification services so that they can make their money and on the other hand the web site operators were paying money to get the PCI certification without really caring what that meant as long as someone was willing to give it to them for some dough. Russ has a good writeup on where PCI-DSS is going. I agree with everything he’s saying.

And now there’s CVE - one of my favorite projects of all time. I know the project well, and we even got the “CVE Certification” a while back. True, not something that will help you get laid, but on the other hand getting the certification was one of the most pleasant experiences we had in that area. Nobody likes to be judged and thus nobody likes to be ‘certified’ by others - but the CVE certification process really wasn’t about ‘judging’ us. At least that’s not what it felt like.

This morning I asked the guys in Beyond Security who were involved in the certification process what made the good feeling that remained. Their answer was that people we talked to at Mitre weren’t sales people (CVE certification is free, they don’t even charge for the picture frames) but rather technical people from the CVE team that actually wanted CVE to be “good”. Talking to someone who both has a clue and cares enough to show it is the difference between Mastercard’s SDP and the new PCI-DSS.

So why am I worried about CVE which is still alive, kicking and putting some sanity in the dozens of weekly security hole announcements? Because just last week we got this:

Date: Wed, 7 May 2008 10:40:49
To: xxxxx@beyondsecurity.com
Cc:”Doe, Jane”
Subject: CVE

XXXXX,
SAIC received confirmation from NIST that SCAP CVE and OVAL testing will be operational by the end of May 2008. By the end of this week, NIST will issue the updated requirements document that will add more requirements for CVE testing.

When SCAP first went operational CVE and OVAL were deferred because the test requirements in those areas were not complete. Historically, MITRE conducted CVE testing. CVE testing has now transitioned over to SCAP laboratories.

If you desire further SCAP information or about CVE and OVAL testing, or a cost proposal, please contact me.

John Doe,
SAIC AT&E Laboratories Communications Director
410.XXX.XXXX

I’ve got to admit I had to read it a few times just to understand what they actually want (although I’m still not sure). Let me make a few wild speculations:

1. NIST will release an updated requirements to make sure all existing CVE certified products are no longer certified. It will not be exactly clear from the new requirements, so they will change the name to MVP just to make sure.

2. The new CVE will be a set of incomprehensible requirements for anyone without a law degree and will make the PCI requirements document look like a children’s book.

2. SAIC will suddenly realize they are not a not-for-profit organization and charge $10,000 for a CVE certification and a $7,500 renewal fee to cover the cost of the “SCAP” lab.

3. CVE certification will be open to everybody: Consultants will hurry to get “CVE certified” and while nobody will really know what that means, as soon as the check clears the certification plaque will be FedEx’d to them. Linkedin recruitment messages will read “need CVE expert to help pass a CVE certification test”.

4. John Doe from the email will call, mail and snail-mail to sign us up at “special terms” and “before the cost goes up”

5. Sponsorships to the annual CVE conference in San Francisco will sell like hotcakes. The MITRE team will not be invited, but the Director of Lab Services in SAIC will be the keynote speaker.

Of course, I’m probably wrong. Too much fiber for breakfast and not enough red meat for lunch makes me cranky and negative.
Here’s the more likely scenario: CVE certification will remain free and open and the SAIC guys doing the testing will be excellent security professionals who are regular bugtraq contributors. The PCI council will release the re-re-reclarification of section 6.6 of the PCI 1.1 and that re-re-reclarification will be a one-liner with no references to other requirements. The Ozone layer will heal and electric cars will roam the streets. Real soon now.

It appears that a new WMF attack is coming, as you recall about a year back an WMF vulnerability was used on several high profile sites to infect visitors, this now appears to start happening again.

The first sign of this is the appearance of exploits for the vulnerability, starting off with version specific and evolving into a generic one.

The second sign is web sites being infect with hidden iframe that redirect to a javascript code that is at the moment dormant, or refers to non-existing domains.

The last stage is those javascripts getting modified, or the non-existing domains poping up into existing, you got yourself an infection.

It is time to start your vulnerability assessment engines, make sure all your windows based machines are tested, verify that your website passes a web site audit, and lastly get updated as this news item evolves.

SANS ISC has collected a very coverage list of April Fool’s Day stories.

It can be found here:

isc.sans.org/diary.html?storyid=4225

My own favorite is Gmail’s new Custom Time feature

It’s time to look the recent state of targeted attacks. Like we already know the main attack vector in these attacks is Microsoft Office attachment. There are no many organizations that simply can filter .DOC, .XLS and .PPT files.
In mid-January Microsoft confirmed that a new, previously unknown Excel vulnerability was used in targeted attacks. On Monday this week US-CERT issued a warning about the new wave of exploitation. This extremely critical vulnerability, rated ‘10.0′ by CVSS meter BTW, was known as header information code execution vulnerability.
The fix is included to today’s Excel Bulletin MS08-014. However, Microsoft says the following now:

What causes the vulnerability?

Microsoft Excel does not properly validate macro information when loading specially crafted Excel files.

In January we had a very small pieces of information related tho this vuln and Trojan exploiting it.

Information about the characteristics of these targeted attack can be read via my FAQ documents.

My bank forced me to change the login password again; they claim it’s an automated procedure that happens every 90 days, but I know that it actually waits for me to remember the password and then immediately forces me to change it.

When I went in to change it, I was reminded of the draconic rules: it has to be at least 6 characters, with at least 2 numbers and at least 2 uppercase and 2 lowercase. These guys went to the security by obstruction school, no doubt.

I decided to fight back. As I finally got around to remembering this awkward strange password I had to pick 90 days ago, I decided I’m staying with it. So I changed it to something else, which I had to write on a piece of paper for fear of forgetting within 30 seconds (if you saw memento, that movie is about me. And I try to always order beers in bottles since seeing it), and I then went to the ‘change password’ section to change it back to my awkward-but-conditioned-to-memory password.

Naturally, the bank was trying to set me straight. “You can’t change back to any of your last 5 passwords” it told me with a grinning smile, giving me the solution right there. As you can undoubtedly guess, I returned the favor by changing the password 5 times to different things and then changed it back to my old one. I win. Next round in 3 months.

People will always outsmart security systems that try to force them into making the ‘right’ decision. What I’ve done today (and I’m quite proud of it, thank you) is being done every day by people who use their CD-ROMs as coffee trays and have never used any
program that didn’t automatically run when double clicking an icon.

But here’s what is really bothering me: What exactly is the attack scenario here? I would like to see the statistics that show how many attackers actually manage to capture a username and password and only fail because they try to use it after 90 days. While these huge numbers are crunched, please put on the Y-axis how many attackers found the password on a post-it stuck to the monitor because the password is so complicated to remember.

Or maybe so many attackers brute force the password, obviously hundreds of millions of times every day for a single account since there is a clear an immediate need for a long and complicated password (BTW, if this attack is possible, someone should tell me how to do it. I’ve been locked out a few times for failing to type the password correctly within a few guesses. I need a few guesses because I didn’t remember which was the current password, which, as you remember, changes every 90 days).

Being the cynic that I am, and having read enough security policy documents, I can guess why the password policy is the way it is: it’s easy to explain and justify, and it makes sense when showing in a powerpoint slideshow. I once heard from a high-profile organization that due to a successful break-in to their network they decided to tighten up security: all passwords now had to be 9 characters instead of 8. I’m guessing someone was promoted for this genius action, and there’s still enough room to increase it further when the next break-in comes (now that’s thinking ahead).

How is a complex password policy bad? Let me count the ways; It makes your user you enemy instead of your ally. It distracts the security people from the real threat. It gives a false sense of security. It encourages your users to find flaws in your security system and use them. What else? I had more, but somebody just came in the door and I forgot.

Ophir put together a nice analysis on how much it would cost to break the security system of SmugMug.com.
This, in response to a bounty that is advertised on their web site.

I think he’s being generous. The really bad guys (people who make money from cybercrime) have access to countless of “free” machines; the crackers can easily break into a few boxes to use them for the attack Ophir describes. But mainly he’s being generous because he is giving them free security consulting, which is what they really need. Hey, SmugMug guys: a security contest is not a cheap replacement to an actual security audit (or consulting with an expert) just like bug bounties are not replacements for QA.

And only god knows why in 2007 the notion of my-url-is-so-long-nobody-will-guess-it is still alive. What do they teach in CS anyway?

Top Ten Web Hacks of 2007 list has been released by Jeremiah Grossman.

Link to Jeremiah’s post: Top Ten Web Hacks of 2007 (Official)

Various XSS issues, possibilities of firefoxurl vulnerabilities, dangers of opening PDF’s, etc. etc.

Happy clicking!

My Admirer application (previously known as Secret Crush) has been removed from Facebook now. The installation process was canceled during the weekend, but now it is finally gone.

Fortinet reported about the Zango spyware installation related to this application last week. The issue was described in this SecuriTeam post.

Response from Zango Inc. is interesting to read - link to the Zango blog here.

From the post:

At no point in adding the Secret Crush widget to a Facebook profile does the widget install either spyware or Zango software, or even attempt to do so. Any suggestion that Zango software is being “secretly installed” is simply not true.

It appears that there was no automatic installation of spyware at all.

The first spyware spreading with Facebook application has been discovered. Security company Fortinet reports that application called Secret Crush is installing Zango (aka AdWare.Win32.180Solution) with Iframe, technically from ZangoCash.com.

Shortly, this is the spreading mechanism:

In opening the request, the recipient is informed that one of his/her friends has invited him/her to find out more information by using “Secret Crush” (this happens frequently with Facebook’s Platform Application). [Figure 2] exhibits the social engineering speech employed by the malicious widget to get the user to install it.

The text included to the request entry is “One of Your Friends Might Have a Crush on You!”. Additionally, the buttons are ‘Find Out Who!’ and typical ‘Ignore’.
It appears that Secret Crush is not included to Facebook Application Directory (no log-in needed) any more. Reportedly FortiGuard Team has informed Facebook guys and probably the application has been disabled already.

Update 4th Jan: The application mentioned is located here (renamed to My Admirer), still accessible and has “50,708 daily active users i.e. 4% of total”.

The exact number of affected users is not available.

Howdy ho from Brazil, folks.

Remember that vulnerability in Gmail filter feature reported by Petko D. Petkov in September? Google fixed this vulnerability a few days after it was disclosed, but something was missing: end users should be noticed about that.
Early this week I was made aware of someone who was hit hard by this vuln months after it was fixed. David Airey’s domain was hijacked and this vulnerability helped on that.

But Google fixed that, what’s the problem? They should have noticed all users about that. New filters could not be injected anymore after the fix, but filters injected before the fix were still there. A simple “please check you filters” Web two-dot-oh notice would be enough, only if new filters were added in the days between the vuln was disclosed and the fix. End users don’t read the same blogs, lists and security resources that we read. Users are not supposed to know the nuts and bolts of the vulnerability, but they should know what manual actions should be taken.
I don’t know about you, but I thought about some solutions for that:

1. Anything under settings should require password, in every change. I guess Yahoo! Mail works like that;
2. Filters that forward messages should be handled in a different way, maybe under “Forwarding and POP/IMAP” tab.

Another simple mitigation action that people should use for any online service is something like a privilege separation (I don’t have a better name for that). Use different accounts for different purposes, have a master account and child accounts that forward every message to the master account.

If you are a moderator in a Yahoo! Group don’t use your main personal profile for group management, for example. Reducing the lifetime of the session to 15 minutes and log in only on trustworthy networks are other paranoid measures that could be considered. If there’s a targeted attack against your account probably your less critical account will be affected.
Do you have any insight about this Gmail vuln? Comment.
More info:

• Google GMail E-mail Hijack Technique (GNUCITIZEN 09/25/07)
  
• New cracks in Google mail (The Register 09/26/07)
• Google Fixes Gmail Cross-site Request Forgery Vulnerability (Netcraft 09/30/07)
• WARNING: Google’s GMail security failure leaves my business sabotaged (David Airey Blog 12/24/07)

A frequent source ‘A’ sending updated NSA-Affiliated IP resources to Cryptome’s Web site has reported the following new information:

Certain privacy/full session SSL email hosting services have been purchased/changed operational control by NSA and affiliates within the past few months, through private intermediary entities.

Reportedly the following services are controlled:

Hushmail - based in Canada,
Guardster - based in USA,
and
SAFe-mail.net - based in Israel.

Link here: NSA Controls SSL Email Hosting Services

Update 22nd Dec: Guardster Team has posted its response on 21st Dec to Cryptome:

We can assure you that we do not cooperate with the NSA or any other government agency anywhere in the world. We invite whomever is making this statement to provide proof, rather than making a baseless accusation.
….

Response from Safe-mail.net Team (24th Dec) is the following:

1. We never had any contacts, direct or indirect, with the NSA or any other
government agency anywhere in the world.
2. All software we use is in-house development.
3. We have never shared our technology with any other party.
….

Update 30th Dec: Hushmail Team has posted its response yesterday to Cryptome’s Web site:

Hush Communications Corporation, the company that provides the Hushmail.com email service, is not owned, wholly or in part, by any government agency.

Additionally, ‘More info on industry Windows security software’ has been released:

Zone Alarm, Symantec, MacAfee: All facilitate Microsoft’s NSA-controlled remote admin access via IP/TCP ports 1024 through 1030; ie will allow access without security flag. Unknown whether or not software port forward routing by these same programs will defeat NSA access.

The post released in Cryptome.org on 1st Nov informed about the future updates with details related to this issue and this is the first piece of information.

To the new readers: Cryptome: NSA has access to Windows Mobile smartphones

An Orkut based virus/worm appears to be on the loose, it propagates by posting notes on people’s scrapbook. So chances are that if you got a new scrapbook item on your long-unused Orkut it is because the worm has infected one of your friends there.

The virus/worm utilizes javascript code to propagate. The source of it can be found here: hxxp://files.myopera.com/virusdoorkut/files/virus.js
Update: Google apparently is actively deleting items from the scrapbook of people that were infected and that have infected others.

Update 2: More details can be found here: http://antrix.net/journal/techtalk/orkut_xss.html

The number of recent QuickTime PoC’s is remarkable large and the active exploitation has begun as well, as many of the readers know.

However, the QuickTime RTSP vulnerability reported on 23th Nov is not the only one.

It appears that WabiSabiLabi team has reported that there is another (they call it zero-day vuln) flaw in Apple’s QuickTime player too.

This is what their blog post states:

We just want to specify that the vulnerability shown on those POCs IS NOT the one present in our marketplace.

They are pointing to PoCs listed at Milw0rm etc.

And a summary:

The first issue reported by Krystian Kloskowski (aka h07) is CVE-2007-6166 - CVSS score 9.3. For workarounds see US-CERT VU#659761.

The second issue reported by unknown person is CVE-2007-6238 - CVSS score 10.0. Reportedly ‘Affected system: Windows XP’.

According to several Israeli newspapers google has exposed the IP address of a blogger that was using the “blogger” service.

You might think he was posting instructions on how to prepare a nuclear bomb or the secret Coca Cola formula. It’s much much worse. He was defaming officials in the “Sha’arei Tikva” municipality, which most Israelis can’t even place on a map, and needless to say have little to no interest on the intrigues and political wars there.

My point is, there is no benefit to anyone for exposing the blogger’s IP except to let these officials take him to court, and while google gave a weak legal fight, the decision was reached by out of court settlement, which means they didn’t even try to go the distance in order to block this request.

I think the main issue is not the blogger’s right for anonymity; it’s more about google’s unclear policy on what they do with the information they have. We know google save search data. We know that they have access to deleted emails on gmail (for who knows how long). We don’t know what they do on google talk, but we can guess. What we already know is scary; the fact that we don’t know the rest is even scarier.
It’s clear to everyone that google has information about us and our private life more than any other Internet entity (we had a securitoon about it a while back). Now it’s clear they are playing loose cannon with that information.

Update: Someone identifying herself as “google employee” writes in the talkback comments to the article that google only handed the IP, but the ISP gave the complete identifying information from that IP, and that the press’s picking on google is unjustified. If that google worker is reading this, feel free to email me your version of the story and it will be posted here anonymously (or just leave a comment below).

It was 11 day ago when JAR: protocol vulnerability in Firefox was reported by pdp.

According to Bugzilla entry #369814 upcoming Firefox 2.0.0.10 (tests done with Gecko/2007111504) are immune to this vulnerability.

A Mozilla Security Blog entry posted by Mozilla security chief Window Snyder has been released too.

However, as a workaround NoScript version 1.1.7.8 and later may prevent this vulnerability from being exploited, as US-CERT VU#715737 states.

The fact is that the Bugzilla report mentioned was filed as security sensitive on 8th Feb already. The disclosure of Petkov made it public.

According to the report of pdp several Web sites supporting open redircts are vulnerable to recent JAR: protocol vulnerability.

More information about these XSS vulnerabilities (hey, these are serious now!) is available at GNUCITIZEN entry here:

Severe XSS in Google and Others due to JAR protocol issues

Update 26th Nov: The author of Beford Blog has shared information that his “jarjarbinks.htm” PoC type link still works - when entering it manually to browser’s address bar. Google is still affected to JAR flaw.