Xk

You would think that it would. But the way Chrome has implemented CSP, it doesn't. When you specify a CSP in a Chrome extension, it applies to the core extension (the background page) and all content scripts. It does not, however, apply to webpages you are running on.

So, if your CSP is set to deny all images, you can still add an image to a webpage. You just can't add an image to the core extension itself. Similarly, if you block eval() with a CSP, you can still eval() from the context of a webpage.

There's been a lot of research about this recently (I've brought this up on HN previously). A team from Berkeley broke 50% of the 50 most popular extensions last year [1]. Some other researchers looked at explicitly malicious extensions [2].

One thing the authors don't mention (wich is brought up in the first paper): things can be much worse than this. If you inject untrusted content to the innerHTML of the extension itself, you've given an attacker the full privileges and permissions of the entire extension. This can be very serious if the extension has access to lots of data (e.g., many Chrome extensions have arbitrary access to all http and https webapges -- a bug in one of your extensions could give an attacker XSS on a user's bank).

The Google team has taken steps to mitigate this [3]. If you write a Chrome extension, you're being negligent if you don't implement a strong CSP. That will prevent the previous issue entirely, but not the issue brought up by OP.

[1] http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...

[2] http://profsandhu.com/zhang/pub/ndss12-chrome.pdf

[3] http://blog.chromium.org/2012/02/more-secure-extensions-by-d...

Those interested in this should look at a paper from Vern Paxon and Nicholas Weaver:

http://www.icir.org/vern/papers/witty-imc05.pdf

A summary of it: A worm used a linear congenital generator to generate its randomness. It used this generator to pick which IPs to try to infect, which hard drives to write data to, and what to write. These researchers used a /8, and were able to use that to count, exactly, the bandwith of all infected machines, how many hard drives machines each had, the time they started up, and locate the exact machine which initially spread the worm. It's really quite amazing that you can get all of this from just packet captures, before you think about it.

Thanks. Will do.

edit: support email sent

You have a very severe security vulnerability on your site. Please provide an email address in your info I can contact you at. (The email field is hidden to others.)

Edit: interwho has fixed the vulnerability. There was a CSRF allowing you to take over someone else's account if they visited your site.

Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1]

Web applications make state-changing operations on GET requests. You might not like it, but they do.

[1] <img src="https://mail.google.com/mail/u/0/?logout style="display: none;" />

CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests.

Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it, there is no good way for the browser to fix the CSRF issue. You can ask the user, which is what's suggested, but that never really works. They'll do one of two things: click "okay" every single time, or stop using your browser.

I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window.

The proposed "solution" to CSRF stops ALL of these use cases. The user would have to manually approve each and every one of them. Given that well under 1% of alerts would be true attacks, the user would almost definitely "okay" on the attacks as well: they would have been trained by thousands of other alerts that this is an acceptable thing to do.

There was a paper by Barth and Jackson on CSRF defenses where they propose an Origin header, but that's the extent to which security is implemented in the browser. It is fundamentally up to the web application for verifying the user did in fact initiate the request. No amount of code in the web browser can get around this fact.

Researchers at UC Berkeley studied this exact question. About 40% of extensions contain at least one injection vulnerability. Some really popular extensions were vulnerable -- even a couple Google authored ones.

http://www.eecs.berkeley.edu/~afelt/extensionvulnerabilities...

There is an XSS on pen.io. I posted this a while ago, but feint didn't fix it.

http://xssdemo.pen.io

Suggestion: It is very hard to allow HTML but remove JavaScript. Write a method called something like isJSPresent() and then after you've done your filtering, check if JavaScript is on the page. If it is, return a HTML-encoded version of the page. Then, the security of your page will rely only on the correctness of that single method, and not on the correctness of your rewriter (which is much more complex).

Please don't use this for passwords. Security is very hard to get right.

Do they do a secure delete of the contents of the webpages? Who knows.

Do they have strong physical protection around the server? Who knows.

Do they run up to date software so the machine can't get taken over? Who knows.

Can you even trust them not to log all your passwords? Who knows.

This is an interesting service for some things, but I would never use it for sending passwords (or anything equally sensitive) back and forth.

Even if you let me "encrypt" the information before uploading it with a password, if this encryption is done in javascript sent by the server then as soon as the server is taken over you can't trust the encryption.

No.

If an attacker gets access to the database, chances are very very good they can get access to the key as well. Very few services correctly separate privileges well enough that an attacker can not gain more access once they have database access.

However ... for the sake of argument, just pretend there's only a 50% chance the attacker can get access to the key. Would you rather there be a 50% chance that you leak EVERY password in the database (regardless of strength) or would you rather lose the people who pick passwords in the 5% because you've used bcrypt?

Fine. Assume it's one bit per voxel.

512 petabits = 2 petabytes.

So only 2 petabytes of data. I'd like to see the server that processed those 2 petabytes.

Notch also points out that even still, 8m is quite a small height. Take it to 16m and now you need 4 petabytes of space.

That's not the case.

Each Telex Station has it's own private key which it uses to decrypt the 224 bit tag. If one Telex station loses its private key, then the user will just use another.

Yeah, I realize that -- I'm just saying, for people who want to read more on the subject of Tetris there is a lot out there.

For those that care, a few years ago some researchers proved Tetris is NP-complete for many problems.

http://arxiv.org/abs/cs.CC/0210020

They have an XSS on https://secure.trust-guard.com/ (enter a username like <img src=g onerror=alert(1)> -- yes, it won't work with chrome's XSS filter)... somehow I'm inclined to believe they are not so great.

(An attacker could exploit that in a number of ways. Here's a simple one: create a site with a domain name that looks really similar. http://secure.trustt-guard.com or something, it doesn't matter. When a user visits, autosubmit a form to https://secure.trust-guard.com with the malicious payload; the first thing it does is hide the error message and incorrect username. The user then enters username/password and attacker reads the values and sends it back to his site.)

What's worse, I can't find any way to report this. Does anyone see a link?

The current implementation uses an iframe and so they can't read the data out of the iframe (same-origin policy).

This would require injecting javascript on to news.ycombinator.com. It wouldn't be so bad, but it would require user interaction to do that. If it requires user interaction then it'll be less used.

Granted, they could make an extension which does that -- but now you have to download something just to use chat. That's a big barrier to entry.

The problem with captchas is they have to be readable to humans.

Sure, a captcha of "lI0Ol1o" would would probably be unreadable to a computer ... but it would be to a human too.

We're quickly approaching the point that image recognition is getting as good at solving image captchas as humans are, and when we do, we'll need to find some other way to do it.

Alright; I'm confused.

First they say that they "generate around 1 petabyte of data per second"

Then they say "ATLAS produces up to 320M bytes per second, followed by CMS with 220M Bps. The data from ALICE amounts to 100M Bps and LHCb produces 50M Bps." only that sums up to 690M Bps ... definitely not 1 petabyte per second. (That is, assuming that 1M Bps means 1 million bytes per second, or just under 1 megabytes per second.)

And then, later on, they talk about a different mode in which "more data is produced by the four experiments, about 1.25G Bps in total." which is still not 1 petabyte per second.

What's going on?

No. Not at all.

If someone managed to break in to your website and get the password hashes, chances are they also have your "secret" salt. There is no reason to separate the salt from the hash, and, in fact, there are no implementations which do that.

However, if I can't convince you of that, then if you ever make a website that takes passwords, please use bcrypt. You can do your super-special-salt-separation-scheme, but just use bcrypt instead of SHA-1.

It is true that scrypt is better than bcrypt, but the transition from salt+SHA-1 to bcrypt is significatnly better than from bcrypt to scrypt, and scrypt doesn't have nearly as nice of an interface as bcrypt does.

That's not the attack you worry about: instead, consider the case where someone somehow obtains the database and can do an offline attack on it. Be it a SQL injection or account compromise (or sheer negligence and publishing the database), once that happens you'd better handle passwords reasonably well.

If the only attack situation you're worried about is a online guessing attack, then there's no need to even hash passwords.

> and/or stop using a single word and use sentences (phrase)

True.

This isn't meant for the user, though. This is meant for the developers. No matter how hard the developers try, users will always pick bad passwords. If you use salted SHA-1, then if the database gets compromised there goes 50% of the passwords. If, on the other hand, you use bcrypt, maybe only 5% of the passwords get cracked.

Bcrypt turns a massive news event (database leaked; thousands of passwords lost!) in to something much less newsworthy (database leaked; twenty passwords lost).

> don't disagree with most of what you said, but...you sure about this part?

Yes. I am sure. I have far, far, far less than 0.000001% of the total money in the bank. If they could not produce this much money when I wanted it, there would be other serious problems.

> Or if you want a more practical example, keep watching Greece

If I was in Greece, I would not have my money in one of their banks.

If I had any bitcoins hosted on mtgox and, for some reason, had not already taken them out, I would do so right now. When you give them your bitcoins, you are trusting them to keep your money safe. I trust my money with my large bank for two reasons: (1) they have a large safe and have practice keeping people out, but more importantly, (2) if someone were to break in and take some of the bank's money, I would know that I could still withdraw my money because they have enough cash on hand for me to do so.

Mtgox has neither of those assurances.

They have absolutely no credibility on the security front. They were using MD5 with no salts at one point in time. They then moved to MD5 with salts. Now they are at "SHA-512 multi-iteration, triple salted." That seems more like they're trying to say "Oooohh! Look at us! See?! We're being secure!" Triple salted means what, exactly? (Other than the fact that it makes it clear these are people who read about salting online and then though "more is better.")

Next: "we have actively been patching holes." Oh no. You mean, you're just going through the code and looking for bugs and hoping you get them all? That might work for normal programs just fine, but even ONE vulnerability is enough to take an entire database. A database hosting just passwords may not be all that bad (it usually is, but it doesn't have to be). A database which hosts thousands and thousands of dollars? Now that is something to worry about. It truly does look like they got lucky on this attack.

As for the guarantee that banks give -- that if they get broken in to, I will still have my money -- there is no way mtgox provides this. Anyone who still has money on mtgox is asking for trouble.

That is indeed what it sounds like, but what's really worrisome about that is that anyone who thinks the solution to keeping passwords is to triple-salt them really needs to learn some things about keeping passwords safe.

I could quintuple-salt my passwords with 4096 byte salts chosen purely randomly and there would be no perceivable advantage over a single 512 bit salt.

(1) You should put your email in your "about" section so the rest of us can see it.

(2) Do you have the source of it? Do you have a non-obfuscated version?

(3) Even if the answer to both questions in (2) is "yes", I still doubt any serious cryptographers would take a look at it. They (mostly) do things to write papers, and you don't get a paper out of "we broke a really weak encryption algorithm in a botnet". The chances that the paper is instead "this botnet has a reasonable encryption algorithm" are so slim, they won't consider it.

(4) That said, there are a number of non-serious cryptographers who would find it an interesting challenge, but if they can't break it, it still doesn't mean it's any good.

> Maybe it is public/private key, and they use (derive?) the public key from the name of the server?

How would that work though? Maybe I just don't know enough, but I can't think of a way to generate a public key from some known source, and then somehow derive a private key from that source such that no one else can derive that same private key.

I guess you could generate an RSA key pair using the domain name as a seed for your random number generator, but that seems like a terrible idea. As soon as they introduce some real randomness in to it, then you're no longer deriving the key from the domain name.

I also suspect (2), but I wouldn't be surprised if they added some extra distortion to make the article read more like "Look how impressive these guys are! They made their own encryption algorithm!".

If they're using their own algorithm and then AES, what's the point? They're worrying about AES being broken? But yeah, you're right.

Seems like it would be better to spend time on the implementation of other parts of their botnet (like ... public key cryptography instead of using domain names as a key?).

> TDL-4's makers created their own encryption algorithm

Two comments about this

-- I give it maybe a week or two against a good cryptographer. You never, ever invent your own encryption algorithm.

-- Even if the encryption algorithm happens to be secure against differential/linear/slide/boomerang attacks, I bet there will be an implementation flaw. It's really hard to get implementation right on those things, even if you have an almost perfect algorithm.

Not that that all really matters -- anything that it's encrypted can be decrypted since they key lives on the computer -- but the fact that they created their own encryption algorithm gives some insight in to their minds. Namely, that they they they are smarter than they really are, and that despite all of that, they don't know enough about security to stick with AES.

> and the botnet uses the domain names of the C&C servers as the encryption keys.

... what? That kind of defeats the entire purpose of encryption when they key is something like that. Besides, what are they using this encryption for. It seems more likely they want a check on the integrity of messages. And even still, a MAC is equally worthless since it's not public/private key.

Either (1) this botnet is really weak or (2) the writers of this article have distorted the truth.