UUID corruption in emailed links?

nikitaavvakumov

Hi all,

I’m hoping for some insight into a strange issue.

Our app’s Ecto repo is configured to use as primary keys UUIDs in the standard 8-4-4-4-12 format. The app periodically sends out emails with links to resources, such as /orders/<order_uuid>. Emails are generated using Bamboo with EEx templates for both HTML & plain text and sent via SendGrid.

In over 99% of cases, everything appears to work as intended. However, the app occasionally logs an Ecto.Query.CastError error after someone visits a URL that contains an odd string in place of the UUID. Here are a few typical examples: “NjBlNjhlZW”, “MjA1MDNhZT”, “NmMzYzhiZT”, “ZDQzNDYwZj” - 10 characters, upper- and lower-case letters, rarely containing a number. Given their format, these are clearly not carelessly copy-pasted UUID fragments but something else entirely.

None of the supposedly affected users have contacted us, so we can’t connect these strings to UUIDs that should have been in those links.

Is it possible that these links are actually generated by the app when it interpolates UUIDs into the URLs? Could it have something to do with character encoding used by certain email clients? Do these 10-character strings ring any bells at all?

Any help or hints towards a possible explanation will be much appreciated.

5 comments

#uuid

0 1268 5

2019-03-05 19:50:17 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

easco

I note that if you take such a string and decode it as a base64 encoded value you get back something that is a valid hexadecimal number. For example:

iex(7)> Base.decode64("ZDQzNDYwZj", padding: false)
{:ok, "d43460f"}

But they each seem to decode to a seven digit Hex number so I’m not sure how that might relate to a UUID.

At work we have a front-end on our mail system that rewrites the URLs on incoming messages as a security measure against bogus URLS (I think it’s this - https://www.proofpoint.com/us). Could it be that some of your users are using something similar which looks for “high entropy” hexadecimal strings and tries to protect the user that way?

Post #1

sribe

I see similar requests all the time, in bursts, and I do NOT have inbound links that use UUIDs. I have assumed that they are some kind of probe or attack.

Post #2

nikitaavvakumov

The encoded Hex could be the leading 7 digits of a UUID, but it’s of course very unlikely that on multiple occasions people made the mistake of copy-pasting only 7 digits of a complete UUID.

On the other hand, the protection measure you mention could be the culprit. Many of our users are from large institutions or government agencies, so it’s feasible that something like this is in use. I’ll see if their docs describbe mangling of URLs in a way that could explain what we’re seeing.

Thanks for your help!

Post #3

nikitaavvakumov

Interesting - I briefly thought about these being attacks but then figured our small app wouldn’t be worthy of anyone’s attention

It seems that the probability of correctly guessing even a 10-character string is much too low for this to be a viable attack vector. Perhaps attackers are just looking at types of responses, something to suggest that an app might be vulnerable. If so, I wonder why the 10-character format.

Thanks for your input!

Post #4

sribe

I never looked into it further, I thought the particular codes might not be random, but might be some default code for some application. It hadn’t occurred to me that they might just be probes for response types.

Post #5

— All posts loaded —