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

Reference:

Thursday, 21 April 2016

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

Wednesday, 25 November 2015

Seahorse "Gnome2 key storage" unlock issue

The issue: 
Seahorse -> Certificates -> "Gnome2 Key Storage" folder unable to unlock

The fix:
  1. Close seahorse
  2. Make a backup of the ~/.local/share/keyrings/user.keystore file and remove it.
  3. Start seahorse again

Thursday, 19 November 2015

Friday, 23 October 2015

Mounting a NTFS partition saved as iso file

Simple as that, ntfs-3g does the magic:

root@ubuntu:/home/partimag/2015-10-22-15-img# ntfs-3g sda4.iso /dir-to-mount-location/

This example is somehow correlated with http://cybersec-linuxhorizon.blogspot.ro/2015/10/partclone-v0273-bug.html

Do not try to mount as loop (mount -o loop) because is not working...


Partclone (v0.2.73) bug

Restoring a Clonezilla partition backup using partclone v0.2.73 could fail as follow:

root@ubuntu:/home/partimag/2015-10-22-15-img# cat /home/partimage/sda4.ntfs-ptcl-img.gz.aa | gzip -d -c | partclone.restore -C -s - -O /home/partimage/sda4.iso
Partclone v0.2.73 http://partclone.org
Starting to restore image (-) to device (sda4.iso)
device (sda4.iso) is mounted at
error exit
Partclone fail, please check /var/log/partclone.log !


Digging a little bit, I found that the reason is very simple and I do not know if I can call it a bug or not.

Pure and simple, before running the restoring command you should create the iso file. In my example, you should create the sda4.iso file and the simple way is:

root@ubuntu:/home/partimag/2015-10-22-15-img#touch sda4.iso

I'm pretty sure that other partclone versions have the same issue...

I must say that Clonezilla distribution is a very useful tool for disk and/or partition cloning/restoring. Partclone is included in the Clonezilla distribution.

If your recovered partition is NTFS and want to mount it, use ntfs-3g as here: http://cybersec-linuxhorizon.blogspot.ro/2015/10/mounting-ntfs-partition-saved-as-iso.html