Microsoft LNK exploit

The recently discovered LNK exploit; using the way Microsoft parses link or shortcut icons for display in order to get something else executed; may be a tempest in a teapot.  It is technically sophisticated, but so far we don’t appear to have seen it used widely.

Probably a good thing.

This exploit could be used in a wide variety of ways.  You can use it in removeable media, so that any time you shove a CD in a drive, or connect a USB stick/thumb drive (or any other USB device, for that matter) to a computer, it results in an infection or some malicious payload.

And remember that OLE stands for object *LINKING* and embedding.  Since it is trivially easy to embed a virus in any Windows OLE format data file, it should be just as easy to create malicious links in any such files.

Microsoft’s own information on the issue seems to indicate that there is a related, but separate, issue with Microsoft Office components, related to Web based activities.  (By the way, when accessing that site, the information about how to protect against the exploit is hidden under the “Workarounds” link, rather than being explicit on the page.)

Some of the potential effects are discussed by Randy Abrams at http://blog.eset.com/2010/07/19/it-wasn%E2%80%99t-an-army

Share

The Internet not a meeting of minds

This is depressing, but probably true.  Ethan Zuckerman, at the current TED, notes that the Internet makes us think we being exposed to, and learning from, differing world views, but that, particularly in relation to social networking, we are usually simply seeking out similar views to our own, and reinforcing our existing viewpoints.

You can read a report from the BBC or see the actual talk at TED.

(I like the “imaginary cosmopolitanism” phrase.  It reminds me of being in NYC.)

(If you can’t see the security implication in broadening your outlook, there is no hope for you.)

Share

CAPTCHA bypassing for profit

Did you wonder what this is used for? The following FAQ may give a hint:

Hi! I want to bypass captcha from my bots. Bots have different IPs. Is it possible to use your service from many IPs?

We have no restrictions about IP: with DeCaptcher you can bypass CAPTCHA from as many IPs as you need.

In other words: Just used a Virus to break into thousands of botnet computers and now you are not sure what to do? These guys will help you take the next step and set up myspace/facebook/gmail/twitter accounts while bypassing the CAPTCHA and you can then use that to spam the world. Thank you DeCaptcher for giving the Internet such a valuable service.

Share

REVIEW: “SSL and TLS: Theory and Practice”, Rolf Oppliger

BKSSLTTP.RVW   20091129

“SSL and TLS: Theory and Practice”, Rolf Oppliger, 2009, 978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   “SSL and TLS: Theory and Practice”

The preface states that the book is intended to update the existing literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security), and to provide a design level understanding of the protocols.  (Oppliger does not address issues of implementation or specific products.)  The work assumes a basic understanding of TCP/IP, the Internet standards process, and cryptography, altough some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.  The author uses the definition of security architecture from RFC 2828 to provide a useful starting point and analogy.  The five security services listed in ISO 7498-2 and X.800 (authentication, access control, confidentiality, integrity, and nonrepudiation) are clearly defined, and the resultant specific and pervasive security mechanisms are mentioned.  In chapter two, Oppliger gives a brief overview of a number of cryptologic terms and concepts, but some (such as steganography) may not be relevant to examination of the SSL and TLS protocols.  (There is also a slight conflict: in chapter one, a secure system is defined as one that is proof against a specific and defined threat, whereas, in chapter two, this is seen as conditional security.)  The author’s commentary is, as in all his works, clear and insightful, but the cryptographic theory provided does go well beyond what is required for this topic.

Chapter three, although entitled “Transport Layer Security,” is basically a history of both SSL and TLS.  SSL is examined in terms of the protocols, structures, and messages, in chapter four.  There is also a quick analysis of the structural strength of the specification.
Since TLS is derived from SSL, the material in chapter five concentrates on the differences between SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and 1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram Protocol), is described briefly in chapter six, and seems to simply add sequence numbers to UDP, with some additional provision for security cookie exchanges.  Chapter seven notes the use of SSL for VPN (virtual private network) tunneling.  Chapter eight reviews some aspects of
public key certificates, but provides little background for full implementation of PKI (Public Key Infrastructure).  As a finishing touch, chapter nine notes the sidejacking attacks, concerns about man-in-the-middle (MITM) attacks (quite germane, at the moment), and notes that we should move from certificate based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and technical details of the SSL and TLS variants you are likely to encounter.  The material is clear, well structured, and easily accessible.  He has definitely enhanced the literature, not only of TLS, but also of security in general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129

Share

Why Is Free Vuln Disclosure so Damn Difficult?

Xyberpix described how difficult it is to disclose vulnerabilities to ZDI and iDefense. But even after you sold it, the process is just beginning. Sure, the researcher gets paid and he is free to resume his work, but the work us, the vulnerability coordinator, just begins.

We recently received 2 disclosures to our SecuriTeam Secure Disclosure program for Sonicwall and google vulnerabilities. We received sponsors for both vulnerabilities which means there is a commercial organization out there that was willing to pay the researcher for their efforts. That part ended well for the researchers.

Now both organizations want the vendors to patch up. Sounds easy, right? We are giving Sonicwall and google free information about security holes in their products, and want nothing in return except for them to fix it.

Well, it’s damn difficult.

Google is always difficult when it comes to security. When I reported an information disclosure vulnerability in google calendar they ignored me, then sent their PR person to say “it’s a feature”, then silently fixed it claiming it was never there. Dealing with google on security issues is like talking to a girl that speaks a foreign language. But more on that later – lets start with Sonicwall.

Wouldn’t you be expect security vendors to be more aware of security problems in their products? Well, for the last few weeks we’ve tried to bang every door, calling in personal favors to tell Sonicwall (for free, let me remind you) about a security hole in their product.
Why bang every door? Because they won’t talk to us since “we’re not Sonicwall customers”. We can’t open a support ticket and they won’t give “us” support. security@sonicwall? yeah, right. Even good friends couldn’t help. The system will not accept a report from non-customers.

I guess our only course of action is to pay Sonicwall money to let them know about their vulnerabilities. I wonder if that’s Sonicwall’s long term strategy for profit? BTW, if you work for Sonicwall and can help, please contact me – but keep in mind paying Sonicwall for telling them about their own security issues is not a part of our plan.

Back to google. The story there is simple and boring. It’s not a bug, it’s a feature. In fact, every browser has this problem, errm I mean feature. In fact, it’s been proven you can execute javascript on the chrome user’s browser so we’ll leave this open as well. If the stupid web app developers can’t solve this we certainly aren’t going to help them.
But why am I boring you with the broad strokes, go read the discussion:
http://code.google.com/p/chromium/issues/detail?id=46795. Nothing we haven’t seen with previous google security bug handling, just ask this guy.

Yes, it is 2010, and we are still talking about Vulnerability Disclosure to vendors. I guess next we’ll be arguing if heap overflows are exploitable.

Update: We were contacted by Sonicwall and the bug will be looked at. Hopefully security@sonicwall will start accepting submissions from non-customers.

Share

National Strategy for Trusted Identities in Cyberspace

There is no possible way this could potentially go wrong, right?

Doesn’t the phrase “Identity Ecosystem” make you feel all warm and “green”?

It’s a public/private partnership, right?  So there is no possibility of some large corporation taking over the process and imposing *their* management ideas on it?  Like, say, trying to re-introduce the TCPI?

And there couldn’t possibly be any problem that an identity management system is being run out of the US, which has no privacy legislation?

The fact that any PKI has to be complete, and locked down, couldn’t affect the outcome, could it?

There isn’t any possible need for anyone (who wasn’t a vile criminal) to be anonymous, is there?

Share

KHOBE – the money link

Hi,

In light of the KHOBE story, it seems a “darker” truth has been uncovered. Apparently the researchers have published their advisory in order to sell their research material to anyone who wants to know more than their limited technical details.

Why is this important? Well, it shows that when publishing their research, their intent was to:
1) Scare
then
2) Sell their software

While there might be legit reasons to check out their research, these new facts do bring the “KHOBE” paper into question, especially whether it is more noise than signal.

More details on the story can be seen here: KHOBE – no problem.

BTW, a bit of exaggeration by our colleague Aviram got him this week’s medal for PR scandal assistant.

Share

Finally, a workable approach to web Single Sign On


In the last 20 years, practically all the large software vendors came out with Single-Sign-On (previously “PKI”) products that were supposed to give a single login that would give you access to all the resources on the network. As good as this idea sounds, in practice that almost never works. Why Single Sign On constantly fails in corporate environments is a mystery wrapped in an Enigma. But it just doesn’t.

On the web, it seems even more logical that a single login will give you access to all the resources, and yet the situation is even worse. Microsoft, google, yahoo, AOL, and now facebook have all tried their Single Sign On initiatives that ended up having users signing up to 4-5 different ‘single sign on’ services and typically just opting for the only single sign on method that works: Using the same username and password everywhere.

Before you ask, OpenID is not a single sign on solution – it’s an identification service. So with that out of the way, are we doomed to never have a workable option to web single sign on?

Well, it seems the solution was always there: in fact, most of us have been using it for a while. Your browser.

Done well, the browser can keep the username/password combination in a secure place, protected by a single password and encrypted on your hard drive. The only risk is a Trojan using your browser to log into web sites without your knowledge – but that’s a risk you have today with keylogger rootkits, so you are not worse off letting your browser save the password for you.

The only two challenges facing the browsers to truly provide an SSO experience were web sites like paypal that refused to let the browser save username/password information (though you could bypass that restriction with bookmarklets such as “Password Saver” on firefox) and the second challenge was just the convenience of needing to login instead of having the browser login for you, as you’d expect in a “real” SSO.

It seems that firefox has picked up the glove. In a recent blog post (http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/) firefox announced an add on that will handle account management; likely not much different than what is done today, perhaps a bit more extended and automated. Facebook, google and some others won’t be happy about this move, but who cares. The best thing about this method of SSO is that you don’t need the site’s cooperation for it to work. In fact, as long as they don’t actively resist (e.g. by adding CAPTCHA’s) firefox can be the de-facto standard for account management in the not-too-far future.

Share

Privacy via lawsuit (vs security)

Interesting story about collecting data from Facebook.  I wonder if he would have had the same trouble if he had written the utility as a Facebook app, since apps are able to access all data from any user that runs them.  Maybe he could talk to the Farmville people, and collect everthing on pretty much every Facebook user.

All kinds of intriguing questions arise:

Has Facebook threatened to sue Google?  If they did, who has the bigger legal budget?

With all the embarrassing leaks, why doesn’t Facebook simply do some decent security, and set proper permissions?  (Oh, sorry.  I guess that’s a pretty stupid question.)

Does the legal concept of “community standards” apply to assumed technical standards such as robots.txt?  If nobody tests it in court, does any large corporation with a large legal budget get to rewrite the RFCs?

If you don’t get noticed, is it OK?  Does this mean that the blackhats, who try hard to stay undetected, are legally OK, and it’s only people who are working for the common good who are in trouble?

Share

Wikipedia as IP theft enabler?

I am not a huge fan of Wikipedia, in terms of tech accuracy, as I’ve noted before.  For a quick idea of a new term it’s great: beyond that, watch out.

However, Charles Muller has pointed out something I hadn’t considered:  that, given it’s popularity, Wikipedia is a prime vector for losing control of your intellectual property.  As one who has had masses of work ripped off by others, I have to be sympathetic to his argument.  He’s got a couple more good points in this quick little piece.

Share

LinkedIn as a recruitment resource

I’m working on an article about the risks in social networking right now, and I’ve come across yet another blog posting about how to use LinkedIn (and Facebook, and Twitter, etc.) to look for job candidates.

I’ve never quite been able to figure out the attraction of using LinkeDin as a source of employment candidates.  The one thing you know about active socnet users is that they are active socnet users.  If you are at all concerned about your employees wasting time at work, you know right off the top that this is a person who will do that.

Of course, if your company is trying to “get into” the socnet world, you might think this is a good thing.  But it’s quite a leap of faith to think they would do it for you, rather than themselves.

(For us in infosec, there would be the added concern that this person is either telling way too much about themselves, or “tailoring” the facts.  So you either have a failure of confidentiality, or integrity.)

Share

Security Seal company sued by FTC

Lets start with the proper disclosure; we provide a Web Site Security Seal service which competes with ControlScan’s. That said, I’m not about to bash ControlScan but rather the poor practices of security seal companies giving out seals to whoever pays them without the proper security checks.

Some background: The FTC sued ControlScan for $750,000 for giving out security seals while not really checking the security of the web sites. This lawsuit and its verdict are good news: It means that services that give out seals need to be responsible for their actions; no more “scanless PCI” badges: if you give out a seal (and I’m looking at all you large domain resellers) that needs to stand for something – when customers see a seal that says “secure site” they need to know the site is secure.

Before you take out the pitchforks, sure – there is no way to verify with 100% certainty that the web site is “secure”. But vulnerability scanning is at a stage today where you can run automated scans and make sure the web site is “secure enough” – meaning it does not have any known vulnerabilities, doesn’t suffer from SQL injections or cross site scripting. If there is a zero day vulnerability in apache, I doubt it will be used against an e-commerce site – it is more likely to be used against a bank or the government. Fact is, over 90% of successful attacks use known vulnerabilities that would have been detected by any competent scanner. If the site is properly scanned and no vulnerabilities are found, this is probably as good as it’s ever going to get; and is definitely better than the chances of your credit card being stolen at a brick-and-mortar store.

What will happen with ControlScan is not really important. What’s important is that security seal providers will now have to stand behind their claims – the fact that the FCC went after a case like this, which is normally way below their threshold, probably means that someone is applying pressure on them; hopefully that will help clean up the act of some online scanning vendors.

Note: Complaint, Exhibits and final judgment here.

Share

Google and security. Oil and Water. (Or: How to DoS google groups)

The buzz was on about google buzz sharing your list of contacts (which they then quickly fixed in their casual we-did-nothing-wrong-these-are-not-the-droids-you’re-looking-for mind trick).

Readers of this blog remember when google calendar let you see the full name behind every gmail address. At that time, google ignored, then decided there’s nothing wrong with that feature, then fixed it. Only it still works, on other google services. Of course, these aren’t the droids I’m looking for.

Well, here’s a method to DoS a google group user; it was discovered by Shachar Shemesh of lingnu about 18 months ago, who told google and was answered with a strong silence. With google the only disclosure seems to be full-disclosure, so with apologies to you google-group users out there, here is the outline of the attack below.

DoS’ing google groups
Domain-Key is a good method to prevent spam from coming in, as well as preventing unwanted emails from being handled if they are sent through “the wrong” SMTP server.

Google has taken domain-key a step further, with their Domain-Key and Google Groups combo. In this combination, if an email is sent to a Google Groups from an SMTP server who is not listed in the Domain-key record, that email will be banned from writing or accessing the Google Group in question.

The banned user will no longer be able to write or read from that group, will not be able to “undo” this change as emails to Google’s technical support regarding this appear to go unanswered.

From this background, the attack seems clear. A malicious attacker can get pretty much anyone banned from a certain Google Group.

Steps to reproduce:

  • Subscribe to a Google group.
  • Look for a victim (Anyone posting to the group from a gmail.com account is fair game).
  • Configure your email client to send emails with a “From” field that matches this email address, and use an SMTP that is not one of those authorized by the domain key. Your ISP’s SMTP servers will probably suffice.
  • Use this configurations to send an email to the group. It doesn’t really matter what the email content is, but I recommend making it look like a genuine email to make is harder to filter (and raise ‘plausible deniability’ in case someone comes asking questions).

As a result:
The victim will be automatically banned from the group.

He or She will receive no notification of that fact: not to the fact he or she was banned, and not even to the fact that the email he or she supposedly sent failed Domain key verification.

The victim will cease to receive emails from the group. They will only find out about it if they try to send an email, at which point they will receive a brief and unhelpful message saying they were banned, with no explanation why and no means to appeal.

Trying to access the group from the web site will result in a “you are banned” message, again, with no helpful information on why the ban was instated nor how to appeal. It is a curious point that even information that is publicly available without registration, such as the group’s archive or description, will be blocked. They will have to sign out of Google to be able to see it(!).

The best means to appeal she is likely to find is “Google Help”, which points to an email address where past experience shows the request email will be unceremoniously ignored, just like Shachar’s email notifying google of this vulnerability.

Share

Mac Virus update

I know, there ain’t no such thing!

Well, we could have a lively debate on that topic, but not right now.

On this occasion, I’m just letting anyone who wonders what happened to the Mac Virus web site (http://www.macvirus.com), which I inherited from Susan Lesch some years ago, what’s happening with it. We have nothing to do with the cobwebby sites at http://www.macvirus.net and http://www.macvirus.org, or with http://macvirus.wordpress.com, whatever that is.

The http://www.macvirus.com URL actually redirects to my own Mac page at Small Blue-Green World site, which now re-redirects to a WordPress page. If you want to go straight to the Mac Virus blog, you can go direct here. It’s still malware-oriented, of course, and, is likely to become more rather than less active in that area.

In fact, most of my Small Blue-Green World content now resides on blog pages. ESET content is still blogged at http://www.eset.com/threat-center/blog/, of course, and AVIEN content is blogged at http://avien.net/blog/.

Confused? Me too…

We now return you to your normal programming. Scheduling, that is, not coding. Unless that’s what you’re doing at the moment. Oh, never mind.

The next time I blog here, it will be about a proper security issue again. I hope.

David Harley FBCS CITP CISSP
Security Author/Consultant at Small Blue-Green World
Chief Operations Officer, AVIEN
ESET Research Fellow & Director of Malware Intelligence

Also blogging at:

http://avien.net/blog

http://www.eset.com/threat-center/blog

http://smallbluegreenblog.wordpress.com/

http://macviruscom.wordpress.com

http://blog.isc2.org/

http://dharley.wordpress.com

Share

How not to handle a responsible XSS disclosure!

Okay, so a few days ago I found a ton of XSS vulnerabilities on various high profile web sites, and on the whole, after eventually managing to contact the relevant teams for the sites, everyone was very grateful.

When will web sites owners learn that it’s a good idea to have a security contact e-mail address on their sites!

However there was one, whose name I’m not going to mention here, that came back to me with the worst possible answer ever.

This is an online retailer, and my e-mail went to their help desk, but still!

Here’s the full e-mail trail (I’ve removed certain bits of info though so that the site or the attack vector cannot be identified.) Please also note that due the nature of what this company does they are required to be PCI DSS compliant.

===============================

—–Original Message—–
From: xyberpix [mailto:xyberpix@blahblah.com]
Sent: 05 January 2010 07:53
To: help@xxx.com
Subject: Website enquiry: General – www.xxx.com

Sent Date: 2010-01-05 07:52:58 (GMT/UTC)

Hi There,

I have discovered a security vulnerability on your web site, and would like to please disclose this to yourselves responsibly. Could you please either contact me with the name of someone who I should report this to, or could you please get someone to contact me at this e-mail address please. If this could please be treated as urgent.

Thank you
xyberpix

===================================
On 5 Jan 2010, at 16:40, XXX Support User2 wrote:

Hi Xyberpix,

Thank you for your email message.

Can I please ask you to supply the screenshot of the page so that we can look into this for you?

I look forward to your reply, upon which I will do my very best to assist you.

Kind Regards,
Alex | Customer Services Representative
Note: Please do not delete the previous correspondence if you are replying to this e-mail. This will help us to assist you better. www.xxx.com

===================================

—–Original Message—–
From: xyberpix [mailto:xyberpix@blahblah.com]
Sent: 05 January 2010 16:59
To: XXX Support User2
Subject: Re: XXX

Hi Alex,

No problem at all please find attached a screenshot.

Also the string that was used in the main search bar to prove this was the following:

‘;alert yadayadayada

Kind Regards,
xyberpix

==================================

Hi,

Thank you for contacting us and sorry for the inconvenience caused here.

May I kindly request you to clear the cache and cookies from your internet browser and then try placing your order opening a new browser.

If you have any further queries please do let us know.

Kind Regards,
Edwin | Customer Services Representative
XXX!

Note: Please do not delete the previous correspondence if you are replying to this e-mail. This will help us to assist you better.

Share

Vendor response to vulnerability disclosure

My wish for 2010: I want this guide to be taught in CS classes to developers everywhere:

http://vrt-sourcefire.blogspot.com/2009/12/matts-guide-to-vendor-response.html

Happy new year everybody.

Share