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.

    • AernaLingus [any]@hexbear.netEnglish
      4·
      3 days ago

      Based on the vague description they gave, I wouldn’t be surprised if it were a simple IDOR attack—it was my first guess before I even read the article. IDOR is something so basic that it’s something moderately interested tech savvy people figure out intuitively without ever trying to learn about hacking…literally day 1 of security class shit. Hope we’ll get a more detailed exploit write-up at some point.

      • 87Six@lemmy.zipEnglish
        2·
        2 days ago

        TL; DR for IDOR for the rest of you: it’s basically based on security through obscurity.

      • 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·
              2 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

  • sad_detective_man@sopuli.xyzEnglish
    2·
    3 days ago

    oh daaammn. literally just found out this exists and then they go all perforated. that would be some of the worst personal data to lose