Atlassian scrambles to fix zero-day security hole accidentally disclosed on Twitter

Twitter security celeb SwiftOnSecurity on Tuesday inadvertently disclosed a zero-day vulnerability affecting enterprise software biz Atlassian, a flaw that may be echoed in IBM's Aspera software. The SwiftOnSecurity Twitter account revealed that Atlassian provided a domain that resolved to a local server with a common SSL …

[Anonymous Coward]

IBM released a patch for the vulnerability tonight

it's available on 80 column punched cards or 800BPI magnetic tape

[Venerable and Fragrant Wind of Change]

Grab the private key?

For the benefit of readers who don't twitt ...

Who exactly can grab this private key, and how? Surely a private key that can be accessed by an unauthorised person is a big no-no, but orthogonal to an idiosyncratic DNS usage?

DNS is designed for performance over security, which is a major reason we don't rely on it for secure transactions and have SSL certs. When you describe a DNS entry as a vulnerability, it looks as if you're suggesting a misplaced reliance on something that's inherently insecure. Or in other words, propping up the edifice by painting over the cracks.

[mj.jam]

Re: Grab the private key?

Looks like they try connecting back to localhost, but via a somewhat circuitous route.

1. Look up DNS record

2. Get back 127.0.0.1

3. Connect to 127.0.0.1 with server name as above

4. Get presented certificate for that server name. So connection is all ok. (Plus since it is a trusted certificate you avoid all warnings. Just connecting to 127.0.0.1 won't work)

For localhost to be able to use that certificate, it must have the key, i.e. you have the key inside the connector. But not just you, everybody with the app has it.

So if instead you

1. Look up DNS record

2. Get back evil hacker's IP

3. Connect to evil hacker's IP with server name as above

4. Get presented certificate for that server name. So connection is all ok. Isn't it?

Far better for your localhost to have its own certificate, and have the client trust just that. However that takes more work.

[Michael Wojcik]

Re: Grab the private key?

Who exactly can grab this private key, and how?

Anyone with a copy of the Atlassian Confluence desktop application, by debugging. The private key is embedded in the desktop app.

This is a classic error, and per the Twitter thread, there are likely many, many more offenders.

[Claptrap314]

Re: Grab the private key?

Worse by far than starting a land war in Asia, I would say...

[Pier Reviewer]

Re: Grab the private key?

Many more offenders? You’re not kidding! This is very common behaviour. A large player in the gambling industry does this. I make a point of collecting such domains. Can be useful for exploiting SSRF ;)

[Neil McCauley]

Dammit Tay!

I knew you were trouble.

[FooCrypt]

TOLA ?

12 months and counting the damage to Aus Tech Exports...!

[Henry Wertz 1]

Why not /etc/hosts?

OK. So why wouldn't they put this in /etc/hosts? And (of course) force it to prefer /etc/hosts over DNS? It's for localhost connections so they DO have control over this. Oh well.

[katrinab]

Re: Why not /etc/hosts?

I'm not sure how that helps.

http://localhost - you get a warning in your address bar that the site is not secure

https://localhost - you get dire warnings about invalid ssl certificates, and it is very difficult to access the site unless you know what you are doing.

Install a self-signed certificate - your anti-virus software will probably go mental

The correct answer is to have your own domain, use split-horizon dns to resolve to localhost, get your own ssl certificate for it and install that. But that is too much work for the average person.