Tuesday 13 February 2018

Alkaline battery capacity

Remaining capacity of
AA / AAA alkaline batteries
(not a cyber security info but useful for hobbies)

* New unused alkaline batteries have 1.55-1.65 V
** Unused but on shelf for more than a year have 1.50-1.55 V

by Arduino_Mother_Hacker

Monday 16 October 2017

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)
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:
or only

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

Generate again the new locales:

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.

Thursday 28 September 2017

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.

Wednesday 13 September 2017

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...

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:

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
# 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.

# 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
    echo "Starting script your-script-name"
    echo "Some info about..."
    /usr/local/bin/your-script #of course, this is an example
    echo "Stopping script your-script-name"
    echo "Some info about..."
    killall -9 your-script #of course, this is an example
    $0 stop
    $0 start
    echo "Usage: /etc/init.d/your-script-name {start|stop|restart}"
    exit 1

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.


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!

Tuesday 12 September 2017

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

Friday 1 September 2017

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 WEB_CMD="/bin/false" to WEB_CMD=""
The funny thing is that in the rkhunter.conf comments, the recommended values are good. :)

Friday 30 June 2017

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/

Wednesday 23 November 2016

[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.

Tuesday 25 October 2016

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. :)