13
Jul

The Cloud Owner’s Manual: Chapter 3 — Privacy

Written by Andrew Jaquith. Posted in Blog Post

Is your company considering cloud-based services such as email or security? You need an “owner’s manual” to know what to expect, and what to look for as you evaluate providers. To help you make informed choices, we have put together a short set of video clips from my well-received presentation The Owners Manual for the Cloud, which I gave at the Forrester Security Forum in Las Vegas last month.

Chapter Three in the Cloud Owner’s Manual explores privacy, examining not only what you should expect from your vendor such as compliance with privacy regulations, but also what “extras” you can reasonably ask to be included in your contract to ensure the highest levels of privacy.

This is the sixth post in our Cloud Owners Manual series. As always, we welcome your comments, observations, Tweets, likes and links.

12
Jul

The Cloud Owner’s Manual: Chapter 2 — Data Protection

Written by Andrew Jaquith. Posted in Blog Post

Is your company considering cloud-based services such as email or security? You need an “owner’s manual” to know what to expect, and what to look for as you evaluate providers. To help you make informed choices, we have put together a short set of video clips from my well-received presentation The Owners Manual for the Cloud, which I gave at the Forrester Security Forum in Las Vegas last month.

Today we present Chapter Two of the Cloud Owner’s Manual, on the subject of data protection. This is a complex topic, covering security assurance, business continuity, disaster recovery and service level agreements. What can you realistically expect to see in the market? What should you be asking your vendors about when it comes to data protection in the cloud? We’ll explore the answers to these questions, based on our own services and those of our competitors, as well as ongoing discussions with industry analysts.

This is the fifth post in our Cloud Owners Manual series. As always, we welcome your comments, observations, Tweets, likes and links.

11
Jul

The Cloud Owner’s Manual: Chapter 1— Fees

Written by Andrew Jaquith. Posted in Blog Post

Is your company considering cloud-based services such as email or security? You need an “owner’s manual” to know what to expect, and what to look for as you evaluate providers. To help you make informed choices, we have put together a short set of video clips from my well-received presentation The Owners Manual for the Cloud, which I gave at the Forrester Security Forum in Las Vegas last month.

Chapter One in the Cloud Owner’s Manual explores Fees. We’ll explore what you can realistically expect to see in the market, based on our own services and those of our competitors, as well as ongoing discussions with industry analysts. Beyond the table stakes, we’ll examine things you should be asking your vendors for when it comes to fees for cloud services.

This is the fourth post in our Cloud Owners Manual series. As always, we welcome your comments, observations, Tweets, likes and links.

10
Jul

Introducing the Cloud Owner’s Manual

Written by Andrew Jaquith. Posted in Blog Post

In a recent blog post, we examined this decade’s “new sports car” – the cloud. CIOs are eager to take a test drive, but security and reliability concerns keep many from putting the pedal to the metal.

Is your company considering cloud-based services such as email or security? Before taking the plunge, you want to know – what are the rules of the road? How safe is it? And how do you drive this thing, anyway? What you need is an owner’s manual – a “Michelin’s Guide” of sorts for operating in the cloud. Our Cloud Owner’s Manual has five chapters. Over the next week or so, we’ll explore each chapter in depth.

To help you make informed choices, we have put together a short set of video clips from my well-received presentation The Owners Manual for the Cloud, which I gave at the Forrester Security Forum in Las Vegas last month.

This is the third post in our Cloud Owners Manual series. As always, we welcome your comments, observations, Tweets, likes and links.

09
Jul

The Cloud Owner’s Manual: Customer Concerns About the Cloud

Written by Andrew Jaquith. Posted in Blog Post

Are you considering cloud-based email or security services? If so, this post is for you.

Forrester Research recently posed a question to several hundred IT decision-makers, asking, “What are your firm’s concerns, if any, with pay-per-use hosting?” (a.k.a. “the cloud”). One particular concern came through loud and clear: security. In fact, according to Forrester, a whopping three-fifths of decision-makers cited security as the largest inhibitor to their move to the cloud.

I’ve spent a significant amount of time probing deeper into the cloud security conundrum, speaking with customers, meeting with our sales engineers and account executives to discuss top-of-mind customer concerns and reviewing common negotiation points we’ve seen come up consistently in our contract discussions. As a company, we’ve reviewed and processed more than 1,800 contracts in the last 12 months alone – and in doing so have identified several dominant questions from prospects “kicking the tires” of the cloud “sports car” for the first time. It’s important to note that many of these questions pertain to the cloud services we know best at Perimeter – cloud email.

To help you make informed choices, we have put together a short set of video clips from my well-received presentation The Owners Manual for the Cloud, which I gave at the Forrester Security Forum in Las Vegas last month. This short clip, below, explores the most frequently asked questions around operations and data protection. I also discuss migration and onboarding questions prospects often ask us once they’ve decided to make the move to the cloud.

This is the second post in our Cloud Owners Manual series. As always, we welcome your comments, observations, Tweets, likes and links.

08
Jul

New exploit campaign targeting Parallels Plesk — admins, beware!

Written by Richard S. Westmoreland. Posted in Blog Post

Last week, the Perimeter Security Operations Center added specific siem detection for an active exploit kit campaign dubbed RunForestRun.  An updated diary article from SANS provides a good summary (https://isc.sans.edu/diary/Run+Forest+Update+/13561) of the campaign:

The campaign uses an underground web server called Sutra TDS that makes analysis difficult.

Two different sets of URLs are used for redirection, and successful redirection only happens when the cookies from the previous stage are set (this evades direct analysis of the final URL)

Successful exploitation via Blackhole Exploit Kit drops ZBot (ZeuS)

Unsuccessful exploitation serves Fake-AV in local language

As we dove deeper into backtracking the jumping point for this campaign, we confirmed that these exploits originated from legitimate sites with compromised JavaScript files.  The sites were compromised due to vulnerable versions of Parallels Plesk and ongoing attacks against the site management platform. The vulnerable versions are prior to Plesk 10.4. Unmask Parasites summarized the attacks as follows:

Feb-Mar 2012, attackers gained admin access to Plesk, put in backdoors and stole user databases (which contained passwords in plaintext)

June 2012, hackers use stolen credentials to modify js scripts with obfuscated code

The .js scripts are appended with a heavily obfuscated routine that causes remote content to be loaded when the site is visited:

/*km0ae9gr6m*/
...obfuscated code...
204.351.440.495.232.315.444.404.205.246.375.52.50.250.132.128.265.96.144.164.295
...obfuscated code...
/*qhk6sa6g1c*/

In other cases, we have observed similar code prepended to HTML files. We are still verifying if this is part of the same campaign or another compromise altogether.  Other 3rd party analysis of the campaign also shows other exploit kits getting used, such as Nice Pack and RedKit.

The script generates a pseudorandom domain with a .RU suffix, and at the start of the campaign loads /runforestrun?sid=cx from that domain.  At the time of this writing the URL is now /runforestrun?sid=botnet.

Based on referral information, the page either continues a series of redirections, or displays a fake error that the domain was suspended.

Recommendations for customers

The RunForestRun campaign is particularly dangerous because it targets sites running Plesk. Who are the typical users of Plesk? Privileged administrators, of course. As such, we regard this campaign as a deliberate strategy to compromise highly privileged employees. That places it in a more serious risk category than your garden-variety malware campaign.

For IT administrators who use Plesk to manage their websites, we recommend that you:

  • Confirm you are not running versions prior to 10.4.
  • If you have been using an older version, upgrade immediately, review all your web files for compromise, and reset your accounts’ passwords.

For Perimeter E-Security managed security customers, we have implemented these protections:

  • Fortigate Antivirus is providing partial client-side protection with JS/Iframe signatures
  • Fortigate Web Content Filtering can block Unrated sites and all *.RU domains if requested
  • IDS Monitoring and 24/7 SaaS Security Monitoring benefits from SIEM correlations created to track this activity and 24/7 Security Analsyts to escalate alerts and assist with log analysis

Due to the complexity of this campaign, it is recommended that local desktop antivirus software be frequently updated. You should also use web browser plugins, such as NoScript, to block unauthorized scripts.

05
Jul

The Cloud Owner’s Manual: Car Safety and Its Relationship to Security

Written by Andrew Jaquith. Posted in Blog Post

The cloud is undoubtedly this decade’s newest “sports car,” and every CIO is kicking the tires. The prospect of cost reduction, flexibility and reduced complexity compared to in-house are driving organizations to vendor “showrooms” in droves. However, serious security and reliability concerns keep many CIOs from firing up the ignition. Although the cloud feels new and risky to some, I’d contend that what these CIOs really need is the equivalent to today’s car safety belts and airbags. Once they have these safety features in place, they’ll be confident enough to start driving their business forward…faster.

I recently had the opportunity to speak at the Forrester Security and Infrastructure Forum in Las Vegas. As a former Forrester analyst, it was a pleasure to take the stage again and speak to former colleagues, as well as a number of current Perimeter customers. In gearing up for this event, I spent some time crunching 35+ years of highway safety information to identify parallels between car safety and information security for my presentation titled “The Owner’s Manual for the Cloud.”

This short video clip examines how security can be a critical enabler of innovation and growth, using some interesting U.S. federal data to make the case. In the following days, I’ll be posting additional clips from my Forrester Forum presentation, so stay tuned and feel free to post questions and comments along the way.

29
Jun

Five Years On, iOS Security Has Been a Huge Win for Customers

Written by Andrew Jaquith. Posted in Blog Post

Apple introduced the original iPhone in June 2007, a little more than five years ago. It’s appropriate at this point in time to ask whether Apple’s then-new, untested mobile platform has lived up to its promise as a secure platform. F-Secure’s Mikko Hypponen, one of the few consistently rational voices in the anti-virus vendor community, believes iOS has been good for customers from a security perspective. As he tweeted yesterday:

iPhone is 5 years old today. After 5 years, not a single serious malware case. It’s not just luck; we need to congratulate Apple on this.

On the opposite side of the argument is Sophos’ Josh Long. Although he concedes that the Apple’s App Store is “relatively safe,” he argues that Apple could do a better job vetting and patching, and that the risks of jailbreaking are still high:

Security researcher Charlie Miller has previously figured out how to break the App Store anti-malware model using a flaw in the iOS code signing enforcement mechanism, and there have been reports of developers working around other App Store restrictions with clever tricks; see the Security Now! episode 330 transcript and search for “vetting.”… The history of jailbreaking iPhones and iPads has provided plenty of evidence that smartphone users are being made to wait too long to get security updates for their devices.

25
Jun

Why I was lazy about changing my LinkedIn password

Written by Andrew Jaquith. Posted in Blog Post

I have a confession to make. I did not change my LinkedIn password until today, more than two weeks after LinkedIn disclosed that its password database had been hacked.

Some background on the attack. As you may know, an unknown attacker compromised the LinkedIn website and made off with nearly 6.5 million password hashes. These were low-sodium hashes, apparently, because they were not salted — making it easier for an attacker to perform what’s sometimes called a “rainbow table” attack. This means the attacker compares the hashes in the compromised database against a precomputed list of passwords that had been previously run through a hashing algorithm, in this case  SHA-1. Because the hashes were not salted, successfully guessing a given password was relatively trivial for commonly used passwords. Most computer security experts, including no less than SANS Institute’s Johannes Ullrich, recommend that passwords should be “salted” in addition to hashed, which makes this type of attack harder.

If you want to read an erudite, well-reasoned discussion about passwords and why naïve hashing strategies (like the one LinkedIn used) don’t work, go and read Brian Krebs’ interview with my friend Thomas Ptacek, founder of Matasano Security, charcuterie expert extraordinaire and all-around good guy. Thomas argues that as a general principle defenders need to make attackers work harder. He also argues that the typical “well, just make sure you salt your hashes” expert advice doesn’t work any more either. Salting your hash won’t work because it doesn’t add much computational time to the attempt. Here’s the key quote:

Let’s say you have a reasonably okay password and you’re using salted, randomized SHA-1 hash. I can, off-the-shelf, build a system that will try many, many tens of thousands of possible passwords per second. I can go into Best Buy or whatever and buy a card off the shelf that will do that, and the software to do it is open source.

If we were instead using something like Bcrypt, which would have just been the difference of using a different [software] library when I built my application, I can set Bcrypt up so that a single attempt — to test whether my password was “password” or “himom” — just that one test could take a hundred milliseconds. So all of a sudden you’re talking about tens of tries per second, instead of tens of thousands.

What you do with a password hash is you design it in the opposite way you would design a standard cryptographic hash. A cryptographic hash wants to do the minimum amount of work possible in order to arrive at a secure result. But a password hash wants to deliberately be designed to do the maximum amount of work.

Thomas is usually the smartest guy in any room he happens to be in, and I agree with his recommendations. What, then, should you be doing in your web applications? Using an algorithm like Bcrypt is a good idea. If you are using a reasonably modern computer programing language (.NET, Java) with good crypto libraries, you can also use PBKDF2, which stands for Password-Based Key Derivation Function #2. Both Bcrypt and PBKDF2 follow the same principle: they create an initial hash, and then (more or less) perform the hashing operation over and over an arbitrary number of times (the “iteration count”). The result is that it makes it comparatively expensive to compute the hash, but that’s ok for the typical person who is just typing to enter a password. He or she won’t mind if it takes a half-second. But if you are an attacker, even a half-second messes up your business model.

(In case you were wondering, if you protect your iPhone or iPad with a passcode, Apple’s iOS 4 and higher use PBKDF2 with 10,000 rounds of iteration to protect the pass codes. That makes me feel pretty good.)

Ok, smart guy. LinkedIn wasn’t doing any of that stuff. Why didn’t you change your LinkedIn password again?

Whoops. I got a little distracted. So, Bcrypt and PBKDF2, those algorithms I mentioned above — the ones  you should be using in your web applications? LinkedIn wasn’t using them. The company just hashed stuff. Attackers were able to run a simple rainbow-table/dictionary attack and recover a lot of the passwords. In fact, our friends at Rapid7 have created a nifty infographic showing what the most popular ones were. Passwords like “link,” “god,” “job,” and “princess” topped the list. (Princess?)

So, shouldn’t I have been worried that wily hackers cracked my password at some point in the last 2 weeks? Maybe a little. I confess, I slacked a bit in changing my password. But then again, I felt pretty sure mine hadn’t been cracked. In the spirit of full disclosure, this was my old password: 3d*f$elMZ0tK.

There is little chance an attacker could have brute-forced it — it is completely random, and fairly long (12 characters). To generate it, I had previously used a third-party password management tool called 1Password. The tool creates an encrypted vault of passwords, all protected by a master password. I use it to generate unique, long and complex passwords for every website I join or log into. As a result, none of my website passwords are shared. They are all unique. And they can’t be easily brute-forced. Some of my passwords are 36 characters long.

I don’t remember any of them, and I don’t care. I make it a rule not to remember my passwords, except for the master password.*

If you follow a strategy like this as well, when the next big website gets knocked over, you won’t have to care either.

PS. If you are interested in password-vault tools, read Elcomsoft’s paper on password managers first. Although I don’t have experience with the other password managers cited in the paper, Keeper and DataVault both seemed to score fairly highly in terms of resistance to brute-force attacks.  See also the 1Password team’s commentary.

*Actually, that’s not quite right. I have also memorized my iTunes Music Store password (16 characters, totally random). I had to memorize it because I type it in so often. But I digress.

19
Jun

Update on the Fake-AV at MLB.com — How It Is Distributed, and Who Else Distributes It

Written by Grace Zeng. Posted in Blog Post

Just a quick follow-up from yesterday’s post about fake-AV malware being served up by MLB.com. We did some more research today, about have additional details.

We pinpointed a specific ad that serves the fake-AV malware. It’s on top of the MLB news page. The ad banner points to plentywatch[.]com, but the banner image is stored on gipcampaign[.]com which is injected with an IFRAME that redirects to adginserver[.]com. Please see the following three screenshots. The ad is still present on MLB.com’s website as of 3:00pm today.

The malicious ad on mlb.com:

Where the ad is hosted:

 

Here’s the IFRAME injection into the ad (captured using WireShark) — click it to see the full image:

 

Note that MLB’s page rotates its ad display constantly. Not every visit will show this malicious ad.  But the number of consumers that could be affected is likely quite large. According to Alexa.com, based on page views, MLB.com ranks 77th in the US, and 344th globally. From the traffic statistics on Alexa, in the past month, every day on average, there are about 11.23 million page views on MLB[.]com. Approximately 3.24 million consumers view these pages every day. Even if the ad were only displayed once every 100 page-views, it would potentially affect over 300,000 PCs.  We hope MLB.com will remove this ad as soon as possible to prevent infecting more of its customers.

MLB.com is not the only website serving up fake AV from this infected advertiser. Based on an analysis of our logs, customers were served malicious ads from adginserver[.]com when visiting many other benign sites as well. As far as we can tell, airfarewatchdog[.]com, homeaway[.]com and blogspot[.]com have all served up the same type of fake-AV ads from adginserver, which ultimately redirected to the .in domains that compromised our customers.

Here’s a bit more information about adginserver, which is hosted in Germany. A direct visit to this domain redirects the browser to a popular search engine in China – Baidu.com. It seems that adginserver is not part of an ad network; its only purpose is redirection.

Domain Name:ADGINSERVER.COM Registrar:NETLYNX, INC. Whois Server:whois.netlynx.com Referral URL:http://www.netlynx.com Name Server:NS1.ADGINSERVER.COM Name Server:NS2.ADGINSERVER.COM Status:clientTransferProhibited Updated Date:11-may-2012 Creation Date:23-dec-2011 Expiration Date:23-dec-2012

Base Record Name IP Reverse Route AS
adginserver.com a 78.159.121.107Germany hosted-by.leaseweb.com 78.159.96.0/19ORG-nA8-RIPE AS28753LEASEWEB-DE Leaseweb Germany GmbH

Interestingly, gipcampaign[.]com is also hosted in Germany with a similar DNS record to adginserver[.]com. With this domain record, and the fact that it directly serves the ad on MLB.com, we feel that, more likely than not, it is or part of a malicious advertising network, rather than a compromised legitimate ad site.

Domain Name:GIPCAMPAIGN.COM Registrar:NETLYNX, INC. Whois Server:whois.netlynx.com Referral URL:http://www.netlynx.com Name Server:NS1.GIPCAMPAIGN.COM Name Server:NS2.GIPCAMPAIGN.COM Status:clientTransferProhibited Updated Date:04-may-2012 Creation Date:19-jan-2012 Expiration Date:19-jan-2013

Base Record Name IP Reverse Route AS
gipcampaign.com3 hours old a 188.72.201.45Germany hosted-by.leaseweb.com 188.72.192.0/18ORG-nA8-RIPE AS28753LEASEWEB-DE Leaseweb Germany GmbH

As we mentioned yesterday, Perimeter E-Security has reported the above domains to Fortinet as malware sites. Customers should consider temporarily blocking access to mlb[.]com,  airfarewatchdog[.]com, homeaway[.]com and blogspot[.]com until further notice.

Evan Keiser and Andrew Jaquith contributed to this post.