Tag: Exploit

Exploiting GraphQL
GraphQL is a query language inspired by the structure and functionality of online data storage and collaboration platforms Meta, Instagram, and Google Sheets. This post will show you how to take advantage of one of its soft spots.

Development

Facebook developed GraphQL in 2012 and then it became open source in 2015. It’s designed to let application query data and functionality be stored in a database or API without having to know the internal structure or functionality. It makes use of the structural information exchanged between the source and the engine to perform query optimization, such as removing redundancy and including only the information that is relevant to the current operation.

To use GraphQL, since it is a query language (meaning you have to know how to code with it), many opt to use a platform to do the hard work. Companies like the New York Times, PayPal, and even Netflix have dipped into the GraphQL playing field by using Apollo.

Apollo

Apollo Server is an open-source, spec-compliant tool that’s compatible with any GraphQL client. It builds a production-ready, self-documenting GraphQL API that can use data from any source.

Apollo GraphQL has three primary tools and is well documented.
- Client: A client-side library that helps you digest a GraphQL API along with caching the data that’s received.
- Server: A library that connects your GraphQL Schema to a server. Its job is to communicate with the backend to send back responses based off the request of the client.
- Engine: Tracks errors, gathers stats, and performs other monitoring tasks between the Apollo client and the Apollo server.
(We now understand that GraphQL is query language and Apollo is spec-compliant GraphQL server.)

A pentester’s perspective

What could be better than fresh, new, and developing technology? Apollo seems to be the king of the hill, but the issue here is the development of Apollo’s environment is dynamic and fast. Its popularity is growing along with GraphQL, and there seems to be no real competition on the horizon, so it’s not surprising to see more and more implementations. The most difficult part for developers is having proper access controls for each request and implementing a resolver that can integrate with the access controls. Another key point is the constant new build releases with new bugs.

Introspection

Batch attacks, SQLi, and debugging operations that disclose information are known vulnerabilities when implementing GraphQL. This post will focus on Introspection.

Introspection enables you to query a GraphQL server for information about the schema it uses. We are talking fields, queries, types, and so on. Introspection is mainly for discovery and as a diagnostic tool during the development phase. In a production system you usually don’t want just anyone knowing how to run queries against sensitive data. When they do, they can take advantage of this power. For example, the following field contains interesting information that can be queried by anyone on a GraphQL API in a production system with introspection enabled:

Let’s try it

One can obtain this level of information in a few ways. One way is to use Burp Suite and the GraphQL Raider plugin. This plugin allows you to isolate the query statement and experiment on the queries. For example, intercepting a post request for “/graphql”, you may see a query in the body, as shown below:

Using Burp Repeater with GraphQL we can change the query located in the body and execute an Introspection query for ‘name’ and see the response.

Knowing GraphQL is in use, we use Burp Extension GraphQL Raider to focus just on queries. Here we are requesting field names in this standard GraphQL request, but this can be changed to a number of combinations for more results once a baseline is confirmed.

This request is checking the ‘schema’ for all ‘types’ by ‘name’ . This is the response to that query on the right.

Looking further into the response received, we see a response “name”: “allUsers”. Essentially what is happening is we are asking the server to please provide information that has “name” in it. The response gave a large result, and we spot “allUsers”. If we queried that specific field, it would likely provide all the users.

The alternative would be to use CURL. You can perform the same actions simply by placing the information in a curl statement. So the same request as above translated over for Curl would be similar to:

You could opt to do this in the browser address bar as well, but that can be temperamental at times. So you can see how easy it is to start unraveling the treasure trove of information all without any authentication.

Even more concerning are the descriptive errors the system provides that can help a malicious attacker succeed. Here we use different curl statement to the server. This is the same request except that the query is for “system.”

When the request cannot be fulfilled, the server tries its best to recommend a legitimate field request. This allows the malicious attacker to formulate and build statements one error at a time if needed:

Pentest ToolBox

Ethical hackers would be wise to add this full request to their toolbox as it should provide a full request that provides a long list of objects, fields, mutations, descriptions, and more:
```
{__schema{queryType{name}mutationType{name}subscriptionType{name}types{...FullType}directives{name description locations args{...InputValue}}}}fragment FullType on __Type{kind name description fields(includeDeprecated:true){name description args{...InputValue}type{...TypeRef}isDeprecated deprecationReason}inputFields{...InputValue}interfaces{...TypeRef}enumValues(includeDeprecated:true){name description isDeprecated deprecationReason}possibleTypes{...TypeRef}}fragment InputValue on __InputValue{name description type{...TypeRef}defaultValue}fragment TypeRef on __Type{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name ofType{kind name}}}}}}}}
```
Ethical hackers, may want to add these to their directory brute force attacks as well:
- /graphql
- /graphiql
- /graphql.php
- /graphql/console
Conclusion

Having GraphQL introspection in production might expose sensitive information and expand the attack surface. Best practice recommends disabling introspection in production unless there is a specific use case. Even in this case, consider allowing introspection only for authorized requests, and use a defensive in-depth approach.

You can turn off introspection in production by setting the value of the introspection config key on your Apollo Server instance.

Although this post only addresses Introspection, GraphQL/Apollo is still known to be vulnerable to the attacks I mentioned at the beginning – batch attacks, SQLi, and debugging operations that disclose information – and we will address those in subsequent posts. However, the easiest and most common attack vector is Introspection. Fortunately, it comes with an equally simple remedy: Turn it off.
March 28, 2023
Log4j: How to Exploit and Test this Critical Vulnerability

UPDATE: On November 16, the Cybersecurity and Infrastructure Security Agency (CISA) announced that government-sponsored actors from Iran used the Log4j vulnerability to compromise a federal network, deploy Crypto Miner and Credential Harvester.

In this article Raxis, a top tier provider in cybersecurity penetration testing, demonstrates how a remote shell can be obtained on a target system using a Log4j open source exploit that is available to anyone.

Introduction

This critical vulnerability, labeled CVE-2021-44228, affects a large number of customers, as the Apache Log4j component is widely used in both commercial and open source software. In addition, ransomware attackers are weaponizing the Log4j exploit to increase their reach to more victims across the globe.

Our demonstration is provided for educational purposes to a more technical audience with the goal of providing more awareness around how this exploit works. Raxis believes that a better understanding of the composition of exploits it the best way for users to learn how to combat the growing threats on the internet.

Log4j Exploit Storyboard

The Apache Log4j vulnerability, CVE-2021-44228 (https://nvd.nist.gov/vuln/detail/CVE-2021-44228), affects a large number of systems, and attackers are currently exploiting this vulnerability for internet-connected systems across the world. To demonstrate the anatomy of such an attack, Raxis provides a step-by-step demonstration of the exploit in action. Within our demonstration, we make assumptions about the network environment used for the victim server that would allow this attack to take place. There are certainly many ways to prevent this attack from succeeding, such as using more secure firewall configurations or other advanced network security devices, however we selected a common “default” security configuration for purposes of demonstrating this attack.

Victim Server

First, our victim server is a Tomcat 8 web server that uses a vulnerable version of Apache Log4j and is configured and installed within a docker container. The docker container allows us to demonstrate a separate environment for the victim server that is isolated from our test environment. Our Tomcat server is hosting a sample website obtainable from https://github.com/cyberxml/log4j-poc and is configured to expose port 8080 for the vulnerable web server. No other inbound ports for this docker container are exposed other than 8080. The docker container does permit outbound traffic, similar to the default configuration of many server networks.

Note, this particular GitHub repository also featured a built-in version of the Log4j attack code and payload, however, we disabled it for our example in order to provide a view into the screens as seen by an attacker. We are only using the Tomcat 8 web server portions, as shown in the screenshot below.

Next, we need to setup the attacker’s workstation. Using exploit code from https://github.com/kozmer/log4j-shell-poc, Raxis configures three terminal sessions, called Netcat Listener, Python Web Server, and Exploit, as shown below.

Netcat Listener, Port 9001

The Netcat Listener session, indicated in Figure 2, is a Netcat listener running on port 9001. This session is to catch the shell that will be passed to us from the victim server via the exploit.

Python Web Server, Port 80

The Python Web Server session in Figure 3 is a Python web server running on port 80 to distribute the payload to the victim server.

Exploit Code, Port 1389

The Exploit session, shown in Figure 4, is the proof-of-concept Log4j exploit code operating on port 1389, creating a weaponized LDAP server. This code will redirect the victim server to download and execute a Java class that is obtained from our Python Web Server running on port 80 above. The Java class is configured to spawn a shell to port 9001, which is our Netcat listener in Figure 2.

Execute the Attack

Now that the code is staged, it’s time to execute our attack. We’ll connect to the victim webserver using a Chrome web browser. Our attack string, shown in Figure 5, exploits JNDI to make an LDAP query to the Attacker’s Exploit session running on port 1389.

The attack string exploits a vulnerability in Log4j and requests that a lookup be performed against the attacker’s weaponized LDAP server. To do this, an outbound request is made from the victim server to the attacker’s system on port 1389. The Exploit session in Figure 6 indicates the receipt of the inbound LDAP connection and redirection made to our Attacker’s Python Web Server.

The Exploit session has sent a redirect to our Python Web Server, which is serving up a weaponized Java class that contains code to open up a shell. This Java class was actually configured from our Exploit session and is only being served on port 80 by the Python Web Server. The connection log is show in Figure 7 below.

The last step in our attack is where Raxis obtains the shell with control of the victim’s server. The Java class sent to our victim contained code that opened a remote shell to our attacker’s netcat session, as shown in Figure 8. The attacker now has full control of the Tomcat 8 server, although limited to the docker session that we had configured in this test scenario.

Conclusion

As we’ve demonstrated, the Log4j vulnerability is a multi-step process that can be executed once you have the right pieces in place. Raxis is seeing this code implemented into ransomware attack bots that are searching the internet for systems to exploit. This is certainly a critical issue that needs to be addressed as soon as possible, as it is a matter of time before an attacker reaches an exposed system.

November 18, 2022
CVE-2022-35739: PRTG Network Monitor Cascading Style Sheets (CSS) Injection
I’m Matt Mathur, lead penetration tester here at Raxis. I recently discovered a cascading style sheet (CSS) injection vulnerability in PRTG Network Monitor.

Summary

PRTG Network Monitor does not prevent custom input for a device’s icon, which can be modified to insert arbitrary content into the style tag for that device. When the device page loads, the arbitrary CSS is inserted into the style tag, loading malicious content. Due to PRTG Network Monitor preventing “ characters, and from modern browsers disabling JavaScript support in style tags, this vulnerability could not be escalated into a Cross-Site Scripting vulnerability.

Proof of Concept

The vulnerability lies in a device’s properties and how they are verified and displayed within PRTG Network Monitor. When editing or creating a device, the device’s icon value is not verified to be one of the icon selections, and any text can be inserted in its place, as shown here:

When the device’s icon is then loaded in any subsequent pages (e.g., the Devices page), the content is loaded unescaped inside of the style tag, as shown below:

This allows malicious users to insert (almost) any CSS they want in place of the icon. A malicious user can cause an HTTP request to an arbitrary domain/IP address by setting a background-image property in the payload, as shown here:

The impact of this vulnerability is less severe due to modern browsers preventing JavaScript in style tags, and from PRTG Network Monitor preventing “ characters in the payload. These steps prevent this vulnerability from being escalated into a Cross-Site Scripting vulnerability.

Affected Versions

Raxis discovered this vulnerability on PRTG Network Monitor version 22.2.77.2204.

Remediation

A fix for CVE-2022-35739 has not been released. When a fix is released, upgrade to the newest version to fully remediate the vulnerability. In the meantime, Raxis recommends keeping a small list of users who can edit devices to limit the impact of the vulnerability. CVE-2022-35739 has minimal damage potential and is difficult to execute, and thus does not warrant additional protections while waiting for a remediation.

Disclosure Timeline
- July 7, 2022 – Vulnerability reported to Paessler Technologies.
- July 8, 2022 – Paessler Technologies begins investigating vulnerability.
- July 14, 2022 – CVE-2022-35739 assigned to this vulnerability.
- August 8, 2022 – Outreach to Paessler Technologies without response.
- October 4, 2022 – Second outreach to Paessler Technologies without response.
- October 7, 2022 – Third outreach to Paessler Technologies without response.
- October 21, 2022 – Original blog post detailing CVE-2022-35739 released.
CVE Links
- Mitre CVE – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35739
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-35739
October 21, 2022
Why Mutual Assured Destruction is an Incomplete Cyber Defense Strategy

“Like it or not, all of us are on the front lines in a cyberwar that is heating up with every day that passes.”
Bonnie Smyre, Raxis Chief Operating Officer

In the wake of the Colonial Pipeline breach, security analysts have discussed the idea that direct retribution might be an effective deterrent to the large-scale cyberattacks of the sort the US is experiencing ever more frequently nowadays. As someone with a strong background in Russian and Eastern European studies, I understand the historical precedent that drives this mindset. However, as a cybersecurity professional, I know that half-century-old strategy will not be nearly as effective against the challenges we face today.

Some ‘MAD’ Background

In the most dangerous days of the Cold War, US and Soviet leaders agreed to a counterintuitive policy that helped ensure neither side would launch a catastrophic nuclear first strike. Recognizing that stockpiles of atomic weapons were sufficient to destroy Earth many times over, the two superpowers agreed that the world was most secure when both sides maintained the ability to respond to a first strike with an equally devastating counterstrike.

Though it sounds barbaric, the strategy of mutual assured destruction (MAD) was one reason a period of détente lasted long enough for both nations to de-escalate tensions and negotiate dramatic reductions in the size of their nuclear arsenals.

The New Battlespace

Though the Soviet Union fell apart in the early 1990s, and the US ‘normalized’ relations with China, the threat they posed to America never disappeared completely. Instead, it has evolved with new technology and shifted into cyberspace. Hackers with ties to Russia and China are widely believed to have been responsible for high-profile breaches of government agencies and contractors, meddling in US political campaigns, and sabotaging critical infrastructure.

I say ‘widely believed’ because in the shadowy world of hackers it’s nearly impossible to prove an attack was state-sponsored. Malicious actors are very much cybercriminals without borders, and it’s not hard for hostile nations to contract out some of their dirtiest work.

As for the weaponry, ransomware, like the type used in the Colonial Pipeline hack, can be a few lines of code, readily available for sale on the dark web. Some of the more helpful black hats even offer support for an additional fee.

Where Deterrence Fails

The simplicity and anonymity of cyberwarfare do more than give cover to state-sponsored actors. In the context of mutual assured destruction, a more dangerous possibility is that non-state actors could launch an attack that triggers a misdirected, full-scale state response. In that scenario, it’s easy to envision a rapid escalation leading to military action.

An even bigger problem with the MAD concept, however, is its central tenet that the civilian population is purposely left exposed. In the case of nuclear war, there is a macabre logic behind that. Taking away the fallout shelters, civil defense infrastructure, and air raid drills made clear to everyone that a nuclear war between the superpowers would likely be the end of civilization. Entering the launch codes meant worldwide annihilation, plain and simple.

In the case of cyberwarfare, there simply isn’t a clear delineation between military and civilian or even public and private sector targets. Colonial is a private company, as are many utilities and other organizations that are of vital importance to our national security. Was the recent ransomware attack a simple economic crime or a strategic strike on the Eastern Seaboard?

Nor is there a foolproof way to gauge the severity of the attack. A small business might be hacked in order to reach a larger upstream supplier. And disrupting several municipalities could have the same strategic impact as an attack on the federal government.

We are the Front Line

From a practical perspective, what all this means is that, at most, deterrence can only be one part of a much larger strategy. And, unlike the Cold War, this new state of perpetual, persistent cyberwarfare can’t be waged solely by our military or managed by diplomats alone.

We’re all in this together. As long as one business is at risk, all of our businesses are. If our businesses are at risk, so is our government. And if our government is at risk, so are our people – from all walks of life.

Like it or not, all of us are on the front lines in a cyberwar that is heating up with every day that passes. The good news is that there are things we can do to protect ourselves and to become harder targets. As we do so, we raise the technological barriers, drive up the costs, and increase the risk to those who would attack us.

Mutual assured destruction helped end the Cold War without nuclear confrontation. But the key to ending global cyberwarfare may well be mutual cooperation – among our government, our military, and our businesses of all sizes.

May 14, 2021
LDAP Passback and Why We Harp on Passwords

Hackers are like anyone else in that they would rather work smarter, not harder – picking the low-hanging fruit first. Oftentimes, we find companies who put it in front of them without even knowing it.

In today’s video, I demonstrate how to conduct a Lightweight Directory Access Protocol (LDAP) passback attack, essentially using third-party hardware or software as an access point to a company network. I’ll show you three different ways to conduct the attack and offer some helpful tips on how to defend against it.

What I believe is important to add here is the common thread that links all of them: access to a password. If you want to know why our discussions seem to always circle back to that concept, it’s because an improperly protected password is a master key for hackers, whether their hats are white or black.

One is usually all we need to get inside your network. From there, the possibilities are limited only by our imaginations (and our scope of work). As I discuss at the outset of the video, too many of our customers make it easy by leaving devices like printers set to their default passwords or even null passwords, meaning they never created a password to begin with.

Once we control the device, capturing legitimate passwords is easy. The Raxis team has conducted several internal network tests where discovering an admin interface with default or null credentials got us full domain admin access to the network. In one case, a vendor told the company that the default password was okay to use for a few weeks until things were all set up. On another, we found a password file on a sensitive file share that was set up without a password while the IT staff moved it to a new server. And still another company had no clue a system had a default password. They said it had always been that way.

LDAP passback attacks can be prevented, but it takes companies implementing robust security protocols for everything with an IP address on your network – including printers and other devices.

Remember, if it’s connected, it must be protected.

Make sure all your devices are locked down with a strong password — no matter how innocuous the device may seem. It’s a hacker’s job to find their way in. It’s Raxis’ job to identify these vulnerabilities so that you can correct them before that happens.

Our team of experts are ready to help you and your organization find its weaknesses and help you strengthen your security. Talk with our team today.

April 30, 2021
SonicWall Patches Three Zero-Day Vulnerabilities
SonicWall has tested and published patches to mitigate three zero-day vulnerabilities in its email security products this week. Hackers are actively exploiting these vulnerabilities in the wild, and customers should patch them immediately.

Affected Products

The vulnerabilities affected the following versions of SonicWall’s email security and hosted email security products:
- 10.0.1
- 10.0.2
- 10.0.3
- 10.0.4-Present
The Addressed Vulnerabilities

The patches released by SonicWall mitigate three CVEs, listed below:
- CVE-2021-20021 (https://nvd.nist.gov/vuln/detail/CVE-2021-20021): An unauthenticated attacker can potentially create an administrator account by sending a crafted HTTP request.
- CVE-2021-20022 (https://nvd.nist.gov/vuln/detail/CVE-2021-20022): An authenticated attacker can potentially upload an arbitrary file to a vulnerable target.
- CVE-2021-20023 (https://nvd.nist.gov/vuln/detail/CVE-2021-20023): An authenticated attacker can potentially read arbitrary files from a vulnerable target.
More details from SonicWall can be found in its company advisory as well as in FireEye’s detail of how the exploits were being used. Here are links to both:
- SonicWall Advisory: https://www.sonicwall.com/support/product-notification/security-notice-sonicwall-email-security-zero-day-vulnerabilities/210416112932360/
- FireEye Detailed Threat Report: https://www.fireeye.com/blog/threat-research/2021/04/zero-day-exploits-in-sonicwall-email-security-lead-to-compromise.html
Remediations

SonicWall has patched its hosted email security product automatically, but customers will need to upgrade in-house email security products on their own, using the following versions:
- (Windows) Email Security 10.0.9.6173
- (Hardware & ESXi Virtual Appliance) Email Security 10.0.9.6173
SonicWall also provides detailed instructions for upgrading in this advisory article: https://www.sonicwall.com/support/product-notification/security-notice-sonicwall-email-security-zero-day-vulnerabilities/210416112932360/
April 21, 2021
IKE VPNs Supporting Aggressive Mode
In Raxis penetration tests, we often discover IKE VPNs that allow Aggressive Mode handshakes, even though this vulnerability was identified more than 16 years ago in 2002. In this post we’ll look at why Aggressive Mode continues to be a vulnerability, how it can be exploited, and how network administrators can mitigate this risk to protect their networks and remediate this finding on their penetration tests.

What is an IKE VPN?

Before we get into the security details, here are a few definitions:
- Virtual Private Network (VPN) is a network used to securely connect remote users to a private, internal network.
- Internet Protocol Security (IPSec) is a standard protocol used for VPN security.
- Security Association (SA) is a security policy between entities to define communication. This relationship between the entities is represented by a key.
- Internet Key Exchange (IKE) is an automatic process that negotiates an agreed IPSec Security Association between a remote user and a VPN.
The IKE protocol ensures security for SA communication without the pre-configuration that would otherwise be required. This protocol used by a majority of VPNs including those manufactured by Cisco, Microsoft, Palo Alto, SonicWALL, WatchGuard, and Juniper. The IKE negotiation usually runs on UDP port 500 and can be detected by vulnerability scans.There are two versions of the IKE protocol:
- IKEv2 was introduced in 2005 and can only be used with route-based VPNs.
- IKEv1 was introduced in 1998 and continues to be used in situations where IKEv2 would not be feasible.
Pre-Shared Keys (PSK)

Many IKE VPNs use a pre-shared key (PSK) for authentication. The same PSK must be configured on every IPSec peer. The peers authenticate by computing and sending a keyed hash of data that includes the PSK. When the receiving peer (the VPN) is able to create the same hash independently using the PSK it has, confirming that the initiator (the client) has the same PSK, it authenticates the initiating peer.

While PSKs are easy to configure, every peer must have the same PSK, weakening security.

VPNs often offer other options that increase security but also increase the difficulty of client configuration.
- RSA signatures are more secure because they use a Certificate Authority (CA) to generate a unique digital certificate. These certificates are used much like PSKs, but the peers’ RSA signatures are unique.
- RSA encryption uses public and private keys on all peers so that each side of the transaction can deny the exchange if the encryption does not match.
Cisco goes into details on these options in their VPN and VPN Technologies article.

Aggressive Mode vs. Main Mode

In this post, we are discussing the first phase of IKEv1 transmissions. IKEv1 has two phases:
1. Establish a secure communications channel. This is initiated by the client, and the VPN responds to the method the client requested based on the methods its configuration allows.
2. Use the previously established channel to encrypt and transport data. All communication at this point is expected to be secure based on the authentication that occurred in the first phase. This phase is referred to as Quick Mode.
There are two methods of key exchange available for use in the first IKEv1 phase:
1. Main Mode uses a six-way handshake where parameters are exchanged in multiple rounds with encrypted authentication information.
2. Aggressive Mode uses a three-way handshake where the VPN sends the hashed PSK to the client in a single unencrypted message. This is the method usually used for remote access VPNs or in situations where both peers have dynamic external IP addresses.
The vulnerability we discuss in this article applies to weaknesses in Aggressive Mode. While Aggressive Mode is faster than Main Mode, it is less secure because it reveals the unencrypted authentication hash (the PSK). Aggressive Mode is used more often because Main Mode has the added complexity of requiring clients connecting to the VPN to have static IP addresses or to have certificates installed.

Exploiting Aggressive Mode

Raxis considers Aggressive Mode a moderate risk finding, as it would take a great deal of effort to exploit the vulnerability to the point of gaining internal network access. However, exploitation has been proven possible in published examples. The NIST listing for CVE-2002-1623 describes the vulnerability in detail.A useful tool when testing for IKE Aggressive Mode vulnerabilities is ike-scan, a command-line tool developed by Roy Hills for discovering, fingerprinting, and testing IPSec VPN systems. When setting up an IKE VPN, ike-scan is a great tool to use to verify that everything is configured as expected. When Aggressive Mode is supported by the VPN, the tool can be used to obtain the PSK, often without a valid group name (ID), which can in turn be passed to a hash cracking tool.If you use Kali Linux, ike-scan is included in the build: We can use the following command to download the PSK from an IKE VPN that allows Aggressive Mode:
```
ike-scan -A [IKE-IP-Address] --id=AnyID -PTestkey
```
Here is an example of the command successfully retrieving a PSK:The tool also comes with psk-crack, a tool that allows various options for cracking the discovered PSK.Because Aggressive Mode allows us to download the PSK, we can attempt to crack it offline for extended periods without alerting the VPN owner. Hashcat also provides options for cracking IKE PSKs. This is an example Hashcat command for cracking an IKE PSK that uses an MD5 hash:
```
./hc.bin -m 5300 md5-vpn.psk -a 3 ?a?a?a?a?a?a -u 1024 -n 800
```
Another useful tool is IKEForce, which is a tool created specifically for enumerating group names and conducting XAUTH brute-force attacks. IKEForce includes specific features for attacking IKE VPNs that are configured with added protections.

What VPN Administrators Can Do to Protect Themselves

As Aggressive Mode is an exploitable vulnerability, IKE VPNs that support Aggressive Mode will continue to appear as findings on penetration tests, and they continue to be a threat that possibly can be exploited by a determined attacker.We recommend that VPN administrators take one or more of the following actions to protect their networks. In addition, the above actions, when documented, should satisfy any remediation burden associated with a prior penetration test or other security assessment.
1. Disable Aggressive Mode and only allow Main Mode when possible. Consider using certificates to authenticate clients that have dynamic IP addresses so that Main Mode can be used instead of Aggressive Mode.
2. Use a very complex, unique PSK, and change it on a regular basis. A strong PSK, like a strong password, can protect the VPN by thwarting attackers from cracking the PSK.
3. Change default or easily guessable group names (IDs) to complex group names that are not easily guessed. The more complex the group name, the more difficult of a time an attacker will have accessing the VPN.
4. Keep your VPN fully updated and follow vendor security recommendations. Ensuring software is up to date is one of the best ways stay on top of vulnerability management.
Also see our post on creating a secure password for more information on creating a strong PSK.
May 23, 2018
Ransomware – What you can do to avoid being a victim

Ransomware is the hot topic today. Malicious actors infect your system with sinister code that hijacks your information. In its most pure form it encrypts your data and yanks it from within your very grasp. Leaving behind only a message – a ransom note. If you ever wish to see your precious data ever again, you will pay. If you don’t pay, your data will be deleted and you will find yourself in the unemployment line.It’s the kind of thing that keeps business owners and managers up at night.The question is – what do you do to guard against it? Once the ransom appears on your screen, you’re done. There are several steps you should be taking to safeguard against ransomware.

1. Prevention

The number one thing you should do to guard against ransomware is to seal up the cracks. Find a good penetration testing company and have your internal and external networks evaluated. The right penetration testing company is going to come in with no credentials and attempt to exploit every weakness your network has. Don’t confuse this with a vulnerability scan – a true penetration test (pen test) approaches your system just like a real hacker. A real person is working your network and looking for exploits.Include social engineering (email phishing, vishing and spear phishing specifically) to your assessment. Ransomware often infiltrates your system by malicious code unintentionally installed by an employee. Using a found USB stick, visiting a malicious website, giving up credentials to an official sounding phone call, clicking a link in an email, etc. etc…. All of these are inadvertent ways an employee may infect their system.The report and remediation recommendations you will get from a pen test are priceless for patching the holes in your security. Evaluate your pen test company carefully. Ask to see sample reports and determine the depth of analysis you will truly get. Do not be guided by price alone.Along with assessing the network for vulnerabilities you should also consider a robust endpoint protection solution with an awareness of ransomware and zero-day vulnerabilities.Patching as a component of a comprehensive vulnerability management program should also be considered as a foundational element in any ransomware mitigation strategy.

2. Anticipation

Remember the saying – “failing to plan is planning to fail”. Ransomware is becoming more and more prevalent. You need to know what data you have, where you have it, and when it was last backed up. A completely audited data system will be much easier to restore. This will also help you get a grip on what has been compromised.

3. Backup, Cloud backup and Services

Once the thief has your data, the jig is up. Your data is encrypted, and there is a ransom to get it back. You’re not going to hack the encryption. If you pay – you’ll usually get your data back (not to mention a target on your back). If you don’t pay – they delete the data and you’re likely out of business.Once the attack happens you have three choices – pay the ransom, go out of business or restore from a backup.You DO backup, right? Surprisingly many companies don’t, and the ones that do often don’t have good practices in place for consistency. It’s critical this backup be separate from your network. You have a few options with backups:1 – Consistent internal backups to off-site drives isolated from the network.2 – Cloud based backupsWhile many experts agree that ransomware has not yet made the leap to the cloud, the issue is getting the data back in time for a reasonable restore. Normal data transfers aren’t reasonable with typical large companies. There are services available that will overnight a hard drive to your door once you’ve been attacked.

4. Restoration Plan

You need a plan in place to restore the data once you get it. Regardless of how you choose to backup and restore – you need this plan. You will have to wipe the entire system and systematically restore it. You also need to keep in mind the data you are restoring has the same vulnerability that got you hacked in the first place. So a smart hacker is likely to get right back in – and the game of cat and mouse continues.You can’t afford to keep playing the game. Restore the system and immediately get it assessed and patched. By now you should see why step 1 is so crucial to avoiding ransomware. You are also likely seeing why step 2 is important.Ransomware is here to stay for a while. It’s the new age stagecoach heist. The hi-tech way of bank robbery. Your best defense is a strong offense, good preparation and a plan for business continuity if and when it happens to you.

November 9, 2016