don’t forget to secure cookies ppl

Update (5/28/14): Regrettably, most of the stories covering this blog post have been all “OMG EVERYTHING IS BROKEN” rather than “Here’s how to make things better til WordPress rolls out a fix” (which I humbly believe will take a while to *fully* fix, given that their SSL support is so patchy). So, given that most people reading this are probably coming from one of those articles, I think it’s important to start with the actionable items that people can do to mitigate cookie-hijacking attacks on WordPress:

  1. If you’re a developer running your own WordPress install, make sure you set up SSL on all relevant servers and configure WordPress to auth flag cookies as “secure.”
  2. If you’re a WordPress user, don’t be logged into WordPress on an untrusted network, or use a VPN. If you are and you visit a wordpress.com site (which confusingly may not actually have a wordpress.com domain name), your auth cookies are exposed.
  3. [Experimental, probably not recommended] You can manually set the “secure” flag on the WP auth cookies in your browser. There’s no guarantee that this works consistently, since the server can always send a set-cookie that reverts it into an insecure cookie. It may cause some WP functionality to break.
  4. If you suspect that your WP cookie may have been stolen in the past, you can invalidate it by (1) waiting 3 years for it to expire on the server or (2) resetting your wordpress.com password. Note that logging out of WordPress does *not* invalidate the cookie on the server, so someone who stole it can use it even after you’ve logged out. I verified that resetting your WP password does invalidate the old cookie; there may be other ways, but I haven’t found any.

Original post below.

 

While hunting down a bug report for Privacy Badger, I noticed the “wordpress_logged_in” cookie being sent over clear HTTP to a WordPress authentication endpoint (http://r-login.wordpress.com/remote-login.php) on someone’s blog.

uh-oh

uh-oh

Sounds like bad news! As mom always said, you should set the “secure” flag on sensitive cookies so that they’re never sent in plaintext.

To check whether this cookie did anything interesting, I logged out of my wordpress account, copied the wordpress_logged_in cookie into a fresh browser profile, and visited http://wordpress.com in the new browser profile. Yep, I was logged in!

This wouldn’t be so bad if the wordpress_logged_in cookie were invalidated when the original user logged out or logged back in, but it definitely still worked. Does it expire? In 3 years. (Not sure when it gets invalidated on the server side, haven’t waited long enough to know.)

Is this as bad as sending username/password in plaintext? I tried to see if I could reset the original user’s password.

wordpresspassword1

That didn’t work, so I’m assuming WordPress uses the actually-secure cookie (wordpress_sec) for super important operations like password change. Nice job, but . . .

It turns out I could post to the original user’s blog (and create new blog sites on their behalf):

wordpress_postblog

I could see private posts:

wordpress_postsecretblog

I could post comments on other blogs as them:

wordpress_postcomment

I could see their blog stats:

wordpress_stats

And so forth. I couldn’t do some blog administrator tasks that required logging in again with the username/password, but still, not bad for a single cookie.

Moral of the story: don’t visit a WordPress site while logged into your account on an untrusted local network.

Update: Thanks to Andrew Nacin of WordPress for informing me that auth cookies will be invalidated after a session ends in the next WordPress release and that SSL support on WordPress will be improving!

Update (5/26/14): I subsequently found that the insecure cookie could be used to set someone’s 2fac auth device if they hadn’t set it, thereby locking them out of their account. If someone has set up 2fac already, the attacker can still bypass login auth by cookie stealing – the 2fac auth cookie is also sent over plaintext.

Update (5/26/14): A couple people have asked about whether the disclosure timeline below is reasonable, and my response is here.

Disclosure timeline:

Wed, 21 May 2014 16:12:17 PST: Reported issue to security@automattic.com, per the instructions at http://make.wordpress.org/core/handbook/reporting-security-vulnerabilities/#where-do-i-report-security-issues; at this point, the report was mostly out of courtesy, since I figured it had to be obvious to them and many WP users already that the login cookie wasn’t secured (it’s just a simple config setting in WordPress to turn on the secure cookie flag, as I understand it). Received no indication that the email was received.

22 May 2014 16:43: Mentioned the lack of cookie securing publicly. https://twitter.com/bcrypt/status/469624500850802688

22 May 2014 17:39: Received response from Andrew Nacin (not regarding lack of cookie securing but rather that the auth cookie lifetime will soon be that of a regular session cookie). https://twitter.com/nacin/status/469638591614693376

23 May 2014 ~13:00: Discovered two-factor auth issue on accident, reported to both security@automattic.com and security@wordpress.org in reply to original email. I also mentioned it to Dan Goodin since I found the bug while trying to answer a question he had about cookies, but I did not disclose publicly.

25 May 2014 15:20: Received email response from security@automattic.com saying that they were looking into it internally (no mention of timeline). Wrote back to say thanks.

26 May 2014, ~10:00: Ars Technica article about this gets published, which mentioned the 2-fac auth issue. I updated this blog post to reflect that.

26-27 May 2014: Some commenters on the Ars Technica article discover an arguably worse bug than the one that the original article was about: WordPress sends the login form over HTTP. (Even though the form POST is over HTTPS, the local network attacker can modify the target on the HTTP page however he/she wants and then it’s game over.) This wouldn’t be so bad if everyone used a password manager and changed passwords semi-regularly, since most people are likely to login to WordPress through their blog’s admin portal (which is always HTTPS as far as I can tell), except that password reuse is rampant. Robert Graham subsequently published this blog post.

29 May 2014, 5:52: Received reply from WordPress saying they would email me again when fixed.

30 May 2014, 14:51: Andrew Nacin says all issues are supposedly fixed.

89 thoughts on “don’t forget to secure cookies ppl

  1. Me

    I was able to reproduce this in 5 minutes, using wireshark I could get the cookie from the target computer and log to his session

  2. Pingback: Happenings of digital privacy in the world (Part 1) | Tomas Touceda

  3. Pingback: ADnjus | Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass

  4. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass – Mores Media

  5. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Padroni

  6. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass

  7. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Tech Tips

  8. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | World Updates

  9. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Business News | Finance News | Stock News | Real Estate News | Auto News

  10. Toobad

    I am not sure why you decided to go public with your vulnerability only 24 hours day after notifying Automattic? Did you have any reason to believe that Automattic would ignore or not fix your vulnerability? Why is disclosing this to the public a good idea?

    That is called irresponsible disclosure. It is dangerous and serves no purpose other than your own purpose.

    1. yan Post author

      Hi Todd,

      First of all, I really respect this viewpoint. Responsible disclosure is important, and so is courtesy to the company.

      However, in this case, I believe that 24hrs was a fair amount of time. The main reason is that SSL support nowadays is widely accepted as the bare *minimum* security guarantee that a website should provide for users’ private information, and this is essentially a bug in WordPress’s SSL support. “Only send auth info over SSL” has been the most basic security recommendation to website operators for the last 15+ years.

      It is rare for researchers to notify website operators before pointing out that a particular website does not support SSL or is sending passwords in plaintext. In my opinion, it is more advantageous to disclose such an obvious bug as soon as possible because:
      1. Any passive network attacker can trivially detect and exploit this bug, so it’s more unlikely that disclosure gives them an advantage. I think it’s fairly likely that someone has found this before me and has possibly been using it.
      2. Users *can* in fact protect themselves until a fix is rolled out by accessing the site through a VPN or making sure they’re not logged into WordPress on a public network.
      3. Developers who run their own WordPress instance have the power to protect their users by fixing this bug on the server side: all they have to do is turn on SSL for their website and change a configuration setting in WordPress that force-secures cookies. This has the potential to protect millions of users, given that a giant fraction of WordPress sites are self-hosted.

      I love WordPress and will continue to support them, but I found their security disclosure procedure a bit lacking. At the time, the page I found for security disclosures instructed me to email security@automattic.com. I did not receive any indication that my email was read or received. Nacin later told me to email security@wordpress.org, which I forwarded my email on to. Yesterday (3 days after initial report), I received a reply from them that they were looking into it, which was much appreciated.

      I think we have the same end goal here (protect users), and this was my understanding of how to best do that, both by getting the issue fixed on WordPress.com ASAP, alerting users to make sure they’re not using WP on an untrusted network, and by teaching developers that they must force-secure auth cookies.

      Let me know if you have any concerns,
      Yan

      1. Jared

        You could have gotten “the issue fixed on WordPress.com ASAP,” altered “users to make sure they’re not using WP on an untrusted network,” and taught “developers that they must force-secure auth cookies,” without endangering millions of user accounts by making this issue public knowledge only 24 hours after your original report.

        You could have done all of that by waiting just a bit more than 24 hours and working with Automattic to resolve the issue. Automattic seems to be a big company, and there does appear to be more than one way to contact them. A responsible representative of the security community, as you are yourself the developer of a security browser extension, would have tried more ways that just one to reach a fellow developer and extended the courtesy of more than just 24 hours.

        Instead, you have chosen to continue the incorrect and dangerous belief/trend that publicly disclosing a security issue will yield quick results.

        1. yan Post author

          I’m genuinely curious about your last statement – what are some real-life examples suggesting that public security “bug” disclosure is harmful to the public? (“Bug” in quotes because I want to include lack of SSL best practices in that category, which some people wouldn’t call a bug per se.)

          Off the top of my head, I can point to a few examples of the opposite, where public disclosure appeared to do more good than harm even if some people were initially upset:
          1. Firesheep was game-changing at the time, and still to date one of the more convincing arguments that every site needs to support HTTPS. http://steve.grc.com/2010/10/28/why-firesheeps-time-has-come/
          2. EFF’s Encrypt the Web report revealed what some would call “security bugs” (lack of HSTS support, which could be exploited using SSLstrip easily by anyone who read the chart and took the time to download some Python scripts) in popular web services: https://www.eff.org/deeplinks/2013/11/encrypt-web-report-whos-doing-what. In its wake, companies started to take encryption more seriously, and in the last few months, we’ve seen a significant rise in commitment to practices like HSTS and STARTTLS.

          I agree there’s some cases in which disclosing a security bug immediately (ex: Heartbleed) is probably harmful, but I don’t think this was one of them. For one, the only real fix is to have better SSL support (though session invalidation will lower the exposure time, which is helpful), which should have been there all along. It’s worth noting that because some potentially sensitive wordpress.com pages don’t support HTTPS, your private information was being sent in the clear all along; so, for instance, you don’t even need to steal login cookies to read private posts. There is almost no doubt that someone has exploited this at some point, possibly hundreds.

          I don’t think WordPress is alone in this. Tumblr and LiveJournal don’t have full HTTPS support, so my default assumption is that you can read private posts (and messages?) there too. Any decent security engineer knows this already, which is why this seems irresponsible to end users in a way that most security bugs aren’t.

          It would be nice to live in a world where users at least *know* the risk that they’re being exploited, which in this case was significant before I ever published anything. Sometimes, the side effect of disclosure is that their risk increases, but the relative danger of public disclosure is lower when the bug was already obvious to most attackers.

          But, admittedly, this is a complicated topic [1], and I’m sure my views are colored by personal experience. I’m open to being convinced that I am completely wrong. We all want to protect users, so let’s figure out how to do that.

          [1] Background reading on ethical disclosure: http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html, https://www.schneier.com/essay-146.html.

          1. Jared

            “what are some real-life examples suggesting that public security ‘bug’ disclosure is harmful to the public?”

            Common sense. If you discover a security issue, as far as you know, only you know it exists. There is no logical reason to think otherwise.

            If you disclose a security issue publicly, your blog followers, your 3,000 Twitter followers, and millions of Ars Technica readers not only know that it exists, but also how to exploit it.

            “There is almost no doubt that someone has exploited this at some point, possibly hundreds.”

            That is no excuse. Perhaps hundreds have exploited this, but now millions know how to. Thanks.

            As far as the danger of a particular security issue is concerned, if only 1 person knows of its existence, it is infinitely less dangerous than if shared with the public.

            I’m not talking about this security issue specifically, I’m talking about the best practices of reporting all security issues.

            The fact that you work on a security extension for the prestigious EFF, yet don’t understand the difference between publicly and privately reporting security issues, concerns me a great deal.

          2. yan Post author

            AFAICT, your general argument here applies to EFF’s Encrypt the Web Report. “It’s bad for the public to know that X doesn’t support HSTS, so let’s not publish a report at all.”

            Assuming that only you know about a bug is generally incorrect when the bug is as glaringly obvious as “not supporting HTTPS.” Commenters on the Ars Technica article even mentioned that they noticed this on WP.

          3. Jared

            ” AFAICT, your general argument here applies to EFF’s Encrypt the Web Report. ‘It’s bad for the public to know that X doesn’t support HSTS, so let’s not publish a report at all.’ ”

            No, my general argument applies to publicly disclosing a security issue only 24 hours after privately disclosing it. If you want to wait a week or two, that’s fine. If you want to contact them more than once, that’s fine. But, for the good of everyone, give the developers a reasonable amount of time to address the issue before telling the whole world how to exploit it.

            Let me give a more real-world example. You go over to your neighbor’s house and notice that their front door is unlocked. You more than likely act on this by knocking on the door to get your neighbor’s attention. If your neighbor doesn’t answer, do you try again later or do you tell the whole neighborhood that your neighbor’s front door isn’t locked? In this particular case, you told the whole neighborhood, thus directly endangering your neighbor’s house.

          4. yan Post author

            No, your analogy is like me telling the world that one person’s WordPress password is “PassWord1″. Telling everyone that one person is a victim is different from telling everyone that they’re all victims to a problem they can go out and fix.

            Modified analogy: say that everyone’s lock in your neighborhood is broken in a way that any moderately competent lockpicker can exploit. But luckily, they can all install better locks and get new keys, even if it’s slightly inconvenient. You point out that all their locks are broken and leave it up to them to go buy new locks and keys. Meanwhile, you also tell all the locksmiths in town to not make the same mistake again.

          5. Jared

            ” Telling everyone that one person is a victim is different from telling everyone that they’re all victims to a problem they can go out and fix. ”

            Yes, but you could have told everyone privately, so that they know to fix their lock before the neighborhood knows that it’s open season to simply open their neighbor’s front door and take whatever they want.

            I can see that you feel telling the world how to exploit a security issue is somehow more responsible than privately disclosing it and working with developers to correct it, and I am sorry for that. I will avoid EFF security software in the future. This isn’t the EFF that I remember first becoming a member of.

        2. Eduardo Bustamante

          It is pretty naive to believe that this issue wasn’t know until now. To a determined attacker, this error is one of the simplest things to find. So, the danger is/was still there even if not made public.

          1. Jared

            Oh, I’m sure others knew before now, but now millions know how that it exists and how to exploit it. Do you honestly believe that each one of those millions already knew?

            That is why public disclosure is irresponsible.

  11. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Tech-RSS.com

  12. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Gizmo Envy

  13. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | Keithpp's Blog

  14. marc

    From what I can see you can’t log into a self hosted (.org) site using the “Log in with WordPress.com” option (jetpack-sso), all you can do with self hosted sites is view the stats at wordpress.com, please correct me if I’m wrong.
    And yes 5 mins with wireshark is all it takes, nice catch.

    1. yan Post author

      I don’t know WP codebase well, but I’m sure you can configure a self-hosted WordPress instance to have the same problem. Certainly ones that don’t support SSL.

  15. Pingback: Serious WordPress issue exposes users to hijacking even if 2FA is enabled | Security Affairs

  16. John Kenney

    Don’t forget to make sure all your page elements are https too! Get a ! warning in Firefox on this site, because of some insecure png files, fix it up.

    1. yan Post author

      Yes, I’ve noticed this mixed content error before and have now decided that the ironic value simply isn’t worth it, so it’s being fixed

  17. Pingback: Dangerous cookies make WordPress accounts open to hijacking | Press Any Key

  18. Pingback: В WordPress выявлены проблемы с защитой сессионных ключей от перехвата | AllUNIX.ru — Всероссийский портал о UNIX-системах

  19. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | TechBox

  20. Pingback: 黑客能利用不安全的cookies劫持你的WordPress博客 | 我爱互联网

  21. Pingback: WP Cookie ermöglicht einfachen Login durch Fremde

  22. Pingback: Cookies open WordPress accounts to easy hijacking | Tech-RSS.com

  23. Pingback: Cookies open WordPress accounts to easy hijacking | Genius Pioneer

  24. Pingback: Cookies open WordPress accounts to easy hijacking | POPFIX - Celebrity, Tech, Sports News

  25. Pingback: Cookies open WordPress accounts to easy hijacking | What's On Scotland

  26. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass

  27. Pingback: Cookies open WordPress accounts to easy hijacking | News around The World

  28. Pingback: Cookies open WordPress accounts to easy hijacking | Wizeguys

  29. Pingback: 黑客能利用不安全的cookies劫持你的WordPress博客

  30. Pingback: 黑客能利用不安全的cookies劫持你的WordPress博客 - IT新闻

  31. Pingback: Yebaa.com | Cookies open WordPress accounts to easy hijacking

  32. Pingback: Cookies open Wordpress accounts to easy hijacking | Tech Auntie

  33. Pingback: Cookies open Wordpress accounts to easy hijacking | Padroni

  34. Pingback: Cookies open WordPress accounts to easy hijacking

  35. Pingback: WordPress Cookie Flaw Lets Hackers Hijack Your Account | vulnerablelife

  36. Pingback: Cookies flaw lets hackers steal WordPress accounts - DigitalMunition

  37. Pingback: Cookies open WordPress accounts to easy hijacking – Health and Fitness

  38. Matt

    Thank you very much for finding and investigating this problem. If there’s a next time, I would definitely appreciate it if you gave us a few days more next time to protect users before it’s public.

  39. Pingback: WordPress Gets Flagged for Insecure Cookie Risk | Ezspk Technical

  40. Pingback: WordPress Flaw Lets Anyone Easily Hack your Login Data Over Public Wi-Fi | Fix My Pc FREE

  41. Pingback: Cookies open WordPress accounts to easy hijacking

  42. Pingback: Cookie Tidak Aman Membuat WordPress Rentan Dibajak

  43. Pingback: WordPress Issue Bypasses The Two-Factor Authentication

  44. Pingback: WordPress Cookie Flaw Lets Hackers Hijack Your Account. - Nairobi Web Experts.

  45. Pingback: Wulnerabilitatea din WordPress permite infractorilor sa intre in panoul de control | Antivirus Free

  46. Pingback: WP Cookie Problematik – Pressengers.de › Wordpress, Wordpress Security, Wordpress Sicherheit › Aktuelles, Internet, Wordpress › Alltägliches und Besonderes

  47. Pingback: Falha no Wordpress facilita que contas sejam hackeadas | Security Attack

  48. Pingback: Unencrypted Cookie Creates Huge WordPress Vulnerability, Compromises 2-Step Authentication

  49. Pingback: Wordpress com Falha facilita ataque em sites e blogs

  50. Pingback: WPTavern: WordPress.com Security Vulnerability Stirs Debate Over Responsible Disclosure | Marketing Online Comercial SEO

  51. Pingback: WordPress cookie flaw could lead to near account takeover

  52. Pingback: Cookie permite secuestro de cuentas | Esaminare

  53. Pingback: Falha no Wordpress.com facilita que contas sejam hackeadas | Minuto TI

  54. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass - jobone.in

  55. Pingback: WordPress Cookie Flaw Lets Hackers Hijack Your Account - Meta Thrunks Security Blog

  56. Pingback: Weekly Cloud Report 005: WordPress Cookie Hijack & More

  57. Pingback: WordPress Cookie Flaw Lets Hackers Hijack Your Account - TechnoXperts

  58. Pingback: Weekly Roundup of Web Design and Development Resources: May 30, 2014

  59. Pingback: Security is nuanced | Andrew Nacin

  60. Pingback: WordPress Gets Flagged for Insecure Cookie Risk

  61. Pingback: Cookies May Help Hackers to Hijack your WordPress Websites

  62. Pingback: Unsafe cookies leave WordPress accounts open to hijacking, 2-factor bypass | VIGALUM

  63. Pingback: ClickSSL Weekly Infosec Snipper – June 2, 2014

  64. Pingback: The WhiP Newsletter #12 | BloggoPress

  65. Pingback: The WhiP Newsletter #12 | Wind River Graphic Design

  66. Pingback: The WhiP Newsletter #12 - WPMU DEV

  67. Pingback: The WhiP Newsletter #12 - WordPress Community | powered by Mpress Studios

  68. Pingback: WordPress | Monblogprofessionnel

  69. Pingback: wp ← Pilzkuh

  70. Pingback: WordPress ist durch ein unverschlüsseltes Cookie angreifbar ← Pilzkuh

  71. Pingback: WordPress Cookie Flaw Lets Hackers Hijack Your Account | My great WordPress blog

  72. Pingback: Security is nuanced

  73. Pingback: prettyPhoto DOM based XSS -Sysadmins of the North

Comments are closed.