Hackers be hacking..

jksjks
edited April 10 in General Chat

An alert Kiwi owner/admin has sent me some suspicious log messages. They are obvious hacking attempts. If you see anything similar or unusual in your logs I'd appreciate it if you could forward the relevant log messages to support@kiwisdr.com

I'm particularly interested in log messages containing ### SECURITY: NO AUTH YET:

And also **** unknown stream type

And any attempted admin login messages from IP addresses you're not expecting.

So far the Kiwi security mechanisms appear to be working and there has not been any evidence of any breaches. Please be sure you have a good, strong admin password in place.

The IP address in question has been added to the IP blacklist which your Kiwi should receive during the overnight update window. You can also update it manually on the admin page, network tab.

Thank you.

N1NKM
«1

Comments

  • fabrysfabrys

    I don't know if I'm on topic but I find this string repeating on my log. although my kiwi is set to not have any free access channels but only with a password.

    While on the new kiwi2 which is not registered online there are no strings that I don't recognise.


    Thu Apr 11 07:57:03 00:49:18.038 01..        child_task WARNING: child returned without WIFEXITED status=0x0000008b WIFEXITED=0 WEXITSTATUS=0
Thu Apr 11 07:57:03 00:49:18.039 01..  1   L GEOLOC: 80.87.192.7 sent no geoloc info, we got "Khimki, Russia" from geo host #1
Thu Apr 11 07:57:03 00:49:18.042 01..        task geoloc_task:P2:T007((1000.000 msec) TaskSleep) exited by returning


  • jksjks

    I'd have to look at this more carefully. It could be a timing bug where the connection attempt is denied due to lack of a provided password. But not before the code sees that no API-provided geo location information had been sent and attempts to obtain it locally.

    There are several timing cases like this at connect time I had to deal with.

  • WA2ZKDWA2ZKD

    people are using other's callsigns to ID themselves on login.

  • jksjks
    edited April 11

    Not sure I understand. Sure, people spoof stuff in the name/callsign field all the time. Not much to be done about that. But the log stuff is a little more serious.

  • WA2ZKDWA2ZKD

    somone used my WA2ZKD call.... so that might mislead an admin thinking "oh it's Jim"..... nothing is safe

  • jksjks
    edited April 11

    Okay, yeah, that's more serious then.

  • jksjks
    edited April 11

    @fabrys That IP address has been showing up elsewhere. Part of a Russian datacenter subnet. Onto the blacklist it goes..

  • fabrysfabrys
    https://forum.kiwisdr.com/index.php?p=/discussion/comment/18360#Comment_18360

    Ok!

  • HB9TMCHB9TMC
    edited April 11

    I think 8.219.247.109 (alibaba cloud) is doing the same as the russian datacenter guys. I've seen that for quite some time but didn't bother, as they did it not as extensive as the russian guys, only maybe once or twice a day.

    It looks like they are collecting information about who is listening to which frequency

  • g0ftdg0ftd

    Hi folks,


    Is the recent requirement to enter a callsign / nickname related to this ?

    Not sure that this really helps if it is.


    Anyone can enter a ham callsign, and how does a Kiwi sysop contact

    a user for a check, since many of us already take our own precautions to avoid

    our email adressess being spread about to avoid spammers ;-)


    At this point can I also raise some awareness of a small group of operators that

    use the QRSS mode. They often use a segment immediatly below the WSPR freqs

    and can be mistaken for someone trying to monitor WSPR, which would be

    deemed a wasting or duplicating the inbuit wspr decoder etc.


    The reality is that occasionally they use the Kiwi RX to feed the audio stream to

    what is known as a "grabber" to visually show QRSS signals for an *hour or two

    a week for tests.*


    So please don't assume that they are bandwidth wasters and block them ;-)


    73 de Andy G0FTD

  • jksjks
    edited April 13

    No, we've had a bot/hacking problem for years now.

    Generally only IP ranges belonging to virtual private server (VPS) providers, where the bots originate, are blocked. Individual IPs are only blocked from obvious hackers (abusing/testing the Kiwi API, etc).

  • g0ftdg0ftd

    >No, we've had a bot/hacking problem for years now.

    Agreed.

    You should see my firewall logs ;-)


    >Generally only IP ranges belonging to virtual private server (VPS) providers, >where the bots originate, are blocked. Individual IPs are only blocked from >obvious hackers (abusing/testing the Kiwi API, etc).


    That's good to know. At least most Kiwi providers know the score.

    But of course some might be a bit more cruder / less wise and might take a

    blunter instrument to solve the problem, thus locking out legit users.


    I've only seen it happen one, but once is enough.

    I guess if we publicize some awareness then we can reduce any issues.

    (REDUCE, since we know that no solution is perfect).


    73 de Andy

  • jksjks

    We've had a couple of cases where after blocking an IP range of a VPS provider a legit Kiwi user (who happens to be using a VPS from that provider) finds they can no longer access kiwisdr.com etc. That's why we have the whitelist mechanism that can make an exception for a single IP address within a blocked range.

    Similarly, there is an option to block only port 8073 connections (or whatever external port the Kiwi uses) in a blocked range instead of everything in the range. This was necessary because some Kiwis used DDNS from providers who were blocked.

    The fun never ends..

  • AB9ILAB9IL

    JKS,

    Is there an option to limit admin access to key-based ssh only, thereby eliminating username / password access? These attacks on KiwiSDRs may be part of the large scale campaign going on since mid-March against _everything_.

    There's an Ars Technica article, "Attackers are Pummeling Networks..." which speculates that the goal is reconnaissance and service disruption. It is so bad that the login attempts are having effects similar to denial-of-service attacks, except these guys seem to want the passwords. Deep down, I'm sure the attackers are the sort who just want to watch the world burn.

  • dl7awldl7awl
    edited April 17

    @AB9IL:

    You asked John, but I try to answer, as it's pure Linux and nothing kiwi-specific. Do the following settings in /etc/ssh/sshd_config:

    PasswordAuthentication no
PubkeyAuthentication yes

    (However, I would leave or set PasswordAuthentication to yes until the key-based login is tested and proved to work.) After each change to /etc/ssh/sshd_config,sshd must be restarted to let the changes take effect.

    Edit: Sorry, I should have mentioned also the other necessary steps to establish a key-based login to kiwi (or any other linux system with ssh access). Here are step-by-step-instructions. (I didn't explicitly test them, but they seem okay.)


    @General

    Whatever measures are taken, I always found it advisable to additionally put ssh on an unusual non-guessable port. I do that since decades with my servers. It doesn't really enhance security, but as a small extra hurdle, it reduces the rush and keeps the logs (/var/log/auth.log in this case) from lots of "noise". This setting is done in the same configuration file.

    Regards,

    Manfred

  • jksjks

    There are some further security restrictions you can place on access to the admin interface: http://kiwisdr.com/quickstart/index.html#id-opt-dot

  • engineercarlengineercarl

    John:

    I caught a couple of those messages you refer to:


    Apr 29 11:48:54 KiwiSDR21391 kiwid: 04:26:20.361 0123 0  ### SECURITY: NO AUTH YET: SND SND 178.250.185.231

    Apr 29 14:23:31 KiwiSDR21391 kiwid: 07:00:57.498 0123 1  ### SECURITY: NO AUTH YET: SND SND 178.250.185.231

    Apr 30 07:04:34 KiwiSDR21391 kiwid: 04:32:24.695 0123  3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231

    Apr 30 07:05:25 KiwiSDR21391 kiwid: 04:33:15.575 0123  3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231

    Apr 30 07:06:16 KiwiSDR21391 kiwid: 04:34:06.408 0123  3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231

    Apr 30 07:07:06 KiwiSDR21391 kiwid: 04:34:57.258 01.3  3 ### SECURITY: NO AUTH YET: SND SND 178.250.185.231


    Carl

  • HB9TMCHB9TMC

    @engineercarl

    That should be prevented with the latest blacklist update. Click "download" on the network tab if you have not allowed automatic updates. But I think your entries (Apr 30) were from before that update.

  • engineercarlengineercarl

    I do allow automatic updates, but I didn't know how often they updated. This was just the result of a grep from 'messages' this morning. I had added him to my (very long) list of local blacklists so either way, that IP won't be getting in again.

    Carl/K6CRS

  • jksjks

    Thanks Carl for reporting this. Always interesting to know there are people actively probing the API as opposed to bots just running around.

  • HB9TMCHB9TMC

    I'm getting again access attempts (only "SET GET_USERS") to my Kiwi from Russia every 30 seconds, from a new subnet.

    195.128.246.0/23

  • jksjks

    Okay, added to blacklist. Thanks.

    Yogicat
  • jksjks

    Added to blacklist: 137.220.40.124 and 207.148.92.163 observed making rapid connections, then using old API (SET MARKER variant). Both from constant/vultr/choopa VPS IP ranges.

  • HB9TMCHB9TMC

    Another Constant/VULTR (136.244.116.0/23)

    L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
L API: non-Kiwi app fingerprint was denied connection

    I wonder if it might cause trouble to block all their IP ranges in a dedicated ipset list. That way we could clean up the block list. They are so kind and list all their networks here: https://geofeed.constant.com/

  • Enactment9972Enactment9972
    edited May 10

    I am seeing the same thing on my public Kiwi2. I added them to my blocklist. 11 attempts within 3 minutes.

    Fri May 10 17:33:32 10:02:54.040 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:33:33 10:02:55.124 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:33:33 10:02:55.128 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:33:49 10:03:10.857 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:33:49 10:03:10.864 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:33:49 10:03:11.679 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:33:49 10:03:11.682 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:34:05 10:03:27.403 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:34:05 10:03:27.408 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:34:06 10:03:28.500 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:34:06 10:03:28.505 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:34:22 10:03:44.419 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:34:22 10:03:44.424 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:34:23 10:03:45.324 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:34:23 10:03:45.326 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:34:38 10:03:59.955 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:34:38 10:03:59.960 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:34:39 10:04:00.844 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:34:39 10:04:00.847 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:34:54 10:04:16.545 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:34:54 10:04:16.553 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:34:55 10:04:17.446 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:34:55 10:04:17.449 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:35:11 10:04:33.158 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:35:11 10:04:33.164 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:35:12 10:04:34.083 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:35:12 10:04:34.086 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:35:27 10:04:49.776 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:35:27 10:04:49.783 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:35:28 10:04:50.669 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:35:28 10:04:50.672 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:35:44 10:05:06.358 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:35:44 10:05:06.363 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:35:46 10:05:08.349 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:35:46 10:05:08.354 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:36:02 10:05:24.089 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:36:02 10:05:24.097 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
Fri May 10 17:36:03 10:05:24.984 0.234567 0        L CMD_MARKER: unknown variant [SET MARKER min=0.000 max=1875.000 zoom=4 width=1920]
Fri May 10 17:36:03 10:05:24.986 0.234567 0        L API: non-Kiwi app fingerprint was denied connection
Fri May 10 17:36:18 10:05:40.732 0.234567 0        L PWD new connection --------------------------------------------------------
Fri May 10 17:36:18 10:05:40.737 0.234567 0        L PWD kiwi W/F ALLOWED: no user password set, so allow connection from 136.244.117.202
  • jksjks

    They are so kind and list all their networks here: https://geofeed.constant.com/

    Interesting. I'm surprised such a list is public. The problem with adding an exhaustive list like that is the extra burden it places on the Beagle. I imagine the traffic filtering code has been tuned to be as efficient as possible. But every search traversal is going to cost something. And the poor Beagle needs all the help it can get.

  • jksjks

    That 136.244.117.202 IP range is now in the blacklist as other people have seen it.

  • HB9TMCHB9TMC

    For the sake of completeness, vultr is active from a new ip range

    192.248.162.0/23

    I think some old vultr ranges could be removed, they seem to change the network every few weeks.

    There's something that I don't understand. The range is already in the block list, I don't quite understand how it gets past iptables:

    L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/waterfall.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi.css> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>
L WEB: IP BLACKLISTED: 1|1 195.128.246.85|195.128.246.85 url=</kiwi/kiwi_js_load.js> qs=<(null)>


  • jksjks

    If your Kiwi is proxied then the filtering cannot be done at the iptables level since all traffic appears with a source IP of the kiwisdr.com proxy server. The filtering must be done by the Kiwi server based on the true IP source passed along in the X-Forwarded-For and X-Real_IP HTML headers added by the proxy server.

  • HB9TMCHB9TMC
    edited May 16

    I see, but it shouldn't be proxied, as far as I'm aware of. (21445) I was using the "domain name" configuration.

    The proxy url was not leading to my kiwi, when I tried it. ("The page you visit not found.")

    I've changed "automatic configuration" to "no" now.

    Not sure if it's a bug related with that; I can't get my two kiwi 2's signed up to my.kiwisdr.com both at the same time.

Sign In or Register to comment.