0

I recently discovered and reported a security vulnerability to Twitter:

enter image description here

Despite my belief that the report it indeed valid, they replied to me with the following response:

enter image description here

As far as I can tell, this security engineer is talking about protection against cookie hijacking. However that is not my concern at all. My concern is that you can completely takeover a Twitter Account of a user as long as you have the value of his auth_token cookie.

No, I don't claim Twitter has a security flaw leaving sensitive cookie values exposed. There are tons of ways a cookie can be hijacked, and that already puts the victim-user into a dangerous position. However, he can reset his password etc. at any time. But when the attacker is able to brute-force his way into obtaining the password of the logged-in user, hence taking full control of the account (changing email, passwords, etc.), the victim has absolutely no chance of getting his account back.

I even made a video to demonstrate how easy the attack is.

Do you think this vulnerability is valid/critical? Am I or the security engineer at Twitter "wrong"?

closed as primarily opinion-based by DKNUCKLES, CaffeineAddiction, Steffen Ullrich, ThoriumBR, Steve Mar 20 '17 at 13:59

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • The core of this is that there seems to be no account lockout (or similar mitigations) applied to the password field in settings. Not critical, (IMHO) but it didn't sound like Twitter Security recognized that as the core issue. I'd suggest re-sending to them. – Scovetta Mar 19 '17 at 15:07
  • @Scovetta I have done so 4 times already. If you can get them to understand the issue, please let me know. – Coto TheArcher Mar 19 '17 at 15:19
  • 4
    I don't think SecSE is the right platform to resolve your dispute with the Twitter security team. If you have contacted them "4 times", chances are they don't want to fix it. If you think the problem is interesting you might want to write a blog post about it. (Also, please don't post screenshots of text.) – Arminius Mar 19 '17 at 15:23
  • Yeah, could you edit and copy paste the actual text instead of the images? – Anders Mar 20 '17 at 13:15
2

Their response is perfectly valid. They are saying that what you found is the intended behavior. There is a usability trade off with security features and they are saying they aren't going to implement one here because the chances of a cookie being stolen is unlikely because of protections they have in place.

They point out that the attacker has to have infected the users computer pretty much to steal the cookie, in which case, they already have their password.

There is one thing they said that i take issue with but its actually to their benefit.

They describe that the cookie can be stolen using XSS if a vulnerability is present but that is not true because their cookie is http-only. So their site is actually more safe than they are even claiming.

For the future, its best to keep your question generic because this isn't really a good place to disclose something you found on somebody elses website.

  • Hijacking a cookie can be done in so many ways. Credential hijacking is another thing, which can often be harder to obtain, compared to cookie sessions. You can easily social engineer most of the world to get them to give you their cookie value without them even realizing - ways like social engineering, man in the middle attacks etc. can help achieve this goal. This is the same logic as hashing your databases. Twitter's got a database with millions of users and their credentials? Why hash the information, when their security against SQL Injections and such is fine? Because even... – Coto TheArcher Mar 20 '17 at 19:28
  • ...if it happens, the damage could be much worse than it already is. The same logic applies to this security flaw. Regardless of the damage that has already been done, you should do everything to protect your user as much as possible, not let give up as soon as the attacker has gained access to his account, and then let him completely takeover his account. – Coto TheArcher Mar 20 '17 at 19:30
  • how can you social engineer somebody into giving you their cookie? Its far-fetched. Why wouldnt I just social engineer the username and password? Its easier. Mitm is almost impossible since they are using hsts and tls. The risk is so incredibly low here that for a social media platform to implement this would be overboard. Their response is perfectly valid. You must be able to balance risk with with usability. Going overboard can turn people away and decrease revenue. They are there to make revenue. None of the scenarios you listed are plausible. – joe Mar 21 '17 at 3:02
  • Creating an apache page, that will redirect twitter.com, *.twitter.com to a fake page can very easily bypass the https protocol/cookie protection and allow the user to have access to the cookie, and therefore the password. I'm not sure if you heard, but a popular YouTuber got his phone stolen, and the thief had access to his Twitter account as it was logged in. What if he had the password too? He could've completely taken over his account, changing all information, like email, password, etc. So, having a user's cookie without his password is definitely not always the case. – Coto TheArcher Mar 21 '17 at 14:31
-1

You are correct Twitter could do more to protect accounts after an attacker is logged. Google I know has dedicated engineering staff to deal with this scenario and minimize the damage after the cookie or even credentials have been breached. I don't know what Twitter does, they may have mechanisms to detect potentially malicious behaviour by an authenticated uaer and such like, If they don't they should, and take a wide perspective on the problem, not only password brute forcing. The security engineer responding. If the primary scenario for compromised cookies is controling the end user device there is no end to what the attacker can do. Including for instance stealing the password from the device rather then by brute force.

Not the answer you're looking for? Browse other questions tagged or ask your own question.