Category: Phishing

People using Vonage beware there’s phishing going on. Keep informed about EV certificates to make sure you don’t get caught.

——————————————————————————————————————-

In an article about phishing I commented that most exploits are initiated using an official Web site that has been subverted by attackers. Well, that’s not necessarily true.

Case in point, I subscribe to TrendLab’s e-mail security alerts and today I received an e-mail message about a fake Web site that’s phishing for useful information. Hmmm, seems like I need to revise my thinking.

Fake Vonage Web site

The fake Web site mentioned in the alert is serving up a very official-looking duplicate of Vonage’s log-in Web page. The whole purpose of the imitation Web page is to capture Vonage user names and passwords. That information allows phishers to access Vonage accounts and sensitive user profiles. The slide below (courtesy of TrendLabs) is that of the phishing Web site:

Real Vonage Web site

I was immediately impressed when I opened the official Vonage log-in page. Vonage is using Extended Validation (EV) certificates. That’s huge. If Vonage members realize that, there’s no way they’re going to get sucked in by the fake site. Oops, wait a minute; it depends on what Web browser they’re using.

I was using Firefox version three and as I explained in an article about security enhancements for Firefox, it’s very apparent when a Web site is using an EV certificate, as shown below:

That was Firefox though, if you’re still using version seven or earlier of Internet Explorer there’s no indication that the Web site is using an EV certificate. For example, the following image is how Internet Explorer version seven displays the Vonage Web site:

I’m happy to say that Microsoft fixed that in Internet Explorer version eight. The address bar turns green, alerting users to the fact that the Web site being displayed is in fact using an EV certificate:

How do EV certs help?

Phishing with fake Web sites relies on the following to be successful:

• Use an e-mail or Web site link to fool victims into going to the fake Web site.
• Obfuscate the address in the URL box to reduce suspicion.
• The victim doesn’t check for https usage or disregards the warning about an incorrect certificate if https is used.

Web sites using EV certificates prevent the above example from happening by eliminating any deception fake Web sites may have, especially if the following is in place:

• The Web browser in use will display evidence that an EV certificate is assigned to the Web site.
• The person browsing knows which Web sites use  EV certificates.

Final thoughts

First, I’d like to thank TrendLabs for publishing security alerts. Especially this notice as it gave me the opportunity to clarify several of my previous articles with a real-world example.

The use of EV certificates needs to become more prevalent. They aren’t the complete answer, but just being able to visually notify the person browsing a Web site of it’s security status is a step in the right direction.

The Tibetan Government in Exile asked the Information Warfare Monitor consortium to investigate allegations of cyberspying. It appears they’ve found evidence of spying plus a whole lot more and that should concern all of us.
——————————————————————————————————————-

To begin, Information Warfare Monitor (IWM) is a well-regarded research team consisting of the SecDev Group and the Citizen Lab, Munk Center for International Studies, University of Toronto. The following skill set will explain why the Tibetan government asked the IWM for help:

Operational Case Studies: Consisting of active operational research employing a cross-disciplinary fusion of intelligence gathered at the field level with advanced network monitoring/visualization techniques.

Analytical products: Generate case study data that illustrate the strategic significance of cyberspace and highlight the opportunities, challenges, and threats implicit to a militarization of cyberspace, including effects generated by third-party actors.

From the beginning

This compelling story about the Dalai Lama and the Tibetan Government in Exile started almost a year ago. That’s when office workers began to complain about misbehaving computers. To us IT types that may seem like business as usual, yet it was the first clue of something being drastically wrong.

After some initial troubleshooting by the Tibetan IT personnel, the IWM group was called into help. It didn’t take analysts from IWM long to determine that several computers were indeed victims of a Trojan program called Gh0st RAT. For those interested, it’s an offspring of the famous Poison Ivy trojan.

Infection via e-mail

The next step was to figure out how the computers were being compromised. IWM researchers eventually determined that opening an attached document (containing malware) was the catalyst for becoming infected. I couldn’t find any mention as to what dropper program was used. Moot point I guess, as the goal was to successfully get Gh0st RAT on the intended computer. The research paper did mention:

“Only 11 of the 34 anti-virus programs provided by Virus Total recognized the malware embedded in the document. Attackers often use executable packers to obfuscate their malicious code in order to avoid detection by anti-virus software.”

Even so, malicious attachments are a well-known attack vector and that method shouldn’t have worked, right? Maybe, except these attackers were very creative, using appropriate e-mail addresses and realistically-named attachments like “Translation of Freedom Movement ID Book for Tibetans in Exile.doc”. Honestly, the following example looks official to me:

Even sneakier

Misleading the office workers became easier for the attackers once several computers were infected, simply because the attackers then have authentic documentation and contact information:

“Once compromised, files located on infected computers may be mined for contact information, and used to spread malware through e-mail and document attachments that appear to come from legitimate sources, and contain legitimate documents and messages.”

Something I didn’t think about was the coincidental spreading of Gh0st RAT. Since the attachments looked real and Gh0st RAT typically doesn’t affect normal computer operations, workers may have inadvertently sent the malicious attachments to others, hastening the trojan’s propagation:

“It is therefore possible that the large percentage of high value targets identified in our analysis of the GhostNet are coincidental, spread by contact between individuals who previously communicated through e-mail.”

I’m not sure how you combat social-engineering; it’s been around a long time and appears here to stay.

Sadly enough, that wasn’t the Tibetan system administrator’s only problem. They had the exploitable operating system vulnerabilities (we all know and love) to deal with. The report didn’t offer any more detail, so I’m not sure whether the attackers used zero-day exploits or if the computers weren’t fully updated.

What’s Gh0st RAT capable of?

Ghost RAT (Poison Ivy) is considered a Remote Administration Tool (RAT), basically a remote access program like VNC. Allowing the attacker almost complete control over the victim computer. Poison Ivy/Gh0st RAT is capable of the following:

• Files can be manipulated completely and the attacker can upload/download files to and from the system.
• The registry can be viewed and edited.
• Active services can be viewed, suspended, or shut off.
• Enabled network connections can be determined and shut disabled.
• Installed devices can be viewed and some devices can be disabled
• Installed applications can be viewed and entries can be deleted or programs uninstalled.

Being recently updated, Gh0st RAT has a few additional features that make it an effective spy tool:

• Screenshots of the desktop can be taken,
• Web cams, microphones, and audio/visual recording programs can be enabled to act as surveillance devices.
• Passwords and password hashes are saved.
• Key loggers can be used in conjunction with other devices to steal information.

All and all, it appears to be an efficient remote admin tool. If you aren’t convinced, check out Symantec’s detailed video that explains Gh0st RAT’s capabilities.

Many Gh0st RATs equal GhostNet

I consider the discovery of the GhostNet to be exemplary detective and forensic work. Initially the IWM team didn’t know what to expect as they worked their way from individual computers infected with Gh0st RAT back to the GhostNet control servers:

“During this process we were able to find and access web-based administration interfaces on the control server identified from the OHHDL data. These servers contain links to other control servers as well as command servers, and so therefore we were able to enumerate additional command and control servers.”

Once they had penetrated the control servers they began to get an idea as to how many computers were members of the GhostNet:

“In total, we found 1,295 infected computers located in 103 countries. We found that we were able to confidently-on a scale of low, medium, high-identify 397 of the 1,295 infected computers (26.7%), and labeled each one as a high-value target. We did so because they were either significant to the relationship between China and Tibet, Taiwan or India, or were identified as computers at foreign embassies, diplomatic missions, government ministries, or international organizations.”

Further insight

I’d recommend listening to Jesse Brown’s (CBC.ca) podcast titled, “Exposing the world’s biggest cyberspy ring“, as he interviews members of the IWM team who were directly involved with the project. I’d also like to recommend the IWM’s official report, “Tracking GhostNet: Investigating a Cyber Espionage Network“; I consider it to be an exceptional document, offering proof as well as a definitive explanation of the entire investigative process. It’s the report that I’ve quoted numerous times in this article.

Final thoughts

It sounds like the Internet is slowly becoming a war zone. How prevalent is this type of electronic espionage? Who’s involved, or is it easier to say who isn’t involved? Depressing isn’t it. Odd as it sounds, I remain hopeful because of organizations like IWM. Their hard work is making the Internet a safer place.

TechRepublic’s IT Security e-mail newsletter (delivered every Tuesday) is a great way to keep on top of security issues related to Information Technology. Please make sure to sign up.

First it was spoofing e-mail, then instant messages, and now spoofing Twitter is where it’s at. Right now the ROI is good for attackers; let’s try and change that.

——————————————————————————————————————-
I just completed an article titled URL shortening: Yet another security risk, in which I discussed URL shortening and how phishers/attackers subverted it to drive unsuspecting users to malicious Web sites. After reading the many comments, I was happy to note that in general users are getting savvier about misdirection exploits.

This appears to apply to Twitter as well, even though messages or tweets, with shortened links make it more vulnerable. Fortunately, Twitter has an additional advantage in that we the users get to pick who can send us tweets. This capability significantly reduces the risk simply because you know who’s sending you the message.

Well, maybe not

I’ve just finished reading an article by Washington Post’s Brian Krebs titled, Twitter Security Hole Left Accounts Open to Hijack. It seems that it’s not that difficult to spoof Twitter messages. Krebs quoted Lance James a security researcher and author of “Phishing Exposed“:

“Anyone could authenticate and hijack a Twitter account by using SMS spoofing services, such as my-cool-sms.com, or phonytext.com. These Web sites allow users to mask what phone number they are texting from by letting the user input whatever phone number they want to appear in the from field.”

Oh great, this totally negates the one advantage that Twitter had over IM and e-mail. It’s not hard to see that phishers/attackers would want to leverage SMS spoofing along with URL shortening to redirect victims to malicious Web sites.

Help from the cellular network operators

One good thing that Krebs alluded to was the fact that SMS spoofing may only work if the attacker is located outside of the United States:

“Twitter co-founder Biz Stone wrote in an e-mail.[Mobile] carriers in the U.S. have their own systems for blocking SMS spoofing. Indeed, most U.S.-based mobile carriers have put in place measures to block SMS spoofing on their networks. But this is generally not the case for international mobile networks.”

It appears that United States is one of the few countries forcing cellular carriers to clamp down on SMS spoofing. That’s great, but spoofing Twitter messages is still possible just about everywhere else. I’ll give you two guesses where most phishing and malware exploits originate, and the first one doesn’t count.

Proof of concept

H Security (a German security company) verified that SMS spoofing works in an article titled, Twitter spoofing fix fails in UK and Germany. The article provides the following details of the process:

“In the UK, we had a mobile phone associated with a Twitter account. By taking only the number of the mobile phone and setting it as the sender field on PhonyText then sending an SMS to +447624801423, the UK number for sending SMS tweets, we were able to see our message appear in the tweets on the honline page.”

The article goes on to explain what this potentially means:

We then promptly removed the association between the phone and the Twitter account. An attacker could have created a message directing followers to malware sites, to other risky locations on the web, or posted tweets designed to ruin the reputation of the account owner.”

What this means

First, the ability to spoof a Twitter message enhances all the normal misdirection schemes that are already in play. The fact that shortened URLs are common place in Twitter messages makes it even easier to pull the scheme off.

The damages from the SMS spoofing and URL shortening exploit can be as simple as malware being loaded on victims’ computers to as complex as stealing sensitive financial information from the victims. Also a cruel joke could be played on Twitter accounts that don’t have unlimited texting. It would be easy to run up some monster phone bills as noted in the Twitter support section:

“Twitter charges you nothing, but how much it costs to use Twitter with text messaging depends on your text messaging plan. Standard text messaging rates (such as international text messaging fees) do apply. Consult your service provider to ensure that your text plan covers your Twitter usage.

If you’re using our international number, give your provider the Twitter phone number you’ll be using to see if you’ll incur extra charges. If you’re using Twitter from outside of the US, please consult your carrier, as every provider has a different policy.”

Final thoughts

Following spoofing’s logical progression was easy for the phishers and malware creators of the world. Yet, from the comments I’ve read, it seems like it’s getting harder for them to find chinks in the armor. That’s good and should be heartening to all of the people who are trying to keep the Internet the amazing place it is.

Still, there needs to be awareness and vigilance as long as the possibility of a RoI is perceived by the dark side.

“Need to know” security issues and news delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

URL-shortening services such as TinyURL and Bit.ly are becoming popular attack vectors. You may not want to automatically click on the shortened URL after you read this.
——————————————————————————————————————-
Originally, the process of URL shortening was developed to avoid broken URLs in e-mail messages. The increased popularity of instant messaging (IM) and Twitter has escalated the use of URL-shortening services like TinyURL and Bit.ly, especially Twitter with its 140 characters per message limit.

How they work

TinyURL, Bit.ly, and other Web sites that offer URL shortening are similar in how they work. All that’s required is to:

1. Go to the respective Web site.
2. Copy/paste the actual URL into the appropriate field.
3. Click on Shorten if you want the Web site to append a generic ending on the URL.
4. If a custom URL is desired, enter your chosen ending and then click on Shorten.

Presto, you have a new shortened URL, as shown below.

From the slide you can see that the finished URL has little meaning and isn’t visually related in any way to the official URL.

Potential phishing method

As with many applications that are helpful to normal law-abiding users, attackers and spammers tend to leverage that same usefulness for ill-gotten gain. URL-shortening services provide attackers and spammers with the following options:

• Allow spammers to side step spam filters as domain names like TinyURL are automatically trusted.
• Prevent educated users from checking for suspect URLs by obfuscating the actual Web-site URL.
• Redirect users to phishing sites in order to capture sensitive personal information.
• Redirect users to malicious sites loaded with drive-by droppers, just waiting to download malware.

As you can see, there are all sorts of opportunities for misuse, just because the victim has no idea where the shortened URL is pointing.

An example

Trend Micro has been very active in researching this particular attack vector and the following slides are borrowed from their Web site. The example uses a typical scam e-mail message to send the message recipient a bogus link. The first slide is the phishing e-mail message:

You may have noticed that the e-mail message displays the actual link instead of a truncated version. Attackers are cognizant of the fact that we as users are constantly told to copy and paste the URL into the browser instead of clicking on the link. So they use extremely long URLs, making the copy/paste as difficult as possible. Come on, why not click on the link, the URL looks right.

Power users who are a bit more paranoid may also check out the link’s properties to see if the advertised URL makes any sense. That’s why attackers now go through the additional effort to use services like Bit.ly and TinyURL. As it prevents the user from truly knowing where the link is pointing. Talk about cat and mouse.

The next slide shows the Web site the link points to and even though the Web site is a fake one, it’s a fairly accurate representation of the bank’s actual Web site:

So, if the victim is fooled, important log in information more than likely will be captured by the phisher.

That’s old news

I dare say that most users aren’t going to fall for the IM or e-mail message phishing exploit, even with the use of shortened URLs. Bad types know that as well and are shifting gears by leveraging the increased use of Twitter. Shortened URLs in tweets (Twitter messages) are so common place; it’s almost an automatic response to click on them, which is exactly what a phisher/attacker wants.

Even better yet, many people use Twitter on their computers. Making URL-shortened links a simple yet effective way to send the computer to a phishing or malicious Web site without the user knowing what’s going on. Not to be overly pessimistic, but security experts say it’s only a matter of time before SMS-enabled phones will be exploited in the same manner.

There’s hope

Every day, I get dozens of tweets that have shortened URLs. I twinge a bit; yet usually click on them if I want to learn more. I already know what you are going to say. I picked the sources that I want to follow, so I should trust them. Yes, No, Maybe?

Well, I’m happy to say that I know of at least two URL-shortening Web sites that offer a preview feature. This means the user can make an educated choice of whether to go to the link or not, because the full-length URL is displayed.

TinyURL preview feature

To initiate TinyURL’s preview all that’s required is to start your computer or smart phone’s Web browser, go to TinyURL’s Web site, and enable the preview opt-in feature. After that every time a TinyURL link is clicked, the browser immediately goes to a preview Web page like the one shown next:

TinyURL’s preview didn’t work when I used any of the Twitter client applications for my iPhone. For example, when I clicked a TinyURL link in Tweetie, it opened Safari and went straight to the linked Web page. That’s not good, I’ll have to remember to only open links in the SMS application.

Bit.ly preview feature

Bit.ly uses a slightly different approach. They have created an add-on for Firefox. Once it’s installed, hovering over the URL-shortened Bit.ly link will open a window displaying the full-length URL. The add-on is still experimental, so before you can install it, you are required to log into the Mozilla Web site.

Previewing Bit.ly’s shortened URLs on smart phones is a bit more complicated as Firefox is required. I know Firefox has a mobile Web browser for Windows Mobile 6, but I’m not using any Windows-based smart phones. So I’d appreciate hearing from you as to whether the Bit.ly preview works in the mobile Firefox browser or not.

Final thoughts

Many industry pundits say that we shouldn’t click on active links, whether they’re in e-mail messages, IM messages, or tweets. That’s an unrealistic expectation; so just make sure to approach links (especially those with shortened URLs) with caution. If possible, use one of the preview features to check out the link first.

Remember when I mentioned that I should trust the sources that I’m following? Well, I’m researching another interesting twist to the URL-shortening attack vector. It seems that SMS spoofing sites can be used by attackers to send tweets that appear to be coming from someone that you are following. Stay tuned to find out what that means.

“Need to know” security news and advice delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

At the moment, the only really safe way to view e-mail is plain text. What if someone actually went to the trouble of creating a safe rich content rendering mode for an e-mail client?

Much as I wish it were otherwise, it doesn’t seem likely that everybody in the world will forsake their unnecessarily HTML-laden ways when it comes to composing emails, not only because many modern email clients default to HTML-formatted e-mails, but also because many people get deeply involved in choosing the right “stationery” background image, fancy fonts, and other pointless frippery when sending intensely interesting and highly informative e-mails like “yo, whats up? how r u?”. Luckily, a lot of those clients do “the right thing” when composing HTML emails, which is to offer a plain text version as well without the person composing the email even having to know about it.

Sometimes, however, we don’t get plain text versions along with the tangle of spaghetti HTML. This may be because, when certain things are done in HTML that cannot be reasonably well degraded to plain text, the email client just skips the plain text version; it may be because some Website developer doesn’t know any better when he designs the automated feedback form reply script; it may even be because someone stupidly turned off the plain text copy capability. It may also simply be the fact that someone is using a particularly low-quality email client that only offers HTML formatted functionality.

Regardless of how it happens, the fact remains that sometimes we just need to be able to sift through the contents of an HTML-formatted e-mail, and probably don’t want to have to do it without getting a headache. The choices are usually limited to:

1. give up on secure practices and just view the rendered HTML e-mail somehow — either within an HTML-capable email client or by viewing the email in an outside application that renders HTML
2. live with the inconvenience of parsing all that markup by eye
3. delete the offending email and request another copy without the unnecessary markup scattered through it

I used to run with number 2 all the time. After a while, I decided to write a simple script I call stripmark that would parse HTML out of the email so I could just view the plain text. Over time, it has acquired a few more capabilities, including translating linebreak tags into actual newline characters in the plain text output. This sort of thing is relatively easy to do, with tools like the Ruby programming language and a highly functional text-mode mail user agent such as Mutt. This, however, is far outside the range of what the average user is able to do, and isn’t exactly within the range of what most technically oriented people are willing to do — especially those whose tools are mostly limited to the MS Windows platform.

The script I use is gradually changing into something akin to the opposite of what text parsing libraries like Markdown do. Such libraries define a simplified markup language that is much easier to use to describe how text formatting should be specified via the keyboard, then parse text formatted in that manner, translating the document into an HTML or XHTML formatted document. In fact, I type these articles in plain text files using Vim, entering Markdown formatting signifiers by hand, then run a script that uses a Markdown library to transform the text formatting signifiers into Web markup before it gets published here at TechRepublic.

If it keeps evolving to that point, my stripmark script will eventually do the inverse: it will translate HTML or XHTML formatted documents into text with simple text formatting signifiers that make emphasis, linebreaks, and other simplified “rich text” characteristics obvious without making the text nigh-unreadable the way an actual Web markup language does.

At the moment, the script is just a dirty hack. Even if it was cleaned up, prettied up, and made worth distributing, though, its use would still be a dirty hack. What’s really needed is for mail user agents and email clients to incorporate such safety related functionality directly, either via official plugins in the case of Unix MUAs or as integrated functionality in the case of mainstream GUI email clients.

By default, a “safety mode” for any e-mail client should perform a number of tasks for the user. A few examples include:

1. Disallow embedded images, Flash objects, or anything else that isn’t actual text and markup in the rendered “rich text” email display without a warning and specific user intervention.
2. Disallow hiding URLs behind link text so that even the most casual, security-ignorant user will not be fooled into thinking a link that says “PayPal” but has a URL with a phishing.example.ru domain is a legitimate PayPal link.
3. Disallow execution of any dynamic content, especially including JavaScript, VBScript, and similar programming languages, without a warning and specific user intervention.

The list could go on at great length, but it would probably be easier to just list things that should be allowed — like italicizing text, bolding text, underlining text, manipulating colors, and physically altering the visible location of content on the screen in a manner that doesn’t hide any content (such as via tables or CSS positioning). It should also clearly indicate when any text uses characters that are not part of the standard ASCII character set, just for good measure, in case someone wants to copy and paste a URL from an email to a browser.

This, at least, would allow people like me, who are aware of the security dangers of normal HTML e-mail rendering, to view the occasional marked up email without having to go to inconvenient lengths to read it without making ourselves susceptible to the dangers of rendered HTML emails.

Unless and until such a MUA or e-mail client that I want to use lands in my lap, though, I’d appreciate it if you’d all default to sending plain text e-mails only. Considering the overwhelming tendency of spammers and phishers to use HTML e-mail, and that most legitimate email users at least offer plain text along with the HTML formatted versions of their messages (whether they know it or not), my spam filtering identifies all HTML-only emails as high-risk targets. If I don’t expect your email, and it’s HTML formatted, you should be resigned to the expectation that I may never read it.

I value my security more than unsolicited emails, and — contrary to my usual policy of avoiding false positives at any reasonable cost — I’m willing to accept a few false positives to protect myself.

Viewing e-mails without rendering HTML formatted content can be a simple, easy, and effective security technique.

    Delivered-To: unknown
    Envelope-to: me@example.com
    Delivery-date: Wed, 11 Feb 2009 09:45:07 -0700
    Reply-To:
    From: "service@paypal.com"
    Subject: Account Expired ! Please renew your account !
    Date: Wed, 11 Feb 2009 11:48:20 -0500
    X-Priority: 1
    X-MSMail-Priority: High
    X-Mailer: Microsoft Outlook Express 6.00.2600.0000
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
    Bcc:
    X-OriginalArrivalTime: 11 Feb 2009 16:45:05.0698 (UTC) FILETIME=[17964020:01C98C68]
    X-user: ::::0.0.0.0:host.example.net::::::

    <html>

    <head>
    <meta http-equiv="Content-Language" content="en-us">
    </meta><meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
    <title></title>
    </meta></head>

    <body>
    <font face="Arial, Helvetica, sans-serif" size="2">Dear Member,<br />
    <br />
    Your PayPal account has expired. <br />
    You must renew it immediately or your account will be closed. <br />
    If you intend to use this service in the future, you must take action at once!<br />
    <br />

    To continue <a href="http://example.org/files/liaz/index.php">click
    here</a>, login to your PayPal account and follow the steps.<br />
    <br />

    Thank you for using PayPal!<br />
    The PayPal Team<br />
    <br />
    </font><font face="Arial, Helvetica, sans-serif" size="2">Please do not reply
    to this email. This mailbox is not monitored and you will not receive a respons.
    For assistence, log in to your PayPal<br />
    account and click the Help link located in the top right corner of any PayPal
    page.</font><font face="Arial, Helvetica, sans-serif" size="2"><br />
    <br />
    PayPal Email ID PP3573</font>
    </body>

    </html>

Obviously, I have changed all the domain names and IP addresses (other than PayPal’s domain name) to protect my privacy and to protect any of you from accidentally visiting a phishing site. I don’t want my readers getting infected because of my articles, after all.

The highlighted snippet contains a link. If you look at it closely, you’ll notice that’s not a PayPal URL in the link — something you wouldn’t necessarily notice if you viewed the email with HTML rendered, which would just look like this:

This isn’t exactly the cleverest phishing attempt in the world. It contains spelling errors, and targets something that most security-aware people will immediately recognize as a common subject of phishing e-mails. A more well thought out attempt might fool someone who doesn’t habitually look at the plain text of e-mails, however.

In general, legitimate emails with HTML formatting come with a plain text version as well these days. When signing up for mailing lists and other mass-notifications, it is almost always possible to choose whether you get emails in plain text or HTML form. The exceptions are almost always phishing emails. Some people may get more HTML formatted emails than others, of course, but for most of us there really isn’t any need to render HTML for all emails. In my case, in fact, HTML formatting is a very accurate predictor that an email I receive is unwanted, and I use HTML formatting as part of my spam filtering criteria.

In my list of basic email security tips from almost a year ago, I mentioned that one should avoid letting HTML render in your email client. Take this as an object lesson in the kind of threat HTML e-mails can present.

The browser is typically blamed for most if not all Web-related security problems faced by business and home users. But the browser isn’’t the problem. The real problems still sit under the browser and about 19 inches from the monitor.

——————————————————————————————————————-

Security blogs and articles about browser problems abound. The browser is typically blamed for most if not all Web-related security problems faced by business and home users. However, this position doesn’t resonate with the way I see security today. It isn’t the browser that’s the problem. The real problems still sit under the browser and about 19 inches from the monitor.

Ok, so a browser with some security features is a good idea. Why open the gate completely when you’re certain barbarians are lurking on the other side. But relying only on the gate to defend the castle is a bad idea.

Another way of looking at the problem is from the perspective of disease control. Melith Abdulhayoglu wrote about this in a recent Security Focus article.

There was a time when most diseases were fatal for humans. Intense study and research helped doctors manage diseases better, and subsequently even prevent them altogether.

Today, vaccination is an established and permanent method of preventing diseases by strengthening the body’s natural defenses against the causal elements. The solution lies in eliminating the threat by shoring up the immune system and creating a wall of defense, and not in just managing the symptoms.

The same principle applies to Internet browsers too. True, browsers do come with a built-in security mechanism. However, it should not be their job to be on watch all the time. Browser[s] are there to perform a function: to browse the Internet. Rather than also attempt to secure the user, they should work together with security products to protect the computer network and data against intruders and prevent attacks.

Source: Don’t Blame the Browser, Melith Abdulhayoglu, Security Focus, 6 February 2009

The key statement here is that browsers are intended to perform a specific function, browsing, not protect your computer from the thousands of exploits floating around the net. And they should never be expected to protect the business network from user behavior. The browser can only do so much, and we have to expect bad things to come through it into our systems. The question, then, is not how well our browsers stop exploits. Rather, we need to ask ourselves how prepared we are to defend against inescapable successful infections of one or more computers connected to our enterprise networks. And what precautions do we take when risky Web browsing is either necessary or inevitable?

Let’s start with the second question first. How DO we ensure safe browsing? For example, I’m always visiting new and interesting Web locations in my research. No browser on the market today can completely protect me from automated nasties I occasionally encounter. Further, I want to click on the unknown just to see what will happen. So how do I protect myself?

First, I don’t rely on my browser. Although I use Firefox for general browsing, I use Google’s Chrome for research. Yes, Chrome. I find that it is a much better tool than Firefox to support the way I work. Do I rely on Chrome to protect my computer? Not a chance. I do, however, rely on the steps I take to minimize the risk to my home research network.

1. I run Chrome sandboxed with Sandboxie. Any stuff that finds its way onto my computer is not permanently stored. When I close the sandbox session, all unwanted visitors are deleted. This is supplemented in the new version of Sandboxie with a DropMyRights-like setting that allows me to work within the sandbox without local admin rights.
2. All computers are protected with a firewall, anti-virus, and anti-spam software.
3. All computers are patched with the most current security patches. This is the most important path to an inoculated computing environment.

I also use good old common sense. However, I can’t rely on common sense at the office. So, I add the following:

1. The network is monitored for anomalous behavior, including extrusion and data leak prevention.
2. Web filtering to minimize inadvertent visits to high risk sites.
3. Awareness training in the hope that it will cause at least some users to think before they click.
4. Where possible, users are not given local admin rights on desktops and their use of handheld devices is controlled.

Finally, I assume there will be an infection or a breach, and I plan for it. No one should expect a strong layered approach to stop a strongly motivated attacker. Nor should we expect any number of security controls, no matter how strong, to protect our networks when users continue to invite disaster. So how can we expect a browser, any browser, to provide end-user device or network security?

My only expectation of a browser is that it works as advertised with no vulnerabilities caused by careless programming or negligent design. Maybe we should ask our browser vendors to focus on these outcomes while we look for other ways to secure our computing environments.

Fighting spam and other botnet recruitment efforts requires constant vigilance.  We might not be able to eliminate the bad guys, but we can certainly raise the level of effort necessary for them to use our networks for financial gain.

——————————————————————————————————————-

Active bots (a.k.a. zombies) continue to grow in number, even after the 4th quarter 2008 takedown of McColo, at the time the world’s largest botnet controller, at a rate of about 300,000 per day.  This is according to a recent internet.com article by Richard Adhikari.  He writes that the reason for the continued increase is the incremental improvements both in bot software and in bot recruitment methods.  In this article, I focus on two ways bots are recruited, mounting a defense, and dealing with bots already working on your network.

Scanning through Adhikari’s article, I found two primary attack vectors described:

1. Improvements in Pharming result in more successful recruitment.
2. Recruiting email is still getting to users who still insist on clicking the included link.

Let’s take a look at what these mean to a business network administrator, what can be done to defend against having an organization’s desktops recruited for botnet duty, and how to detect bots which have slipped through our defenses.

Two popular pharming techniques

Pharming is the redirection of a Web site’s actual or intended traffic to a malicious site.  Redirection is often accomplished in one of two ways: modification of host files or by taking advantage of weaknesses in DNS services.

The Hosts file is an old method of resolving domain names to IP addresses when DNS services are either not available or when slight adjustments to resolved addresses are required.  The Hosts file, residing by default on every Microsoft Windows system, contains domain/IP address information which overrides DNS name resolution.  So all an attacker has to do is drop a small script on a desktop, modify the Hosts file, and abracadabra, the user is thenceforth directed to one or more sites of the attacker’s choice.  Let’s step through an example on a Windows XP SP2 system.

The hosts file is located in the same place on all current versions of Windows, shown in Figure 1.  Hosts is a text file WITHOUT an extension.  Adding an extension causes Windows to ignore the file on bootup.

Figure 1

Hosts ships with content designed to assist administrators, as shown in Figure 2.  Note the entries are similar to host address resource records in DNS.

Figure 2

To demonstrate how this works, I chose to redirect my Web site name, adventuresinsecurity.com, to google.com.  I started by pinging Google and entering the IP address returned into the hosts file along with my domain name, as shown in Figure 3.

Figure 3

After I saved the file (with no extension), I flushed the resolver cache by entering ipconfig /flushdns at a command prompt.  This performed two tasks.  First, it removed all cached name resolution records from my test machine.  Second, it loaded the contents of the hosts file into the resolver cache.  Since the resolver cache is checked before a Windows system sends a DNS query, adventuresinsecurity.com will always resolve to the Google IP address.  (For detailed information on DNS and resolver cache operation, see DNS resource record integrity is still a big, big problem.)

To test, I closed and reloaded Microsoft IE7 and entered adventuresinsecurity.com in the address space.  As you can see in Figure 4, I was directed to google.com instead of my Web site.  If an attacker placed this entry, he or she would likely redirect me to a page which looked exactly like the actual site.  Applications at the substitute site could then perform various tasks, including enlisting the redirected system into a botnet.

Figure 4

Default access to the Hosts file is read/execute for all users except local admin.  As long as your users are not logging in and browsing the Web as local administrators, this type of attack will be troublesome for black hat hackers.  But there is another way.

Black hats do not have to gain access to the local Hosts file to redirect users to malicious sites.  Recent discoveries about DNS vulnerabilities make resolver cache poisoning at the server level a real possibility, especially if DNS service providers have not patched or properly configured their servers.  Poisoned cache entries can potentially redirect all systems requesting name resolution to malicious servers.  For more information about DNS security issues, see:

• An Illustrated Guide to the Kaminsky DNS Vulnerability
• DNS Cache Poisoning
• DNS resource record integrity is still a big, big problem

Name resolution redirection, in any form, is growing as an insidious method of attracting new recruits into spam botnets.  Although outside the scope of this article, it’s important to understand that redirection also increases data and identity theft risk.

Spam growth and metamorphosis

Spam and pharming for bots feed each other.  Bots send spam and many spam messages help recruit.  And spam is on the rise as a percentage of the global message total.  According to Adhikari’s article, the percentage of email messages identified as spam has grown from 72 percent in the fourth quarter of 2008 to 85 percent in January (about 150 billion messages), with no signs of slowing.

So much of this spam is intended to increase the size of botnets, which increases the amount of spam, which increases the size of botnets, ad infinitum.

Defense

Blocking all spam without blocking a sizable number of valid messages is not possible.  In addition, spam filter vendors are always playing catch-up as spammers adapt to filtering technology.  So organizations must allow some spam to get through, relying on user behavior—not clicking links in spam messages–to protect the network and sensitive data.  Since relying on humans to do the right thing is never really good way to ensure security, security professionals must take additional steps to detect and eliminate bots and other bothersome malicious code which have already found they way into the enterprise.

Preventive measures are well known but often not implemented, including:

• DO NOT allow users to log in as local administrators.  At the very least, limit their system access when accessing the Internet.  (See Use DropMyRights to protect systems from admin users.)
• Filter Web site access.  If you don’t have the budget to pay for this, OpenDNS is a great way to provide this function.
• Ensure your DNS services are patched and security configured.  If you don’t host your own service, check for vulnerabilities with free services like the DNS Nameserver Spoofability Test.  If vulnerabilities exist, work with your vendor to fix them.  If necessary, switch to a service more attentive to your network’s security.

Detection

No matter what you do, bots will likely find their way onto your network.  Two primary detection, intervention, and eradication methods can help rid you of them.  The first is blocking spam coming from the bots and the infected machine’s ability to accept new commands from botnet HQ.  Blocking outgoing spam is possible if the right monitoring systems are in place.  Not only can an IPS device, for example, block the spam.  It can also alert staff that a bot is in the house.

Second, extrusion/intrusion detection methods, also found on IPS devices, can detect or block bot attempts to connect to unrecognized or non-business related external servers.

Finally, and most obvious, is the implementation and daily management of an antivirus solution.  I know, I know.  This is getting a little old, but you’d be surprised by organizations that still “don’t get it.”

The final word

Fighting spam and other botnet recruitment efforts requires constant vigilance and frequent adjustments to administrative and technical controls.  We might not be able to eliminate the bad guys, but we can certainly raise the level of effort necessary for them to use our networks for financial gain.

Providing only the local system access necessary for business users to perform their jobs should be the ultimate goal.  But until that time, we can drop their rights when appropriate.

——————————————————————————————————————-

Microsoft Windows XP system and security administrators don’t have to wait until management decides to deal with user angst and approves removal of local admin access from normal users–a move necessary to protect end-user systems from risky behavior.  Nor do they have to undertake the more onerous task of moving to Windows Vista.  Instead, implementation of DropMyRights allows them to protect users and the business from the behavior of high-risk applications, like Web browsers.

DropMyRights is a free download.  It comes as an MSI package containing the executable and source.  It’s not easy to find, so Steve Gibson provided a link in the Security Now episode notes in which he discusses the value of this utility.  See Figure 1.

Figure 1 (http://www.grc.com/securitynow.htm)

Once installed, DropMyRights runs from a command line, using a path to the desired application and the access level as arguments.  Figure 2 shows the syntax I used to run Firefox.  Note the requirement for the entire path for the executable.  There are three levels of access available.  I used ‘N’, or normal.  Details about the rights removed at each level (Normal, Constrained, Un-trusted) are provided in Browsing the Web and Reading E-mail Safely as an Administrator, written my Michael Howard, author of DropMyRights.

When I entered the command, DropMyRights removed certain rights from my user token.  Using the modified token, now with no local admin rights, it launched Firefox.  Actions like installing a root kit or other unwanted applications while browsing were now blocked.

Figure 2

This is great for those of us who know what a command line looks like.  However, our business users need a little more handholding.  So I tested a shortcut to launch Firefox with Normal user access to my system, as shown in Figure 3.

Figure 3

Not long ago, I wrote about a free sandboxing program, Sandboxie.  Shouldn’t it be enough to protect our systems?  Yes and no.  As I wrote in the article, Sandboxie prevents unwanted applications and miscellaneous junk from being written permanently to your disk.  However, anything malicious written into the sandbox can still compromise your privacy.
The current version of Sandboxie doesn’t provide a means to reduce user rights when an application is launched.  However, a combination of DropMyRights and Sandboxie seems to work well.

First, I configured my default sandbox to force Firefox into a sandbox every time I ran it, as shown in Figure 4.

Figure 4

Next, I simply ran Firefox using the shortcut shown in Figure 3.  DropMyRights ran Firefox and Sandboxie forced it to run, with reduced rights, in a sandbox.

Using DropMyRights for an enterprise rollout shouldn’t be a problem, according to the EULA contained in the downloaded MSI.  However, neither DropMyRights nor Sandboxie should be a permanent solution for organizations without the political will or clout to remove local admin access from normal users.  Providing only the access necessary to perform their jobs should be the ultimate goal.  But until that time, we can drop their rights when appropriate.

This week’s security events include news of a security vulnerability found in MS SQL Server 2000, scammers exploiting older versions of Asterisk VoIP systems to make unauthorized calls, a project at Google that allows native code to be run in a browser, and new vulnerabilities discovered in the wake of Microsoft’s largest Patch Tuesday release this week.

————————————————————————————————

Security vulnerability found in MS SQL Server 2000

The folks over at SEC Consult have found a vulnerability in Microsoft’s SQL Server 2000 that will allow a remote attacker to execute code on the server.

The problem appears to lie in the extended stored procedure sp_replwritetovarbin, which can be exploited by supplying uninitialized variables by parameters.  Depending on the version of Windows that is running, it is possible to trigger a memory write or even use it to execute arbitrary code in the process context of the running SQL server.  It is worth noting that sp_replwritetovarbin is accessible by anyone by default, and hence can be exploited either via an authenticated user, or even via SQL injection through a vulnerable web application.

So far, this vulnerability has been confirmed on SQL Server 2000/2005, though not confirmed on SQL Server 2008.  According to SEC Consult, a release date for the patch remains uncertain despite the promise of a patch by Microsoft by September.  The recommendation is to remove the sp_replwriterovarbin extended stored procedure as a workaround.

You can read the Security Advisory here.

Scammers using Asterisk VoIP systems to make unauthorized calls

Criminals are taking advantage of older versions of Asterisk - some of which have a number of serious flaws, and exploiting them to make unauthorized outbound calls.  One such variant - called vishing - is to configure compromised Asterisk exchanges in order to receive follow-up calls to their phishing or spam emails.

In the scenario described by U.S. Federal Bureau of Investigation (FBI) though, these scammers are using hacked systems to dial-out from a list of predefined numbers, and then playing a pre-recorded mp3 or wav file.

According to an advisory by the FBI:

The [vulnerabilities in Asterisk] can be exploited by cyber criminals to use the system as an auto dialer, generating thousands of vishing telephone calls to consumers within one hour.

The logical thing to do would be to ensure that your Asterisk exchange, even if it is a hardware-based VoIP derivative, to update to the latest version of Asterisk or firmware. In the meantime, Digium - the creators of Asterisk, have called the Fed warning as a “tempest in a teapot”.

You can read more from Network World here.

Google goes native client

Google has whipped out a research project in order to allow x86 native code to run in the confines of a Web browser.  The idea is to allow online applications to take full advantage of the local CPU power for processing.

Possible applications would be a photo-sharing Web site where users can touch-up photos from a single interface.  In such a scenario, the ability to run native code on the desktop PC will allow for a much more responsive application by minimizing remote data transfer and latency.  The obvious problem here has to do with the question of security - protecting users from malicious applications or sites, which Google’s research project attempts to resolve.

According to heise Security UK:

Native Client is composed of a browser plug-in and a GCC based compiler. The plug-in works with Firefox, Safari, Opera and Google Chrome. Linux, Mac OS X and Windows are all supported too, with only Internet Explorer being the exception.

You can read more about Native Client from this blog entry at the Google Code Blog.  Alternatively, you can download this white paper (pdf) which looks at the process in detail, highlighting topics such as how the sandbox is designed.

Why not just use Java or existing client-side engines? I have no idea. Do you think this concept will take off?

New vulnerabilities discovered right after Patch Tuesday

Earlier this week, Microsoft delivered the largest patch release in five years - 28 patches covering 8 reported vulnerabilities. Hot on its heels however, came news of not one, or two, but three vulnerabilities that the Redmond-based company appeared to have missed.

One of them affects Internet Explorer 7, and involves exploiting an XML parsing component via a typical heap overflow.  What is important to note is that there are already many sites - mainly hosted in China, that are actively exploiting this flaw.

According to SecurityProNews though:

Microsoft downplayed the threat saying they were “aware only of limited attacks that attempt to use this vulnerability, but they were investigating. Until a fix is produced, the company recommends running Protected Mode in IE7 in Windows Vista, and the default high security level on Windows servers.

At the moment, the attack still requires some JavaScript in order to achieve code execution.  As such, disabling JavaScript could somewhat mitigate the risk.  Or maybe just switching to another browser makes more sense.

The second vulnerability involves MS SQL Server 2000 - which we covered above, at least appears to be an earlier reported flaw that has yet to be fixed.  The final vulnerability has been reported to affect the WordPad Text Converter for Word 97.

Microsoft is currently still investigating.

Do you have any comments or feedback on the security news roundup this week?