Hacker News Reader

Comment by DesktopECHO | Hacker News Reader

Follow-up to my earlier report about the stock firmware on these Android TV devices, with a script to de-fang Stage 0 by preventing the payload from downloading (chattr +i FTW!)

View on HN

For what it's worth that domain in your repo is also listed in the 1Hosts block-list [1] but only in the Xtra category, not sure why. It seems that is a known malware site. Oddly enough it is not listed in the PiHoleBlocklist [2]

[1] - https://github.com/badmojr/1Hosts [listed but only in Xtra]

[2] - https://github.com/Perflyst/PiHoleBlocklist.git [not listed]

Yeah only the primary server seems to be on blocklists. The malware uses 3 DNS addresses, all on Linode.

Not that it matters, as the malware uses 8.8.8.8 if it doesn't like the DNS reply -- Then it tries a DNS server on port 5353!

Another thing to look at if you have time is packet characteristics. I have found that many malware and bot installations appear to use really odd network libraries. Just do a tcpdump for a while and see what sticks out, such as missing MSS, really high TTL, missing SackOK, timestamps enabled this seems to be default on Android. Also look at the TCP header sizes vs. the normal TCP header sizes from legit devices on your network.

    tcpdump -i any -p -NNnnt -s0 -c512 proto 6 and 'tcp[13] == 2' # get syn packets, use "-i any" to see direction

I'm not sure where malware authors find their libraries but they do not try at all to look like normal traffic [Edit] or perhaps their government is telling them to add/remove specific options.

Thanks for the guidance here. Where I'm really stuck is when tcpdump tells me about the presence of the offending traffic and correlating process. In this case, it's the Android "system_server" process and I'm not sure how to find the hook into it that downloads the malware.

In hindsight I should have made this an Ask HN post...

just reading you comment about differing packets, I was already thinking that seems like a dumb thing to have look different. Then you end with exactly that. Just goes to so that the world is so insecure that even minimal effort will get quite a return in this world. If it gets a big enough return so that even those that do stop it still makes it worth while, then why spend energy trying to do more. Hell, even Bill Gates is attributed to saying something about why should he pay for optimizing when disk space and cpu is always increasing faster than any optimizations could.

Wow, yes, only 1Hosts (Xtra) includes 2 of the 3 command & control domains: https://archive.is/drYgk

I am surprised that none of the usual threats lists have picked these domains up.

Edit: https://github.com/badmojr/1Hosts/issues/964

I'm not too surprised, as the malware goes out of its way to use ycxrl.com -- Going to extents like using 8.8.8.8 instead of the default DNS server, and trying a DNS server on port 5353.

Using those techniques, nobody would get a chance to see this second fall-back.

EDIT to clarify: Thanks for listing this, it's definately good to list these addresses as 'bad' for others to be aware, but DNS blocking won't slow down this malware, not even a bit.

Here's what it took for me to see cbpheback.com -- Install Pi-hole on the Android device and add these rules to iptables:

  adb shell iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p tcp --dport 5353 -j DNAT --to 127.0.0.1:53
  adb shell iptables -t nat -A OUTPUT -p udp --dport 5353 -j DNAT --to 127.0.0.1:53

> ..but DNS blocking won't slow down this malware, not even a bit.

Yep, in a world of encrypted DNS transports, it is a folly to believe that DNS-based blocks would be affective at thwarting any sort of malware. That said, some IoC (indicators of compromise) setups do rely on it nevertheless.

just because something new comes along doesn't mean you stop doing the thing that worked for all of the older/existing things. otherwise, the existing things start working.

you make it sound like people dumb for relying on something that works in certain situations. that's just hubris on your part if that's what you actually feel.

You make it sound like I compared DNS-based security to snake oil. That's just futuristic thinking on your part (:

>setups do rely on it nevertheless.

this is where I'm drawing my conclusion. no snake oil accusations necessary. the sentence is read with an implied "nevertheless, [dumbasses|idiots|noobies]" type of ending

Reply on news.ycombinator.com