Revolut sending data to facebook?


#1

I monitor my home network in detail so i can see what every device is doing and who they are talking to, this is when i noticed when i open my revolut account on my phone i can see data being sent to graph.facebook.com. Why is this data being sent to facebook? I personally don’t use facebook and do not want my data in their domain!


#2

Where exactly did you monitor this? On the device or externally? Can you decisively assign that connection to the Revolut application?


#3

i isolated the device on my network and implemented ssl stripping to see what was happening, it is indeed the revolut app.


#4

I am not sure what you mean by “isolate” and “SSL stripping” but if you dont monitor it on the device you cant tell with absolute certainty.


#5

then i recommend you read:https://comodosslstore.com/blog/what-is-ssl-stripping-beginners-guide-to-ssl-strip-attacks.html


#6

If you really managed to pull that off, that would be of way greater concern than any contact to whatever host.


#7

not really something to be concerned with, revolut security is fine, i have direct access to the device, you can’t repeat this on a device you don’t have direct access to, at least not easily!


#8

It does not really matter, unless you severely modified the application or the underlying system you should not have access to any TLS packets.

Anyhow, back on topic, can you determine on the device itself that Revolut’s PID is opening a connection to that host?


#9

the packets contain information from revolut wrapped in the data being sent to facebook.


#10

I didnt ask about the content (which you still should not be able to read for aforementioned reasons) but about the origin.

Can you point the origin of the connection to the PID of Revolut?


#11

i don’t think you fully understand, its the revolut api that’s calling this action! Knowing the PID is not required here!
In the data its clear this is the revolut app


#12

You cant know any of that, because these connections should be properly safeguarded. Hence the only bit you can tell is if the connection in question originated from Revolut’s PID.

On the other hand if you are truly claiming you managed to peek into the packets, then you managed to break TLS - and that is much more worrisome.


#13

SSL/TLS stripping is nothing that uncommon, it’s advertised as a selling point on loads of enterprise-grade web proxies and gateways!

The PID is irrelevant if the Facebook Graph request includes Revolut references


#14

Alright, lets try another approach.

Can you exactly describe the steps you took to arrive at the point where you can claim that the connection to Facebook originates from Revolut’s application and that it contains sensitive data?


#15

i just explained it to you.


#16

Alright, this doesnt go anywhere.


#17

First of all, there is nothing new about SSL/TLS stripping. It is a very common feature in a lot of enterprise kit. It doesn’t mean that you have “broken TLS”, and it does not require any reverse-engineering of the application or the operating system.

It just means that you terminate the Revolut TLS connection on your proxy/gateway and you present a new TLS connection to the mobile phone. If the gateway presents a certificate to the phone that you have manually installed/trusted, then voila, it works.

(Incidentally, the way to avoid this is to implement SSL/TLS certificate pinning. Revolut has not done this, which is why the app ignores the new certificate and establishes the connection anyway.)

Second, you don’t need to know the source PID on the device. The source PID actually isn’t going to tell you that much! Instead, what you can see from the traffic dump is that there are calls to api.revolut.com which include, amongst other things, references to graph.facebook.com, a whole bunch of fb_ identifiers, advertising IDs and even details including the device model and identity. This is all in the same series of requests from the same source, therefore they are coming from the same PID.

Unless you actually have something useful to add, I’m not entirely sure why we are going around in circles about this.

The evidence clearly shows some correlation between the Facebook Graph API and Revolut. This is not outlined in the General Terms of Service, nor in the Cardholder Terms. The Privacy Policy mentions “If you allow us to, we will collect friends lists from Facebook”, except in this instance, consent was never actually requested or given, and still Revolut is communicating with Facebook.

If you want to try and prove this for yourself, then look into mitmproxy or some similar tool. It’s not rocket science.

In the meantime, it seems obvious that Revolut should a) stop shipping information to Facebook when the user did not actually consent to it, and b) should use certificate pinning, and perhaps even HSTS, to prevent this kind of MITM on connections used for sensitive banking data.


#18

Could you please be just a tad more clear what you are referring to? You dont terminate a connection and “present” a new connection. What you could do is reroute the connection and sneak a self-signed certificate matching that host into the connection, after you have managed to get Revolut to trust that certificate or one in its chain.

As the OP hasnt been clear at all as to what he did, we can only speculate at this point.

Quite the contrary, if the PID in question initiated the connection we could say with confidence that it is communicating with the host in question.

I asked for clarification, which neither of you could provide so far.

Evidence? Which evidence? So far we only have wild allegations.


#19

Actually that is exactly what proxies do. The client, in this case, establishes a TLS session with the proxy, using a custom certificate that you generate/trust. The proxy then connects upstream to Revolut, negotiating it’s own TLS session, against the Revolut certificate. The proxy terminates the Revolut connection, because the proxy initiated it.

This is exactly the point. The Revolut app is not checking the certificate. There is no seemingly no certificate pinning implemented to verify that the certificate it receives is actually the one from Revolut. In this instance, the proxy certificate is trusted by the OS because the user configured it to do so, and therefore Revolut implicitly trusts it too. That’s what makes this MITM possible.

I don’t get what point you are trying to make. We already know the Revolut app initiated the connection by correlation with the Revolut API. Knowing the process ID of the initiator is not going to tell us anything we do not already know. We know that the connection came from the Revolut app.

I’m not really sure how I can give much more clarification:

  • Set up an MITM proxy between the phone and Revolut
  • Open the Revolut app
  • Watch as Revolut API and Facebook Graph API appear in the same set of connections

How much simpler can we make this?

Evidence in the connection logs produced by the MITM proxy. I am looking at them right now. Literally. Right in front of me. If I didn’t fear accidentally posting some sensitive session IDs or really upsetting someone at Revolut, I would gladly see it posted here.


#20

I am pretty sure it is. The check is not against the certificate itself though, but checks whether the certificate has been signed by one of the trusted root certificates.

I am not sure what you are referring to here. How does the Revolut API correlate to any TCP connections to graph.facebook.com?

You forgot the important bit that you need to modify the set of certificates Revolut is trusting :wink:

There will be quite a few connections, where do you draw the connection between Revolut and Facebook from?

I dont dispute that you have such connections, I wonder how you can be certain they originate from the same application.