4

Regarding privacy matters, I wonder if it is possible, by a party, including myself and mobile telco provider firmware (on stock distributions), to sniff all the outgoing HTTP requests of a Wi-Fi network without the need of the device to be rooted? If such is possible, can you give me an example or two of how could they do it?

I know there are similar apps like Shark for Root, but they all require the devices to be rooted.

|improve this question
  • Welcome to the Android Enthusiasts! This site is for users of Android, which means that questions about development/programming are off-topic here (see the What topics can I ask about here?). Development questions are on-topic on our sister site Stack Overflow. // And guess why all those apps require root: In order to "sniff", the NIC must be switched to "promiscous mode", which is not possible without root. So you can write a sniffing app, but it cannot access the packages to be sniffed. – Izzy♦ Jan 9 '14 at 12:18
  • I think this question could be okay if it approached the issue from a security standpoint. For instance, could an app I've installed sniff my HTTP packets if I've never rooted my phone? In fact, this question isn't necessarily about developing such an app at all, now that I re-read it. – ale Jan 9 '14 at 13:39
  • Rephrase question so it doesn't get closed. – geffchang Jan 10 '14 at 2:33
  • @geffchang I have rephrased my question – lalalalalala Jan 11 '14 at 17:29
  • Oops, I meant to say that I rephraseD the question so it doesn't get closed. But I suppose your edit is still OK. – geffchang Jan 12 '14 at 0:36
1

If you have a compromised kernel, then it doesn't matter whether you have root or not. Packet sniffing app goes through the kernel's public interface for sniffing packets, which is why they're subject to security restrictions; a compromised kernel can simply bypass all that and read the packets directly from the kernel internal data structure or directly from the hardware. Kernel code runs under supervisor mode which gives them direct access to the hardware including being able to read any parts of memory of any program running on the system.

If it's a branded phone that had been customized by your telco, they build the device image for your device, including the kernel image. In non-branded phone, it is similar situation except it's with the manufacturer. Additionally, manufacturers can also install malicious hardware.

|improve this answer
  • in other words, I want to know if a provider can sniff HTTP requests through firmware, for devices that are connected to the provider's fixed line (ADSL, for example) and access the internet through a WI-FI router (for example...). Please, disregard the use case of the providers 3g/4g network. If you will, please edit your anwser so I can mark it as accepted :) – lalalalalala Jan 11 '14 at 19:10
  • 1
    @lalalalalala: if your telco provides you with a compromised system image, then yes they can read anything in the system including Wifi communication and even encrypted traffic (since the kernel have access to the data in memory before encryption). If you don't have a compromised system though, they can only read unencrypted communications that goes through their mobile network, i.e. it is impossible for them to sniff Wifi traffic nor any data that uses secure end to end encryption on an uncompromised system. – Lie Ryan Jan 11 '14 at 19:24
  • @LieRyan: Be careful with the term "impossible" - ISPs use the defense of "network management" to justify what are essentially MITM attacks to decrypt and inspect customer SSL traffic (see Blue Coat's SSL Visibility Appliance as just one vendor example of equipment capable of seeing your SSL traffic). As soon as your traffic leaves your LAN it should be considered vulnerable to attack. – Mr. Buster Jan 11 '14 at 23:47
  • @Mr.Buster: I'm not intricately familiar with the BlueCoat appliance, but from the limited reading I did, it seems the only way it can create an MITM connection is if you have BlueCoat's root certificate in your device, otherwise you'll get security warning from the browser (and is really your own fault for ignoring the warning). I would consider this situation as you having a compromised device. – Lie Ryan Jan 12 '14 at 1:00
  • 1
    @lalalalalala: promiscuous mode is only needed if you want to capture other device's connection on the same network (ala wireshark or firesheep). It isn't necessary to switch to promiscuous mode to capture the device's own Wi-Fi connection (for that only system app privileges is necessary, since system apps can set global proxy setting). With that said, if your device update is managed by your telco (as is the case with most on-contract devices), they do have the ability to modify your kernel and do practically anything possible. – Lie Ryan Jan 12 '14 at 21:05
3

If you're only interested in looking at HTTP requests, then it's possible to do that by installing a web proxy and configuring Android to use it. However, that's not completely reliable, as not all apps respect the central proxy settings: Firefox is an example of an app that doesn't.

A web proxy doesn't require root, but the user has to set it up by hand: you can configure it automatically only if you have root. If that weren't the case it would be a bit of a security problem in Android: a normal app could eavesdrop or otherwise interfere with other apps' network communication.

Of course, even for real packet sniffing, you only need to root the device if you want to install the sniffer on the device. To see the device's network traffic, it's much easier and more convenient to install a sniffer on a desktop Linux machine acting as a (Wi-Fi) router.

|improve this answer
  • Hint for those not seeing the connection: This answer was made on a previous version of the question, which was modified after the answer was posted. // Chin up, Dan! :) – Izzy♦ Jan 13 '14 at 17:03
  • then this answer should be removed as not relevant – Marian Paździoch Nov 21 '18 at 12:11
  • @MarianPaździoch it is not the fault of Dan that OP didn't give a thought to when editing their question and changing the intent upon which an answer is to be based. They invalidated the answer by changing the intent of the question, which is a bad etiquette because one is disrespecting the efforts and time of somebody that were invested into answering the question. The solution is to not delete the answer, but either revert the changes in the question (provided that does not invalidate another answer) or to accommodate both the earlier and later revisions in a single revision. – Firelord♦ Nov 25 '18 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.