Locales cosmetics. Kali on Raspberry Pi

After installation of the Kali Linux on a Raspberry Pi platform (at least in the Kali GNU/Linux Rolling) I noticed that the Xfce login screen shows in the upper right corner the full list of local keyboards installed (the locales). I don't like it! :) I don't need other than C and US keyboard and more than that, you can save some precious space on the Raspberry Pi storage.

The following post is purely cosmetic. There is no problem with the default installation despite the huge and not necessary keyboard list.

So, let's free some space!

1. First, after login (shell or X), run in console:
locale -a (Display a list of all available locales)
or
locale -a -v (As above but the -v option causes the LC_IDENTIFICATION metadata about each locale to be included in the output)


2. Make sure the file /etc/default/locale exists (if not, create it) and has proper content, such as:
LANG="en_US"
LANGUAGE="en_US:en"
or only
LANG=C.UTF-8

3. Delete all (but C.UTF-8 and en_US.utf8) generated locale data:
rm -rfv /usr/lib/locale/*

Generate again the new locales:
locale-gen

4. Restart the Pi or stop/start the X service:
service lightdm stop
service lightdm start

Of course, if you need more keyboards (or something different than US) you can in the step 3.

SSH over proxy or over multiple hosts

Well, sometimes an evil sysadmin won't let us to live in peace and close all the ports that you need (of course, except the ssh).

Presuming that you already have a host with ssh and Internet access (host1 in the following example) you can use it as a "jump" platform or as SOCKS proxy server to reach a target host (host2 here).

+-----------+<--port 22-->+---------+<--port 2222-->+----------+
|   mybox   |-------------|  host1  |---------------|   host2  |
+-----------+             +---------+               +----------+
localhost:8080            "jump" host                  target

Using as proxy server:
(in this example we have two steps, but you can join those steps in one. Hint:  use && as in command1 && command2 and -f ssh parameter).

mybox:~$ ssh -D 8080 -N -p 22 user@host1
user@host1's password:

Type the password and let this terminal open and open another one.

mybox:~$ ssh -X -p 2222 user2@host2 -o ProxyCommand="/usr/bin/connect -5 -S localhost:8080 %h %p"

Jumping over ssh:
mybox:~$ ssh -t -X -p 22 user@host1 ssh -X -p 2222 user@host2

You may ask yourself "Why not using the second example all the time because is simple and more convenient???". 
Well, the simple answer is that you can not use X11 forwarding (-X parameter) if the host1 had not implemented the X11 forwarding rule in the sshd_config. So, no X11 forwarding in this case.
The first example (proxy), because is a SOCKS tunnel, have no importance if the host1 have or not have the X11 forwarding rule active. As a tunnel, it pass the packets between the two ends of it.

WordPress - Administration Over SSL

There are at least two ways to redirect over a SSL connection the WordPress administration.

The most usual (and recommended ways) are:

1. In the wp-config.php file

Insert into the wp-config.php file the following line:

define('FORCE_SSL_ADMIN', true);

It must be inserted somewhere above wp-settings.php location.

2. Modify the Apache virtual host settings (or .htaccess file or the main httpd.conf)

# Force SSL for wp-admin folder and wp-login.php file
    RewriteEngine On
    RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
    RewriteCond %{HTTPS} !=on [NC]
    RewriteRule ^/?(wp-admin/|wp-login\.php) https://your-site.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
# End Force SSL...


Notice!
For both ways, of course, you must also already have SSL configured on the server and a (virtual) host configured for the secure server before your site will work properly with these constants set to true.

A more comprehensive reference here:
https://codex.wordpress.org/Administration_Over_SSL

rc.local issue and init.d scripts

Well, the only issue with rc.local file is that this file does not exist in modern Debian flavors.
For the old fashion guys like me that is an issue, at least for ten minutes. :)

So, what can we do about? We have at least two options:
To forgot about rc.local and start your task using init.d scripts, or
To enable the rc.local script.

Both ways have pluses and minuses and is up to you what way you will choose. For myself, I prefer the first way. Yes, it's a little bit strange to make a script for each task you will run at boot but you have a better granularity and control over the process.

Nevertheless, one way or another, following the next steps you will have a script that run on boot (or in rcS.d, or in rcX.d) :)

The first option:

Making init.d scripts, copy and paste this code and do the modifications in the start, stop sections. Save it to /etc/init.d/ folder and set the executions rights (chmod +x /etc/init.d/your-script-name).

#! /bin/sh
### BEGIN INIT INFO
# Provides:          your-script-name
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

# Some scripts that run always (it is not mandatory...)
touch /var/lock/your_script

# Carry out specific functions when asked to by the system
case "$1" in
 start)
    echo "Starting script your-script-name"
    echo "Some info about..."
    /usr/local/bin/your-script #of course, this is an example
    ;;
 stop)
    echo "Stopping script your-script-name"
    echo "Some info about..."
    killall -9 your-script #of course, this is an example
    ;;
 restart)
    $0 stop
    $0 start
    ;;
 *)
    echo "Usage: /etc/init.d/your-script-name {start|stop|restart}"
    exit 1
    ;;
esac

exit 0

##################### End script

# Adding the init.d script to default targets (in this case to level 2,3,4, and 5, see the script headers)
root@linuxhorizon:~# update-rc.d your-script-name defaults

# Removing
root@linuxhoriozn:/etc/rc2.d# update-rc.d -f your-script-name remove

The second option:

Making the rc.local script

root@linuxhorizon:~# cat > /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/put/your/script/here

exit 0
############### End rc.local

root@linuxhorizon:~# chmod +x /etc/rc.local
root@linuxhorizon:~# systemctl start rc-local
root@linuxhorizon:~# systemctl status rc-local


Now it's a good time for a coffee! :) By the way, do you know how it look the caffeine molecule? Probably you don't, so here it is, click to enlarge!

The magic of REISUB

When everything goes wrong and you graphic interface (X) will stop responding (dead, hung, freeze etc.) there is a magic word who can save you from a disastrous reboot by powering down your computer

First, type "R" (the letter) while holding down Alt and SysRq (PrintScrn). This shortcut can give you the contorl over the keyboard letting you to switch to console mode (Ctrl-Alt-Fx, while x is is your terminal as F1, F2 etc.). If this is not working you can try the next step:

Type the phrase “REISUB” while holding down Alt and SysRq (PrintScrn) with about 1 second between each letter. Your system will reboot. 

For a shutdown, REISUO will do the trick. :)

But what are those letters do?

r – Puts the keyboard into raw mode, taking control of it away from the X server.
e – Sends the terminate signal to all processes, asking them to end gracefully.
i – Sends the kill signal to all processes, forcing them to end immediately.
s – Flushes data from your cache to disk.
u – Remounts all file systems read-only.
b – Reboots your computer.
o - Shutdown your computer.

You can try step by step one the letters, maybe you are lucky enough to gain control over your computer without rebooting (the letter B).

An Ubuntu cheat sheet could be found here: https://files.fosswire.com/2008/04/ubunturef.pdf

The rkhunter (1.4.2) update issue

I found that the rkhunter v1.4.2 (Debian distro, I don't know about other flavors or versions) had a strange problem. Installed for the first time, I can not update it: 

host:/root# rkhunter --update
Invalid WEB_CMD configuration option: Relative pathname: "/bin/false"

Fixing this in config file (/etc/rkhunter.conf) by removeing /bin/false between quotes I had another error:

ns3:/etc# rkhunter --update
[ Rootkit Hunter version 1.4.2 ]

Checking rkhunter data files...
Checking file mirrors.dat                            [ Skipped ]
Checking file programs_bad.dat                       [ Update failed ]
Checking file backdoorports.dat                      [ Update failed ]
Checking file suspscan.dat                           [ Update failed ]
Checking file i18n versions                          [ Update failed ]

So, digging a little bit I found the following solution. All you need is to replace the followings in the /etc/rkhunter.conf file:

From UPDATE_MIRRORS=0     to UPDATE_MIRRORS=1
From MIRRORS_MODE=1       to MIRRORS_MODE=0
From WEB_CMD="/bin/false" to WEB_CMD=""

The funny thing is that in the rkhunter.conf comments, the recommended values are good. :)

GoldenEye? No! Tuesday! And is much worse!

Tuesday's massive outbreak of malware that shut down computers around the world has been almost universally blamed on ransomware, which by definition seeks to make money by unlocking data held hostage only if victims pay a hefty fee. Now, some researchers are drawing an even bleaker assessment—that the malware was a wiper with the objective of permanently destroying data.

Full story here: https://arstechnica.com/security/2017/06/petya-outbreak-was-a-chaos-sowing-wiper-not-profit-seeking-ransomware/

[0day] [exploit] Advancing exploitation: a scriptless 0day exploit against Linux desktops

A powerful heap corruption vulnerability exists in the gstreamer decoder for the FLIC file format. Presented here is an 0day exploit for this vulnerability.

This decoder is generally present in the default install of modern Linux desktops, including Ubuntu 16.04 and Fedora 24. Gstreamer classifies its decoders as “good”, “bad” or “ugly”. Despite being quite buggy, and not being a format at all necessary on a modern desktop, the FLIC decoder is classified as “good”, almost guaranteeing its presence in default Linux installs.

Thanks to solid ASLR / DEP protections on the (some) modern 64-bit Linux installs, and some other challenges, this vulnerability is a real beast to exploit.

Most modern exploits defeat protections such as ASLR and DEP by using some form of scripting to manipulate the environment and make dynamic decisions and calculations to move the exploit forward. In a browser, that script is JavaScript (or ActionScript etc.) When attacking a kernel from userspace, the “script” is the userspace program. When attacking a TCP stack remotely, the “script” is the program running on the attacker’s computer. In my previous full gstreamer exploit against the NSF decoder, the script was an embedded 6502 machine code program.

But in order to attack the FLIC decoder, there simply isn’t any scripting opportunity. The attacker gets, once, to submit a bunch of scriptless bytes into the decoder, and try and gain code execution without further interaction...

… and good luck with that! Welcome to the world of scriptless exploitation in an ASLR environment. Let’s give it our best shot.

The news was posted here by Chris Evans aka scarybeasts.

A day to remember! IoT botnet or when the decepticons army get to life.

Article published on the Linux Horizon website 

October 21, 2016 - A day to remember. The IoT gets to life but not in the good way.

Friday, October 21 was the day when the IoT decepticons army had the first stroke. Unfortunately is not a movie but this even have lot things in common with the Transformers movie.

In few words, the IoT botnet lunched the biggest large distributed denial-of-service attacks targeting the Krebs on Security website take it down for a while.

Well, in the IT security filed the things are moving fast, but this time was unexpected a such large attack using a botnet designed primary to penetrate and take control over BusyBox systems.

According to Javvad Malik, one of the AlienVault cyber-security specialists, and I quote, "The Mirai botnet is malware designed to take control of the BusyBox systems that are commonly used in IoT devices. BusyBox software is a lightweight executable capable of running several Unix tools in a variety of POSIX environments that have limited resources, making it an ideal candidate for IoT devices. It appears the DDoS attacks of October 21 have been identified as sourced from XiongMai Technologies IoT equipment.".

The peak power was reached on September 20, 2016 when the Mirai botnet delivered 620 Gbps DDoS traffic to Krebs on Security website.

That's was a record! 620 Gbps generated by IoT devices??? Wow!

Do you think that was enough? Well, is more than that.
The person who appear to be responsible for the attack, Anna-senpai published the source-code of the Mirai botnet client, loader and CNC console: http://hackforums.net/showthread.php?tid=5420472
For those who don't have hackforum account, the source was posted also on Github: https://github.com/jgamblin/Mirai-Source-Code/

Hmmm... Source-code of a malware tool, do we want to release the demons in the dark? Well, yes! Even so, publishing the source-code it's a good thing after all. :)

Reference:

• https://www.alienvault.com/blogs/security-essentials/the-mirai-botnet-tip-of-the-iot-iceberg
• https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
• http://www.linuxhorizon.ro/mirai-iot-botnet.html

Linux-in-the-middle - Linux box as transparent bridge

The linux box as transparent bridge

Sometime we can not mirror a switch port in order to access the data that are traveled on the wire... In this case how can we listen the data traffic? You can install a hub but on modern networks hubs that can sustain actual traffic speed is hard or even impossible to find.

So, what is the solution?
Well, the might Linux is here to help you. Of course, you need a laptop or another device (Raspberry PI?!?) with at least 3 network interfaces.


Actually, we will transform the linux box into a bridge

Before setting the bridge interface with brctl you should install the tools contained by bridge-utils package.

For debian like distros all you have to do is:

As root: apt-get install bridge-utils


This is a bridge script. Notice that only eth1 and eth2 interfaces are include into the bridge. The eth0 is left for it's usual purpose.

#!/bin/bash

/etc/init.d/networking stop

#Initializing bridge and interfaces
ifconfig br0 down
ifconfig eth1 down
ifconfig eth2 down
brctl delif br0 eth1
brctl delif br0 eth2
brctl delbr br0

sleep 1
echo "Bridge should be empty by now..."
brctl show
echo
echo
#Starting the bridge
echo "Bridge construction started..."
ifconfig eth1 0.0.0.0 up
ifconfig eth2 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth1
brctl addif br0 eth2
brctl stp br0 off
echo "Bridge rised!"
echo "1" > /proc/sys/net/ipv4/ip_forward
ifconfig br0 up
brctl show
brctl showstp br0
brctl showmacs br0
# END script

Now all you can do is to interconnect your linux box in the middle of a network connection as follows (for ASCII art fans):

+----------------+     +--------------+     +-------------+
|                |     |              |     |             |
| Local network  +-----+  Linux box   +-----+ Workstation |
|                |     |              |     |             |
+----------------+     +--------------+     +-------------+

The bridge is transparent and you should not worry about what interface (we are talking only about eth1 and eth2) should be connected to the workstation or to the local network.

Now, you can dig into the network traffic listening the br0 interface... The tcpdump will show his magic. :)