Com­pSec: Plug those gaps

Make things a bit harder for cy­ber­crim­i­nals by get­ting rid of your ‘low-hang­ing fruit’ be­fore it’s too late

Linux User & Developer - - Contents -

Fix the more ob­vi­ous threats to your sys­tem and that in­cludes print­ers

Hack­ing into a sys­tem does not nec­es­sar­ily re­quire com­puter-savvy peo­ple, well versed in soft­ware ex­ploita­tion. More of­ten than not it’s a case of leav­ing bread crumbs and ‘low-hang­ing fruit’ di­rectly ex­posed to the in­ter­net for all the bad guys to see (and, of course, take ad­van­tage of).

Whether it’s an old un­patched sys­tem or an easyto-guess pass­word, that’s all they need in or­der to get their first foothold into the sys­tem and start their lat­eral move­ment and sys­tem piv­ot­ing. The me­dia is full of such cases, like the hacked GitHub ac­count of Gen­too Linux (see http://bit.ly/lud_­gen­too). Hav­ing guess­able pass­words, and not us­ing pub­lic key au­then­ti­ca­tion or 2FA au­then­ti­ca­tion mech­a­nisms, is a ter­ri­ble mis­take that typ­i­cally ends up in a data breach. Run­ning old soft­ware (some­times even on mod­ern OSes) poses a se­cu­rity threat too.

So this tu­to­rial will guide you through some real cases where the bad guys were suc­cess­ful in hack­ing into some sys­tems by spot­ting, and then ex­ploit­ing, some very tasty low-hang­ing fruit. No ad­vanced skills are needed, just some Bash or Python script­ing and some tool or an­other. From old DES-en­crypted pass­words to leaked NTLM hashes on an LDAP schema, all the bad guys had to do was reach out…

Re­hash old hashes

Think about all those servers and work­sta­tions you’ve been up­grad­ing since the very first time you in­stalled them. Like, say, the very first web server your com­pany had run­ning, on a flam­boy­ant De­bian Sarge with Apache Server 1.X. Since those old heady days a lot of things have changed, of course, and you’ve been up­grad­ing that old web server to this day. But what about the hashes? Un­less you force your users to change their pass­words reg­u­larly (in case you are still us­ing pass­word au­then­ti­ca­tion, that is), by up­grad­ing a sys­tem you won’t be up­grad­ing those old hashes al­go­rithms at all.

On some oc­ca­sions I’ve seen DES-en­crypted pass­words hap­pily co­ex­ist­ing with salted SHA512 hashes on mod­ern De­bian Stretch servers – no kid­ding. Why? Be­cause the sys­tem man­ager did not think to make their

users change their pass­words and, let’s be frank here, be­cause users tend not to change them at all un­less forced to. Un­less it’s af­ter a data breach, of course.

One thing you can do right now is to make sure all your servers and work­sta­tions do not have old DES-en­crypted pass­words or MD5 hashes. Log in to these com­put­ers and have a look at the /etc/shadow file. Cur­rent GNU/ Linux sys­tems use salted SHA512 hashes. If you spot any non-SHA512 hash, run the fol­low­ing com­mand to force those par­tic­u­lar users to change their pass­words the next time they log in:

chage -d 0 <USER>

Get the file 01-hashes.txt from the coverdisc. This is a recreation of an /etc/shadow file found on a real email server run­ning De­bian Stretch. This server was orig­i­nally run­ning De­bian Sarge, and the sys­tem ad­min up­graded it fol­low­ing the ob­vi­ous path: Lenny > Squeeze > Wheezy > Jessie > Stretch. Some users, though, hadn’t changed their pass­words since the very first time, not even the sys­tem ad­min him­self! Brute-forc­ing DES with John The Rip­per (see Re­sources) is more than fea­si­ble, so clone its repos­i­tory and have fun crack­ing these pass­words!

Get rid of the usual sus­pects

Ev­ery sin­gle GNU/Linux sys­tem ships with some well­known users, such as www-data, git, root and so on.

For those servers with pass­word-based au­then­ti­ca­tion mech­a­nisms, if users’ pass­words are easy to guess, it might as well be game over. We have found on a bunch of servers that some of these users, in charge of run­ning some net­work ser­vices (like the Apache web server), were al­lowed to ex­e­cute a shell. On one such oc­ca­sion this was be­cause the server was run­ning an OwnCloud in­stance and they needed the www-data user to per­form some ad­min­is­tra­tive tasks run­ning the occ PHP script via an SSH con­nec­tion.

The www-data user had a guess­able pass­word and the SSH server was us­ing pass­word-based au­then­ti­ca­tion. So it came as no sur­prise that one day the sys­tem ad­min no­ticed that the web server was hav­ing some se­ri­ous trou­ble in ser­vic­ing pages to clients. It turned out that some­one had been able to gain a non-priv­i­leged shell as www-data by guess­ing the pass­word, and they had started run­ning brute-force at­tacks against other com­put­ers and net­works.

When­ever pos­si­ble, don’t al­low valid shells to dae­mon ac­counts and make sure to re­name them. Al­low ac­cess to those users who re­ally need to use SSH by edit­ing /etc/ ssh/sshd_­con­fig and adding an Al­lowUsers en­try, in the fol­low­ing way:

On some oc­ca­sions I’ve seen DESen­crypted pass­words co­ex­ist­ing with salted SHA512 hashes

Al­lowUsers <user1@IPADDR> <user2@IPADDR>

Of course the IP ad­dress can be spoofed, but if you com­bine pub­lic key au­then­ti­ca­tion with Al­lowUsers en­tries, you should prob­a­bly be fine. You can even in­crease your se­cu­rity by com­bin­ing 2FA mech­a­nisms, pub­lic key au­then­ti­ca­tion and LUKS.

Car­ry­ing around a non-en­crypted lap­top is a per­ilous busi­ness. On one oc­ca­sion, some­one stole a lap­top that had no en­cryp­tion at all. They then by­passed the en­tire INIT process and got ac­cess to the user’s home directory. There they found a pub­lic/pri­vate key pair in the ~./ssh/ directory. Run­ning the fol­low­ing com­mand, they got a list of valid hosts to which the user reg­u­larly con­nected:

cat /home/<USER>/.bash_his­tory\ > |egrep --color=yes "ssh|scp|sftp"

Fi­nally, they tried to con­nect to those hosts by run­ning:

ssh -i <ID_RSA_KEY> <USER>@host

The user did not have his pri­vate key en­crypted, so no pass-phrase was needed in or­der to use it, and so the bad guys were able to hack into a bunch of servers.

Now, imag­ine this hap­pens to you. Do you have, at least, a strong pass-phrase pro­tect­ing your pri­vate keys? Do you have en­cryp­tion at all on the vol­ume where you store your pri­vate keys? You can use John The Rip­per to brute-force pri­vate keys just as eas­ily, of course. Gen­er­ate a new RSA pub­lic/pri­vate key-pair, and when asked for a pass-phrase, type some­thing dic­tio­nary­based such as mar­i­o­bros:

ssh-key­gen -t rsa -f id_my_weak_rsa

In­stall John The Rip­per JUMBO ver­sion on your com­puter and then ex­e­cute the fol­low­ing:

./ssh2john.py id_my_weak_rsa > id_rsa.hash

From this point on, it’s just a mat­ter of run­ning John with a good dic­tio­nary and wait for the best (or the worst):

./john –wordlist=/path/to/dic­tio­nary.txt \ > id_rsa.hash mar­i­o­bros (id_rsa)

Feel free to crack the pri­vate key in­cluded on the coverdisc (03-id_rsa).

On the other hand, let’s imag­ine you did have your en­tire file sys­tem en­crypted with LUKS. Un­for­tu­nately, if your cho­sen pass-phrase is weak, you are still doomed. To demon­strate this, grab a spare USB stick, cre­ate a new VFAT par­ti­tion on it and then run the fol­low­ing com­mands to cre­ate a new LUKS-en­crypted vol­ume. In this case when asked for a pass-phrase, choose a weak, dic­tio­nary-based one:

crypt­setup luk­sFor­mat /dev/<DE­VICE> crypt­setup luk­sOpen /dev/<DE­VICE> MYLUKS mkfs.vfat /dev/map­per/MYLUKS -n dataen­crypted crypt­setup luk­sClose MYLUKS

Now you’ve got your­self a fancy VFAT LUKS-en­crypted de­vice. Bet­ter, right? Well, try­ing to per­form pass­word guess­ing on LUKS de­vices is ad­mit­tedly slow, but you can al­ways dump the LUKS header with all its keys to a file and work against this file to speed up the process. Brute­force-luks (see Re­sources) is per­fect for this pur­pose; first in­stall it:

git clone https://github.com/glv2/brute­forceluks.git

apt-get in­stall dh-au­tore­conf libcrypt­se­tupdev cd brute­force-luks

./au­to­gen.sh

./con­fig­ure && make

Next, dump the LUKS header from your USB stick and run brute­force-luks against it with a good dic­tio­nary:

sudo dd if=/dev/<DE­VICE> of=luks-header bs=1M count=10

./brute­force-luks -t 2 -f <DIC­TIO­NARY> luks_ header

When the only way to ac­cess your SSH servers is by means of pub­lic key au­then­ti­ca­tion, any at­tempt at pass­word brute-forc­ing will ir­re­me­di­a­bly fail. How­ever, at­tack­ers will in­evitably keep on try­ing. That’s why it’s im­por­tant to in­stall a tool like fail2ban, to ban those an­noy­ing at­tempts.

There’s also the pos­si­bil­ity of a pri­vate key brute-force at­tack by us­ing, for ex­am­ple, Crow­bar (see Re­sources). When a non-valid pub­lic key is of­fered, the /var/log/ auth.log file will have en­tries like the fol­low­ing: Jul 22 08:28:42 server1 sshd[19289]: Con­nec­tion closed by <IPATTACKER> [preauth]. It’s easy to track these at­tempts and ban them with fail2ban. Just edit /etc/fail2ban/ fil­ter.d/sshd.conf and ap­pend the fol­low­ing line to fail­regex:

Print­ers can pose a tremen­dous threat be­cause they can be ex­ploited and used as a pivot

^%(__pre­fix_­line)sCon­nec­tion closed by

<HOST> \[preauth\]$

Once the new rule is added, use fail2ban-regex to make sure it’s work­ing:

fail2ban-regex /var/log/auth.log \ > /etc/fail2ban/fil­ter.d/sshd.conf

Do RSA weak keys ring any bells? It’s some­thing from the past (see https:// jblevins.org/log/ssh-vulnkey) but it’s still pes­ter­ing our present. Old em­bed­ded SSH de­vices with no firmware up­grades are still af­fected by this is­sue. And guess what – some of those weak RSA2048 keys are still found in ./ssh/au­tho­rized_keys2 files!

Make sure you do not have any old em­bed­ded de­vice (router, IoT or what­ever) run­ning a vul­ner­a­ble OpenSSL ver­sion and, in case you do, make sure all the vul­ner­a­ble keys have been re­moved.

Oth­er­wise, an at­tacker could down­load pre-cal­cu­lated RSA2048 pri­vate keys and use them to gain il­le­gal ac­cess to one of these de­vices. Try it; down­load pre­cal­cu­lated RSA2048 pri­vate keys from http://bit.ly/lud_r­sakeys. Then down­load and in­stall the afore­men­tioned Crow­bar to brute-force these de­vices us­ing the down­loaded keys: git clone https:// github.com/galkan/crow­bar.git. In­stall its de­pen­dency first: apt-get in­stall python-paramiko and try your luck with:

./crow­bar.py -b sshkey -s <IP_ DE­VICE/32> \

> -u <USER> -k /path/to/rsa/2048/

Does that seem un­likely? We’ve seen it hap­pen. Twice.

Pen-test your print­ers

You prob­a­bly have some print­ers on your net­work. Hope­fully, these print­ers won’t be ac­ces­si­ble from the in­ter­net but they pose a tremen­dous threat nonethe­less be­cause they can be ex­ploited and used as a pivot. PRET (see Re­sources) is an amaz­ing pen-test­ing tool for print­ers. It al­lows you to per­form some pen-test­ing tests and ex­ploita­tion of PS, PCL and PJL print­ers.

What sort of at­tacks can be pos­si­ble on a printer, you may be think­ing? Browse to http://hack­ing-print­ers.net/wiki/in­dex. php/Main_Page to find out. Are your print­ers up­dated to their lat­est firmware?

Are they ex­posed to the in­ter­net? One of our en­gage­ments took place some time ago when we spot­ted some odd con­nec­tions from a re­mote IP ad­dress to an HP Of­ficeJet 8210 printer on an un­usual TCP port. It turned out the printer had been hacked and some­one had been able to spawn a net­cat lis­tener on TCP port 1210. They ba­si­cally ex­ploited the vul­ner­a­bil­ity re­ported at http://bit.ly/ lud_h­p­ex­ploit, by fol­low­ing, step-by-step, the post on HP’s own web­site at http://bit. ly/lud_­root­printer. See? Even if they were not well-versed in printer hack­ing, they did it any­way. But of course you can even do it quicker us­ing PRET!

Let’s find out which print­ers you can see on your net­work. First, in­stall PRET de­pen­den­cies: pip in­stall col­orama pys­nmp; apt-get in­stall im­agemag­ick ghost­script. Next, ex­e­cute PRET to get a list of your print­ers: cd PRET/; ./pret.py (for this com­mand to suc­ceed you need to al­low UDP pack­ets to your com­puter). Pick one and re-run PRET with the lan­guage that your printer sup­ports (ps, pcl or pjl):

./pret.py <IP> ps Some print­ers may sup­port more than one of these lan­guages, and some vul­ner­a­bil­i­ties may be suc­cess­fully ex­ploited by us­ing one but not the oth­ers. Bear in mind that by us­ing PRET your printer may well be gush­ing out a lot of pages with odd PS/PCL/PJL codes printed on them. Try­ing to per­form path tra­ver­sal is a good start­ing point when­ever as­sess­ing the se­cu­rity of your print­ers. If you can do it, the chances are that you may have a po­ten­tial at­tack vec­tor to in­ves­ti­gate:

tra­ver­sal ../../../bin Path tra­ver­sal set.

Some­times you won’t be able to do that, but maybe you will be able to use the printer as a sort of covert repos­i­tory for spread­ing mal­ware, il­le­gal con­tent stor­age and so on. A bunch of print­ers are vul­ner­a­ble to this par­tic­u­lar flaw al­though some ven­dors do not cat­e­gorise it as a proper vul­ner­a­bil­ity. It’s easy to test for that; us­ing PRET, try to up­load to and then down­load a file:

./pret.py <PRINTER> pcl put <FILE> ls get <FILE>

Feel free to ex­plore all of the pos­si­bil­i­ties of PRET and read more about printer ex­ploita­tion at http://bit.ly/lud_­root­print2.

You won’t be up­grad­ing old pass­word hashes just by up­grad­ing the sys­tem

Above Teach your­self a bit of the PS, PCL and PJL lan­guages. Too daunt­ing a task? No fret – use PRET!

Right When­ever you set up pass-phrases for your LUKSen­crypted de­vices, go for the Snow­den ap­proach: it de­liv­ersFig­ure 1

Above MFPs are multi-func­tional de­vices in­deed: here you are about to gain a re­mote shell. Smash­ing!Fig­ure 2

Newspapers in English

Newspapers from UK

© PressReader. All rights reserved.