• Edit 1 (2018-01-05): Add FreeBSD
  • Edit 2 (2018-01-06): add several links, official info from Apple
  • Edit 3 (2018-01-08): Web browser section, new link, AV, tools
  • Edit 4 (2018-01-09): AlienVault,iOS, PoC
  • Edit 5 (2018-01-15): Add flog to chrome, PoC

Summary

Introduction

As usual there are two (not so ?) new security flaws. But this time it is related to the hardware and more specifically to the processor by 3 different vendors (AMD, ARM and Intel).

So here is a synthesis of every information I have collected on the Net. Thanks to all people who reported and/or provided links/information/tools/PoC.

CVE references

Communication from researchers

Communication from vendors (hardware, software, hoster, cloud based solution)

Analysis, demos, resources, mitigations, PoC, recommendations, tools

My obvious recommendations are to patch ASAP, but as we know it is not so obvious. Maybe you can start by patching web browser and apply correct settings, there will be some exploit in the wild in a couple of hours/days. Another important information is the relationship between Anti-Virus and windows patches, there are some recommendations about this on the MS website

Web browser information

Patch issues

  • AMD CPUs and MS Patch issue
  • About performance and PCID

Sources of information




Summary

Introduction

During the latest GreHack CTF (2017) there was a simple 150 points network challenge (easier than the 50 points exploit challenge ;-) ).

The text of the challenge invited us to listen to the port 4242.

Solution

Thanks to the netcat command we detected a SSH connection attempt. We had to wait a while (as we understood, all IP addresses of each VLAN have been scanned in loop).

In order to catch the traffic we decided to use sshesame, a fake SSH server.

For that you just need to install the golang package on your favorite Linux OS (Kali Linux for instance) and run go get -u github.com/jaksi/sshesame to download the sources and compile the program.

At this time we were ready to catch the SSH traffic and check if there was some insteresting stuff like a password or a username.

./sshesame -port 4242 -listen_address 192.168.142.201

But at the first connection we got an error message because we run sshesame with the default cryptographic configuration: ED25519. The bot tried to use RSA or DSA.

The simplest way for sshesame is to create the private/public keys (the RSA ones in our case).

ssh-keygen -t rsa

And re-run the command with the good option.

./sshesame -port 4242 -listen_address 192.168.142.201 -host_key id_rsa

After a while, we received these information:

WARN[3888] Failed to establish SSH connection:[]        
WARN[3888] Failed to establish SSH connection:[]        
WARN[3888] Failed to establish SSH connection:[]        
WARN[3888] Failed to establish SSH connection:[]        
WARN[3888] Failed to establish SSH connection:[]        
INFO[3898] Client connected                              client="192.168.4.30:54620"
INFO[3899] Client connected                              client="192.168.4.30:54630"
INFO[3899] Client connected                              client="192.168.4.30:54636"
INFO[3899] Client connected                              client="192.168.4.30:54646"
INFO[3899] Client connected                              client="192.168.4.30:54650"
INFO[3899] Client connected                              client="192.168.4.30:54662"
INFO[3899] Password authentication accepted              client="192.168.4.30:54646" password=admin user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established                    client="192.168.4.30:54646"
INFO[3899] Password authentication accepted              client="192.168.4.30:54636" password=root user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established                    client="192.168.4.30:54636"
INFO[3899] Password authentication accepted              client="192.168.4.30:54662" password="GH17{bruteforce_is_not_hacking}" user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established                    client="192.168.4.30:54662"
INFO[3899] Password authentication accepted              client="192.168.4.30:54650" password=123456 user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established                    client="192.168.4.30:54650"
INFO[3899] Password authentication accepted              client="192.168.4.30:54630" password=toor user=root version=SSH-2.0-libssh2_1.8.0
INFO[3899] SSH connection established                    client="192.168.4.30:54630"
INFO[3899] Client connected                              client="192.168.4.30:54664"
INFO[3899] Client connected                              client="192.168.4.30:54666"
INFO[3899] Client connected                              client="192.168.4.30:54668"
INFO[3899] Client connected                              client="192.168.4.30:54670"
INFO[3899] Client disconnected                           client="192.168.4.30:54662"
INFO[3899] Client disconnected                           client="192.168.4.30:54646"
INFO[3899] Client connected                              client="192.168.4.30:54672"
INFO[3899] Client disconnected                           client="192.168.4.30:54630"
WARN[3899] Failed to establish SSH connection:[no auth passed yet] 

It was a SSH - bruteforce.

And if you check each login/password you find this entry:

INFO[3899] Password authentication accepted              client="192.168.4.30:54662" password="GH17{bruteforce_is_not_hacking}" user=root version=SSH-2.0-libssh2_1.8.0

And the password was corresponding to the flag format: “GH17{bruteforce_is_not_hacking}”

Conclusion

This (easy) challenge was related to this interesting talk Down The Rabbit Hole: How Hackers Exploit Weak [SSH] Credentials To Build DDoS Botnets we saw before the CTF.

Thanks for the challenge.




Supprimer les snapshots des mises à jour windows

A exécuter en tant qu’administrateur :

Vssadmin delete shadows /all /quiet

Le lien officiel sur le site Technet de Microsoft : Vssadmin delete shadows



Other articles