NSA Releases Guidance on How to Protect Against Software Memory Safety Issues

When the NSA makes a post about software best practices to reduce hacking attempts, you know there’s a problem.  For the non-programmers, a memory safe programming language is one that has built-in features to reduce or eliminate the possibility of a poorly crafted program to be exploited (usually by malicious input) by causing a memory buffer overrun or similar failure that can corrupt data, run a malicious payload, or escalate privileges.  These problems have been around for years, and there are several programming languages that are common offenders (C and C++), but are ubiquitous and have long codebase history that makes it unattractive to rewrite.

Fortunately there are quite a few memory safe programming languages to choose from, such as C#, Go, Java, Ruby, Rust, and Swift.  Of course it’s not enough to just change programming languages, good security coding practices, hardening tools, safe compiler options, and thorough testing should also be used as well.

For the NSA full article, click here:  https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/

Leaked Database of over 1 billion Chinese Civilians for Sale

The Shanghai National Police (SHGA) database of over 1 billion Chinese citizens is apparently up for sale for 10 Bitcoin (~USD $200,000 ).   This represents terabytes of personal data including full name, address, birthplace, age, birth year, nationality, photo information, national ID number, mobile number, and any committed crimes and case details for the individuals.   (Source link has been obscured, sorry.)

Included in the for sale ad were samples of the data to verify authenticity.  The alleged leak was apparently from a contract software developer that had errantly posted the database login credentials to a project blog some months earlier. 

The leak has been verified by several people and posted online, but Western media has not really picked up on the impact of such an event.  If legitimate, it represents the largest data leak ever reported.

Oddly enough, there doesn’t seem to be anything called the “Shanghai National Police”, only the “Shanghai Municipal Police” returns any search results as a legitimate entity in major search engines.  Still, regardless if this is a translation error or some other mis-identification, the validity of the data appears to be proven.  We attempted to connect to the sample link provided through a VM and VPN and were able to download the 110mb compressed gzip sample file and view the sample files.  When uncompressed, the files were several hundred megabytes each in JSON format in English language and Chinese characters (multi-byte format), consisting of personal information, police record case data files, and an address merge with cell phone data.   Here’s an example of the personal detail record file:

The police case record data appears to be of the most concern,  with the actual data content consisting of detailed police reports of the charged offense, including the date/time and specific location of the criminal events.  Deciphering the information is difficult for most westerners since most of the text is in traditional Chinese, but it would be trivial to use automated translating to get the gist of the content when inserting into a database.

With the horse already having left the barn, there doesn’t appear much that the Chinese government can do to mitigate this leak.  Addresses and phone numbers can of course be changed by the individuals, but having these records open to the public (particularly the police reports) is a massive blow to individual privacy (such that it is in PRC), and will likely cause problems for millions of people for years.

SolarWinds Hacked – Or “Another Example of Why Putting Security in the Cloud Might Not Be Safe”

The supply chain giant SolarWinds, used by every major branch of the government, all military branches, and almost all of the Fortune 500 companies, has been hacked by a Russian hacking group that gained access to sensitive emails, APIs, and SSO tokens and user accounts since as far back as March of 2020.   See a summary from Krebs here: https://krebsonsecurity.com/2020/12/u-s-treasury-commerce-depts-hacked-through-solarwinds-compromise/

This is a classic example of why outsourcing  your security and sensitive operations isn’t always a good idea. 

One of the most frequent discussions we have with our clients is why we are generally opposed to putting security operations “in the cloud”.  After all, it’s offered by just about every IT supplier, and the security software vendors are all jumping on board as well.  Sure they are, because it’s a great recurring revenue source for them, as opposed to buying a traditional perpetual software license that you install on your premises computer(s).

To be sure, there are obviously Cloud deployments that can be done safely and securely; then again, that’s probably what SolarWinds thought too.  Security, and especially Cyber Security, is a never ending game of cat-and-mouse, with the mousetrap always getting better and the mouse always getting smarter.  

We will see this again, whether it’s another twitter hack where celebrities posting for bitcoin submissions (https://www.pandasecurity.com/en/mediacenter/mobile-news/twitter-celebrities-hacked) or maybe a service provider like Workday or Okta getting hacked and exposing sensitive client data to be sold on the darkweb or nation states for further exploitation. 

For certain clients or situations, using cloud based security application makes sense, but in general we advise against using the cloud for access control and video surveillance for sensitive locations or enterprise applications.

Caveat Emptor.

Securing Ubuntu Linux with ufw and tcpwrapper

Nerd Title:  Security Ubuntu Server with tcpwrappers and ufw.

We don’t write many cybersecurity related articles because there are plenty of other people out there also doing it, and well… we can’t be experts at everything. 

Still, once in a while we come up with a problem that has a solution so clean and elegant that we have to share it.  This article will quickly explain how to setup tcpwrappers and a firewall to automatically ban users attempting to connect from unauthorized IP addresses.   The process is simple, every modern linux distribution comes with a firewall of some kind, Ubuntu currently uses ufw.  It also supports a package called ‘tcpd’, or tcpwrappers. The solution we used was to install a base ufw rule limiting only ports for SSH, HTTP, and HTTPS traffic and block everything else.  It looks something like this:

root@acme.com:/root/# ufw status
Status: active

To Action From
-- ------ ----
22/tcp LIMIT Anywhere
443/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22/tcp (v6) LIMIT Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)

This is a common configuration, but the downside is that everybody can knock on your door and attempt to login.  You can limit how much/how fast, but basically it’s open to the public.  This is where tcpwrappers comes in. You can search the internet about tcpwrappers, there are many online explanations and guides about it. Tcpwrappers has been around a long time, and they never changed the goofy name, but essentially it works by checking two files: /etc/hosts.allow and /etc/hosts.deny to see if you’re a good guy or a bad guy, and what to do with you.  This is where the fun comes in. (Note, you’ll need root permissions to do this.)

First you have to install tcpwrappers – “sudo apt install tcpd”

Then edit the /etc/hosts.allow file and add the services you would use, something like this (change your own hostnames or IP addresses you want to allow in):

ALL: 127.0.0.1
smtps: ALL
imaps: ALL
ALL: 43.79.214.93                 # Work Server
ALL: 71.60.242.15                 # Home
ALL: rockhouse.mynetgear.com      # Home
ALL: 172.210.145.232              # Testing Cloud Server

The IP addresses or hostnames with ALL: in front are allowed into the server for whatever port or service they connect to, as long as the firewall rule allows it. This is your “whitelist” of good guys to let in the door.  The big difference here is that unlike firewall rules, tcpwrappers allows for hostnames, so if you have a dynamic IP address using a hostname (like dyndns.org), you don’t  have to update the firewall rules each time.  Need to add a new remote host that should be allowed to access ssh? Add it here.

Next, edit the /etc/hosts.deny file and add the following string (it should all be on one line):

ALL: ALL: spawn ((/usr/local/bin/banip.sh %h; /bin/echo -ne "client = %h; server = %H; process = %d; PID = %p date = "; /bin/date) >> /var/log/tcpwrappers.log &)

This single line blocks everybody from everything that isn’t in the whitelist above.  Notice also here tcpwrappers calls a shell script called /usr/local/bin/banip.sh.  This script calls “ufw” to write a firewall rule to ban the remote attacker forever.  You can put this wherever you want, but the script should look something like this:

#!/bin/bash
#This script attempts to ban ip addresses using Ubunutu's UFW
#
if [ `whoami` != "root" ]; then
echo "you must be root to run $ME"
fi
if [ "$1" = "" ];
then
echo -n "Enter the IP Address: "
read IP
echo -n "You entered $IP, correct? (Y/N) "
read ans
if [ "$ans" = "y" -o "$ans" = "Y" ]; then
echo "Blocking $IP"
ufw insert 1 deny from $IP port 22
exit
else
echo "Ok, quitting."
fi
else
echo "Blocking $1"
ufw insert 1 deny from $1 port 22
fi

This is a very simple script that takes an IP address and tries to ban it on port 22 for access using ufw.  If you run it manually without any arguments it will ask you for an IP address to ban.

This script will also create a logfile in /var/log/tcpwrappers.log that you can see where people have tried to gain access to your server and been shut out. 

Blocking 106.75.251.140
Skipping adding existing rule
client = 106.75.251.140; server = 45.33.101.254; process = sshd; PID = 78110 date = Fri 13 Nov 2020 04:54:48 AM UTC
Blocking 84-255-249-179.static.t-2.net
client = 84-255-249-179.static.t-2.net; server = 45.33.101.254; process = sshd; PID = 78153 date = Fri 13 Nov 2020 04:55:19 AM UTC
Blocking ns3268691.ip-5-39-81.eu
client = ns3268691.ip-5-39-81.eu; server = 45.33.101.254; process = sshd; PID = 78167 date = Fri 13 Nov 2020 04:55:36 AM UTC
Blocking 118.24.48.15

You can also see a list of banned IP addresses by typing “ufw status”.  If you’ve accidentally banned an IP you didn’t mean to, then you can unban it by using “ufw delete rule#”, where rule# is the actual line from “ufw status numbered” that you want to unban.  Note that this list can get rather long, as there are people with nothing better to do than write scripts to try to break into whatever servers they can find.  In the short time I wrote up this article, I had 32 attempts on my demo server alone.  If you need to reset, you can just type “ufw reset”, but that resets everything back to factory defaults.  You can use a quick script to do this also:

sudo ufw --force disable \
&& sudo ufw --force reset \
&& sudo ufw default deny incoming \
&& sudo ufw default allow outgoing \
&& sudo ufw allow 22/tcp \
&& sudo ufw limit ssh \
&& sudo ufw allow 80/tcp \
&& sudo ufw allow 443/tcp \
&& sudo ufw --force enable

This has been a very fundamental explanation of how to easily allow remote access while also keeping the bad guys out at the same time, using a blend of the old  (tcpwrappers was written in the 1990’s) and the new.