The Security Skeptic

Web site vulnerabilities

Brian Prince (eWeek.com) recently published an article that summarized the results of the latest web vulnerabilities report by WhiteHat Security researchers. On the same web page, you'll find a link to the August 2008 and March 2008 WhiteHat Security Reports. What can we observe from this series of reports spanning 18 months?

Percent of sites with at least one security issue. In March 2008, 9 of 10 sites had at least one serious vulnerability. The August 2008, the number declined to 82 percent and the latest study reports 72 percent. This is an encouraging downward trend, but the fact that nearly 3 of 4 sites still have at least on serious exposure to attack is somehow not comforting.

Sites vulnerable to cross site scripting (XSS). In March 2008, 70 percent of sites were vulnerable to XSS. In August 2008, the same percent of sites were found vulnerable to XSS. The most recent study finds 66% of the sites vulnerable to XSS and the team believes that the prevalence of XSS is underrepresented in the study. That the downward trend is nearly flat here is disturbing enough, but the most recent study also indicates that the average remediation time (time to fix) of cross-site scripting vulnerabilities is a discouraging 67 days.

Time to remedy. Even more discouraging than the sad statistics I've cited are the reasons time to fix is so long. While I can accept that many organizations do not have the expertise to fully understand the complexity of vulnerabilities and appreciate the risk should these be exploited, I find other reasons in the list that wreak of hubris or greed. Among the top "greed" reasons cited in the report you'll find "Feature enhancements are prioritized ahead of security fixes", "Solution conflicts with business use case" and "Compliance does not require it". In the hubris category, we find "Risk of exploitation is accepted". I claim the latter is hubris because few organizations actually assess risk correctly and factor harm to others fully, especially if direct loss can be offset in some other manner, for example, nuisance fees collected from customers buying on credit.

Brian Prince comments that the news isn't all that bad, citing that 17% of sites had no serious vulnerabilities, ever. I give Brian credit for unbounded optimism and a laudable commitment to balanced reporting, but let's be honest: 17% is terrible. All of these statistics are terrible and they are not improving. They are reversible, but only if the same organizations that today accept risk of exploitation glibly and prioritize new features and haste to publish choose to reverse their thinking.

The economy is sluggish. No one expects a quick turnaround. This is an opportune time to fund security measures: seriously, who'll notice a larger allocation to security and IT among the already abysmal losses? Seize the moment, commit to reviewing and testing web application code prior to publication, test sites frequently for vulnerabilities, and reduce time to fix.

Avoid malware threats: do what malware analysis would do

Gary Warner has published an intriguing article describing how the UAB Spam Data Mine finds new malware threats delivered by email.  Gary provides a step-by-step description of the automation implemented at UAB, using an example (this morning's Social Security version of Zeus). The procedure Gary outlines is very detailed, but not impossible for a human to repeat. In fact, I highly recommend studying it in the context of what any individual can do to reduce his own threat to falling victim of a malware download.

For example, the UAB spam analysis considers the Subject lines and Senders that arrive in 15 minute intervals and builds a picture over time of the prevalence of related themes or senders: in Gary's example, the repeated mention of "Social Security statement" in subject lines serves as a trigger. Related subject lines and senders are counted, and high counts trigger a more careful analysis. Can an individual follow this same sequence of actions and discern spam from safe email? Let's consider a real world example.

Last night, I received a stream of email from  "CVS Pharmacy". The subject lines, however, were "Weekend is near", "Busy or just absent?", and other random sentences that phishers use to attract attention to their phish email.  Looking at the message body, I see that the message is exactly the same, with each message containing a banner claiming "Delivery department work across the Globe."

At this point, the UAB spam analysis would visit hyperlinks in the suspicious message bodies and begin crawling for malicious executables buried amid the web pages.  DO NOT VISIT ANY LINKS. Rather, at this point, I - and you - should be saying, "Warning, Will Robinson! Mark or delete the message as spam".

Note that while humans are not automatons, we tend to respond automatically given repetitive tasks. Phishers and spammers rely on the fact that many email users haven't been programmed to respond in the manner that the UAB spam analysis automation responds. Now that you've seen how relatively simple a "spam aware" response can be, apply it!

Congratulations to Gary for providing a relatively straightforward and painless way for readers to improve their defenses against spamming and phishing awareness.

Model for a High Security Zone Verification

The ICANN community is developing guidelines for introducing new top level domains (TLDs). New TLDs create opportunities for innovation and greater choice for Internet users. Regrettably, they also expand the name space for criminal use. Sensitive to concerns expressed by anti-abuse communities, ICANN has introduced a concept paper for a voluntary high security zone program.  The concept paper describes a verification program that distinguishes a TLD registry operator who demonstrates an enhanced level of trust and security over the baseline that gTLD registries are expected to provide when standard contractual provisions are met. The program measures both business and operational criteria and includes verification of Registry operations as well as Registrar operations. Registries will contractually oblige Registrars to implement controls required by the Program to assure that trust and security measures extend from the registry through the registrar to the registrant.

The concept paper identifies controls to reduce the potential for malicious conduct, including fraud and other criminal activities, at the Registry and Registrar levels. While such measures cannot ensure that no domain name registered in the TLD would be exploited for criminal use, the measures assure that the service providers meet best industry business and operational practices to reduce the incidence of malicious or compromised domains and to quickly respond when malicious conduct is reported.

The concept paper identifies an initial set of objectives of the verification program. For example, Registry and Registrar organizations would be vetted to substantiate the identity of the legal entities that operate the Registry and registration services. A 3rd party security audit would be conducted to determine whether the registry’s IT infrastructure satisfies physical access, logical access and availability security criteria. Checks would be performed to confirm that data integrity, availability, consistency and completeness criteria are satisfied.  Registry and registrars would be expected to demonstrate effective controls to reduce malicious conduct, consistent with the recommendations in the Malicious Conduct Explanatory Memorandum for new TLDs.

The concept paper explains that certain registries will voluntarily submit to initial and periodic audits to obtain and remain certified because they see a business value from “being more secure”. Other registries may seek certification because their target market, e.g., a TLD for financial or medical services, are regulated and demand it.

For some, the concept paper is a radical departure from the way GTLD registries operate today. Others have already asked why the program is voluntary rather than mandatory. Some current GTLD registries, however, have asked whether they would be able to volunteer for the program. Diverse opinions will no doubt exist, and that’s not a bad thing. I believe the concept paper provides an excellent point of focus for the community and I encourage you to review it and make your opinions known through the public comment forum which remains open until 22 November 2009.

Tackling malicious conduct through compliance

For some time, the Internet user, law enforcement and security communities have voiced concerns that domain name registration services are too frequently exploited, that a preponderance of malicious domains are registered through a small number of registrars, and that certain registrars are lax, unwitting accomplices to, or "have the appearance of facilitating" malicious activities such as fast flux. While acknowledging that many registrars and resellers serve them well, these communities also call ICANN to task for not acting swifty to compel registrars who serve as the loci for registration and DNS abuse to clean up their operations or face deaccreditation.

What is often perceived as ICANN's disinterest or lack of willingness to take action against registrars can be attributed in part to the enforcement mechanisms available through the existing ICANN Registrar Accreditation Agreement. ICANN COO Doug Brent explains that "aspects of the existing RAA are hard to enforce" and "there are significant mismatches between community expectations and actual enforcement provisions and tools. RAA provisions should define practices that are efficiently enforceable... On a daily basis, staff compliance work is either aided or frustrated by clear, enforceable language."

Taking into account the day to day experience attempting to enforce compliance, ICANN staff has identified
several new obligations to concerns about domain registration and DNS abuse. Staff has also identified amendments that would clarify the RAA and promote registrar compliance with existing RAA obligations. The following Staff Notes were submitted to a GNSO RAA amendments drafting team for consideration:

1) Consider cybersquatting by registrars a violation of the RAA.

2) Oblige registrars to investigate credible reports regarding malicious conduct and report back to complainants.

3) Escrow privacy and proxy registration data.

4) Require registrars to provide full information on affiliates (e.g., reseller contact information).

5) Extend requirements for problem investigation to some definition of validation or verification of accurate Whois data.

6) Clarify and codify the amount of time a registered name holder has to respond to an inquiry or accept liability for harm caused by wrongful use of that name.

7) Reduce the number of arbitrators to save time and expense for all involved, when arbitration is required.

8) Improve administrative process for TLD accreditation so that registrars in good standing can efficiently be accredited for additional TLDs.

9) Require a registrar to promptly notify ICANN of any security breaches affecting the registrar and 
affected registrants when there is reasonable evidence of unauthorized access to their accounts.

Brent gives context to these notes, explaining that "success for the community and for registrants is a set of rules that provide adequate registrant protection, are easily understood by all, represent a consensus, and that
can be both effectively implemented by Registrars and are efficiently enforceable in a way that meets expectations." ICANN's Kurt Pritz aptly describes these notes as "outlining areas of potential concern in the RAA, and offering some possible implementation options for community consideration".

This is where you play an important role. If you are interested the subjects discussed in the staff notes speak out! Subscribe to the RAA mailing lists (1, 2, 3). If you have theinterest *and* time to volunteer, ask the GNSO Secretariat for information regarding working group participation.

Twitter scams: More of the same from attackers

Chester Wisniewski has an interesting article about direct messageTwitter attacks at the Sophos blog. He explains how a follower he trusts sent him a tweet inviting Chester to join him in making $500/day online. Knowing the sender, Wisniewski knew immediately this was a phishing tweet, and his article explains what he found as he continued his investigation.

What is surprising about Wisniewski's article is not that attackers are tweeting for phish, but how similar Twitter phish specifically and social network spam in general are to email phish. Phishing today varies little from the scam formula adopted more than a decade ago. For example,

• Wisniewski's tweet phish originated from a newly registered domain. Thousands of malicous domains are registered every month. This figure has remained relatively constant over the past two years. 
• Wisniewski's tweet phish came from a trusted follower, or more precisely, from the compromised account of a trusted follower. Wisniewski explains that this phishing attack was very likely preceded by a phish attack against Twitter or against a social network that allows you to share posts from Twitter. Wisniewski recommends, and I concur, that "using sites that request your username and password for social media is never a good idea."
• The domain was registered using a private domain registration. Such registrations gives criminals who have populated Whois with false registration information in the past an additional level of obfuscation, so this behavior is not a change but a refinement.
• Wisniewski's tweet referred him to a domain. Whether email or tweet, a recipient who bites on the lure and visits the phish site lands on a "known dirty domain", a domain registration that persists for any of several reasons: the domain is fast fluxed, resolved at an orphaned name server, or "sticky" because the takedown process employed by some registrars remains cumbersome, inefficient and overly vulnerable to abuse.
• The scam web site accepts credit card information and uses a certified secure SSL certificate, which Internet users commonly and incorrectly assume protects their transaction from identity theft. To be clear, "certified secured" in this phishing scam means that no other criminals can see your credit card information while it's communicated from your PC to the phisher's scam web site.

What is less surprising is that the best practices to avoid phishing and malware on Twitter and social networks are almost exactly the same as best practices written for email years ago. Summarizing from a recent article by Sarah Perez, they are:

1. Be wary of any URL (hyperlink) in a tweet or email. Phishers use HTML to embed malicious links in seemingly familiar, "safe" links. Don't click on a hyperlink; instead, type the link in manually.
2. Be aware that criminals will "hijack" popular topics to prey on your enthusiasm. The strategy is simple: find someone who is so caught up in a topic he forgets rule #1 above.
3. Be aware that criminals compromise email, Twitter, and social network accounts so they can deceive you more effectively. Wisniewski's tweet is an excellent example of this tactic. Don't let your guard down simply because the sender is someone you trust: remember, senders can be spoofed.
4. Install antivirus and antimalware software, and keep these and other software up to date. The more current you remain with security patches for your operating system, browser, and Adobe applications (reader and flash), the safer you'll be from malware that's often lying in wait for you at phishing sites. To keep current, download and use Secunia Personal Software Inspector.

Sarah Perez concludes her article by saying that it's not just a matter of common sense anymore. This doesn't mean common sense plays no role; in fact, all the protective measures you may take will prove worthless if you don't use some common sense, so please think before you click. 

Trusting Third-parties with your password

On the Twitter password change page you'll find the following notice:

Note: If you have trusted a third-party Twitter service or software with your password and you change it here, you'll need to re-authenticate to make that software work. (Never enter your password in a third-party service or software that looks suspicious.)

There are so many things wrong with this note I hardly know where to begin. First, who are these third parties? A search quickly reveals that there are dozens. Many allow you to pull tweets from a blog or Facebook or (insert laugh here) improve your Tweet productivity. Many are free. Of course, this is where the matter of trust comes in. Few things in life are free, and many free online services translate to "we won't charge you so long as you agree to let us track you and mine your activity". On what basis should you trust a third-party Twitter service? Well, start with the Privacy policy, and if you can't find one, be suspicious.

Speaking of suspicious, exactly how does following Twitter's guideline "Never enter your password in a third-party service or software that looks suspicious" help you avoid account compromises? Avoiding suspicious software and services is so easy a caveman can do it. Avoiding convincingly similar software is another skill set entirely, and one that millions of users have yet to master.

So here's a suggestion for Twitter. Change the note! I suggest the following:

Note: THINK CAREFULLY before you trust a third-party Twitter service or software with your password. Generally, sharing passwords is a VERY BAD IDEA, especially if you care a whit about your privacy. If you insist on violating this important rule, please Please PLEASE use UNIQUE passwords for these connected applications, and for goodness sake, DON'T USE THE SAME PASSWORD YOU USE FOR ONLINE BANKING! Oh, by the way, if you change your Twitter password, you'll need to re-authenticate to make that software work. Oh, and one more thing: Always be suspicious of ANY form that asks for a password, whether it looks suspicious or exactly like the one you're familiar with using. Double-check the URL you are visiting. When in doubt, type it manually, OK? OK...

Nine ways to mitigate malicious domains

In collaboration with antiphishing, security, CERT, and financial communities, ICANN has collected a proposed list of measures for new TLD applicants to implement to mitigate malicious conduct involving domain names.

Vetted registry operators. Recommended by APWG and security experts in the financial industry, this measure is intended to ensure that no criminal organization can own or influence a registry operator (e.g., through indirect shareholding or ownership).

Demonstrated plan for DNSSEC deployment. An applicants will be expected to publish a detailed plan and timeline for signing their zone file and for signing delegations (domain names registered in its TLD).

Prohibition of redirection by TLDs.Acting on the recommendation of ICANN’s SSAC, the ICANN Board of Directors has agreed that applicants must return negative responses when a DNS query is made to a non-existent domain and must not synthesize (redirect) queries for error resolution or advertising purposes.

Removal of orphan glue records. Orphaned glue records frequently point to name servers that host malicious domains. This measure requires applicants to explain the policy they will enforce to ensure that a name server record in a delegation will not persist in the TLD zone file when the parent domain name is deleted from the zone.

Requirement for thick Whois records. This measure requires applicants to provide Whois output that identifies the sponsoring registrar, the status of the registration, the creation and expiration dates of each registration, contact information for the registrant and designated administrative and technical contacts, plus name server information.

Centralization of zone file access. Today, organizations must individually contract with TLDs registries to obtain (FTP) access to zone files. This does not scale to the potentially large numbers of zone files the new TLD program may spawn. This measure provides for the implementation of a common access point for organizations that require access to TLD zone files. (Look for a future article explaining how centralization of zone file access will be implemented).

Documented registry level abuse contacts and procedures. This expands the ICANN SSAC recommendation that all registrars maintain an abuse handling process and publish contact information. Registries will similarly be asked to have public and easily accessible abuse handling agents.

Participation in the Expedited Registry Security Request process. A GTLD registry uses the ERSR process to request a contractual waiver for actions it might take or has taken to mitigate or eliminate a present or imminent security incident of global significance. This measure allows ICANN and registries to maintain operational security during an incident.

Draft Framework for High Security Zones Verification.The high security zones verification program establishes a set of operational and security control standards that collectively improve confidence in the ability to maintain security, availability, confidentiality, and privacy of systems and information assets supporting critical registry IT and business operations.

The publication of this explanatory memorandum and consideration of these measures for new GTLDs within the ICANN process is a landmark event. However, it's critical that all interested parties recognize that this is a discussion draft only. Simply put, this is not a "done deal." To ensure that any or all of these measures are incorporated into the new TLD application process, you must voice your support through the ICANN public comment process http://www.icann.org/en/public-comment/

Is office cleaning a proper analog for web security?

Nikolai Bezroukov offers an interesting view of Unix Security:

"The main problem with Unix security is that it is very similar to office cleaning services. It is a dull and unrewarding task that needs constant attention and often involves fighting against your own management."

This characterization may apply to Unix security, but it falls shy of being sufficient for web security in several respects:

It assumes that an office exists. Web applications span multiple servers, hosting sites and networks. Containing web applications to a particular domain of control may be a consideration during a design phase but this objective is often neglected during growth stages and ultimately abandoned.

It assumes that cleanliness is a design and operational objective. Web application cleanliness translates to keeping a web site clean of vulnerabilities. Few organizations put a premium on securing web applications over publishing content as quickly as humanly possible and considerable data are available to support this assertion (see Report: Nearly 6 Million Infected Web Pages Across 640K Compromised Sites).

It assumes a steady state of dull and unrewarding. WebSense reported that in 1H2009,  over three-quarters of web sites  with malicious code were found to be legitimate sites that had been compromised. That's not dull but dramatic and frightening. It's also rewarding but not for the legitimate web operators.

One aspect of Nikolai's characterization of Unix security that does apply is that web security is a task that needs constant attention. Specifically, every aspect of web application you host needs attention from design through deployment and continuing for as long as the application remains in a production environment.

Fighting with one's management is disputable. My experience is that management doesn't always fight against investing in securing web applications. The problem not whether management fights but when. Management rarely opposes investments in security in the aftermath of an incident involving a breach or defacement of a web site. Management needs to assess risk more carefully early and continuously during the lifetime of a web application and security staff need to help them by providing good data to assess that risk.

Orphaned Glue Records

When you register a domain name, you are obliged to identify a name server that will host the DNS information for that domain (the zone file). Commonly, organizations operate name resolution service for a given domain on a host that has been assigned a name from a distinct (separate) domain. This is called an out of bailiwick assignment since the name is not assigned within your "jurisdiction", which is the zone file for your domain.

An example is in order. Imagine that Example, Inc. has registered domains example.TLD and example2.TLD, and has identified NS1.example.TLD and NS2.example.TLD as the name servers for example.TLD. In TLD's zone file you would find the name server (NS) and A records (also called glue) for example.TLD, as follows:

example.TLD    NS  ns1.example2.TLD
example.TLD    NS  ns2.example2.TLD
example2.TLD   NS  ns1.example2.TLD
example2.TLD   NS  ns2.example2.TLD
.
.
.
ns1.example2.TLD   A   10.0.1.53
ns2.example2.TLD   A   10.0.2.53

Now, let's suppose example2.TLD is deleted from the TLD registry. This might occur if Example, Inc.  fails to renew the registration for the domain. It might also occur if the domain was suspended because it had been associated with malicious activity (hold this thought). The registry operator (in concert with the sponsoring registrar) should remove the resource records associated with example2.TLD. Removing the glue records however would affect example.TLD since NS1.example2.TLD and NS2.example.TLD host example.TLD's zone. TLD has some options: rename the name server or make it an "orphan" (so labeled because the parent domain name no longer exists).

In the scenario I presented, *all* the resource records are managed by a single registry. The issue of orphans becomes more problematic when an organization registers domains in one registry and hosts name service in another.  Additionally, name servers often host zone files for many domains, so removing glue records might interrupt name service for other domains that also used ns1.example2.TLD or ns2.example2.TLD to host zone files. Policies vary across GTLDs and CCTLDs, further compounding the problem. In cases where the domains involved are not in the same top level domain, the registry operators cannot know unless they are notified by registrar or registrant(s) involved in the name deletion.

Let's go back to that thought I asked you to hold. Imagine that a bad actor registers a bunch of phish domains in TLD *A*, and hosts them at a name server in TLD *B*. Now imagine that the parent domain is removed in the same manner as my example, as a result of a suspension action by a registrar. The orphaned name server is now an obscure corner from which other phishing domains can operate name service.

Preliminary results of study of the prevalence of this form of DNS abuse suggests that there is a correlation between malicious domains (in particular, fast flux attack domain) and orphaned name servers. This is an important problem to solve, and I'd love to hear your opinions on how to solve it.

Evacuation Kit for Domain Name Holders

I live on an island off South Carolina situated in what is referred to as the Hurricane Belt, where many Islanders appreciate and practice hurricane preparedness. Documentation is an important aspect of  "being prepared". The principle is that you collect all documentation you might need in advance of a possible evacuation. For example, my family keeps a portable file cabinet that contains  our home, flood, wind and rain insurance information, photos of our possessions, automobile titles, the deed to our property, CDs burned with financial records, etc. If we evacuate, this "evacuation kit" is the first thing that goes into our car.

I'm frequently asked what measures I'd recommend to domain name holders (in the ICANN parlance, registrants) to protect and prepare against domain name hijacking or domain registration account hacking, and I'm reminded of our evacuation kit. Here, I discuss documentation that might be useful should you or your organization experience a domain name hijacking or account attack.

First, let's consider the threat landscape. Domain hijacking or registration account attacks typically result in one of two types of consequences: (1) the attacker changes DNS configuration, so that name resolution for the domain is performed by a name server not operated by (or for) the victim, or (2) the attacker alters registration contact information and effectively takes control of any domains registered under the compromised account.

To recover from either of these events, you will need to provide documentation (evidence) to a registrar or dispute resolution service that proves an association existed between you, the complainant (the one who has legitimately registered the domain name) and the domain name or account, prior to the incident. Imagine if you were tasked with proving that Example, Inc. was the legitimate registrant of example.com Some or all of the following "paper trail" could serve as evidence to corroborate this claim:

• A domain history, i.e., copies of registration records that show Example, Inc. as the registrant of record 
• Billing records demonstrating that the registrant has maintained account currency,
• System or web logs, archives illustrating that example.com has been associated with content published (and perhaps copyright or otherwise protected) by Example, Inc.
• A history of financial transactions that associate example.com with the registrant. Credit card and other customer invoices often record the merchant name, address, phone numbers and *domain names*
• Telephone directories (Yellow pages), marketing material, etc. that contain advertising that associate Example, Inc. with example.com. (Here, I'd want as many prior years' directories as I could present to illustrate that the domain name has been associated with my company.)
• Correspondence from registrars and ICANN (annual Whois reporting, renewal notices, notices of DNS change, telephone call records, etc.) sent or placed to email or postal addresses or telephone numbers of employees or legal agents of Example, Inc.>
• Legal documents, for example, a contract for the sale of a business from Acme, LTD. to Example, Inc. that contains a clause such as "as a condition of sale, Acme, LTD. agrees that the domain name example.com shall be transferred to Example, Inc.".
• Tax filings, business tax notices, etc. that associate the example.com with Example, Inc.

This list is representative of the type of information that might be useful. I'm neither an attorney nor a dispute resolution arbitrator, and I am not suggesting that all of these documents would meet legal criteria as evidence.  Some or perhaps all of these documents might require corroboration from other parties (i.e., credit card companies, tax collectors/IRS,...) or a notary stamp or equivalent. I do suspect that presenting this kind of documentation to a registrar may be sufficient to justify an immediate return of a domain and restoration of correct DNS configuration data in many cases. I also suspect that, just as many of my fellow islanders aren't prepared to recover from losses resulting from a hurricane, many domain name holders won't be prepared if they are targeted for a domain hijacking. Consider my list and prepare an emergency domain recovery kit.