SECURITY.TXT

While listening to a recent episode of Security Now Steve Gibson discussed some help that is on the way for securing web sites and services. I have not seen much mention of it anywhere else but I feel that it is definitely something worth noting.

When it comes to identifying security risks in web sites and services a major problem in the industry has been two-fold. First security researchers have been weary of testing the security of a sites and services because of legal action that may be taken against them and second when and if they do test a site, and they discover a vulnerability in the site or service, there often lacks a way to properly disclose the vulnerability to the developers. Because of the lack of disclosure options often the identified vulnerability just goes unreported and therefore remains out in the wild providing the adversary with many avenues and vulnerabilities to attack.

This is where a web developer and security researcher, Ed Foudil, and what he has submitted to the IETF, steps in to save the day. Mr. Foudil has graciously submitted to the IETF a draft that seeks to standardize SECURITY.TXT. According to securitytxt.org "The main purpose of the security.txt file is to help make things easier for companies and security researchers when trying to secure platforms. Thanks to security.txt, security researchers can easily get in touch with companies about security issues."

Security.txt is a simple text file, similar to a robot.txt file, located in the root directory of a website that defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities that they have identified. Not only does this file provide you with the proper contact information but it also provides one with a secure way to transfer the information as outlined below taken from the draft IETF which can be read HERE

2.4.  Encryption:
   This directive allows you to add your key for encrypted
   communication.  You MUST NOT directly add your PGP key.  The value
   MUST be a link to a page which contains your key.  Keys SHOULD be
   loaded over HTTPS.
   <CODE BEGINS>
   Encryption: https://example.com/pgp-key.txt
   <CODE ENDS>

As Steve Gibson said "this is so simple it's brilliant" and should be applauded!

CYBER SECURITY LAB USING MICROSOFT HYPER-V PART 1

CYBER SECURITY LAB USING MICROSOFT HYPER-V

PART  1

This series of blog posts will outline the steps taken to stand up a cyber security lab using Microsoft's Hyper-V. This lab will be used for everything from running Kali LINUX penetration testing tools, offensive countermeasures and techniques using tools like Active Defense Harbinger Distribution, cyber forensics, and anything else that I may choose. I will be using a hosted Hyper-visor for the lab, Microsoft's Client Hyper-V running on Windows 10 Professional. Anyway, enough is enough let’s get started!

The first thing we have to do is to navigate to Control Panel -> All Control Panel Items  ->  Programs and Features.

Next enable the Hyper-V option

After Windows installs the Hyper-V feature you will need to reboot your host system. Once the host comes back up we will begin customizing some of the Hyper-V settings. The first setting that will be configured will be the Server settings. The server settings affect how the Hyper-V server functions.

The first server setting that we will configure is Virtual Hard Disks (VHD). The VHD setting identifies where on our host system the vhd (or vhdx) files will be stored.

After identifying where to store the vhd and vhx files we will do the same for Virtual Machines. On the left pane select Virtual Machines. This setting specifies the default folder to store vm configuration files.

Next is Physical GPUs. This setting determines whether or not VMs with have direct hardware access to any installed GPUs on our host system. This setting is not applicable to our environment so we will make sure that Use this GPU with RemoteFX is unchecked.

We will also leave the next setting, NUMA Spanning and Storage Migrations alone as it too is not applicable to our environment (if you want to know more about this setting you can read about it at https://technet.microsoft.com/en-us/library/dn282282(v=ws.11).aspx). We will also not be doing anything with the Storage Migrations setting as we really don’t have a need to move or migrate any VMs in our lab environment.

The final server setting, Enhanced Session Mode Policy, is one of the most import. You can find out more about it HERE but in a nutshell this setting provides functionality similar to the way RDP allows access to local resources and Enhanced Session Mode brings similar functionality using VMConnect. One needs to be very careful with this feature because this is where one can break segmentation and isolation between the VM host and the VMs in the lab setup. And since we will be using this lab for all sorts of nefarious things as a precaution we will NOT be enabling this feature. We can always enable it in the future should it be needed.

Finally, we have the User Settings. These are pretty straight forward and do not require any customizing. The only thing to check and verify is ensure that the Use enhanced session mode box is unchecked. Once complete click APPLY and then OK

DID SOMEBODY SAY KRACK?!

DID SOMEBODY SAY KRACK?!

What is KRACK?

KRACK is the acronym for Key Reinstallation Attacks.

Earlier this week it was revealed publicly that computer security researcher Mathy Vanhoef (@vanhoefm) had discovered a “serious weakness” in the Wi-Fi Protected Access 2 (WPA2) protocol. This is indeed important because WPA2 is by far the most popular encryption standard for Wi-Fi networks in use today and is pretty much the de facto standard for securing all Wi-Fi networks. Everything from home Wi-Fi to public hotspots up to enterprise wireless networks rely on the confidentiality and integrity provided by the WPA2 protocol.

How an attack using KRACK works?

The vulnerabilities identified by Vanhoef is in the Wi-Fi standard itself and not in any one individual product. This means that any attack that is successfully able to exploit these vulnerabilities will work against any properly configured WPA2 protected network.

The main attack vector is against the WPA2 protocol’s 4-way handshake. This handshake is performed when a client requests to join the targeted Wi-Fi network. The handshake is used to authorize a device, through a credentialing process, when connecting to an access point. At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all traffic from the newly connected device.

Vanhoef explains the attack method at a high level on his site krackattacks.com. He states that “In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice”.

Is this the end of secure Wi-Fi?

For the sake of brevity, I will keep my answer short. Individuals and enterprises should be concerned but no this is not the end of secure WiFi...Yet.

For starters, Although Vanhoef shows that these exploits are possible they are still primarily academic, as there has yet to be seen an attack exploiting the recently disclosed vulnerabilities in the wild. It was noted by security architect Kevin Beaumont, on his blog, that there is currently no publicly available code to carry out the attack and that it would require an “incredibly high skill set” to execute this type of attack (KRACK). Additionally, it has been identified by other researchers that KRACK may require a threat actor to be in close proximity to the victim they are attempting to compromise. This greatly limits the potential for a widespread attack but it does leave the door open for more targeted attacks.

So, what are we to do?
                                                                       

First and foremost, the obvious. The first thing anyone should be doing is looking out for vendor patches. The bright side to all of this, if there is one, is that KRACK was first disclosed to vendors back in July (2017) and revealed to the Community Emergency Response Team (CERT) Communication Center as well. CERT then distributed a comprehensive exposure of KRACK back in August thus providing more than adequate time to vendors to prepare patches before disclosure to the public. As I sit here and prepare this post Microsoft has indicated that it has already patched the KRACK vulnerability. In a statement to The Verge Microsoft said “We have released a security update to address this issue. Customers who apply the update, or have automatic updates enabled, will be protected. We continue to encourage customers to turn on automatic updates to help ensure they are protected.”

At the enterprise level mitigations for KRACK attacks (or any type of eavesdropping) should start at the foundation with a secure design of the wireless infrastructure. This should include the use of range-limiting antennas, limiting signal output strength on radio cards, and placing wireless access points away from the exterior walls of buildings thus reducing the amount of wireless traffic that is sent outside of a buildings physical boundary. Another strong mitigation is the use of a VPN when not on a trusted Wi-Fi network. A VPN will protect the data in transit encrypting the connection between the device and the remote server. This will shield the data from anyone on the untrusted public network. Including an attacker that may be attempting to exploit KRACK.