5 ms·

... ok, I can see how the host MAC segment could be an issue if the UUID is generated "client" side and distributed.. What's the risk (in terms of "pwning") wh

... ok, I can see how the host MAC segment could be an issue if the UUID is generated "client" side and distributed.. What's the risk (in terms of "pwning") when the UUID is generated on a server?

michaelt 3y ago
Step 1: Generate UUIDs using a highly predictable pattern Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf and assuming nobody will be able to download it without knowing the UUID Step 3: Attacker predicts the UUID and downloads the private file. Obviously the real solution here is to not use UUIDs as security keys - but dumbasses shoot towards their feet all the time, and UUIDv4 makes them hit less often.
- stephenr 3y ago
  By that logic serial-type ids are unsafe for use too, and much more vulnerable. I was kind of expecting some claim that actually exploits the inclusion of a hardware identifier, rather than "don't use predictable numbers as secrets".
  - bhaak 3y ago
    > By that logic serial-type ids are unsafe for use too, and much more vulnerable. Yes, they are. Still, it's not good security advice to point towards an other thing and say "this is even worse".
    - stephenr 3y ago
      The point I was making is that the claimed "exploit" is completely outside the bounds of what a reasonable person would do. It's like complaining that a garden hose can be used to fill a car with carbon dioxide so we should recommend against using hoses in gardens.
      - bhaak 3y ago
        That's often an issue that people think attackers wouldn't got all the way because it's too cumbersome. "Reasonable" has a very imprecise definition. > On a recent Code Assisted Penetration Test (CAPT) our team identified a vulnerability in a client's web application which allowed the consultant to bypass authentication and take over legitimate user accounts. The issue stemmed from the use of UUID version 1 in password reset tokens instead of the secure version 4 counterpart. https://realizesec.com/blog/sandwich-attacks-exploiting-uuid-v1 https://realizesec.com/blog/sandwich-attacks-exploiting-uuid...
        stephenr 3y ago
        Ok, well for this case specifically let's just assume that "reasonable" means "knows a UUIDv1 isn't random, and shouldn't be used as if it were". You can probably sub in "suitably experienced" for "reasonable" if it reads better.
  - smallnamespace 3y ago
    Of course serial IDs are unsafe, but it's (presumably) obvious to most implementers. Look up the v1 spec. Essentially the entire ID space is timestamp + UUID, both of which are easily guessable. The amount of entropy matters, and v1 has little of it. The danger here is that a UUID seems random when it really isn't.
    - stephenr 3y ago
      I'm aware of the contents of UUIDs, I just thought we were somehow past absolute bottom of the barrel "well this might be misused by someone who clearly has no idea what they're doing" before claiming things have caused "pwning". Entering URLs wrong can also cause phishing breaches, that doesn't mean we stop using URLs does it?
      - smallnamespace 3y ago
        Everyone, even experienced engineers can make mistakes. Calling that 'bottom of the barrel' isn't helpful. Especially in a larger team you can't expect everyone to know fine details of every other part of the system. If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects.
        stephenr 3y ago
        > If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. Either we have very different ideas of what "mostly" means or you don't know what the different versions of UUID include as well as you think you do. If we're considering the 5 published versions: 1 is built from random data; 2 are built from time & host data; and 2 are built from a namespace and a "name". If we consider the 3 proposed additional versions: 1 is built from time & host; 1 is built from time & random data; and 1 is built from custom data. So I personally wouldn't consider "most" to mean either 1 of 5 (20%) nor 2 of 7 (28.6%). > I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. I would expect someone who is writing software and encounters UUIDs to take the few minutes needed to understand the basics of what goes into the different versions, ensure they're being used correctly. > If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects. They don't need to "hold the entire system in their head". They just need to (a) have the most basic understanding of what a UUID contains, and then (b) use it appropriately.
  - lazide 3y ago
    Incrementing serial ids in URLs to find additional information is a super classic ‘easy’ compromise. Happens all the time, and has for decades.

... ok, I can see how the host MAC segment could be an issue if the UUID is generated "client" side and distributed.. What's the risk (in terms of "pwning") when the UUID is generated on a server?

michaelt 3y ago

Step 1: Generate UUIDs using a highly predictable pattern Step 2: Use the UUID as a security key - like saving a private file at files.example.com/12345678-1234-5678-1234-123456781234/private-file.pdf and assuming nobody will be able to download it without knowing the UUID Step 3: Attacker predicts the UUID and downloads the private file. Obviously the real solution here is to not use UUIDs as security keys - but dumbasses shoot towards their feet all the time, and UUIDv4 makes them hit less often.

stephenr 3y ago
By that logic serial-type ids are unsafe for use too, and much more vulnerable. I was kind of expecting some claim that actually exploits the inclusion of a hardware identifier, rather than "don't use predictable numbers as secrets".
- bhaak 3y ago
  > By that logic serial-type ids are unsafe for use too, and much more vulnerable. Yes, they are. Still, it's not good security advice to point towards an other thing and say "this is even worse".
  - stephenr 3y ago
    The point I was making is that the claimed "exploit" is completely outside the bounds of what a reasonable person would do. It's like complaining that a garden hose can be used to fill a car with carbon dioxide so we should recommend against using hoses in gardens.
    - bhaak 3y ago
      That's often an issue that people think attackers wouldn't got all the way because it's too cumbersome. "Reasonable" has a very imprecise definition. > On a recent Code Assisted Penetration Test (CAPT) our team identified a vulnerability in a client's web application which allowed the consultant to bypass authentication and take over legitimate user accounts. The issue stemmed from the use of UUID version 1 in password reset tokens instead of the secure version 4 counterpart. https://realizesec.com/blog/sandwich-attacks-exploiting-uuid-v1 https://realizesec.com/blog/sandwich-attacks-exploiting-uuid...
      - stephenr 3y ago
        Ok, well for this case specifically let's just assume that "reasonable" means "knows a UUIDv1 isn't random, and shouldn't be used as if it were". You can probably sub in "suitably experienced" for "reasonable" if it reads better.
- smallnamespace 3y ago
  Of course serial IDs are unsafe, but it's (presumably) obvious to most implementers. Look up the v1 spec. Essentially the entire ID space is timestamp + UUID, both of which are easily guessable. The amount of entropy matters, and v1 has little of it. The danger here is that a UUID seems random when it really isn't.
  - stephenr 3y ago
    I'm aware of the contents of UUIDs, I just thought we were somehow past absolute bottom of the barrel "well this might be misused by someone who clearly has no idea what they're doing" before claiming things have caused "pwning". Entering URLs wrong can also cause phishing breaches, that doesn't mean we stop using URLs does it?
    - smallnamespace 3y ago
      Everyone, even experienced engineers can make mistakes. Calling that 'bottom of the barrel' isn't helpful. Especially in a larger team you can't expect everyone to know fine details of every other part of the system. If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects.
      - stephenr 3y ago
        > If you look up UUIDs you will (correctly) get the impression that they're mostly random, except some types aren't. Either we have very different ideas of what "mostly" means or you don't know what the different versions of UUID include as well as you think you do. If we're considering the 5 published versions: 1 is built from random data; 2 are built from time & host data; and 2 are built from a namespace and a "name". If we consider the 3 proposed additional versions: 1 is built from time & host; 1 is built from time & random data; and 1 is built from custom data. So I personally wouldn't consider "most" to mean either 1 of 5 (20%) nor 2 of 7 (28.6%). > I would not expect every engineer to know to inspect the UUID and figure out its type and to know that this could have real consequences for guessability by external actors. I would expect someone who is writing software and encounters UUIDs to take the few minutes needed to understand the basics of what goes into the different versions, ensure they're being used correctly. > If your team is small enough that everyone can hold the entire system in their head at once, that's great, but that excludes many real world projects. They don't need to "hold the entire system in their head". They just need to (a) have the most basic understanding of what a UUID contains, and then (b) use it appropriately.
- lazide 3y ago
  Incrementing serial ids in URLs to find additional information is a super classic ‘easy’ compromise. Happens all the time, and has for decades.