11 ms·

Lenovo Forums stores plaintext password as a cookie

209 points by ashitlerferad 4y ago

37 4y ago
From Jan 31.... Wonder if this has been fixed yet
- iamdual 4y ago
  Yeah, tested. They fixed.
  - aendruk 4y ago
    Did you select “Remember me” in your test?
    - deleted 4y ago
      [deleted]
    - iamdual 4y ago
      Yes, I found a remember me button on an external login page. There was a base64 encoded cookie but not in plain text. It was JSON string, includes some AES like encryption data, and expiry time.
aendruk 4y ago
I don’t see a “Remember me” option [1] on the login form anymore. Maybe they’ve removed it until this can be properly resolved? [1]: Screenshot at https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpad-P14s-Gen-2-AMD-Linux-support/m-p/5111011?page=3#5554431 https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpa...
julianlam 4y ago
I wonder what forum stack they use... Asking as someone who works with forum software on a daily basis.
- switzer 4y ago
  BuiltWith says that the CMS used at forums.lenovo.com is from Lithium Technologies, and it was first detected in July, 2012. I'm not sure if this is the forum software, or something else.
  - tyingq 4y ago
    Lithium is now Khoros (https://khoros.com/ https://khoros.com/), which is in pretty broad use.
- daxaxelrod 4y ago
  Judging by the network tab, it looks like they wrote their own. All the api requests fall under the same domain. https://forums.lenovo.com/api/v1/user/getCountryByIp https://forums.lenovo.com/api/v1/user/getCountryByIp https://forums.lenovo.com/api/v1/forums/getForumAccess https://forums.lenovo.com/api/v1/forums/getForumAccess https://forums.lenovo.com/api/v1/forums/getCurrentForumTrees https://forums.lenovo.com/api/v1/forums/getCurrentForumTrees https://forums.lenovo.com/api/v1/topic/getTopic?fid=6&tid=5124794&page=1 https://forums.lenovo.com/api/v1/topic/getTopic?fid=6&tid=51... Also interesting that they have no auth requirement on the getCountryByIp route
  - tyingq 4y ago
    They seem to consistently mis-spell "community" in the code, which is kind of interesting: var __currentForum = window.CommuntiyForums&&CommuntiyForums.findCommuntiyHomepageByUrlPath()||''; if(__currentForum&&__currentForum.hit){ lmdBrandVal = "Forum Details:"+ __currentForum.forum.board; }else{ var __websiteInfo = sessionStorage&&sessionStorage.websiteInfo ? sessionStorage.websiteInfo : sessionStorage.currentCommuntiySite; if(__websiteInfo&&JSON.parse(__websiteInfo).board) { lmdBrandVal = "Forum Details:" + JSON.parse(__websiteInfo).board; } }
    - zbuf 4y ago
      I inherited a codebase like this, from a developer coding in their native language. Function names or variables started with a typo, and they just carried on with tab/auto completion from then on. By the time I arrived the damage was wide and it was easier to leave it consistently wrong than try and fix across several codebases.
megous 4y ago
As long as it's a http only secure cookie... it should not be a huge issue. Session ids are basically replacement for username+password anyway, and nobody cares they're stored in a cookie. Server knows the plaintext password already, too. So the only remaining issues are security issues around sharing your computer with other people, or programs. I guess stealing a session id is mildly less problematic than stealing the password in case the password is re-used elsewhere.
- deleted 4y ago
  [deleted]
- 0des 4y ago
  it's all the same- biscuits, macaroons, maybe next we can do churros or something.
- skeeks 4y ago
  And what if the server is compromised in the future? It is trivially to then extract all the cookies and send them to a attacker-controlled server. The attacker then uses those password to try to login on different platforms. After initially setting a password, the database/server should only store a salted hash. No exceptions.
  - invokestatic 4y ago
    Nothing stops a hacker from siphoning all the credentials from a login page either. Servers have to handle plaintext passwords regularly.
    - djtriptych 4y ago
      but only ever in memory. writing to disk is the issue here.
      - UncleMeat 4y ago
        But there is no evidence that they are writing the passwords to disk.
mooreds 4y ago
I just tried to replicate this issue (because I wanted to see it in action). I was able to sign up and sign in repeatedly. I never saw a 'RMEPass' cookie set, nor was I able to click 'remember me'. So it seems like they have fixed at least one part of this issue.
- aendruk 4y ago
  Or mitigated the issue by disabling the affected feature.
  - mooreds 4y ago
    Fair, hard to know which.
matthewaveryusa 4y ago
This is equivalent to basic HTTP authentication. If used over TLS it's safe-ish: The real issues arise from servers logging HTTP requests/headers and whatnot in plaintext. The two benefits of using a session over the raw password are that: 1) sessions are typically scoped in time, and 2) if the session is revealed, it can't be used for credential stuffing (using the same credentials on a different website to see if the password was used there too.) Having said that I'm not being an apologist: The design should be better
- eatonphil 4y ago
  > HTTP authentication Just clarifying, do you mean basic auth with the `Authorization: Basic base64(username : password)` scheme?
  - matthewaveryusa 4y ago
    yeah -- updated.
  - blenderdt 4y ago
    Which can also be sent in the URL like: https://username:password@example.com https://username:password@example.com But this is of course even worse because most servers log this. Headers are not often logged.
    - VWWHFSfQ 4y ago
      I'm fairly certain that's just a convenience. The HTTP client will transform that into basic auth header in the actual request
      - blenderdt 4y ago
        Interesting. I wonder what really happens because I sometimes use this when I need to send an Authorization header to a location behind basic auth. As far as I know only Nginx accepts multiple Authorization headers.
T3RMINATED 4y ago

209 points by ashitlerferad 4y ago

37 4y ago

From Jan 31.... Wonder if this has been fixed yet

iamdual 4y ago
Yeah, tested. They fixed.
- aendruk 4y ago
  Did you select “Remember me” in your test?
  - deleted 4y ago
    [deleted]
  - iamdual 4y ago
    Yes, I found a remember me button on an external login page. There was a base64 encoded cookie but not in plain text. It was JSON string, includes some AES like encryption data, and expiry time.

aendruk 4y ago

I don’t see a “Remember me” option [1] on the login form anymore. Maybe they’ve removed it until this can be properly resolved? [1]: Screenshot at https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpad-P14s-Gen-2-AMD-Linux-support/m-p/5111011?page=3#5554431 https://forums.lenovo.com/t5/Other-Linux-Discussions/Thinkpa...

julianlam 4y ago

I wonder what forum stack they use... Asking as someone who works with forum software on a daily basis.

switzer 4y ago
BuiltWith says that the CMS used at forums.lenovo.com is from Lithium Technologies, and it was first detected in July, 2012. I'm not sure if this is the forum software, or something else.
- tyingq 4y ago
  Lithium is now Khoros (https://khoros.com/ https://khoros.com/), which is in pretty broad use.
daxaxelrod 4y ago
Judging by the network tab, it looks like they wrote their own. All the api requests fall under the same domain. https://forums.lenovo.com/api/v1/user/getCountryByIp https://forums.lenovo.com/api/v1/user/getCountryByIp https://forums.lenovo.com/api/v1/forums/getForumAccess https://forums.lenovo.com/api/v1/forums/getForumAccess https://forums.lenovo.com/api/v1/forums/getCurrentForumTrees https://forums.lenovo.com/api/v1/forums/getCurrentForumTrees https://forums.lenovo.com/api/v1/topic/getTopic?fid=6&tid=5124794&page=1 https://forums.lenovo.com/api/v1/topic/getTopic?fid=6&tid=51... Also interesting that they have no auth requirement on the getCountryByIp route
- tyingq 4y ago
  They seem to consistently mis-spell "community" in the code, which is kind of interesting: var __currentForum = window.CommuntiyForums&&CommuntiyForums.findCommuntiyHomepageByUrlPath()||''; if(__currentForum&&__currentForum.hit){ lmdBrandVal = "Forum Details:"+ __currentForum.forum.board; }else{ var __websiteInfo = sessionStorage&&sessionStorage.websiteInfo ? sessionStorage.websiteInfo : sessionStorage.currentCommuntiySite; if(__websiteInfo&&JSON.parse(__websiteInfo).board) { lmdBrandVal = "Forum Details:" + JSON.parse(__websiteInfo).board; } }
  - zbuf 4y ago
    I inherited a codebase like this, from a developer coding in their native language. Function names or variables started with a typo, and they just carried on with tab/auto completion from then on. By the time I arrived the damage was wide and it was easier to leave it consistently wrong than try and fix across several codebases.

megous 4y ago

As long as it's a http only secure cookie... it should not be a huge issue. Session ids are basically replacement for username+password anyway, and nobody cares they're stored in a cookie. Server knows the plaintext password already, too. So the only remaining issues are security issues around sharing your computer with other people, or programs. I guess stealing a session id is mildly less problematic than stealing the password in case the password is re-used elsewhere.

deleted 4y ago
[deleted]
0des 4y ago
it's all the same- biscuits, macaroons, maybe next we can do churros or something.
skeeks 4y ago
And what if the server is compromised in the future? It is trivially to then extract all the cookies and send them to a attacker-controlled server. The attacker then uses those password to try to login on different platforms. After initially setting a password, the database/server should only store a salted hash. No exceptions.
- invokestatic 4y ago
  Nothing stops a hacker from siphoning all the credentials from a login page either. Servers have to handle plaintext passwords regularly.
  - djtriptych 4y ago
    but only ever in memory. writing to disk is the issue here.
    - UncleMeat 4y ago
      But there is no evidence that they are writing the passwords to disk.

mooreds 4y ago

I just tried to replicate this issue (because I wanted to see it in action). I was able to sign up and sign in repeatedly. I never saw a 'RMEPass' cookie set, nor was I able to click 'remember me'. So it seems like they have fixed at least one part of this issue.

aendruk 4y ago
Or mitigated the issue by disabling the affected feature.
- mooreds 4y ago
  Fair, hard to know which.

matthewaveryusa 4y ago

This is equivalent to basic HTTP authentication. If used over TLS it's safe-ish: The real issues arise from servers logging HTTP requests/headers and whatnot in plaintext. The two benefits of using a session over the raw password are that: 1) sessions are typically scoped in time, and 2) if the session is revealed, it can't be used for credential stuffing (using the same credentials on a different website to see if the password was used there too.) Having said that I'm not being an apologist: The design should be better

eatonphil 4y ago
> HTTP authentication Just clarifying, do you mean basic auth with the `Authorization: Basic base64(username : password)` scheme?
- matthewaveryusa 4y ago
  yeah -- updated.
- blenderdt 4y ago
  Which can also be sent in the URL like: https://username:password@example.com https://username:password@example.com But this is of course even worse because most servers log this. Headers are not often logged.
  - VWWHFSfQ 4y ago
    I'm fairly certain that's just a convenience. The HTTP client will transform that into basic auth header in the actual request
    - blenderdt 4y ago
      Interesting. I wonder what really happens because I sometimes use this when I need to send an Authorization header to a location behind basic auth. As far as I know only Nginx accepts multiple Authorization headers.

T3RMINATED 4y ago