4 ms·
> To narrow down the app, we decided to observe connections to the image from clients (phones) to our servers. We did this by opening the popular apps one-by-on
by oefrha 6y ago
> To narrow down the app, we decided to observe connections to the image from clients (phones) to our servers. We did this by opening the popular apps one-by-one and noting down the time. After doing this for all the apps, we then ran this query in Hive: SELECT * FROM wmf.webrequest WHERE year=2021 AND month=2 AND day=9 AND parse_media_file_url(uri_path).base_name='/wikipedia/commons/1/16/AsterNovi-belgii-flower-1mb.jpg' AND webrequest_source='upload' AND uri_host = 'upload.wikimedia.org' AND user_agent='-' AND ip=<IP>;
> We then found the specific app that was making the request by matching the time when it was opened and the time image was requested from our servers, restricting the results to the User-Agent '-' and from the IP we tested.
Unless I missed something, running mitmproxy/Charles etc. in front of the phone would have been way easier than querying the entirety of Wikimedia server logs and trying to match IP & timing windows.
- simonh 6y agoIf they have the logs in Elasticsearch or something similar it wouldn't be all that hard.
- Muley 6y agoCertificate pinning has made this a pain in the arse.
- oefrha 6y agoYou can only pin your own certificate, not someone else’s. In this case you probably don’t even need SSL proxying to pin down the culprit, as I dare say not many apps connect to wikimedia on startup. You do need SSL proxying to be sure though.
- zwily 6y agoThe app may not load at all with mitmproxy if it has pinned its server cert though.
- oefrha 6y agoNo, you can selectively decrypt HTTPS requests for only some domains, and act as passthrough for others.
- ohgodplsno 6y agoNope. Starting from Android 10, unless an app has explicitly allowed user certificates (and no-one reasonably does, it's all behind a <debug-overrides> flag), you will not be able to MITM it. You may inject your certificates as much as you want. The only option is to have a device on which you have root access, which can push system certificates with adb. This pretty much only means the android emulator these days.
- oefrha 6y agoI don’t use Android so I wasn’t aware of that. But that’s a completely separate concern from cert pinning which does not hinder decrypting third party connections at all. Edit: after looking into this a bit, this is pretty nuts. How do enterprises inject certificates now?
- olliej 6y agore enterprise injection: They don't. It's been made increasingly clear that allowing certs roots to infect unrelated apps is a Bad Thing. MDM profiles etc presumably allow internal certs to be deployed, but those are hopefully limited as countries, let alone companies, have attempted to use those mechanisms to spy on millions of people.
- matheusmoreira 6y agoSo it's still possible on rooted devices? Seems good enough.
- sdfhbdf 6y agoJudging by the last point they seemed to want to doublecheck findings and confirm before throwing accusations around. > To further confirm this finding and to ensure that we had the correct app, we decided to log DNS queries from a phone by setting up a local resolver to capture DNS traffic. After pointing the phone towards it and launching the app, we noticed that it was indeed the one looking up upload.wikimedia.org on startup.
- antimius3000 6y agoThey didn't have 'the phone'. They only had traffic logs and had to find the app that matched a certain traffic pattern. And they did have 'something like ElasticSearch', it's all in the link, and even in this reply.
- abluecloud 6y agoI'm confused, it says > We did this by opening the popular apps one-by-one and noting down the time
- Rebelgecko 6y agoIt sounds like they did have the phone. Otherwise, Wikipedia is doing some sketchy stuff if they can figure out what apps are on my phone just from my IP address (IMO unlikely)
- detaro 6y agoI mean, the query doesn't look that complicated, and is something they'd obviously be already familiar with how to use - not that mitmproxy etc is particularly hard, but its another thing.
- jrochkind1 6y ago"way easier" depends on what you are familiar with. If you are familiar with "querying the entirety of wikimedia server logs" and do it all the time (the word "entirety" makes it seem like a big deal, but they clearly have tools meant for this that they use all the time)... and have never learned to use "mitmproxy/Charles etc" before.... It sounds like the "querying the entirety of the server logs" for this task probably took them tens of minutes at most. It would probably take me at least an hour or two to learn how to use "mitmproxy/Charles etc". So "way easier"? If you have to do this sort thing all the time, it might be useful to install and learn how to use "mitmproxy/Charles etc", why not? Certainly worth considering. But if the tools you have are working for you... I mean, what they did seems like it worked to get them the answer and was pretty efficient, using the toolset they use all the time for dealing with wikimedia ops... Seems like some good detective work to me. I get the desire to point out other tools that would be well-suited for this kind of task, but why the need to point it out as if they did something wrong or not "way easier"? Sounds like what they did was pretty easy for them, and they didn't need to learn new tools to make it "way easier". I enjoyed hearing about how they tracked this down, and found it useful. Pointing out how they didn't use the "right" tools just makes it less likely people will be willing to share their processes.
- oefrha 6y agoYou added way too many assumptions to a short non-accusatory comment.
- whatatita 6y agoIt looks like it wasn't a big deal to perform the lookup, so I guess it comes down to what the engineer was familiar wit. It does say later in the post that they used a local proxy to confirm their findings, too. Maybe they wanted to check from both sides, just to be sure.
- deleted 6y ago[deleted]