It is a common trend today that applications are leaking data to the network. This is an open-source and linux-oriented list of such applications. The behavior was discovered using NSA Litoměřice's ipwatch solution, tcpdump, netstat, Burp proxy and other software.
The bugreports should be submitted and linked.
It's interesting that I usually can't find anyone on the web who cares.
Direct further questions regarding privacy and security to your operating system vendor. </note>
udp 0 0 0.0.0.0:5353 0.0.0.0:* 12358/chromium --password-store=detect
All WebKit browsers: ignore user-agent settings, send real information to Google domains
Uses 184.108.40.206 DNS server if no other is available: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
As of 12/2015 (update: 07/2018: the bug is still there), the default configuration of Stardict in Debian Sid uses dict.cn as the default dictionary. Additionally, as clipboard scanning is enabled by default, this means that as you start Stardict, your clipboard contents gets sent in the following HTTP (unencrypted) request:
GET HTTP://dict.cn/ws.php?utf8=true&q=clipboard_content HTTP/1.1\r\n
It has been confirmed that if you use KeePassX, which by default uses “copy password to clipboard”, this password is immediately sent by Stardict in plaintext to this .cn server.
Related, but not the same:
(at least) in Debian, an automatically spawned service (dirmngr) seems to periodically checks key updates on keyserver over plain HTTP, exposing list of your friends to the network.
Aug 17 07:55:13 localhost dirmngr: error accessing 'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x191B300C733BBEA2': http status 404
systemctl --user disable dirmngr.service systemctl --user mask dirmngr.service
to disable this.
By default Linux replies to ARP queries on all interfaces. This seems to be in accordance with RFC 826 from 1982, part “Am I the target protocol address?”. It has two consequences:
Example decloak: arping -i br0 10.1.10.1
Defense: echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
Gets a file when you connect to the network to check if there is a captive portal.
1842 root 788 S htpdate -D www.google.com www.yahoo.com www.linux.org www.freebsd.org
Btw. there used to be a root shell on ttyS0.
Sends out configuration during installation (stores timezone and mirror settings for sysadmins with lazy fingers). more details
It also seems to leak when looking for embedded content or links.
Calls home upon connection. This probably leaks unique information in the “login” thing. We have not conducted MitM (yet).
It calls to Canonical, Google and YouTube. It downloads advertisements to “music” and “video” “pages”. There does not seem to be a straightforward option to turn them off.
A stock CM 12.1 was installed. During installation, all possible spy settings were turned off. Upon each boot, the device connects to android.pool.ntp.org despite having time synchronization disabled in settings.
Additionally, the following HTTP request was observed:
GET /generate_204 HTTP/1.1 User-Agent: Dalvik/2.1.0 (Linux; U; Android 5.1.1; Nexus 4 Build/LMY48B) Host: connectivitycheck.android.com Connection: Keep-Alive Accept-Encoding: gzip
This request has been disabled by “settings put global captive_portal_detection_enabled 0”. The NTP thing does not seem to be possible to disable. Strangely, we find no users solving this in public forums.
Please note that the sniffing was carried only on wifi. We don't have equipment to sniff mobile data at the moment.
Sends broadcasts when changing monitors. Seems to be scanning for network printers.
Checks for updates
Checks for updates
Checks for updates
Sends broadcasts upon startup, so others can sniff while you sniff.
Listens to the world for file transfer, even when it's turned off. And even when status is offline.
Eternal spy connects to Google Market (tcp/5228) even though updates have been disabled and Market was never started. (Android 4.1, Samsung Galaxy Ch@t Backdoor Edition)
Traffic collected during 30 minutes of idle phone laying on the desk includes:
…despite all services are disabled in system settings and the phone has never been connected to any Google service.
Brief sniffing on one popular network reveals similar patterns and requests are exposed by many other mobile phones too. Sometimes such requests apart from tracking allow for full remote compromise.
I have hotfixed the problem using the following netfilter rules to allow only my favorite sites. Of course malware with sufficient privileges can add an exception to the firewall itself.
iptables -N CHECKALLOWED for ip in 220.127.116.11/24 18.104.22.168/24 22.214.171.124/24 126.96.36.199/24 188.8.131.52/24 184.108.40.206/24 192.168.0.0/16; do iptables -I CHECKALLOWED -d $ip -j ACCEPT done iptables -I OUTPUT -j CHECKALLOWED iptables -I OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A CHECKALLOWED -j REJECT
However, spying features in Windows are much more advanced, for example: