9

I recently received an email containing the following chunk (don't click!):

<A HrEf="/@/0X0a290d92b/UALI=28389-UI=176738575-OI=279-ONI=5477-SI=0-CI=0-BI=577-II=27913-IDSP=1-KLEM=11-TIE=A-IDE=276135-MID=572-FID=0-DIOM=0" sTyLe=color:#000;font-size:10px;font-family:arial;>
<span>UNS</span></a>

Here is a link to the raw email: https://gist.github.com/anonymous/16963a230cab0a3a1bcfc81209f297f1

As far as I know, /@ is not a valid url. How is my browser able to resolve it to a site?

Neal Fultz
  • 9,282
  • 1
  • 39
  • 60
  • 1
    [`@` is allowed in URL paths](http://stackoverflow.com/a/19737890/1591669), so `/@` is a valid relative URL. – unor Apr 17 '16 at 14:23
  • Relative to what? The link is in an email. `https://mail.google.com/@/0X0a290d92b/` doesn't seem to resolve to anything. – Neal Fultz Apr 17 '16 at 15:20
  • What browser or Mail-Client are you using? Maybe it is targeting a specific implementation. IE11, Edge and Vivaldi couldn't open "/@/0X0a290d92b" – Sascha Sep 06 '16 at 13:53
  • I use Gmail on a Chromebook. – Neal Fultz Sep 06 '16 at 17:10
  • 1
    You might want to inspect the actual link, that is created by gmail. a simple ``href="http://example.com`` will be forwarded to google and immediately redirected. ``example.com`` – Sascha Sep 07 '16 at 07:52

2 Answers2

2

As it was already mentioned in comments @ is allowed in URL paths.

Regarding URL resolving. I guess that attacker uses <base> tag to explicitly set default URL for all relative links in email body and hopes that your browser/email client will resolve it for you.

UPDATE

The original guess might be correct since it is not supported by majority of mail clients

After a bit of investigation I realized that 0x0A290D92B is actually is hex-encoded IPv4 address 162.144.217.43. The only thing which I do not yet understood is how it is supposed to be transformed to http(s)://0x0A290D92B in browser. It seems like the attacker is targeting specific browser/mail client behavior.

Community
  • 1
  • 1
vsminkov
  • 10,912
  • 2
  • 38
  • 50
0

It's treating everything before the @ as auth information that gets passed to the URL. The "real" url starts after the @, which is the encoded IP address that vsminkov mentioned. So the leading forward slash is discarded.

An easier to read example: http://username:password@example.com/

It's all just layers of obfuscation.

Here's an interesting link that goes over it in more detail:

http://www.pc-help.org/obscure.htm

and here's RFC 2396 describing that part of the URL:

URL schemes that involve the direct use of an IP-based protocol to a specified server on the Internet use a common syntax for the server component of the URI's scheme-specific data:

 <userinfo>@<host>:<port>

where may consist of a user name and, optionally, scheme- specific information about how to gain authorization to access the server. The parts "@" and ":" may be omitted.

 server        = [ [ userinfo "@" ] hostport ]

The user information, if present, is followed by a commercial at-sign "@".

 userinfo      = *( unreserved | escaped |
                     ";" | ":" | "&" | "=" | "+" | "$" | "," )
Jeff Bobish
  • 596
  • 4
  • 6
  • Maybe if it started with an `@`, but a `/@` should be an absolute path because it starts with a slash and the protocol is omitted. – Neal Fultz Sep 07 '16 at 14:58
  • When the url is parsed everything before the @ is pulled out, put into a request header field, and sent to the url starting after the @. So the url that gets resolved will be /0X0a290d92b... It extracts the auth information (in this case just a backslash) before trying to resolve the URL. I'll try to find a good reference and post it here. – Jeff Bobish Sep 07 '16 at 15:09
  • Added some more info to the answer above from an RFC. The forward slash is a reserved character so it shouldn't be valid in though. It's possible it just causes the auth data to be tossed out on certain browsers (either now or in the past). – Jeff Bobish Sep 07 '16 at 15:40
  • also another question about slashes, with `/@/`, does that imply the host is localhost? When I just type `/@/` into the browser bar, it takes me to `file:///@/` – Neal Fultz Sep 07 '16 at 16:14
  • 1
    Hmm so maybe the initial slash is not considered part of the auth because it's reserved and just the ampersand is removed, making the URL start with //0x0A290D92B. That seems like it would work to redirect the user to the malicious site. – Jeff Bobish Sep 07 '16 at 18:14
  • @JeffBobish yeah, but majority of browsers does not throw `@` away. So the riddle is what is the target audience of this attack – vsminkov Sep 08 '16 at 10:10
  • No I think they all do, they either try to process it as auth information or they just ignore it. That part of the URL has been around for ages. If used elsewhere in the URL it's a valid character, if used at the beginning it is considered an auth field (whether that field is used by the browser or not). Click on this, for example: https://user:password@www.google.com – Jeff Bobish Sep 08 '16 at 13:25