(May 8) Several security issues were fixed in cups-filters.
Comment
(May 7) Updated kernel packages that fix two security issues and one bug are now available for Red Hat Enterprise Linux 5.9 Extended Update Support. The Red Hat Security Response Team has rated this update as having [More…]
(May 7) Updated kernel packages that fix three security issues and several bugs are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having [More…]
Fraudsters are impersonating online banking websites in order to gain unauthorised access to customers’ emails. Most online banking phishing sites simply try to steal whatever credentials are required to gain access to a victim’s bank account, but by also gaining access to the victim’s email account, the fraudster can prevent the victim from receiving any email alerts regarding account activity.
With access to the victim’s emails, the fraudster could also potentially net a much larger haul. These emails will indicate to the fraudster which other banks, shops, social networks and other online services the victim uses. The fraudster can then attempt to compromise the victim’s accounts on these services by initiating password resets, which will be sent to the email address he now has access to. In some cases, the fraudster will also be able to change the password of the victim’s own email account, thus locking him out and making him unaware that further compromises are taking place.
The following phishing site targeted customers of
Chase Bank earlier this month. Like many other phishing sites, it did a good job of looking like the real Chase Bank, although the address bar revealed that it was actually served from a
hacked gift store.
Clicking on the Log In to Accounts button takes the victim to the following page, where he is told that a
POP email service is required in order to continue. This is purportedly part of a verification measure, and the victim is prompted to enter his email address and email password so the site can log in to the victim’s email account automatically.
POP (Post Office Protocol) is one of the most widely supported mail retrieval protocols, which lets an email client download email from a mail server. Many webmail providers (including Gmail,
Outlook.com and
Yahoo Mail) also allow mail to be retrieved via this protocol.
As soon as the victim clicks the Login button, he is taken to the real Chase Bank homepage which, unsurprisingly, looks rather similar to the original phishing site, albeit with the correct URL in the address bar.
At this point, the victim may simply assume he has to log in again after completing the previous verification step. If he does, he will be taken to his online banking account as expected. Meanwhile, the fraudster could well be helping himself to the victim’s emails, starting the process of compromising each of the victim’s other accounts one by one.
Chase Bank customers who have enrolled to receive Account Alerts can be notified of account activity via email. By deleting these emails, the fraudster might be able to prevent the victim from becoming aware of any fraudulent transactions until it is too late.
The phishing site used in this particular attack was one of the 8.5 million sites blocked by Netcraft’s
phishing site feed and has since been taken offline.
Although many secure websites reacted promptly to the
Heartbleed bug by patching OpenSSL, replacing their SSL certificates, and revoking the old certificates, some have made the critical mistake of reusing the potentially-compromised private key in the new certificate. Since the Heartbleed bug was announced on 7 April, more than 30,000 affected certificates have been revoked and reissued without changing the private key.
Internet users rely on public key cryptography to verify the identity of secure websites: SSL certificates contain a public key that is generated from its associated private key. At the start of the secure connection, the server proves that it has the private key by decrypting messages encrypted with the public key, or by cryptographically signing its own messages. Keeping the private key secret is critical — if an attacker steals the private key, he can impersonate the secure website, decrypt sensitive information, or perform a man-in-the-middle attack.
Although we typically refer to “potentially-compromised” certificates when discussing the Heartbleed bug, the CA/Browser Forum adopts a much more cautious approach to its terminology. This group lays out the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, and they consider a private key to be “compromised” if there exists a practical technique by which an unauthorised person may discover its value — even if there is no evidence of such a technique having been exploited.
By reusing the same private key, a site that was affected by the Heartbleed bug still faces exactly the same risks as the those that have not yet replaced their SSL certificates — if the previous certificate had been compromised, then the stolen private key can still be used to impersonate the website’s new SSL certificate, even if the old certificate has been revoked. Certificates that have been reissued with the same private key are easy to identify, as the new public key will also be identical to the old one.
Only 14% of affected websites (Zone A in the above Euler diagram) have done all three required steps after patching the Heartbleed bug – they have replaced their SSL certificates, revoked the old ones, and made sure to use a different private key. This zone also includes sites with certificates that expired shortly after the bug was disclosed.
Zone B represents the 5% of sites that have made the fundamental
mistake of reissuing their certificates without changing the private key. This is the most dangerous zone, as not only could these websites still be vulnerable to impersonation attacks, but the website administrators will probably believe that they have done everything necessary to fix the problem. An additional 2% have reused the same private key and not revoked the old SSL certificate.
The white outer zone represents nearly 57% of the affected sites which have taken no action whatsoever — they have neither reissued nor revoked their certificates. A further 21% have reissued their certificates with a new private key, but failed to revoke the old ones.
The Canadian government ought to appreciate the risks posed by the Heartbleed bug more than others, particularly after the bug was exploited to
steal social insurance numbers from the Canadian Revenue Agency. However, some parts of the Canadian government have made the mistake of reusing private keys while trying to mitigate the risks.
The Quebec Automobile Insurance Corporation is a crown corporation responsible for licensing drivers and providing personal injury insurance to the public. One of its websites at secure.saaq.gouv.qc.ca was issued a new SSL certificate in response to the Heartbleed bug, and the previous certificate was revoked on 29 April. The CRL revocation status listed the reason as "keyCompromise", but the issuing certificate authority nonetheless allowed the new certificate to be signed with the same private key. This means the new certificate can also be impersonated by anyone who is in possession of the compromised key.
This type of mistake could be prevented by certificate authorities: if public keys from revoked certificates were blacklisted, new requests with the same public key would be rejected. This type of automated check does not seem to be in use by most CAs; however, Netcraft’s Site Reports and browser extensions can be used to determine whether a website has signed its replacement certificate with the same private key:
