Web site reputation

Recently several companies have developed features or products to make web surfing more secure. One of these technologies uses reputation. Reputation is a measure of trust for a web site or web page. In this case trust is typically measured by how much SPAM, malicious traffic, or attacks a site is known to generate. It turns out that measuring these things is not that hard because a majority of web traffic flows through a relatively small number of gateways and backbone networks.

This is a very good idea. If a web site is known to host malware or send a lot of SPAM, then block or warn users before they visit a site. Of course, cyber-criminals have started to figure out how to bypass these checks. They simply attack sites with good reputations and get them to host the malware. In some cases, it's just a matter of providing an advertisement.

Reputation based security is still a great idea because it forces the crooks to work harder. However, we can't get over confident and rely on this technique to always protect us. This means keep your software patched, don't click on suspicious links, and ignore any offer that is to good to be true.

Are Open Source Applications More Secure?

Full Disclosure: I am a long time Firefox user

Recently, there have been serious security advisories for Chrome, Safari, and Internet Explorer:

http://www.eweek.com/c/a/Security/IE-Attacks-Circulate-as-Microsoft-
Updates-Advisory-766154/
http://www.v3.co.uk/v3/news/2259391/apple-updates-safari-browser

While a patch is now available for Safari (and perhaps Chrome), the community is still waiting on a fix from Microsoft.

Browsers, and Internet Explorer in particular, are the most commonly used application in the world. Additionally, most web users visit one of the top 500 sites at least once a day. This intersection makes for a very attractive target for criminals. At any given moment, the site you are visiting, even the site you are using to read this post, could be attacking you through your browser and trying to seed your system with malware.

Your first line of defense is a secure browser. I can't prove this easily, but I think an open-source browser like Firefox will always be more secure than a proprietary browser.

My advice:

1. Keep your browser up to date, note ie8 is not exposed by this current vulnerability
2. Keep your OS up to date
3. Run some sort of host-based intrusion protection system, if you have one of the consumer security suites you have this
4. Run at least a basic network firewall
5. Businesses should run a network intrusion protection system

For the really advanced users out there:

Make use of virtualization software and run a special purpose virtual machine for your banking and financial applications, run another virtual machine for casual web browsing and entertainment. Never ever browse the web using your host system.

One last piece of advice:

Don't forget to wear some green today!

Michael

Conficker and April 1

Well, here’s the Wikipedia entries that got me thinking:

As a countermeasure, ICANN and several TLD registrars began in February 2009 a coordinated barring of transfers and registrations for these domains”

Variant C contains code to sidestep these countermeasures by generating an expanded daily list of 50000 domains across 110 TLDs. This new pull mechanism, however, is disabled until April 1

I’ve also been following the work at SRI regarding this threat.

Even 1 million Variant C infections results in potentially 50 billion whois queries.

I think Wednesday is going to be a slow day on the Internet.

Registrar's are still a weak link

Very nice article on the hack against Check Free here.

Current theories center on the likelihood that a Check Free employee got suckered by a phishing or straight-up social engineering attack.

I'm going to hazard a guess that this was a spear-phish or more targeted form of attack. A quick search of Linkedin, Facebook and other social networking applications finds a treasure trove of CheckFree/Fiserv employees.

It's a small step to go from these links to a targeted attack against Fiserv IT staff.

However, as the article notes Fiserv was not the only target in this attack and Financial Institutions (FI) are dangerously reliant on a single registrar.

My recommendations:

1. FI's and others must monitor and protect themselves from domain hijack -- I recommend Pharming Shield.
2. Get social networking applications out of the data center, IT personnel must not use corporate resources (including email) to access these sites
3. The Financial Industry is at risk from a single-point of failure at Network Solutions. This must be addressed through community efforts and directly by the platform providers.

Happy Holidays!

A few Podcasts with Dane Deutch

These were done with a Catbird partner DCS NetLink.

The Game Is Not Over -- Security for your web site

1. Man-in-the-middle (MITM) attack against SSL plus Sitekey/Passmark – The Stop-Phishing Research Group at Indiana University demonstrates that if you are not very careful about the URL and the SSL certificate, and most people are not, the attacker will be successful
2. Sniffing a connection to steal session cookies to bypass user authentication – Robert Graham of ErrataSec, has demonstrated why you need a security barrier for your laptop at Starbucks (If his name for this attack sticks "side-jacking" then we might as well all give up and start referring to SSL as a condom for your browser)
   
3. If you think you don’t have to worry about these exploit techniques, then you better have the Security Excuse bingo card (found on Schneier on Security),
   

It looks pretty bad. SSL can be bypassed, authentication cookies can be stolen. If you follow the blogosphere’s impression of the recent Blackhat/Defcon events, it's all useless and there is nothing we can do to stop the crooks. To top it all off, there isn’t just one Hackistan (great Yak snacks by the way) there are many Hackistan’s and no web site is to small or broad-band connected PC to innocent for them to exploit.

Truth is, if a malicious hacker with the capabilities of a Grossman, Skoudis or Moore is after your site, then you will get hacked. Lucky for you these guys are busy™.

Solutions? Focus on your business needs and take some precautionary steps:

• Run traditional vulnerability scans (because Skoudis and Moore teach us that the old problems are new again)
  
  
• Run a web application scanner and use a secure coding inspection tool, Grossman and Zorkul are better, but it’s foolish not to automate everything you can
  
  
• Use SSL from start to finish on your web-site, you have an obligation to protect the integrity and security of all the data exchanged between your site and your customer’s browser – otherwise your giving it away to any crook with a copycat access point or a promiscuous wireless card
  
  
• Don’t ignore MITM because you think it is hard, it gets easier to do every day – Lucky for all of us, it’s also getting easier to protect against and detect MITM, Pharming, Highjack and Malware Injection, I know someone who can help
  
  
• Last but not least, plan on getting hacked, have an incident response plan and be prepared, playing security excuse bingo is a losing strategy

Get started today!

Disregard any pop-up security windows you receive

I received this in my mail today:

Dear Electronic Crimes Task Force Member,

CSO magazine is conducting a survey in cooperation with the U.S. Secret Service and CERT Coordination Center, the 2007 eCrime Watch. The purpose of this project is to uncover electronic crime trends.

CSO magazine’s sister company, IDG Research Services, has been commissioned to help us collect your feedback. Please click on the following URL to begin the survey or copy and paste the URL into your browser:

https://url-hidden

Disregard any pop-up security windows you receive. (Emphasis mine)

Please be assured that any information you provide is confidential and your responses will be used only in combination with those of other survey respondents. This survey should take no more than 10 minutes of your time. If you have any questions about this survey please contact IDG Research Services at ------@idg.com or ATSAIC ----------, USSS, San Francisco Field Office 415/-------.

Thank you in advance for your help.

Of course my first thought, was that this was a phishing attack. I couldn't imagine CSO and the ECTF telling me to "Disregard any pop-up security windows you receive."

Imagine my surprise and relief, when I went to the site and there were no warnings. So, they got it right, the SSL certificate was correct and unexpired ... but everyone is so accustomed to that not being the case, that as a matter of course they included the disregard pop-ups message. Is our infrastructure broken or what?

Virtually Secure

Christofer Hoff has a good post here. In particular,

Combine that with NAC agents on the hosts and...whether or not it actually works is neither here nor there. They told they story and here it is. It's good to be king.

His point being that Cisco doesn't have to worry about when they are going to deliver a product or even how will it will work when they do ...

Meanwhile, back in your virtualized data center, you can be warm and happy knowing that Cisco's virtually shipping product has you virtually secure already. Nice, huh?

What about Real Security -- Real Security for Virtualized Infrastructures? You've deployed half a dozen quad-core systems and thrown out 150 obsolete boxes. Maybe you had IPS and NAC in your datacenter already, but do you have it now? If your virtual windows 2000 server get's infected and starts attacking the other systems on the host, how will you know?

Maybe you will know when the infection begins to spread to other hosts and their virtual servers, but by then you will have a real mess on your hands.

The right answer involves doing something today, not waiting for a vendor to implement a solution next year. Here is the pragmatic prescription for today, virtual servers are servers, period.

If there reliability and security are important to your business then you have to secure them with same mature IT processes that you use for everything else:

1. Specify the appropriate security requirements at the start
2. Determine and implement secure baselines that meet your business and security requirements
3. Validate/test that the performance and security of your systems meets the stated requirements before you put them in production
4. After deployment, test them again -- virtualization really helps you here
5. Use change control and segregation of duties -- (ITIL and ISO 17799 driven) processes and controls to keep working systems, working
6. Patch management and vulnerability management are a continuous process -- don't treat these problems with a calender ... not unless you like emergencies
7. Continuously monitor your network and systems, use the protection appropriate to the value of the data or business operations, such as:
   
   • Gateway: firewall, anti-spam, anti-malware, content filtering, vpn ...
   • Network: vulnerability monitoring, IDS/IPS, NAC, Policy management and compliance ...
     
   • Endpoint: Anti-malware, AAA, log analysis, patching, encryption ...
     
   
   
8. Disaster/Business continuity planning, incident response and training have to include your virtual infrastructure -- DR/BP might be a big driver behind your virtualization effort, but nothing substitutes for a good test.
   

Do all of the above, appropriately to the level you need, don't wait to become the next security breach. It's more about the process than the tools.

I hate Passwords #10

From IP: link here

What I think needs to be done is that the public needs to be educated about these sites, and the security risk they pose.

The "public" is already being educated. We tell them over and over that they should not share their password with anyone. The problem is that the public gives up their password all too easily. We can keep blaming the public, and we will, but we should also try to understand why someone will give up their Yahoo (or other service) password easily, while the same person would never share their ATM PIN.

I think the public is pretty smart, but they learn best when they experience immediate consequences from their actions. Right now, I know that identity theft and losses from this behavior are at a tolerable level because most of the public are still willing to give their password away -- where the same public will never forgot to lock their car door at the shopping mall parking lot.

If the consequences (or at least people's awareness of these consequences) get a lot worse, we will either see a change in behavior or the deployment of technologies to eliminate reliance on passwords (tokens, client-side certificates ...).

TriCipher Responds

After I published TriCipher USB key, Tim Renshaw, VP Field Solutions at TriCipher responded with the following confirmations and clarifications:

Yes, we use two authentication "stores". In the TriCipher solution (our name aludes to our 3-key technology) set, we use public key crypto, but instead of having a single private key and public key, each user has 2 private keys and a public key. A private key the user controls and a second private key kept on the TriCipher ID Vault appliance. Of course, then there is a 3rd key, the public key.

For our "USB key" feature, the USB device serves as the 2nd "what you have" factor and of course works in conjunction with the user's password. These two components are used to recreate what is best to think of as the "user's key". Note that loss or theft of the USB key provides an attacker no attack vector to guess or work backward to the password. Same with theft of the password. Whether phished, pharmed, keylogged or social engineered in any way, possession of the password alone is useless without the USB key.

The "user's key" is used in conjunction with the other private key for that user kept on the ID Vault (ID Vault key). To properly authenticate both the user's key and the ID Vault key are used to co-sign, if you will, and consequently create a standard, x.509 certificate based, verifiable signature for any client-SSL enabled relying party site.

Important points:

• Relying party needs no TriCipher code to accomplish this standards-based function.
• The two private keys for each user are never recombined anywhere to be compromisable in a single location.
• The user's private key is never stored anywhere, ever.

No, we do not get in the middle between authenticating sites and users. We utilize the true two-way, mutual authentication SSL mechanism built into both the server and client ends. All our "magic sauce" briefly described above is done between the client and the TriCipher ID Vault directly. It is pretty accurate to think of the connection between the client and the ID Vault as forming a secure, virtual smart card. Certainly as far as all the client code is concerned, the signature is performed by a local, smart card as we again use the existing standards for signing procedures, CAPI and PKCS11.

I still have to wonder about the compromised computer kiosk. If I insert my USB key into an 0wned system, can that system rip the token from the key and log my password?

TriCipher USB key

From the marketing glossy it would seem they use public key crypto, with two authentications stores. One is on the key and the second is on the Web.

The key is used to authenticate you to the TriCipher key vault on the web. TriCipher then authenticates you to the financial web site. My guess is that you establish an SSL tunnel to TriCipher using a certificate on the key. You then authenticate yourself to TriCipher using something you know. Then TriCipher somehow authenticates you to the bank and establishes an SSL session between you and the bank that is already authenticated.

My guess is that TriCipher starts as a man-in-the-middle and then somehow hands off the session, maybe a reverse tunnel is established from the bank back to you?

Since you're running software off of the key and your authentication to TriCipher involves a cert and something you know, it's possible to evade key loggers. One method would be for TriCypher to display a captcha image back to the user which the user combines with their pass-phrase to create a one-time key for the session.

But this is all guess work from a marketing glossy. Might be fun to try it out.

Phishing and Pharming

I work at a startup. It should come as no surprise that I think we do some very cool things. About a year ago, our Marketing VP realized that we had the ability to offer protection against a certain type of attack.

She created this product.

We’re still often asked, “What are Phishing and Pharming?" Here is my response:

Phishing and Pharming are common attack methodologies designed to harvest authentication credentials and personally identifying information (PII). Criminals use these attack methods to gain unauthorized access to financial, e-commerce, health care or other institutions. The attackers then sell, trade, or use these stolen identities to commit further compromises. Over 90% of these attacks target financial institutions.[1] Ultimately, these identity thefts result in billions in damages from these institutions. [2]

Phishing attacks begin with an email or instant message, the “lure” which tricks the victim into giving up their identity. Common Phishing attacks succeed 3-5% of the time, more advanced techniques like Spear-Phishing achieve 15% success rates.[3] A study at the Indiana University indicated that Phishing attacks that utilize social networks might achieve success rates as high as 70%. [4]

Pharming attacks do not require a lure or any voluntary action from a user. With Pharming, the attacker compromises the network infrastructure of the victim web site. Pharming attacks are typically not detectable by the victim and may go unnoticed for hours or even days. The bank customer almost never detects these attacks and once they are detected, the victim financial institutions are notorious for not disclosing their costs. With clever construction a Pharming attack can achieve more than an 80% success rate.

Pharming is a collection of several old and new attack techniques including: DNS or domain hijack, DNS cache poisoning, Man-in-the-Middle (MITM), script injection, malware seeding and related site attacks involving cross-site scripting (XSS), frames, pop-ups and numerous other exploits of the user’s browser. In March of 2005, one Pharming attack diverted 1,304 domains and harvested over 7,000 victims in only a few hours.[5] More recently a sophisticated Pharming attack targeted 50 financial institutions -- this attack affected at least 1,000 systems per day.[6]

Protecting against these attacks[7]
Phishing is a form of social engineering, preventing these attacks requires a combination of user education and implementation of technologies to make it easier for potential victims to recognize fraudulent sites.

Pharming attacks start with an exploit against the network and application infrastructure of a web site. Financial institutions should perform the following actions to protect against Pharming:

• Protect your entire site with SSL; educate users to look for the padlock
• Monitor your domain and DNS infrastructure for cache poisoning, hijack and spoofing
• Monitor your web servers and DMZ systems for vulnerabilities; implement a continuous security process for vulnerability and patch management of these critical systems
• Monitor web content for script injection and unauthorized modifications; extend this monitoring to partner sites which include content via frames or cross-site scripting
• Implement a secure web “watermark” that validates the security of your web site; educate your users to look for and verify the watermark is correct
• Develop a security response plan with your service providers to react quickly and cooperate to take down a malicious site targeting your institution

For both Phishing and Pharming, provide simple mechanisms for your customers to report abuse or suspect web sites. The prevalence of these attacks will continue to rise with the swell of e-commerce. Responsible institutions must increase the difficulty (and the resulting cost) of making a copycat web website and they must implement continuous monitoring and response processes to respond in the event of an attack.

Citations

1. APWG Activity Report. (2007 April). Published by the Anti-Phishing Working Group. Retrieved June 14, 2007 from http://www.antiphishing.org/reports/apwg_report_april_2007.pdf
2. Phishing and Pharming (2006 January). Published by McAfee. Retrieved June 14, 2007 from http://www.mcafee.com/us/local_content/white_papers/wp_phishing_pharming.pdf
3. 'Spear Phishing' Tests Educate People About Online Scams. (2006 August). Written by David Bank of the Wall Street Journal. Retrieved June 14, 2007 from http://online.wsj.com/public/article/SB112424042313615131-z_8jLB2WkfcVtgdAWf6LRh733sg_20060817.html?mod=blogs
4. Social Phishing. (2005, December 12). Written by Tom Jagatic, Nathaniel Johnson, Markus Jakobsson, and Filippo Menczer School of Informatics Indiana University, Bloomington. Retrieved June 14, 2007 from http://www.indiana.edu/~phishing/social-network-experiment/phishing-preprint.pdf
5. SANS ISC Diary. (2005 March). From Sans Internet Storm Center. Retrieved June 14, 2007 from http://isc.sans.org/diary.html?date=2005-03-31
6. Elaborate ‘pharming’ attack targeted 50 banks. (2007, February 22). Written by Jeremy Kirk of the IDG News Service. Retrieved June 14, 2007 from http://www.infoworld.com/article/07/02/22/HNpharmingattackonbanks_1.html
7. Protection recommendations from numerous sources including: Microsoft, Symantec, SANS, RSA, CSO Online, Network World and others:

• http://www.consumerfraudreporting.org/pharming.php
• http://www.csoonline.com/fundamentals/quicklists_pharming.html
• http://www.networkworld.com/research/2005/071805-pharming.html?
• http://www.verisign.com/static/030910.pdf
• http://www.microsoft.com/athome/security/privacy/pharming.mspx
• http://www.apani.com/net-news/0606/82
• http://www.wired.com/news/infostructure/0,1377,66853,00.html
  
• http://www.cs.indiana.edu/pub/techreports/TR641.pdf,
• http://www.infoworld.com/article/07/02/23/HNsecondgoogledesktopattack_1.html
• http://reviews.cnet.com/4520-3513_7-5670780-1.html
• http://www.securityfocus.com/columnists/429
  

Hello and a Question for Michael

My beautiful espousa forwarded this message to me from a friend:

Something came up today and I have a quick question for Michael: In a nutshell, someone online accessed my checking account (with Washington Mutual) and drew out 500.00 from USAA (the bank with which I have a savings account, a credit card and renters' insurance.)

I recently did an online electronic transaction from USAA, telling them to remove funds from my Washington Mutual account (like I do every month) to pay off an insurance premium.

Between last night and this morning, a transaction took place whereby 500.00 was transferred via a "USAA Internet Chk" from my WaMu account to an alleged USAA accont somewhere, or probably, just through USAA and out a back door. I have both USAA and Washington Mutual investigating it, but boy, it's a rude way to start someone's morning!

Anyway Michael, if you have a view of what may have happened, I'd love to hear it. The only thing differently I've done recently is to reset my DNS server numbers in my wireless router to those of openDNS.com, a free service that supposedly prevents phishing, etc. I've since reset the router to just get DNS numbers automatically (I'm with Verizon).

Sorry to bother you with this, but you're probably much savvier than any of these folks and might have some insight. As it is, I'm grateful that ------y keeps her money with a separate bank, though we do have other WaMu Joint accounts... Makes us gunshy to use the internet for banking transactions (emphasis is mine) - or at least to maybe designate just one, and then to feed it funds for electronic fund transfers at the time bills come due...

All the best,
N------

This sort of thing is very uncommon, but we always jump to the conclusion that we've been hacked by a criminal. This is the email I sent back to my friend last night:

Hello N------,

1. Go to a friends house or a system at work and change all of your passwords! Don't use your computer, it may have been compromised.
   
   
2. Never re-use a financial site password with any other site.
   
   
3. Change the password on your router and other network equipment.
   
   
4. Have an expert look at your computer, if it has been compromised you'll need a professional to get it fixed. If it were me, I would back up my data and reinstall from secure media.
   

If you were not phished then your bank may have been pharmed.

It is very unlikely that an outsider directly compromised the the bank. If you used a unique id and password, a random hacker would not gained access by guessing your password.

There are many possible explanations for your problem.

Someone you know compromised your access:

• They knew enough about you to access your account. If this is true the bank will be able to follow the money to them.

Some stranger compromised your access:

• If you used your bank password at a secondary web site the secondary web site might have been compromised, leading to a compromise of your bank account.
• Your system may have been compromised through an attack launched by a web site that you have visited. These days criminals compromise you via the web and install a program to record the web sites and passwords you use (keystroke logger). Once they captured your bank password they would have set up a transfer to withdraw money from your account.
• You may have been phished or pharmed. I doubt you were phished, but pharming is very hard to detect. In a pharming attack the criminals impersonate your bank web site by hijacking the infrastructure the site relies on. You think you're visiting WAMU or USAA but in reality you have been redirected to a fraud site.

An employee at one of your banks has exploited a flaw in the bank's security:

• Banks have several layers of protection to prevent this, but criminals are very creative at exploiting loopholes or flaws in network or web application security.

Either USAA or WAMU has made a transaction error:

• This doesn't happen often, but it does happen. Personally, I have had my bank process duplicate transactions on more than one occasion. The situation you describe is very suspicious but it may turn out to just be a simple mistake.

Take care and feel free to contact me directly.

So what do you think, did I give my friend good advice?

ICANN Factsheet: Root server attack on 6 February 2007

I'm reading through the the ICANN factsheet (08mar07.pdf) and this paragraph jumps out at me.

A third category is the huge increase in individual Internet users installing routers in their homes, usually to provide wireless access or to link up several computers in the house. These consumer products usually come with the same password and a large percentage of home users never change this default password, making it easy for hackers to seize control of them for their own ends. If consumers were encouraged to change the default password or if router manufacturers were persuaded to provide each unit with a different password, then future attacks against the Net’s infrastructure could be tackled at (the) source.
(my emphasis)

I know there has already been quite a bit said about this topic here, here and here. However, this particular paragraph is written by the people who make sure that the wheels stay on the Internet's bus. This is really a very important issue and it's time the router vendors solve this problem.

The factsheet is well written and introduces a lot of information regarding the attack. Now that is has been published I can speak a little about it here. (Full disclosure: Catbird performs DNS monitoring for some of the root service providers.)

After the attack I reviewed our aggregate DNS and web performance data. Catbird gathers over one million data samples each day so I had more than enough to choose from. I chose a random samples of our monitors and developed the two charts included in this post.

The Feb 6 attack occurs around the midpoint of each chart. The attack hit two of the thirteen root servers very hard, but as you can see from these graphs the downstream DNS providers and the web sites they serve were not affected.

I make this point because I do not believe the attackers intended to bring down the Internet. I think that this was the performance test of an attack botnet. This attack combines good advertising with a live product demo. I will not be surprised to hear about a rise in DDOS attacks and extortion demands made against high-value commerce web sites.

I recommend that we all brush up on our understanding of anycast, GeoDNS and related defenses against DDOS.

Another Attack on DNS Root Server Infrastructure

Hackers overwhelm key Web computers

For those of you who need more information, Wikipedia has a good article on why DNS root servers are important to everybody.

Every time you type a URL, or click on a link in your web browser a DNS server directs your computer’s browser to the right server on the Internet. For performance reasons, you usually use the DNS server on your local network or one provided by your ISP. Your local DNS server relies in-turn, on other DNS servers in a tree-like hierarchy. Ultimately, all DNS servers rely on the smooth functioning of the thirteen DNS root servers.

An attack on the root servers is an attack on the fundamental structure of the Internet. It’s the DDOS equivalent of a doomsday device. This the sort of thing a villain like Ernest Blofeld would attempt; it could be the action of a sociopath, the prelude to a grand attempt at extortion, the test of an info-weapon or an act of war.

Fortunately, as noted by John Crain, this type of attack has become much harder to pull-off. However, Harder ≠ Impossible. The current infrastructure can handle an enormous load, but there are limits. The picture below shows the situation at 11:00 AM PST:

Picture 1: dnsmon.ripe.net (2/6 17:00 UTC - 19:00 UTC)

As you can see in this reporting period, two of the thirteen servers are still experiencing significant load. The following picture shows the effect of the attack from its beginning:

Picture 2: dnsmon.ripe.net (2/6 08:00 UTC - 2/7 08:00 UTC)

As you can see, the attack hit server ‘’G’’ and ‘’L’’ the hardest. The red spikes indicate an average probe failure rate exceeding 90%.

Most likely, this attack will not affect you directly. It is a lot like a solar flare’s effect on radio communications – there’s a lot more noise in the system today and don’t be surprised if you notice a slightly different “feel” to the Internet today.

The lesson here?

Performance monitoring is often a leading indicator to an attack on your computer infrastructure. It is important to understand your baseline performance and monitor the systems you rely on for any significant deviation from baseline.

For the Internet, we can thank the very good folks at RIPE .