I'm the developer of the ExchangeRate-API.com service.

Obviously it's upsetting to have our API used by a scammer, but our service couldn't have been involved in this hack beyond fetching a JSON-formatted response of up-to-date exchange rates because that's the only functionality our service/domain provides.

My guess is that the scammer implemented a call to our API to fetch up-to-date exchange rates in order to make their fake wallet seem more plausible & real. Interestingly my API doesn't even support any exchange rates involving cryptocurrencies and so the scammer would have had to additionally integrate with a different API to get something like the up-to-date exchange rate between BTC and USD.

The API is a very simple service - it's just a few endpoints that supply JSON formatted exchange rates over HTTPS. Anyone with an email address can sign up to use the service for free and there are even some totally "open access" endpoints that don't require any authentication. One of these has been used in the GNU `units` converter software for a while.

With regard to proving it's a legitimate service, this is the point where I wish I had made more progress with the landing page update that emphasizes social proof I've been working on recently! The API is used by ICs/teams at hundreds of recognizable companies. There are tens of thousands of free users including some that have used the API consistently for free for over a decade. I guess you could check many instances of the service being archived on the wayback machine? https://web.archive.org/web/20240000000000*/https://www.exch... I'll definitely admit the domain does look a bit odd but back in 2010 when registering it the "Exact Match Domain" bonus was a big factor for SEO. The site has been a top 3 Google result for "exchange rate api" pretty consistently - presumably also how the scammer ended up using the service.

I've used Cloudflare since approx. 2019 and their "cloudflared" tunnel infrastructure since approx. 2021 to secure servers against DDoS.

I'll contact popey to see if we can get more details on the exact path/request they saw being made to our domain and if that leads to any further information or logging from our side.

I think what parent is saying is the DNS request could have gone to your domain but the TLS handshake and HTTP POST could have contained another domain, because your site and the bad actors server could both be behind the Cloudflare CDN, which would handle both transparently.

No, I mean the initial HTTP request can go to some other site, which can then issue a redirect to anywhere it pleases (i.e. to exchangerate-api.com).

If you're running a malicious service and you want to throw people off the scent, one common strategy is to redirect to random legitimate services so that anyone investigating thinks you're part of the other service.

Such a redirect would be visible in wireshark.

Sure, there was a bit of guesswork on my part. I could analyse the traffic in more detail, but when I wrote this all up, it was Sunday evening, and I wanted to do the minimum analysis to get a response to the unlucky rube.

I still have the snap, and could test further, but I suspect the endpoint linode boxes will disappear and popup somewhere else sometime.

What I mean was your wording implied that exchangerate-api.com was somehow implicated, but in my opinion that is too much of a leap to make.

The only thing implicating that site is a redirect that you got from a site that you know you don't trust.

Yes, I understood your point.

I further thought about your feedback and the comments from the owner of exchangerate-API and have removed that section from the blog and mentioned it in a follow-up post.

I appreciate your comments, as they made me think more about that topic.

Great, thanks :)

Another way IPv6 could make things better: no need to point multiple domains at the same IP address, so you could have a one-to-one relationship between domain and address and prevent shady things from hiding behind legit things.

And, sadly, make it easier for repressive regimes like China and Iran to block access to websites that are currently accessible thanks to CDNs' reuse of IP addresses.