Uncategorized

SEC-Labs recognized at August 2018 Security Researcher’s list at MSRC

msrc
The Microsoft Security Response Center (MSRC) is pleased to recognize the security researchers who have helped make Microsoft online services safer by finding and reporting security vulnerabilities. Each name listed represents an individual or company who has privately disclosed one or more security vulnerabilities in our online services and worked with us to remediate the issue.

 

Both Stefan Schörling and Mattias Borg from SEC-LABS R&D is recognized at the Microsoft Security Response Center security researchers list for August 2018.

This was due to a vulnerability discovered with Johan Dahlbom and was reported to Microsoft.

We would like to give our appreciation to the MSRC team and it was a pleasure working with you to resolve this issue!

The list can be found here:
https://www.microsoft.com/en-us/msrc/researcher-acknowledgments-online-services

SSH native in Windows 10 1803

If you manage a mixed platform your might be switching between, RDP sessions, Remote PowerShell and other remote Tools.

Except for old legacy applications which may not be possible to manage without a GUI, it’s easier, possible to automate and will save you a lot of time using a command line interface.

To extend this support, there is now a native SSH client in Windows.

You may want to check your firewall rules to Control who and where admins can connect and what you need to block

KrackAttack – Vulnerability in WPA2 – Disclosed

A security researcher Mathy Van Hoef will disclose a vulnerability in WPA2 within a few hours.

The vulnerability leaves Wi-Fi traffic open to eavesdropping and it will be possible to inject malicious content and much more.

CVE’s
CVE-2017-13077
CVE-2017-13078
CVE-2017-13079
CVE-2017-13080
CVE-2017-13081
CVE-2017-13082

 

Important URLs
https://www.krackattacks.com/
https://github.com/valentijnscholten/krackattacks/

 

Van Hoef on Twitter
https://twitter.com/vanhoefm

::Updates::

From Krackattacks.com

Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):

  • Basically all Wireless networks are vulnerable and the vendors are working to get the patches out.
  • Microsoft was mitigating this on the client side in the October patch release cycle
  • If you won’t get an update to your router your really only option is to get a new one (if it’s out of support)
  • Recommendations are to apply patches as soon as they’re available.

 

 

This post will be updated

Security by obscurity is not so obscure

This scenario was discoverd in the real world.

A VPN solution which had a device verification functionality which is all fine but the problem was that the verification is executed only on the client side.

And you don’t only want to protect from external attackers but also users connecting their home PC to the internal network.

We only want managed devices on the inside and one unmanaged home device with i.e. no AV and lots of keyloggers and other malicious code running.

When this kind of verifications are executing on the client side there is no guarantee that the outcome is correct (which is why certificate based authentication is prefered as one of the factors since you can assure that it’s your internal device)

In this example there was a client side verification which was querying  (amongst other things) a file on the local system.

The endpoint compliancy failed due to some security setting

Remediation required

Let’s do the same thing again with procmon running

The service tries to query for a file in the c:\windows\system32 folder xxx.dll

So we create an empty dummy file, xxx.dll.

When we try to connect again with process monitor running we have a different result.

And we are prompted for user name and password, and hopefully this customer has an extra factor of protection, like SMS or certificate

Certificate is the best way to verify a device, to verify a user it depends on your identity management and how you choose to manage the identities and how to verify them