• taladar@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    27
    ·
    14 days ago

    So if I understand that correctly that cache is never updated again after it is initially created? Wouldn’t that lead to a lot of issues when the online account has its password changed in terms of the new password not working too? Something seems to be missing from this article.

    • Gibibit@lemmy.world
      link
      fedilink
      English
      arrow-up
      28
      arrow-down
      1
      ·
      14 days ago

      That is addressed in the article

      Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, [independent security researcher Daniel] Wade reported, multiple older passwords will work while newer ones won’t.

      • taladar@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        14
        ·
        edit-2
        14 days ago

        Yeah, but “some cases” is extremely vague. If it is indeed cached indefinitely under all circumstances I would expect changed passwords to never work at all.

        If it is just “some cases” it could be anything from the system using a stale cache just when it can not reach the online server (reasonable) over caches still being in some kind of TTL period to some sort of bug.

        • SL3wvmnas@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          4
          ·
          14 days ago

          In typical MS fashion this might be very hard to debug with the hundreds of interacting components./s

          In all seriousness they reviewed their internal docs not even the code (likely because it’s extremely complex) and said fixing this would brake existing functionality. I think “some cases” is doing heavy lifting for “we know many cases, but won’t tell the bad guys out there”.

      • SL3wvmnas@discuss.tchncs.de
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        14 days ago

        “We originally looked at a code change for this issue, but after further review of design documentation, changes to code could break compatibility with functionality used by many applications.”

        Year of the Linux (Server|Desktop). Seriously. If you are in IT pls look into this (and hide your RDP server behind some VPN. No not MS RDP Gateway.)

        • the_crotch@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          7
          ·
          14 days ago

          hide your RDP server behind some VPN

          Anyone who isn’t doing this already is dumb. Same goes for exposing ssh publicly. I don’t care that you’re using a cert to log in, if there’s a 0 day in the openssh server you’re boned

          • Max@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            13 days ago

            If there’s a 0 day in the VPN software then I’m also probably boned. The chances of that seem on par with the likelihood of an openssh vulnerability? I feel like vpns are useful to secure services without good authentication, but their use in front of an openssh server has never made much sense to me.

            • the_crotch@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              3
              ·
              edit-2
              13 days ago

              They would have to breach the vpn and then also breach the other services once they’re on your network. It’s another layer of protection.