Hacking in the Far East 8: Summarizing the Most Striking Security Flaws

Proceeding to the summary, Paul S. Ziegler lists the top three security-related problems he has encountered during the years spent in the Eastern Asia.

After I’ve shown you all of this cool stuff that we can do and all these weird vectors, we’re going to sum them up a little, and we’re going to look at what I like to call the Top 3 Hit List, which is basically the top 3 things I’ve seen in the last 6-7 years, that made me go: “Huh?” and that I’m allowed to disclose, because they’re not under NDA anymore, or because they never were to begin with.

Airport Security

Passport verification machine at the airport Number 3 is the most harmless and it’s called Airport Security. Now, if you go to Narita airport and you check in, you have to put your passport on a certain reader which reads the chip inside, if it’s already a chip-enabled passport, and will check whether your passport is correctly signed, all of this stuff. So, this is the machine, it’s very nice (see image). It also checks you in if it finds you. This thing handles all of your passport data, so what I find slightly unnerving was watching it boot, because this screen came up (on the image). What I found more unnerving is that the very day I took that picture was the day where a remote 0day was published for XP SP2, so we know that the box was hackable at that particular point.

“Ultra Secure” JavaScript

Payment screen for using a router in a cafe Number 2 is what I like to call the “Ultra Secure” JavaScript, which is a technology often employed in Japan; I’ve seen this a couple of times, this is just one example (see right-hand image). This is a router; you need to log in to use it. It’s a standard router, it was actually used as a pay router in a cafe, so they said: “If you want to use the Internet, please enter your credit card details here.” So, I just figured out: “Well, I’m kind of bored, let’s look at the source for this.”

Source code for the authentication page Here is the source; can anyone spot a flaw? (see left-hand image) Let me give you a hint: it’s this part of JavaScript that says “var password”. It gets worse: if password equals this, then call the function “send_login”. So, the entire authentication was done in JavaScript, and this is a run-of-the-mill standard router produced by a huge Japanese manufacturer of routers. This is not a fluke; there were tens of thousands of these things deployed, and we all know how often router firmware gets updated.

Security Flaws: Non-Critical?

But this is nothing compared to the grand finale. The grand finale happened while I was working for a Japanese company, consulting for them in the mix of development and security efforts, and they asked a Korean company to provide them with software, so the Korean company would develop it.

So, they gave them the contract, and the Koreans looked at it and they go: “Ok, we know how this works.” So, they developed it and they sent it back to us. Now, the client remembers that I have a security background and goes: “Yeah, you know what, can you test this? We know you’re busy, but just take 20 minutes out of it, just give it a rough look.”

So, what I do is I go to the login form, I hit Shift and I hit the numbers 01 and I hit Enter, and the server comes back with: “SQL query Upper Quote cannot be found because of malformed query,” and I go: “Ok, there may be something wrong here.”

It turns out the thing is an absolute catastrophe, and when I say absolute catastrophe, the damn vulnerable web app prototype kit that you practice your web attacks against would be considered secure against what these guys delivered.

If you disabled JavaScript you could use the admin panel the way you want, because there was no other authentication going on.

So, we had everything: we had RFI, LFI, XSS, we had SQL injection on the main page, SQL queries weren’t filtered at all. But my personal favorite was the fact that it stored credit card numbers in plain text in database, and you could look at that from the admin interface, and the admin interface was secured with JavaScript, and by that I mean there was JavaScript that would check a cookie on your machine, and if the cookie was not set – by the way, the cookie had to be set to 1 – it will call the JavaScript Back function to send you back to the previous page.

So, obviously, if you just disabled freaking JavaScript, you could look at the admin panel and use it the way you want, because there was no other authentication going on. All the login form for the admin interface did was set this cookie to 1. Obviously, we have some really big security issues with this thing.

So, the Japanese got this, I’m not going to reveal to you how I got them to accept that there might be security issues, but they sent it back to the Koreans, the Koreans looked at it and they figured out that there were some issues, and, of course, it explodes with them, and one developer gets fired because he should have known, he was supposed to be the foreign technology guy. Another issue was that they got SSL warning, because the certificate they were using simply did not match the domain name. They’ve got a signed certificate, but it was not for the correct domain name, so of course we got a huge warning for that.

But what happened after this is that the communication between the Korean company and the Japanese company exploded as well, because the Koreans accused the Japanese of being rude, and the Japanese accused the Koreans of being lazy. So, we’re back at where we are right now, basically.

To quiet it down we got another consultant who was fluent in Korean, and we set up this huge meeting, and during the meeting, basically, they worked together to identify 2 sets of flaws: they identified the critical flaws which had to be fixed before launching, and they identified the non-critical flaws which had to be fixed whenever, at some point while we’re making money.

Critical software flaws identified during the meeting So, here’s the list of the critical flaws (see left-hand image): users are not able to log in if the name contains special characters – by the way, that’s because special characters would cause the SQL query to fail. The too quick session timeout was annoying to potential users, so it should increase from 1 hour to 3. They disliked the colors, and this freaking SSL error kind of annoyed users, so that had to be fixed. And the credit card numbers being stored in plain text in the database – that was bad.

Security issues were listed as non-critical They didn’t really care about the security implications, but there’s a law in Japan prohibiting that under very strict penalties, so that obviously had to be fixed. Here’s a list of the non-critical flaws (right-hand image): SQL injection on login form; 207 counts of XSS; and the admin console being ‘secured’ by JavaScript. And here’s a quote I received from the CEO of the Japanese company, which goes: “We can launch with those, no one would check that.” He went on to say that only weird people like me would check that.

You can see this thing is still live, and the Korean company has deployed the same prototype to about 3 dozen other clients, but in the end you know what? From what I’ve told you guys, we can at least be proud they fixed SSL. Unfortunately, they didn’t fix SSL; they fixed the error message, which was the critical flaw. And they fixed the error message by removing SSL altogether.

So, let me sum up. Are we screwed? Yes, we are.

Read previous: Hacking in the Far East 7: Too-Near Field Communication

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: