Category: Hacker Crap

Sony EPIC Fail

I just received this in the mail today:

Although we are still investigating the details of this incident, we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network password and login, and PSN online ID. It is also possible that your profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network password security answers may have been obtained. If you have authorized a sub-account for your dependent, the same data with respect to your dependent may have been obtained. If you have provided your credit card data through PlayStation Network, out of an abundance of caution we are advising you that your credit card number (excluding security code) and expiration date may have been obtained.

Wow. Epic fail.

Don’t the programmers at Sony understand the most basic rules about storing personal data? You never store it in the clear. And data for verification purposes should never be stored at all – it should just be HMAC-ed and the fingerprint/hash stored instead.

On my part, I did not store any credit cards with Sony because I have never bought anything from the PSN (and to avoid my nephew accidentally buying anything off the PSN). As for my passwords, I have been practicing new password policies for a while now. So, I think that I should be safe.

While I understand that Sony could just be playing it safe and saying that everything that they store could have been stolen, but this does not help me sleep better at night, knowing that Sony has my data.

No wonder they need to rebuild PSN from the ground up. They are quite screwed. Their new firmware introduced this hole and they cannot patch the consoles through the PSN until the PSN is secure. It’s a security nightmare indeed. Then, they need to re-architect the entire system and restore all the data.

If we thought that the Amazon down-time was bad, this is much worse. Lawsuits!

Anonymous vs Aaron Barr

Personally, I used to think that Anonymous were just a bunch of kids doing dumb stuff since their attacks have largely been limited to DDoS attacks against targets. DDoS attacks do not reflect any sort of sophistication and can be done by just any dumb hick with access to the right resources.

However, their latest attack on the security company HBGary is quite another thing altogether, and deserves some respect. From the Ars feature article on the story, I found that Anonymous has been right to act and to do it with some sophistication and class. While I still think that they’re a bunch of kids, at least they’ve got their heads screwed on right.

When someone threatens your life, you have every right to beat them down hard. I totally support the kind of action that they took against the security expert.

This is another lesson that we security types should learn, that security is a never ending cat-and-mouse game where the role of predator and prey can swap places constantly. Personally, I know some basics on security too and as one of the top sys-admins at Serverfault, I have to also keep a watchful eye on the dozens of servers that I administer.

However, it is not so easy to stay on top of the game because I am learning new things all the time, and have to do that to stay ahead. However, I know full well what my limits are and that I may be good, but I am most certainly not the best at the game. However, that’s fine with me because I do not sell my services as a security expert. I am a chip designer and embedded engineer. Knowing some security does help even at the chip level.

Hmm. Maybe it’s a good business idea to design ‘security chips’??

Hats off to Anonymous! Keep up the good work!

Gawker Passwords

After reading the news report about the Gawker password leak, I thought to myself, WTF?!! According to the BBC article, I just couldn’t believe the kind of passwords people chose to use for their accounts. Unfortunately, I see this everywhere, particularly in corporate environments. People tend to come up with passwords that depend on what keys are placed in sequence on a keyboard.

Okay, having previously worked in information systems security, I have learned some things about password security. And the biggest thing that I learned from this leak is that, these people did not take suitable password protection measures.

  • A password must never be stored in the clear because it can be read if the database is dumped.
  • A password must never be encrypted because it can be read if the secret key used to encrypt it is broken along with the application.
  • A password must never be hashed because it can be read if a common password is used (like in this case) where the hashes can be calculated outside of the attack.
  • A password must always be randomly seeded and hashed so that the same password, can have different hash values under different conditions.

In fact, the last method – a randomly seeded hash – is only good for now, until it is broken. In fact, this scheme should be used to encrypt any sort of data used for one-way authentication. There are many different ways to do a seeded hash but the concept is similar in all cases – to prevent a value from having the same hash all the time.

Can you imagine it, the most common password is “123456”??!!!

This is probably a good time to plug a simple tool that will come in very handy with online passwords – pwdhash. It comes with both a Firefox and Chrome plugin so it can be easily used in modern browsers. What it does is to seed a password with the domain name and hash it. So, even if your password is “123456”, it will be sent as a random string of characters to the website.

Mulling over DDoS

The Wikileaks fracas is escalating, with hacktivists on both sides of the divide working to take down sites that are seen to be on the wrong side of the issue. Personally, I do not have any political opinion on either the Wikileaks issue or the attacks. I leave that to less technical authors to write on. Personally, I just like mulling over the whole problem of DDoS attacks.

Any reader of this blog should be familiar with what a DDoS attack is. But to me, the problem of a DDoS attack is similar to that of an arms race – the side with the bigger gun or bullet wins. In the case of the initial attack, Wikileaks moved over to AWS and was able to hold off attacks for a while. This is because Amazon had bigger pipes and defenses than the attackers. However, the attacks have taken a turn and secondary sites such as credit cards and law-firms are being hit as well. It seems like certain parties are taking this opportunity to settle some beef.

But back to the whole problem with DDoS.

I’ve mulled over this with my former boss and some co-workers, for the purpose of a clandestine project that I was working on. The conclusion that I came to is that a DDoS is effective in its simplicity – the side with the bigger pipes win. The company that I used to work for, has one of the biggest pipes in Malaysia and we could take people down, single-handedly, if we wanted to.

However, there are strategies to mitigate a DDoS attack.

Bigger pipes
Wikileaks moving to Amazon was in effect, buying bigger pipes. This mitigated attacks for a while until they got booted off Amazon. If it is not possible to buy pipes from a single provider, it would make sense to buy pipes from multiple providers and distributing the site across the globe. This is what Wikileaks has now done – distribute its content over a list of hundreds of worldwide mirrors operated by volunteers.

Faster software
DDoS attacks exploit the fact that a computer is kept busy by servicing network packets (either at the application or networking layers). Obviously, the solution to this problem would be to have bigger machines – this means having faster processors, larger memories, lighter operating systems. Surprisingly, some people do not realise that the TCP/IP stack plays an integral role in these attacks and if the OS has a more efficient stack, it would be able to withstand more punishment. Not all web-servers are created equal and some are able to handle concurrency better.

IPv6
One method that is not often thought of, is moving infrastructure over to IPv6. Most of the internet still runs on IPv4 today. In fact, many network providers simply do not cater to IPv6 and simply drop the packets from their network. Therefore, moving a site over to IPv6-only could help mitigate DDoS attacks by limiting the available sources of attack. Compromised botnets would be less effective if most of their machines were still on IPv4 only.

Future clouds
What would have been interesting would be if the attackers had shifted to launching attacks from cloud service providers. In fact, this was one of the queries that I raised once, in a meeting with a local cloud provider – launching attacks from within the cloud provider itself. If the provider is not careful, attackers could buy network and computing resources in order to launch attacks within the cloud itself. This would be difficult to detect because most cloud providers put their metering on external traffic, not internal ones. Imagine the attackers buying EC2s to attack Wikileaks from the inside of Amazon infrastructure. The attack would only need to be bad enough to take down the Wikileaks machines, without compromising the rest of Amazon’s infrastructure. Therefore, it is important for cloud providers to think about isolating their internal machines from each other.

Of course, there are many more considerations that could fit this little blog, but these were just some thoughts that I felt like writing down.

Stuxnet Worm

This video comprehensively explains how a hypothetical attack could be carried out by an attacker using the Stuxnet worm. This has very serious implications because it means that low-level industrial embedded systems are also now targets for attack. These SCADA systems are used everywhere and lack the necessary resources to defend themselves from attack.

The technique used is a fairly straight-forward one. The attacker can download and modify a programming library and use that to intercept the actual programme being downloaded onto the SCADA system.

This technique has been used for ages, in a non-malicious way. For example, my Xilinx board does not properly support my OS for programming. Thankfully, someone out there has written an open source driver to intercept all the Xilinx calls. Install this driver and the Xilinx ISE will think that it is talking to its own driver while all its calls are actually being intercepted by the wrapper.

Interesting, and cool.

This makes me think that I will probably need to build in some protection to my future cores to at least enable a limited amount of security checking of downloaded code.