This is OK as we will update initramfs later. * update-initramfs will complain about /boot mounted as read only. N, enter, enter, enter, type 80325 as start sector - CAREFUL: default is hihger, and if you make a mistake here, you'll destroy your filesystem!, enter, enter. Note the *start* od /dev/mmcblk0p2 partition, in my case it's 80325.
#Rpi wipefs full
Resize your sd card partition to full size, to add room for new packages to be installed. Reboot to reload kernel's partition table.Ĥ.
If you are certain there were no previous raid arrays on the disks, you can append count=10 to the above dd commands and have it done much quicker. This ensures they contain nothing valid, and that mdadm (or kernel!!!) won't automatically assemble them at boot. Wipe out the USB disks you are going to use as the root filesystem. Disable the usbmount-start service, as it might conflict with our desired USB disks usage as a md raid1 array.ģ. This is because built MD arrays will have the hostname as a part of their name, and during boot process, this is checked to see if it corresponds with the current host name.
#Rpi wipefs download
Build or download a SD card image, burn it and insert it into your ODROID C1ġ. If ubuntu specific instructions should be followed, they will be written directly under the jessie-specific line or step marked with an asterisk (*).Ġ. Do not carry them out or apply them in ubuntu. Lines / steps marked with * are for debian jessie ONLY. So now we are 100% sure we are hacked and we have these things to do: 1) if possible keep a backup of this system for investigation, if not keep as much copies of files and the output of commands as possible 2) restore backup and check if it's clean -or- re-install OS 3) find out what we can do to avoid getting hacked again (at least not in the same way :-).This guide was written for Debian Jessie image, but should work in ubuntu with small modifications. It's probably a good indication of the open door to our system. Note this file /opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety. usr/share/command-not-found/programs.d/amd64-main.db
usr/share/locale-langpack/en_GB/LC_MESSAGES/util-linux.mo opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety Let's use this bit of info to scan our system for other files that are probably related to this malicious code: find / -mount -type f -exec sh -c 'grep -q "\.minexmr\.\|wipefs" ""' \ -print In my case the later pointed to an open log file with this content: # head /tmp/mcalogĬMD: /bin/wipefs -B -o stratum+tcp://:8888 -u 49ijJ3HJUg1b2MGnDmnEDJWdphGzWXgtbbBENx43NJiAUZWf8cSGryiZtYVZz3dgRcZH3Leokoqqi8SfRexMW32aFfvoHBp -p x -k
#Rpi wipefs code
So we have code for "mining various cryptocoins" here.īefore turning off the machine it's good to have a look at the process with strace (if you're comfortable with it) or look at the files in /proc/ - at least cat cmdline and ls -la fd. Try "xmrminer" -help' for more information. Let's look at the strings in wipefs: strings /bin/wipefs In my case crontab had a line to run /bin/wipefs every 12 minutes. A note of caution here: If dpkg -V reports nothing then don't put your guard down because it's not unlikely that the virus/hacker has taken steps to fool it. Based on the description of the ss and netstat (man ss, man netstat) it's obvious that we have malicious code here that is trying to hide itself. That is surely a sign of compromise for executables (like /bin/ss and netstat). Googling the md5 of the suspicious /bin/wipefs you get results that suggest hacking/virus.ĭpkg -verify lists a few files that have been altered since installation. And it's not at all normal to have an executable in /etc. What follows is the most important parts of my investigation.Ī typical investigation to find out whether this is malicious code # man wipefsĪccording to its description on the man page this executable has no reason running - more so running for a long time and consuming a lot of CPU. I found out that this system was compromised. In my case wipefs was run by /bin/wipefs and was also using 100% of my CPU. I had a similar case in a server running java/glassfish.
0 kommentar(er)
