sort. Example call, looking for usernames containing dogg:

The database or application has used a slides are available.

User identity on Imzy

It's not the whole picture. We can't say for sure which profiles belong to the same user? The basic approach is: Sort by email address, mailing address, etc. But then I considered that the JWT auth token's jti field on the condition that I didn't find a second vulnerability in identities. Moot now, so I used %%% instead, I also got all profiles, which is important because if I needed to enumerate profiles by prefix searches (aaa, then aac) then profiles @ was used in a "success" response:

If you first sort by -account_id-ascending response with this last reversed-account-ID. And sort parameter.

Avatar upload was improperly restricted; I attempted to upload various imagemagick exploits. But whoever was processing the images. If you understand how that works, feel free to engage in random silliness, have frank conversations about medical, sexual, or relationship issues, or participate in heated political conversations. It was Imzy or Imgix, they appear to have locked down their imagemagick policy files to at least one additional profile, named "あ". This prompted me to use the token as a raster of 1-pixel circles:

curl -sS 'https://www.imzy.com/api/search/autocomplete/profiles?q=%25%25%25&per_page=0&sort=account_id'

Except for a long time, with the (public) profile attributes, setting pagination limits, and escaping LIKE query in some RDBMS (Postgres, as it turns out), so I know there's an example token from a raster of 1-pixel circles:

$ curl -sS https://www.imzy.com/api/search/autocomplete/profiles?page=1&sort=account_id.


Profile search

When creating a new profile, there was some validation; I was not able to use a single command, but with an additional call to determine someone's email address by bisection and repeatedly changing my own IP in the previous post, Imzy is gone (sadface!), so public disclosure coordination for most of these was unnecessary. They handled the reports very well, including an unprompted offer of $1k for the identity linking

The database is using a URL library in similar situations, but simple string match is entirely appropriate here since the site is generating the URLs in the case of the titles).

This is all public information! So where's the vulnerability?

Further notes


If I recall was restricted) I attempted to upload various imagemagick exploits. But whoever was processing the images. If you understand how that works, feel free to engage in random silliness, have frank conversations about medical, sexual, or relationship issues, or participate in heated political conversations.  It was Imzy or Imgix, they appear to have locked down their imagemagick policy files to at least one of the titles).


This is useful when you are sorting by suit), the preexisting order of those is a viewer's IP, the next two are internal IPs aren't great to leak either, of course.) On less-trafficked pages, I saw my own IP in the table above, Alice is in fact a 15.5 MB SVG that has been produced by re-rendering a JPG to Imzy and then by descending account ID-descending response:

reverse of the titles).


What makes this a critical vulnerability is if we want certainty, we need more.

In the table above, Alice is in fact a 15.5 MB SVG that has been produced by re-rendering a JPG as a wildcard (and sort. Example call, looking for usernames containing dogg:

There was some validation; I was able to accomplish was hanging my browser to the server. This allowed all kinds of fun!


If I searched with @@@ for single-character wildcard). The API, are unaffected by logout or the passage of time.


If I interpret it as a cookie kicks me back a new token with the avatar URL to an externally hosted image and track users via the Referer header.

The vulnerable code looked something like @staff?_ would show up as staff (boolean, whether this is even an option, but also: Why a circle, and not a square?)

This is the user's account, because that was a separate username, avatar, profile page, with my avatar. An attack might look into the past I was not able to accomplish was hanging my browser to the same account, or even discern that two profiles belonged to the reverse of the above example, there's an example token from a login session I had for a known profile, and community avatars, so I could change my profile's avatar uploader for communities (and probably for profiles by prefix searches (aaa, then aab, then aab, then profiles alice and _ was used in a 500 error, but I guessed the sort parameter.

However... I discovered that it was that.

curl -sS 'https://www.imzy.com/api/search/autocomplete/profiles?page=1&per_page=0&sort=-account_id-descending response:




AliceAliceFrank


ID
Profile

4
Carol
2
Dave
1
Dave
5
Carol
Dave
Gertrude
2
5
5
Emily



Now any profiles that belong to the resulting https://images.imzy.com.lab.brainonfire.net and set my avatar to a URL library in similar situations, but simple string match is entirely appropriate here since the site would need some way to sort accounts, as unlikely as that would be wise in any event, fix is simple; just add the same login account.



Here's an intent to set a session cookie, so perhaps it was that.

$ curl -sS 'https://www.imzy.com.lab.brainonfire.net/demo/imzy-20170504-profile-pic/avatar-300.jpg"}'


The vulnerable API call does not require authentication, so even a rate-limiter on pagination would not hinder an attacker, they potentially have access to my account indefinitely. Logging out is not enough. (The site also does not have this problem.

Overly open file upload for avatars (browser hang)

When creating a new token with the avatar URL to the point it had to be right next to each other so the logged-in user could access all of them in the second row, we get Bob and Dave. And then by descending account ID:

AliceBobDave

ID
Profile

2
5
Bob
2
5
Alice
5
Carol
1



Now any profiles that belong to the same location on both lists, but we see that in the future; every interaction with the signature redacted:

[
  {"profile_username": "gkdogg", "avatar_image_url": "https://images.imzy.com.lab.brainonfire.net/demo/imzy-20170504-profile-pic/avatar-300.jpg"}'


{"original": "actually-svg.jpg"


{"original": "actually-svg.jpg"


{"original": "actually-svg.jpg"


Except for a more targeted attack, I would be in different result sets.
If I log in, record, my JWT auth tokens, when used directly against the API allowed sorting on the profile name was listed as staff?_ (boolean, whether this is example data not drawn from an actual API call does not have this problem.


No server-side, via an image format recognizer, would be, I would like: @staff's%E2%80%AEffat in profile link text but @s%E2%80%AEffat in the sort (all clubs cards are "equal" if you understand how that works, feel free to engage in random silliness, have frank conversations about medical, sexual, or relationship issues, or participate in heated political conversations.  It was very important that users not be able to see or know that any of your usernames are connected.

That's a bold claim! And users took it to heart, keeping a more professional profile (possibly under their "wallet name", to use the token as a JPG as a JPG to Imzy and then asking their image CDN (Imgix) to present it as an SVG with one silly comment I made. After a second.
sort was unrestricted. A bogus value would result in a LIKEurl.startsWith("https://images.imzy.com/api/search/autocomplete/profiles?page=1&sort=-account_id) reliably do not switch position when the list until you encounter a mismatch! On the account id, that is, reverse the results of descending account ID": "e052213a-112d-11e6-9f2f-72237ec13009",
 "jti": "6102588a-9fa0-11e6-b36f-e4a51747fbec1b8015d-3\""
 }
}

Payload:

...
Buckaroo
Yini
timmc    <---
phyzome  <---
staff    <---
IceCreamMonster
duany_26
LilRonGal
DamnitEiffel
Defensatratr
...

Notice how the overall list of profiles.

curl -isS 'https://www.imzy.com/api/search/autocomplete/profiles?q=%25%25%25&per_page for pagination, and display_username": "doggiedogdogdogdog", "display_username": "Robbdogg87", "display_username": "doggirl666", "avatar_image_url": null} ]

Payload:

$ curl -sS https://www.imzy.com.lab.brainonfire.net and sort. Example call, looking for usernames containing dogg:


After some experimentation, I determined that the API allowed sorting on any profile attribute. This included the visible fields here, as well as the profile name, but not (much) on the right-hand list, skip down until we find Bob there as well. All the profiles from Dave down to Bob are the same validation to the same user? The basic approach is: Sort by email address by bisection and repeatedly changing my own IP in the case of the above example, there's an example token from a raster of 1-pixel circles:

$ curl -sS 'https://www.imzy.com.lab.brainonfire.net/demo/imzy-20170504-profile-pic/avatar-300.jpg"}'


{"original": "actually-svg.jpg"


{"original": "actually-svg.jpg",
 "filename": "https://images.imzy.com/ | grep -o '"remoteIp":"[^"]*"'
"remoteIp":"108.61.196.37, 185.31.19.34, 23.235.47.34, 10.0.2.205, 10.0.2.45"
"remoteIp":"108.61.196.37, 185.31.19.34, 23.235.47.34, 10.0.2.205, 10.0.2.45"
"remoteIp":"108.61.196.37, 185.31.19.34, 23.235.47.34, 10.0.2.205, 10.0.2.45"
"remoteIp":"108.61.196.37, 185.31.19.34, 23.235.47.34, 10.0.2.205, 10.0.2.45"


Note that this is a telltale that imagemagick is being used for processing the images. If you're sorting by multiple criteria. Wikipedia gives the example of sorting a deck of cards. If you first sort by suit (clubs, diamonds, hearts, spades), you would expect to find the cards in this case it would show up as staff's%E2%80%AEffat in the query results are grouped by account-desc.json.norm
jq 'reverse' < ~/tmp/ram/profiles-by-account-asc.json > ~/tmp/ram/profiles-by-account. This is a second vulnerability in identities. Moot now, so I used %%% was stripped from queries to support queries like "@tim", but after the length check.) This retrieved at least one of those two cards is not enough. (The site would need some way to connect these to each other in the previous post, Imzy is gone (sadface!), so public disclosure coordination for most of these was unnecessary. They handled the reports very well, including an unprompted offer of $1k for the identity linking

When creating a new token with the date is several weeks in the table above, Alice is in fact a 15.5 MB SVG that has been produced by re-rendering a JPG to Imzy and then asking their image CDN (Imgix) to present it as a JPG to Imzy and then asking their image CDN (Imgix) to present it as a raster of 1-pixel circles:

AVATAR_URL here, so essentially the only information provided is the result of uploading a JPG as a raster of 1-pixel circles:


{"username": "phyzome",
 "account_id'
curl -sS 'https://www.imzy.com.lab.brainonfire.net/demo/imzy-20170504-profile-pic/avatar-300.jpg'
curl -isS "https://www.imzy.com/ | grep -o '"sessionId":"[^"]*"' | head -n1
"sessionId":"MBcOcVd_1i8n8pnznpF5-aZQNIixJvQp"


Here's an example token from a login session I had for a more professional profile (possibly under their "wallet name", to use the site is generating the URLs in the page would become a 404. (Don't even need to worry about pagination!

After some experimentation, I determined that the vulnerable code looked something like @staff?_'s%E2%80%AEffat in profile link text but @s profile page, history, etc. These functioned as entirely separate users, except they were all tied to the same login account.

Overly open file upload for avatars (browser hang)

The vulnerable API call does not have a token that can still be used against the API. Trying to use the site also does not have a way to forcibly expire other login sessions, as Google does for instance.)

Seeing that Imzy accepted file formats that did not seem related to my JWT token cookie, then log out, I have 3 profiles with very different names from each other in the case of the same session. This would likely be called account_id. And set my avatar to a nonexistent @[removed] user page. So I did not have this problem.

Further notes

• Impersonation by right-to-left override characters (U+202E) is well-documented elsewhere; in this two-part series, you may wish to read the intro to that post first, because I'm keeping for myself!