Security Posts

Monitoring SSL VPN Gateways - A Step-by-Step Guide

BreakingPoint Labs Blog - Wed, 2020/09/23 - 12:46
Virtual private network (VPN) connectivity is one of the most critical services in today’s…
Categories: Security Posts

Assess the Effectiveness of Dynamic NGFW Updates: Palo Alto Security Audit

BreakingPoint Labs Blog - Wed, 2020/09/23 - 12:46
One benefit of breach and attack simulation is continuous assessment, and I set Keysight Threat…
Categories: Security Posts

Assess Cloud-based Web Application Firewalls with Breach and Attack Simulation

BreakingPoint Labs Blog - Wed, 2020/09/23 - 12:46
Securing your web applications is a necessity. As the 2020 Verizon DBIR reports, web application…
Categories: Security Posts

Lessons Learned from Verizon DBiR 2020

BreakingPoint Labs Blog - Wed, 2020/09/23 - 12:46
Verizon had just released its annual Data Breach Incident Report (DBiR) 2020. It analyzes 32,002…
Categories: Security Posts

StreamDivert: Relaying (specific) network connections

Fox-IT - Thu, 2020/09/10 - 10:14
Author: Jelle Vergeer The first part of this blog will be the story of how this tool found its way into existence, the problems we faced and the thought process followed. The second part will be a more technical deep dive into the tool itself, how to use it, and how it works. Storytime About 1½ half years ago I did an awesome Red Team like project. The project boils down to the following: We were able to compromise a server in the DMZ region of the client’s network by exploiting a flaw in the authentication mechanism of the software that was used to manage that machine (awesome!). This machine hosted the server part of another piece of software. This piece of software basically listened on a specific port and clients connected to it – basic client-server model. Unfortunately, we were not able to directly reach or compromise other interesting hosts in the network. We had a closer look at that service running on the machine, dumped the network traffic, and inspected it. We came to the conclusion there were actual high value systems in the client’s network connecting to this service..! So what now? I started to reverse engineer the software and came to the conclusion that the server could send commands to clients which the client executed. Unfortunately the server did not have any UI component (it was just a service), or anything else for us to send our own custom commands to clients. Bummer! We furthermore had the restriction that we couldn’t stop or halt the service. Stopping the service, meant all the clients would get disconnected and this would actually cause quite an outage resulting in us being detected (booh). So.. to sum up:
  • We compromised a server, which hosts a server component to which clients connect.
  • Some of these clients are interesting, and in scope of the client’s network.
  • The server software can send commands to clients which clients execute (code execution).
  • The server has no UI.
  • We can’t kill or restart the service.
What now? Brainstorming resulted in the following:
  • Inject a DLL into the server to send custom commands to a specific set of clients.
  • Inject a DLL into the server and hook socket functions, and do some logic there?
  • Research if there is any Windows Firewall functionality to redirect specific incoming connections.
  • Look into the Windows Filtering Platform (WFP) and write a (kernel) driver to hook specific connections.
The first two options quickly fell of, we were too scared of messing up the injected DLL and actually crashing the server. The Windows Firewall did not seem to have any capabilities regarding redirecting specific connections from a source IP. Due to some restrictions on the ports used, the netsh redirect trick would not work for us. This left us with researching a network driver, and the discovery of an awesome opensource project: WinDivert (Thanks to DiabloHorn for the inspiration). WinDivert is basically a userland library that communicates with a kernel driver to intercept network packets, sends them to the userland application, processes and modifies the packet, and reinjects the packet into the network stack. This sounds promising! We can develop a standalone userland application that depends on a well-written and tested driver to modify and re-inject packets. If our userland application crashes, no harm is done, and the network traffic continues with the normal flow. From there on, a new tool was born: StreamDivert.  StreamDivert StreamDivert is a tool to man-in-the-middle or relay in and outgoing network connections on a system. It has the ability to, for example, relay all incoming SMB connections to port 445 to another server, or only relay specific incoming SMB connections from a specific set of source IP’s to another server. Summed up, StreamDivert is able to:
  • Relay all incoming connections to a specific port to another destination.
  • Relay incoming connections from a specific source IP to a port to another destination.
  • Relay incoming connections to a SOCKS(4a/5) server.
  • Relay all outgoing connections to a specific port to another destination.
  • Relay outgoing connections to a specific IP and port to another destination.
  • Handle TCP, UDP and ICMP traffic over IPv4 and IPv6.
Schematic inbound and outbound relaying looks like the following: Relaying of incoming connections Relaying of outgoing connections Note that StreamDivert does this by leveraging the capabilities of an awesome open source library and kernel driver called WinDivert. Because packets are captured at kernel level, transported to the userland application (StreamDivert), modified, and re-injected in the kernel network stack we are able to relay network connections, regardless if there is anything actually  listening on the local destination port. The following image demonstrates the relay process where incoming SMB connections are redirected to another machine, which is capturing the authentication hashes. Example of an SMB connection being diverted and relayed to another server. StreamDivert source code is open-source on GitHub and its binary releases can be downloaded here. Detection StreamDivert (or similar tooling modifying network packets using the WinDivert driver) can be detected based on the following event log entries:
Categories: Security Posts

Disinfection of PPE such as N95 respirator masks

Niels Provos - Sun, 2020/03/29 - 18:29
An article from Consolidated Sterilizer Systems starts with: "With the global Covid-19 pandemic everywhere in the news, many healthcare professionals and concerned citizens are grappling with the shortage of respirator masks, vital tools for ensuring that healthcare workers are not infected by the people they’re trying to help."

The article suggests that microwave steam based disinfection has been effective at disinfecting, specifically removing H1N1, from non-metal N95 respirator masks. Here is a 3D grid that can be placed into a glass tupperware container filled with some water and then put into a microwave. Don't put anything with metal into the microwave. Alternatively, you can use this grid in the oven as well; see the description in the article.

This grid is 4.4" square and 1.25" tall. It's easy for me to produce any other dimensions.

The log reduction for microwave steam is around ~5, i.e. 100,000 times less viable virus. The article does not give a protocol. I put the filter in the microwave for 3 minutes which was sufficient to boil the water for 2 minutes. For oven steam, the protocol requires 3 hours under warm water steam and let to a slightly smaller log reduction of ~4.8, i.e. 63,000 times less viable virus. This requires an oven that has good temperature control.

Disclaimer: It is unclear if this is effective for disinfection. Even with high-temperature filament, it is unclear if a 3d printed grid is appropriate for this application.
Categories: Security Posts

Thu, 1970/01/01 - 02:00
Syndicate content