Luckily there now is a way to press a button and get secure gmail with SSL, at least. Thanks to Martin McKeay for the tip – the big Goog has enabled HTTPS in the Gmail options settings–

Gmail has been capable of running on SSL for quite some time, but it’s not something that’s enabled by default. I always typed the https in by hand, but I don’t completely trust that method. I’ve used Better Gmail2 in the past, but that doesn’t like FireFox 3 for some reason. There are also a number of scripts for GreaseMonkey that force Gmail to use SSL, but now Gmail has made it an option on the settings page. It’s on the bottom of the page and easy to miss if you’re not looking closely.

Good, now I can stop worrying about my email and get to the tough task of securing my apartment instead.

Go read the full article about this new feature here.

In particular, SSL certificates (as used to identify https websites) might contain one of these weak keys — and so it would be possible for an attacker to successfully impersonate a secure website. Of course the attacker would need to persuade you to mistakenly visit their site — but it just so happens that one of the more devastating attacks on DNS has recently been discovered; so that’s not as unlikely as it must have seemed back in May.

Anyway, my old friend Ben Laurie (who is with Google these days) and I have been trawling the Internet to determine how many certificates there are containing these weak keys — and there’s a lot: around 1.5% of the certs we’ve examined.

But more of that another day! because earlier this week, Ben spotted that one of the weak certs was for Sun’s “OpenID” website, and that two more OpenID sites were weak as well (by weak we mean that a database lookup could reveal the private key!)

OpenID, for those who are unfamiliar with it, is a scheme for allowing you to prove your identity to site A (viz: provide your user name and password) and then use that identity on site B. There’s a queue of people offering the first bit, but rather less offering the second : because it means you rely on someone else’s due diligence in knowing who their users are — where “who” is a hard sort of thing to get your head around in an online environment.

The problem that Ben and I have identified (advisory here), is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com. Then, even if the victim is really cautious and uses https and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an identity provider could be very disappointed. There’s other attacks as well, but you’ve probably got the general idea by now.

In principle Sun should make a replacement certificate and that should be it (and so they have — read Robin Wilton’s comments here). Except that they need to put the old certificate onto a Certificate Revocation List (CRL) because otherwise it will still be trusted from now until it expires (a fair while off). Sadly, many web browsers, and most of the OpenID codebases haven’t bothered with CRLs (or they don’t enable their checking by default so it’s as if it wasn’t there for most users).

One has to conclude that Sun (and the other two providers) should not be trusted by anyone for quite a while to come. But does that matter ? Since OpenID didn’t promise all that much anyway, does a serious flaw (which does require a certain amount of work to construct an attack) make any difference? At present this looks like the modern equivalent of a small earthquake in Chile.

• Certified Information Systems Auditor (CISA) : http://www.isaca.org/cisa/
• Certified Information Systems Security Professional : https://www.isc2.org/cissp

Are You Ready ?
A few basic questions to ask yourself to gauge how ready you are:

• Do I meet the spirit, and not just the letter, of the experience requirements ?
• Has there been sufficient diversity in my experience ?

Five Step Approach to CISA or CISSP Exam Preparation

1. Perform an initial benchmark and assessment of your readiness
2. Read a “survey” level preparation guide cover to cover
3. Perform a secondary benchmark, and compare your readiness
4. Review official, or “deep dive”, preparation materials on areas identified as your weaknesses
5. Re-benchmark, and repeat targeted reviews until ready

CISA and CISSP Preparation

I am sure many of you are aware of the recent massive-scale SQL injection attacks targeting Microsoft ASP applications running on IIS. The latest report has the number of attacked sites at 500,000. The press makes it sound like there is a new vulnerability in IIS or ASP. This cannot be further from the truth. The reality is the attacks are targeting Web applications where user input validation is not done (this is one of the fundamental security programming techniques). When a Web application does not validate its form input, it is opening itself up to code injection attacks including SQL injection. Today, the security industry is doing a decent job of communicating the importance of input validation. But you'll still find many legacy Web applications that have these flaws. And this is exactly what happened here: the attackers (well, they are organized) are using Google to find old ASP pages that take user input, and are systematically going after these pages to perform SQL injection attacks.

If you have legacy Web applications, the best thing you can do is use HP's Scrawlr, a lightweight Web crawling and SQL injection detection tool to detect your vulnerabilities. You can download Scrawlr here:

https://download.spidynamics.com/products/scrawlr/.

We'll be back with another edition of how important application security is to business today. Stay tuned.

• Passport
• Voting ID card
• PAN card
• Driving License card
• Government issued ID card
• Social Security Card
• Military ID card
• Consular ID card
• Postal ID card
• Government Employee ID Card
• Credit Card
• Debit Card
  

Breach Description:
ACAP Security and affiliated sites are actively marketing a "secure payment system that allows Internet-based businesses to accept secure PIN-debit card payments and transactions at their online store."  The PinPay and SoftCard sign-up pages and account access pages are not adequately secured with encryption, potentially exposing extremely sensitive personal information.

Reference URL:
Merchant 911 Blog

Report Credit:
Tom Mahoney, the Founder and Director of Merchant 911

Response:
From the online source cited above and my own cursory investigation:

Back in January, I had short email dialog with a Kip Long, who claimed to be one of the principles of a company called Softcard out of Huntington Beach, CA. They are not to be confused with SoftCard Systems in Athens, GA. As far as I know, SoftCard Systems is a legitimate company with a legitimate product.

Mr. Long was rather aggressively, but not very successfully, trying to impress me with their product - from what I can make of it, a virtual PIN based card.

The company uses PinPay - to process transactions and both companies are a part of ACAP Security, Inc..

I reviewed their site for possible inclusion in our website’s resource pages, but promptly rejected them.

their insecure sign-up form - was requesting “Identity Card Numbers” and issue dates.
[Evan] The sign-up forms at SoftCard.biz and PinPay.net are not secure.  Neither are their respected login pages.

“Identity cards” are selectable from a drop down menu and include such ID information as Passport, Driver’s license, SSN, and Credit Card.

The form also requires a full name and DOB.

I tried using the HTTPS URL but it appears that they do not have a security certificate tied to their site.

The fact that Mr. Long used a hotmail address to pitch the company made me wonder too, given that at Merchant911 we try to instill in our members that a free email address from a customer is a fraud alert.

If a company official can’t use his company’s domain for email, I’m not going to talk to him.

I called their attention to the insecure web form in January. They still have the form up there, happily collecting this information with an insecure form.
[Evan] I also sent emails and heard nothing in return.

I have to wonder how much information has already been sniffed or otherwise compromised. You probably don’t want to fill out this form.
[Evan] My advice would be to NOT fill out the form and NOT conduct business with a company that has not demonstrated a willingness to secure your information.

Commentary:
Tom informed me about this vulnerability (and potentially a breach for anyone that signed-up/in) a couple of weeks ago.  I've been a little busy lately, but was finally able to check it out.  Let me recap what I found.

First, let's go to www.softcard.biz. This is the site that Tom originally pointed out to me.



The flash home page forwards visitors to a static index (indexaa.html) page.  The first paragraph on the page informs visitors about PinPay.

"The PINPAY SoftCard is a wise way to carry and transfer money. It gives you the ability to purchase products at participating stores throughout the world (as well as at online shopping malls), with the security of a PIN that travels the internet via private encrypted tunnels. It also allows you the ability to load money to your card, pay bills, transfer money to merchants, transfer money between cards, and withdraw cash from your card at the store."



See where the page says, "Register for your FREE card HERE!!"?  This is a link to the sign-up page that Tom was referring to.



No "https" in the URL.  Tom was right on that.  The sign-up form asks for a personal information ranging from name and address to identity card information (even information for a "Second Identity Card").



The "Select Identity Card" drop down menu displays the choices for the prospective customer, including Passport, Voting ID card, PAN card, Drivers License card, Government issued ID card, Social Security card, Military ID card, Consular ID card, Postal ID card, Government Employee ID Card, Credit Card and Debit Card



SoftCard (or PinPay or ACAP Security) are asking for some very sensitive personal information!  First, this is quite a bit more information than they need to approve a person for a "PINPAY SoftCard".  Second, no encryption?!  Third, who is ACAP/SoftCard/PinPay and what will they do to secure my information once they have it supposing it wasn't intercepted on the way to them?

Let's dig a little (public) information about ACAP Security.  According to Entreprenuer.com, ACAP launched "Personal Private Network" (ppn) technology, commercially available under the trade name ppnPRO, which is described as a "highly secure, and highly private" personal private network.  ppnPRO uses "Government approved AES encryption, with strong personalized 256-bit encryption keys, and encrypting all information- network addresses, applications and ports, as well as the confidential data content".  Sounds impressive, but it also sounds like the company should know a thing or two about securing web site transactions with encryption. 

I want to discuss the risk of sending confidential private information over a public network such as the internet without encryption, in particular.  This is not a new topic, but I will take some time to demonstrate the risk.

In order for my information to be compromised, someone (or something) will need to capture the traffic.  In order for someone to capture my traffic, they will need to tap into the communication somewhere between me (my computer) and the destination (the web server).  My information doesn't travel directly from my computer to the server.  There are intermediaries (routers, switches, firewalls, etc.) that have to get (or forward) my information from my computer to the server.



As you can see depicted in the graphic above, there are at least 16 routers (or hops) between this example source and www.softcard.biz.  The final few hops are not reported due to filtering.  So where could my traffic be captured?  At the very least:

• Between my computer and my router (or firewall)
• Between my firewall and the ISP hand-off
• Between all the traversed devices within my ISP's network
• Between all the traversed devices through the internet
• Between all the traversed devices within the destination ISP's network
• Between all the traversed devices within the destination organization's network and the server itself.
  

One of the issues I talked about was the possibility of stealing Phorm’s cookies, which I elaborate upon in this post. I have written about Phorm’s system before, and you can read a detailed technical explanation, but for the present, what it is necessary to know is that through some sleight-of-hand, users whose ISPs deploy Phorm will end up with tracking cookies stored on their machine, one for every website they visit, but with each containing an identical copy of their unique Phorm tracking number.

The Phorm system strips out these cookies when it can, but the website can access them anyway, either by using some straightforward JavaScript to read their value and POST it back, or by the simple expedient of embedding an https image ( <img = "https://.... ) within their page. The Phorm system will not be able to remove the cookie from an encrypted image request.

Once the website has obtained the Phorm cookie value, then in countries outside the European Union where such things are allowed (almost expected!), the unique tracking number can be combined with any other information the website holds about its visitor, and sold to the highest bidder, who can collate this data with anything else they know about the holder of the tracking number.

Of course, the website can do this already with any signup information that has been provided, but the only global tracking identifier it has is the visiting IP address, and most consumer ISPs give users new IP addresses every few hours or few days. In contrast, the Phorm tracking number will last until the user decides to delete all their cookies…

A twist on this was suggested by “Barrie” in one of the comments to my earlier post. If the remote website obtains an account at the visitor’s ISP (BT, Talk Talk or Virgin in the UK), then they can construct an advert request to the Phorm system, using the Phorm identifier of one of their visitors. By inspecting the advert they receive, they will learn what Phorm thinks will interest that visitor. They can then sell this information on, or serve up their own targeted advert. Essentially, they’re reverse engineering Phorm’s business model.

There are of course things that Phorm can do about these threats, by appropriate use of encryption and traffic analysis. Whether making an already complex system still more complex will assist in the transparency they say they are seeking is, in my view, problematic.

(FYI, for the impatient, click here.)

There are two ways to generate random numbers on computers: (1) use a software program called a Pseudorandom Number Generator (PRNG) or (2) use a hardware random number generator. A Pseudorandom Number Generator uses a seed value to generate a sequence of numbers that appear random. The problem is that the same seed generates the same random sequence. The hardware based RNG observes and samples some physical phenomenon which is random, such as cosmic rays, RF noise, etc. (aka Entropy).

RNGs are important in Information Security because they are used to generate encryption keys, salts, etc. Historically, attacking RNGs has proven effective, such as the defeat of Netscape’s HTTPS sessions.

Most operating systems utilize a hybrid approach, implementing a PseudoRandom Number Generator that has a seed that is regularly updated through the collection of random hardware events. This process is called Entropy Collection or Entropy Harvesting. For most applications, this approach should be completely sufficient. However, one of the key assumptions is that the operating system has been up and running long enough for the seed value itself to become hard to predict through the collection of Entropy. Also, many of the Entropy collecting events come from properties of hardware devices, such as the minor variations in hard drive rate of rotation. As such, there are a few circumstances where the OS RNG may not be good enough for strong cryptographic key generation:

• Live Boot CD ( The start state of the RNG may be predictable. )
• Virtualized Hosts ( OS may be dependent on simulated events for randomness. )

( Given the exploding popularity of virtualization, this is an area worthy of research. Stay tuned. )

Design of the Got Entropy Service

Many RNGs (such as the one included in Linux, as well as OpenSSL’s) allow the addition of entropy from outside sources. So I started looking to Entropy sources I could use to bolster the RNGs on my virtual hosts (and other uses…). While I was looking into this, it occurred to me that I had an unused TV tuner card, a PVR-350.

When a TV is tuned to a channel with no local station, the ’snow’ on the screen is RF noise (the same as the static between stations on AM radios). But, for reasons beyond our scope, you never use a direct physical observation as the RNG. You have to ‘de-skew and whiten’ the data prior to sampling it. Here is the process that I use:

1. Collect about 3 minutes of video ( about 130 MB data ).
2. Using a random key and IV, encrypt the data ( using openssl & AES-128-CBC ).
3. Discard the first 32k of the file.
4. Use each of the following 32k blocks as samples.
5. Compress each sample with SHA-256.
6. Discard the last block.

• Steps 2 and 3 remove any patterns, such as MPEG file formatting, from the data.
• Steps 4 and 5 generate a 32-byte random value ( 1024 to 1 compression in the hash ).

Check it out at http://gotentropy.artofinfosec.com

Can an Attacker Broadcast a Signal to Undermine This?

Such an attacker could not remove RF noise from the received signal. Our eyes and brains are good at filtering out the noise in the TV video, but there is a lot of it. Part of the noise comes from the atmospheric background RF, but there are also flaws (noise) in the tuner’s radio and analog-to-digital capture circuitry.

I think this is a pretty strong RNG, and I have provided an interface for pulling just the values.

Also, I have written a script ( getEntropy.sh ) that will pull Entropy from the service and seed it into /dev/random on Linux.

Results from ENT

Here are results, from a sample run of the Got Entropy, analyzed by ENT ( A Pseudorandom Number Sequence Test Program provided by John Walker of www.fourmilab.ch - Thanks, John! ).

• Entropy = 7.999987 bits per byte
• Optimum compression would reduce the size of this 13366112 byte file by 0 percent.
• Chi square distribution for 13366112 samples is 233.85, and randomly would exceed this value 82.48 percent of the time.
• Arithmetic mean value of data bytes is 127.4767 (127.5 = random).
• Monte Carlo value for Pi is 3.143054786 (error = 0.05 percent).
• Serial correlation coefficient is -0.000078 (totally uncorrelated = 0.0).

Resources for the Curious…

• Wikipedia - Pseudo-random Number Generator
• Wikipedia - Hardware Random Number Generator
• NIST - Random Numbers Page
• Netscape RNG Attack
• van Heusden Video Rand

Cheers, Erik

Art of Information Security would love your feedback !

Got Entropy ?