Exclusive: Neon takes down app after exposing users' phone numbers, call recordings, and transcripts
techcrunch.com
Call recording app Neon was one of the top-ranked iPhone apps, but was pulled offline after a security bug allowed any logged-in user to access the call recordings and transcripts of any other user.

Call recording app Neon was one of the top-ranked iPhone apps, but was pulled offline after a security bug allowed any logged-in user to access the call recordings and transcripts of any other user.

  • Flyberius [comrade/them]@hexbear.netEnglish
    3·
    3 days ago

    Yeah that was my first guess. I’m a fucking idiot and even I implement some form of authorization check on my apps used by about ten people.

    A uuid isn’t enough.

    • dev_null@lemmy.mlEnglish
      2·
      3 days ago

      Can you give an example of how such an attack would work when using UUIDs? UUIDs can’t be feasibly brute forced. Unless of course you have a separate vulnerability that leaks them (like putting them in GET params).

      • Flyberius [comrade/them]@hexbear.netEnglish
        3·
        3 days ago

        Say for example you’re app provides sharing links or emails you links to documents. In that situation a user van easily leak these to other people.

        A uuid is not sufficiently secure on its own. You need to have permissions on your documents

        • dev_null@lemmy.mlEnglish
          1·
          3 days ago

          I guess my point is that, the root cause of an issue here is them being leaked. If you have an app that loads a time-limited UUID from an API with an authorized request, which is used for a “view document” button to download the content to show in-app, and the UUID never leaves the app outside of an HTTPS POST request, then there is no issue. It’s then effectively a temporary access token.

          Basically, if the UUID allows access without separate authorization, then it’s effectively a password and should be treated accordingly. And then when you leak that “password”, that’s the actual problem

          And what probably happens is people use them for authorization but don’t treat them as the sensitive credentials that they become

          • Flyberius [comrade/them]@hexbear.netEnglish
            2·
            2 days ago

            Yeah I get that that. I’ve made quite a few web apps and I’ve also used a lot of niche industry ones that have awful security, like the examples I have.

            Time sensitive/single use uuids are not the problem, it’s assuming that the uniqueness and hard to guessness of the uuid is good enough for security