WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me
Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

 


This will be short and sweet, if you have privileges to boot your PC into safe mode you can follow the following steps to delete the affected update.


Crowd Strike Workaround Steps:

  1. Boot Windows into Safe Mode or the Windows Recovery Environment

  2. Navigate to the C:\Windows\System32\drivers\CrowdStrike directory

  3. Locate the file matching “C-00000291*.sys”, and delete it.

  4. Boot the host normally.

 

 

So Open SSL announced that they are going to release details of a Critical OpenSSL vulnerability that  affects versions 3.0.0 to 3.0.6. There is rumbling that this vulnerability may be a major deal likened to the everyone's favorite CVE of 2014, heartbleed. 

 

Open SSL will be releasing their patch/update Tuesday 1st November 2022 between 1300-1700 UTC


But unlike heartbleed this OpenSSL vulnerability might not have the same impact to security and network infrastructure that heartbleed had. So far most security and network infrastructure companies are looking ok. As you would expect many of these companies don't run the most bleeding edge versions of open source libraries for this very reason. Also many times stability and security take president over new features. 

 

What I wanted to do is put links to OSS (Open Source Software) lists that are used in different vendors platforms. I started out hopeful but for many of the companies it is very difficult to find. I will post hem as i run across them.

 

Cisco - https://www.cisco.com/c/en/us/about/legal/open-source-documentation-responsive.html

Palo Alto Networks - https://docs.paloaltonetworks.com/oss-listings/pan-os-oss-listings

Juniper - 

Fortinet -

Aruba - 

Arista - 

Extreme Networks - 

Checkpoint - 

F5 - 

Citrix ADC -

 

 


There is a new flavor of protocol reflection attacks on the streets!  

The TCP Middlebox reflection attack is the first reflection attack to utilize the TCP protocol. Traditionally the TCP protocol was not susceptible to spoofed source packets because of its state based nature (three way handshake).  Researchers at University of Maryland and the University of Colorado discovered that many network devices, such as load balancers, proxies, and firewalls, could be susceptible to specifically-crafted packets that could generate amplified traffic (up to 65x) at a victim.  These devices could be inherently susceptible to the spoofing because many of these devices have to contend with Asynchronous network traffic and out of order packets.

 

Akamai did a really great write up on what they saw and how they mitigated the attack. https://www.akamai.com/blog/security/tcp-middlebox-reflection

 

Shadow Server also has a write up. https://www.shadowserver.org/news/over-18-8-million-ips-vulnerable-to-middlebox-tcp-reflection-ddos-attacks/


So on to your firewalls:

The out of the box Palo Alto Firewalls do not appear to have any mitigation configured by default to protect against this attack.  But its not the end of the world.  Palo Alto and many other security vendors have low level TCP protection that basically normalizes TCP traffic and cuts out the flood attacks, malformed protocol attacks, etc., before they are even processed by your firewall. This minimizes  impact on the device resources like CPU and memory for these types of attacks.

 

In the Palo Alto world this is called "Zone Protection Profiles". If you run BPA (Best Practice Assessment) - which you should - then the Zone Protection Profiles are often flagged if you don't have them configured. 

 

The zone protection profile is pretty strait-forward to set up but, before you start, you need to do a little research and investigation into your device

  1. You need to determine the maximum CPS or connections per second your device can handle. This is a list of devices and their specs on the Palo Alto Networks site. https://www.paloaltonetworks.com/products/product-selection
  2. Next you will want capture some metrics around how many CPS your devices are seeing. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/zone-protection-and-dos-protection/zone-defense/take-baseline-cps-measurements-for-setting-flood-thresholds/how-to-measure-cps
  3. Next you will want to do a few calculations and configure your zone protection profile. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/zone-protection-and-dos-protection/zone-defense/zone-protection-profiles

 

Here is the "Cool SH*T Props" to Palo Alto Networks...when you create a zone protection profile, by default under the Packet Based Protection > and > 'TCP Drop the TCP SYN with Data' and 'TCP SYN ACK with Data' are already checked. This means when you apply your newly configured zone protection profile to your security zone it will protect you from current Middlebox vulnerability by dropping any of the cleverly crafted SYN packets because they would be larger then 0 bytes.

 


Yeah!


So I wanted to post a little bonus. Here is a quick and easy flood protection calculator I threw together in google sheets, just add your average CPS.








 

Enhanced Data Visualization Dashboard using Splunk

 

I am a fan of Palo Alto Networks NGFW, especially the visibility it can give you in to your traffic. PAN does a pretty good job within their management tools of organizing and reporting on the data, but most of us also have large SIEMs or Logging solutions like Elastic's ELK stack. Splunk, exabeam, etc.

Splunk being one of the more popular SIEM and logging solutions, I created a PAN Threat Dashboard I wanted to share. If you have Splunk running in your environment and the Splunk Palo Alto Networks add-on installed all the pre-defined fields should work correctly. If not, you may need to tweak 1 or 2 fields in the dashboard to make it work. When you copy the code from my GitHub save it in a text editor and perform the following steps.  It should be up and running in your environment in no time.

 
You will need to identify your Palo Alto firewall host= fields (how Splunk identifies the device sending logs) to populate the field2 drop down menus.
 

Directions:

  1. Log into Splunk and go to Search
  2. Click on Dashboards and Create a new Dashboard
  3. Once you have created your new dashboard go to edit and select source tab on the top
  4. Clear out the default text in the dashboard and copy and paste the dashboard from GitHub.
  5. Before you save the dashboard you will need to identify your Palo Alto firewall host= fields to populate the field2 drop down menus, I have space holders firewall-1, firewall-2, etc. configured currently

 

You should be good to go!

 

So SolarStorm the SolarWinds supply chain hack... Yeah.... You might have heard about it? 

 

SolarWinds supply chain was compromised. What that means is a trojanized version of a SolarWinds  package was uploaded and distributed to their clients .  The infected package contained malware named SUNBURST, and when clients installed the infected package it also installed the malware.  The malware creates a backdoor to allow the bad actors to control the server, move laterally, and exfiltrate data. Basically what ever they want....

 

 

 Updated Solarwinds Attack Lifecycle:


What should you do now:

 

As information starts to come out and the initial freak out calms down we are learning more about the impact of these exploits, and they are pretty huge. I wanted to gather a collection of information and vendor responses in one place to try to help fellow nerds have a resource of reliable information. 

 

SolarWinds

Fireeye Links

US Cybersecurity and Infrastructure Security Agency (CISA) 

Palo Alto Networks Unit 42

Check Point

Splunk

Mcafee

Microsoft

Infoblox

 Elasticsearch (Elastic Security)
Link to Blog post about Reverse Engineering the encoded  DGAs:
Cynet
Symantec
CrowdStrike
 
 
** is a link that has been added. I will also highlight them in Bold font.

**Update**
I have noticed that after upgrading Ubuntu to 20.04 or 22.04 I have run into a little snag.  It appears that the upgrade over rights the sysctl.conf file back to default values. The symptom is your wiregurad server will not be forwarded IP V4 or V6 traffic. 
 
To resolve the issue perform the following steps.
  1. sudo nano /etc/sysctl.conf
  2. net.ipv4.ip_forward = 1
  3. sudo sysctl -p
 
WireGuard is a simple, fast, and secure VPN that utilizes state-of-the-art cryptography. With a small source code footprint, it aims to be faster and leaner than other VPN protocols such as OpenVPN and IPSec. WireGuard is still under development, but even in its non optimized state it is faster than the popular OpenVPN protocol. In fact it connects so quickly you'll likely find your self going to whats my IP to insure your traffic is actually being tunneled.

The WireGuard configuration is as simple as setting up SSH. A connection is established by an exchange of public keys between server and client. Only a client that has its public key in its corresponding server configuration file is allowed to connect. WireGuard sets up standard network interfaces (such as wg0 and wg1), which behave much like the commonly found eth0 interface. This makes it possible to configure and manage WireGuard interfaces using standard tools such as ifconfig and ip. I was going to post a guide but there are so many good guides already on the internet just google it. Also the official documentation is really good and has some install guides as well.

Enjoy, be safe, support and contribute to WireGuard.