> It appears that only these two addresses are still infected:
> 44.25.64.73 ether1.ap.beacon.hamwan.net
> 44.98.249.7 AP-A-250.tampa.flscg.org
A little too optimistic, a longer scan yields this list:
44.140.129.12
44-25-128-124.ip.hamwan.net[44.25.128.124]
ether1.ap.beacon.hamwan.net[44.25.64.73]
44.34.131.144
AP-000.StPete.flscg.org[44.98.249.66]
AP-120.StPete.flscg.org[44.98.249.67]
AP-240.StPete.flscg.org[44.98.249.68]
AP-A-250.tampa.flscg.org[44.98.249.7]
Rob
> All of the hosts I can control in 44.34/21 have been updated this evening.
> Please let me know if you notice any other troublemakers there. Thanks for
> the report.
This is the latest packet to TCP port 8291 I have seen from addresses in the 44.34 network:
01:13:28.014665 44.34.128.100
04:04:59.569058 44.34.128.101
01:21:03.741867 44.34.128.102
01:11:34.822173 44.34.128.34
00:21:39.834057 44.34.128.35
01:53:00.697869 44.34.128.39
03:36:45.895350 44.34.128.94
07:13:36.922146 44.34.129.114
04:22:32.850903 44.34.129.117
03:32:09.935080 44.34.129.40
02:27:34.360165 44.34.129.41
01:51:02.516010 44.34.129.42
01:18:43.892712 44.34.129.73
Times are UTC+2
When you have updated those devices after those times it should be OK
Rob
> When you know who owns one of the above systems, please advise them that their router is
> compromised and that they have to update it.
> As it seems now, updating will also remove the worm, but in my opinion it is safer to cleanly
> re-install it using netinstall and restore your backed-up configuration.
> (you make backups, don't you??)
In the message I used the word "router" a couple of times, but it does not matter if it is a router or WiFi device,
they all run the same software. When your device is on the above list, it has already been compromised.
(probably at least one device on AMPRnet has been infected from internet and now it is infecting other devices
inside AMPRnet, so you can be affected even when you have no internet access at all)
However, the good news is that it appears that updating the RouterOS to 6.40.6 (bugfix) or 6.41.3 (current)
is going to render the worm ineffective, it appears there is no real need to netinstall.
When you have internet access, updating is a simple matter of clicking "check for updates" in the
system->packages menu, select "current" or "bugfix" channel and click "download&install".
Of course this does not work when you have no internet access, but then you can still download the desired
npk files from mikrotik.com, upload them in the device and reboot.
Rob
Likely unrelated to the issue with the rogue gateway servers, please note that this weekend
an exploit was launched that affects MikroTik routers running RouterOS older than 6.38.5 and that
has its webservice (WebFig) open to the outside network.
These get infected via the webservice and start a worm that scans for other routers to infect.
Once it is inside your network it may propagate to other devices. It will scan for the usual MikroTik
configuration interfaces, of which port 8291 (winbox) is most easily identified.
(the others, 23, 80 etc are already scanned so often that it is difficult to identify the source)
I did a trace of about 10 hours on the 44.137.0.0/16 network and over that period it was scanned
by over 345.000 unique IP addresses on the internet, and randomly connecting back to a few
of them returns an old version RouterOS every time...
Disturbingly, there are also a couple of AMPRnet IP addresses on that list! They are mainly in
two different networks. Unfortunately they do not appear in ampr.org reverse-DNS.
wlan1.w7hr-sunnyslope.hamwan.net[44.24.240.110]
wlan.kd7tqn.hamwan.net[44.24.240.221]
wlan1.baldi.we7x.hamwan.net[44.24.240.222]
poe.haystack.hamwan.net[44.24.241.41]
44-25-128-124.ip.hamwan.net[44.25.128.124]
r1.crystal.hamwan.net[44.25.128.169]
lan.r1.beacon.hamwan.net[44.25.64.65]
ether1.ap.beacon.hamwan.net[44.25.64.73]
44.34.128.100
44.34.128.101
vrrp.hil.memhamwan.net[44.34.128.102]
44.34.128.103
ptpsco.leb.memhamwan.net[44.34.128.163]
ptpazo.leb.memhamwan.net[44.34.128.184]
44.34.128.34
44.34.128.35
44.34.128.36
44.34.128.39
44.34.128.62
44.34.128.94
44.34.128.99
44.34.129.114
44.34.129.117
r2.mno.memhamwan.net[44.34.129.35]
ptphil.mno.memhamwan.net[44.34.129.38]
sec1.mno.memhamwan.net[44.34.129.40]
sec2.mno.memhamwan.net[44.34.129.41]
44.34.129.42
44.34.129.66
44.34.129.67
44.34.129.73
44.34.131.144
AP-120.StPete.flscg.org[44.98.249.67]
AP-240.StPete.flscg.org[44.98.249.68]
AP-A-250.tampa.flscg.org[44.98.249.7]
W9CR-Mgmt.StPete.flscg.org[44.98.249.76]
AP-B-330.tampa.flscg.org[44.98.249.8]
AP-C-110.tampa.flscg.org[44.98.249.9]
44.103.35.26
44.140.129.12
When you know who owns one of the above systems, please advise them that their router is
compromised and that they have to update it.
As it seems now, updating will also remove the worm, but in my opinion it is safer to cleanly
re-install it using netinstall and restore your backed-up configuration.
(you make backups, don't you??)
When you run a MikroTik router and have not updated RouterOS, please update it to at
least 6.40.6 (select bugfix-only in the updater) or the current version 6.41.3. In the latter case,
be aware of the issues around updating from 6.40 to 6.41 in complicated switched configurations.
And of course, always configure a firewall that disallows access to the configuration interfaces
from the internet, as always for devices like this.
Rob
.> That is correct - there are plenty of gateways in the portal that have no subnets attached to them, but they are filtered out of the encap list.
Ok, then apparently these "rogue gateways" (they happen to be all from Poland) are using some
method to use the encap file to load tunnel interfaces and static routes.
I had expected them to use the script that Marius wrote for MikroTik, but in that case they would not
receive the RIP broadcasts and so would not be able to build all those tunnels (and send MikroTik neighbor discovery on them).
I suspect there has been some "how to setup an AMPRnet gateway" doc going around in Poland...
Tom SP2L is already looking at it.
Maybe you can just remove all gateways that have had no subnets for some time.
Although that will likely not fix anything...
Rob
Lately I see a number of gateways that are registered without subnets, but still they send traffic.
When tracing it, it appears to be usually traffic like MikroTik neighbor discovery.
It gets logged in our firewall because it is IP-encap traffic coming from an address that is not in the
IP-encap routing table. And it isn't in the IP-encap routing table because that gateway does not have
subnets.
Would it be an idea to not send the RIP announcements to gateways without a registered subnet?
It would not be useful to them anyway, I think.
Rob
> The RIP sender sends RIP only to gateways listed in the encap table,
> unless a bug has surfaced that I wasn't aware of. That code has been
> stable for several years, so I doubt it.
Does that table contain only gateways that actually have routes to them?
Or is there also a listing for those that only are registered in the portal
but with "No subnets"?
I wonder how those gateways know the route to us to transmit tunnel data
when they do not actually route anything themselves?
They appear to be MikroTiks so most likely running the script by Marius YO2LOJ
and that would have to receive the RIP data to bring up the tunnels.
Rob
> Of 688 entries in the ENCAP.TXT table there are 130 that are /32 single
> IP host. That's about 19% of all routes that ONLY reach ONE host and do
> NOT serve a subnet or provide gateway services for anyone else.
> I too wonder why these single host routes are allowed????
I don't see anything wrong with that, this is just a single host on the tunnel network.
What I am wondering about is the gateways that do not have anything routed to them at all.
Look in the portal and view in subnet mode, there are many gateways that show nothing there.
Rob
Can anyone reach the UBNT.COM web site from AMPRNET ?
The site give me timeout
Of course its accessible from non ANPRNet address
Thanks Forward
Ronen - 4Z4ZQ