Good Summary of Heartbleed

17. April, 2014

This article contains a good summary of the Heartbleed bug and it’s consequences.

Want to know whether you’re affected? Check sites you use here:

Note: You will want to check the issue date of the certificate as well. If it was issued before the April 8th, 2014, you may still be vulnerable since an attacker might have stolen the private keys.

HTML5 vs. Security

22. November, 2013

HTML5 vs. Security” was a talk given by Thomas Röthlisberger of Compass Security AG which gave a nice overview over some of the security problems that HTML5 brings.

Areas covered by the talk:

Together, those technologies allow remote attackers to scan internal networks, access intranet sites and track users.

For example, if you’re visiting a site while connected to a compromised WLAN access point, an attacker might send you a manifest for this site. The manifest then contains the names of some files which exist on the original site plus additional resources. When you’re back in a safe network, the browser will use the saved files when you visit the site again, making the attack permanent.

Another place to save malicious code is the local storage. Or we can use the local storage to attach a permanent ID to the browser / user.

CORS and WebSockets allow to scan the local network for open ports. With Web Workers, thousands of ports can be scanned in the background. Or you can use the technology to build an ad-hoc botnet to crack passwords.

Shell of the Future is a proof of concept that demonstrates how you use the browser of another person to browse the web. This means that the attacker can a) see all the information (session cookies, JavaScript) that the hijacked browser has and b) that the attacker can drive said browser (downloading more resources, scanning the intranet, etc).

In some cases, these vulnerabilities are necessary to make the new feature useful. What you need to be aware:

  • Decline strange/unexpected requests by your browser
  • When you configure your server, make sure you send the correct Access-Control-Allow-Origin headers. Never configure your server to reply with “*”.
  • There is no anonymity if you allow web sites access to the Geolocation API or local storage.

Google Shares Your WLAN Passwords with NSA

17. July, 2013

If you “Back up my data” is enabled on your Android phone, then Google keeps a clear-text, unencrypted copy of your WLAN passwords on its servers. Since Google is an US company, the government and its agencies have access to this data. Google also keeps a database with the location of all WLANs (for their location service) so it’s trivial for them to gain access (even though someone must physically walk/drive into the range of the WLAN router).

Solution: Disable this function, use a local backup program (disable cloud backup for them as well) and change all your passwords.

Related articles:

Overview Of Man in the Middle Attacks

26. February, 2013

David Blake posted a current overview of Man in the Middle type attacks15 Surprising Ways You Could Fall Victim to a Man in the Middle Attack

These include:

  • Key-loggers (hard- and software)
  • Browser plugins
  • Cameras (a.k.a Shoulder Surfing)
  • Wireless attacks

CVE Changes Counter

7. February, 2013

The Common Vulnerabilities and Exposures or CVE is a registry for security related flaws and computer systems.

The old counting system allowed only for 9’999 bugs per year.

That’s no longer enough.

Isn’t that scary?

Passwords Suck

25. January, 2013

On Wednesday, GitHub improved their code search. A few hours later, a couple of people had tried “begin rsa private key” and got more results than any sane person would anticipate. Just in case, this isn’t a problem of GitHub, the same problem can be found on pastebin or with Google.

There are several reasons for people to publish sensitive data:

  • They don’t know what they’re doing (ignorance)
  • They are sure “no one will ever find out” (security by obscurity)
  • Distributing sensitive data anonymously (crackers)
  • It’s easier that way (laziness)

It’s not a corner case, either. The SQL*Plus tool from Oracle has no easy way to set the password from a script except by passing it on the command line which effectively publishes the password to any user on the same computer. You can install a “client-side Oracle wallet” to fix this.

But the common issue behind all that is that it’s either too easy to do it wrong or too hard to do it right. Just to see how bad the situation is, I asked for a secure web login/example on The answer was basically “it’s too complex to do.”

This sucks.

Targeted Spamming via Facebook

26. September, 2012


In the past few weeks, I started getting mails from friends which just contain a link:

hey, Aaron


9/25/2012 12:34:56 PM

Turns out that someone is analyzing my Facebook account and sends me mails using names from my friends list.

If you get such a mail, don’t click on the link. It probably points to a page which infects your computer with a virus.

Right now, these mails are pretty easy to identify as fake because the email address is wrong. But you should know that the sender address in emails is just a text; neither the sending nor the receiving computer will check what is in there. A spammer can write anything into that field. If the scheme starts to fail too often, I expect to see “better” email addresses.

This means as a receiver, you should never click on links in emails. As a sender, you should never share links by email.


Embarrassing Security Failure at PayPal

26. March, 2012

PayPal is one of the places who really care about security.

But even they were vulnerable to XSS type of attacks using the search feature (see this article for details).

At the moment, I’m not sure if that’s more embarrassing or frightening. Sure, it’s shameful but when even those guys don’t get it right … who can?

Stand up for your freedom to install free software!

19. October, 2011

Read the truth behind so-called “Secure Boot” and sign the statement.

Who is Responsible For Data Theft?

22. July, 2011

Would you like to see your name, address, birth date and email on a public bill board? On the main street? What if the bill board is behind a big sign “don’t read this”?

If that worries you, why do you give your data to web sites of big companies? Many of them, even the big ones, show very little interest in keeping your contact detains secure. Many sites are still vulnerable to cross site scripting or SQL injections.

If anyone puts your life or privacy at risk, they are liable – except when web sites are involved. Even if they violate common sense and even the most basic rules of security, the worst that can happen is that they have to apologize. Pollute some fish? To Jail! Lose 300 million customer records? Oops, sorry about that.

Paul Venezia asked an interesting question: Should companies be accountable for the security risks they take? He says:

In the United States, at least, very specific laws govern patient information and how it is stored, accessed, and disseminated. HIPAA regulations were put into place to ensure that sensitive patient information isn’t distributed to just anyone — that is, only to the people who need that information. They also prevent health care providers from discussing any type of patient information with anyone else. They were explicitly designed to protect patients, and each patient must sign a waiver to authorize the release of that information to another person or party. Yet we have no regulations on the storage, access, and dissemination of sensitive user information on public websites — none. Thus, there’s almost no business case for providing any form of high-level security for customer accounts.

Interesting thought. I have two comments:

1. Not individual developers should be liable but the company which runs the site. It should be in their best interest to keep their data secure.

2. Today, it’s too complex to create secure web sites. Yesterday, I used renderSnake to create some HTML. If you supply a string value for output, the default is not to escape HTML special characters like <, > and &.

Creating a login component for a web site is pretty complex business and there is a no reasonable tutorial or template component which you could use that gets most security issues right like:

  1. Transmitting the password via HTTPS (encrypted) instead of using plain text (which anyone in the same LAN can read)
  2. Encrypting the password before it’s stored in the database
  3. Storing the password with a salt to make it harder to attack it with rainbow tables
  4. Escaping special characters in user names and password to prevent cross site scripting or SQL injection.
  5. Avoiding security questions like “Name of your cat?” More than 50 people know the name of my cat! The name might even be on the web somewhere (possibly next to a photo on Flickr) How secure is that?
These are the basic rules to make your web site safe against identity theft. It would be simple to create a law saying “if you violate the rules named once per year by a committee of experts, you’re liable for a hefty fine”. If that would happen, I’d support it.


Get every new post delivered to your Inbox.

Join 334 other followers