Tag: Pentest

  • Cool Tools Series: Host Discovery

    Before starting any penetration test, you must know the scope of the work. Depending on the type of assessment, this could be specific hosts or full ranges of IP addresses with live hosts scattered throughout. If the scope is the latter, then it is a good idea to initially identify which hosts are live and then discover common, known vulnerabilities on the hosts. This will narrow down the attack surface and potential attack vectors to help establish a list of priority targets during the assessment.  

    There are several tools that I like to use when I start a new assessment. Some are free open-source tools, while others are commercial.

    Open-Source Tools

    Nmap

    The first tool I always use in Nmap. Nmap is an open-source tool that can identify live hosts and services by conducting protocol enumeration across systems. It can also be used for specific configuration checks or even as a vulnerability scanner by using the Nmap Scripting Engine (NSE).

    Even when I use Nmap with vulnerability scanners, I still regularly utilize Nmap scripts. Nmap come pre-installed with Kali Linux but can easily be installed on any Linux or Windows system. Using Nmap for the first time can be intimidating, but after using it for a bit, users often find it very easy and reliable.  I usually run the initial scans by ignoring ICMP checks (Ping) and just assume that all hosts are live. I do this because some network admins like to disable ICMP on live hosts as a security measure (Good on ’em!).

    nmap -v -A --open -Pn -iL targets.txt -oA nmap_scan

    Note: -Pn disables the ICMP check.

    If the scope is extremely large and the Nmap scans won’t complete in the time allowed, I enable the ICMP check by remove the “-Pn”:

    nmap -v -A --open -iL targets.txt -oA nmap_scan

    Below is a screen shot of a typical initial scan I perform on network assessments (internal & external):

    nmap -v -A -Pn --open {IP Range} -oA {Output File Name}
    Nmap Discovery Scan

    The commands above are easy to learn once you use them a few times, and I’ll cover what is going on here.  

    • First, I like to use the “-v” which enables verbose outputs.
    • The “-A” enables OS and version detection, as well as script scanning and traceroute output.
    • “-Pn” disables ICMP ping for host discovery, causing the scan to assume that all hosts are live.
    • Next, we have the IP range, in this instance a standard /24 internal network. If I have specific hosts or multiple ranges to target, I will create a text file and use the “-iL” switch to point to the text file.
    • Lastly, I like to output the results to all supported formats by setting “-oA.” The reason I do this is because I like to ensure I have the different file types for future use. For example, the .nmap output is easy to read when I want to scan through the output. I typically use the XML output for importing into Metasploit or when using Eyewitness to enumerate web hosts.

    There are quite a few good cheat sheets out there too if you let the Googles do the work for you. If not, follow this series for more Nmap tips and tricks in the future.

    Masscan

    Another tool similar to Nmap is Masscan. Masscan is a TCP port scanner that scans faster than Nmap. Unlike Nmap, Masscan requires you to define the ports you want to scan. I typically don’t use Masscan and just stick with Nmap, but it’s a good option if you want to quickly look for specific open ports on a network.

    OpenVas

    Another tool I use on occasion is OpenVAS (a.k.a. Greenbone), a vulnerability scanner. Greenbone offers a commercial version, but there is an open-source version available as well. I’ve used this many times when I am unable to access my usual vulnerability scanners. One downside to the tool is that It can be difficult to install. I recently followed the instructions for installing with Kali and ran into quite a few issues with the install. I’ve also noticed that the initial setup can take some time due to the signatures that are downloaded. If purchasing a commercial vulnerability scanner is too expensive, then Greenbone is definitely worth looking into, despite its challenges.

    OpenVAS Dashboard

    Commercial Tools

    Nessus

    By far, my favorite vulnerability scanner is Tenable’s Nessus. There is a free version available, but it’s limited to 16 IP addresses. If you are doing a lot of vulnerability scanning or time-boxed penetration tests, then it might be worth looking into purchasing this.

    The thing I like most about Nessus is how I can sort by vulnerabilities across all hosts in a given scan. I can also sort these vulnerabilities by risk rating, which helps me narrow down critical or specific vulnerabilities to exploit or signs that a host or service may be a high priority for a closer look.

    When viewing Nessus results, never ignore the informational findings. They often provide clues that more may be going on on a host or service than you realize at first glance.

    Nexpose

    Another great vulnerability assessment tool is Nexpose, owned by Rapid7. Nexpose is similar to Nessus, as it provides similar vulnerabilities. There are some slight differences in the way the products display results.

    Nexpose is built around “sites.” Each site has defined hosts or IP ranges under it. From there each host’s vulnerabilities will be listed.  The easiest way I’ve found to list out all vulnerabilities is to create a report from the site I’m working in.

    Besides greater extensibility, one major advantage with Nexpose is that it ties in with Rapid7’s vulnerability management product, InsightVM. If you’re looking for a full vulnerability management solution and not just a vulnerability scanner, Nexpose is a good option to check out.

    There are many other tools that I use, but these are always my first go to tools to start an assessment. 

    Follow the series!

    Stay tuned for more posts in the Cool Tools series, where the Raxis penetration testing team will highlight some of their favorite tools and explain how to get started with them.

    Take a look as Adam Fernandez dives into Nmap for Penetration Tests in the next post in this series.

  • How Artificial Intelligence Will Power Raxis Continuous Penetration Testing

    A few years ago, Mark Zuckerberg of Facebook and Tesla’s Elon Musk feuded very publicly over whether artificial intelligence (AI) would be the key to unlocking our true potential as humans (Zuck) or spell doom for our species and perhaps the Earth itself (Musk). Apparently, neither of them accepts the notion that AI, like all technology, will expose us to new concerns even as it improves our lives.

    Meanwhile, here in reality, business owners are still facing the less dramatic, but more urgent threat posed by all-too-human hackers. Most seek money, some are in it for fame, others cause havoc, and many want all of the above. It’s against this mob that Raxis is using AI, more accurately called machine learning, to give honest companies an upper hand in the fight.

    Here’s how it works:

    Human Talent Sets Us Apart

    Raxis has built an incredible team of elite, ethical hackers, who are all the more effective because of their diverse backgrounds and skillsets. Our process starts with a traditional penetration test. Based on our customers’ parameters, we set our team to work testing your defenses.

    Think of this like your annual physical at the doctor’s office (without the embarrassing paper gown). Our goal at this stage is to find ways into your network and determine where we can go from there. Once you know where you’re vulnerable, you can remediate and feel more comfortable that your defenses are solid.

    AI Extends Human Capabilities

    One major challenge of staying cybersecure is that new threats are emerging and new vulnerabilities are being discovered even as I write this sentence. The point of continuous penetration testing is that we leverage technology to account for the pace of this change. Our smart systems will continually probe your defenses looking for new weaknesses – with software that is updated in real time.

    In keeping with my earlier example, this part of the process is analogous to wearing a heart monitor and having routine blood work. As long as everything remains normal, we let the system do its job.

    Humans Enhance AI Effectiveness

    When our AI discovers an anomaly, it alerts our team members, who quickly determine if it’s a false positive or a genuine threat. If it’s the former, we’ll simply note it in your Raxis One customer portal, so you don’t waste time chasing it down. The latter, however, will trigger an effort by our team to exploit the vulnerability, pivot, and see how far we can go.

    Consider this exploratory surgery. We know there’s a problem, and we want to understand the extent so that you can fix it as quickly as possible. That’s why we give you a complete report of the vulnerability, any redacted data that we were able to exfiltrate, and storyboards to show you how we did it.

    More than a Vulnerability Scan

    If you’re familiar with vulnerability scanning, you’ll immediately recognize why the Raxis Continuous Penetration Testing is different . . . and better. Ours is not a one-and-done test, nor is it a set-it-and-forget-it process. Instead, you have the advantage of skilled penetration testers, aided by technology, diligently monitoring your network.

    AI isn’t ready to change the trajectory of the human race just yet, but it is improving our ability to protect the critical computer networks we rely on.

    If you’d like to learn more, just get in touch, and we’ll be happy to discuss putting this new service to work for your company.

     

  • How Much Should You Pay for a Penetration Test?

    “Even after 10 years as CEO of Raxis, I’m still amazed at the wildly different pricing attached to a vast and loose array of services broadly labeled as penetration tests. I know something is amiss when I see quotes range from $1,500 to $18,000 per week (and more) for what is ostensibly the same work.“

    Mark Puckett, Raxis CEO

    I understand and appreciate the confusion among companies large and small who need this essential service, but who have no good way of knowing whether they’re getting a bargain or being fleeced. That’s why, once again, I’m stepping in with a straightforward guide that I hope will be helpful to any business that needs to test its cyber defenses against professional, ethical hackers.

    Rules of Thumb
    • As with other professional services, the adage that you get what you pay for does hold true in penetration testing. A quote that’s a lot lower than reputable competitors is cause for skepticism, as is one that is substantially higher. Fortune 500 companies may well need multi-month testing that can cost $250,000 and more, but it’s unlikely smaller firms do.
    • There are some external factors that can affect the price of a penetration test – whether it’s conducted onsite or remotely, or whether it’s a remedial test. For the purposes of this guide, we’ll stick with just the testing itself.
    • The scope is everything. Be certain that what you discuss is exactly what you are getting for the price. Consider carefully what you’re trying to achieve. Are you serious about preventing hackers from hijacking your network, stealing your data, or holding it for ransom? That’s a different objective than simply checking a box to comply with laws or industry regulations.
    The Differentiators

    When you’re considering a company to perform a penetration test, there are three major factors you should take into account alongside cost. They are the skillsets of the pentesters who will actually be doing the work, the time they propose to spend doing it, and the methodology they will employ in the process. Reputable firms like Raxis will spend the time necessary upfront to make certain you know what to expect before you sign a contract.

    Skillsets

    Not all pentesters are the same, and the pricing should reflect that. For example, some testers are phenomenal at hacking Windows systems, but are not nearly as strong when it comes to Linux or mobile technology. Many environments have a mix of Linux, Windows, Android, iOS, Mac OS X, Cisco IOS, wireless networks, and others. Make certain that the team you select is well-versed in all the technologies you have in scope so they can perform a valid test.

    Earth with a question mark

    To reiterate, you should know exactly who will be doing the testing. Just because a company is based in the US does not mean that its testers are. Some firms cut costs by using un-credentialed, offshore teams to do their work. That may or may not be a cause for concern if it’s disclosed upfront. If it’s not, however, I would consider that a big red flag. 

    Time Dedicated to the Job

    The amount of time penetration testers spend on jobs can really vary, and that will influence the price. Some pentesters believe that a week, two weeks, or even months are required to get a comprehensive test completed on your network. There are no hard and fast rules here, but the time should be proportional to the challenge.

    If you’re quoted anything less than a week, I would hope that it’s an extremely small scope of just a handful of IPs with a few services running on them. Otherwise, I’d be skeptical. The key here is to make sure the time spent on the job makes sense with what is in your scope. Also, remember to factor in complexity. For example, a single IP with a large customer facing web portal with 10 user roles will take a lot more time than 250 IP addresses that only respond to ping.

    Interestingly, I’ve heard that some of our competition is taking a week or more to quote the job.  I don’t understand the reasoning behind delays during the sales process, but I certainly recommend taking that into account when you make your decision.

    Methodology

    There are a few different ways to conduct penetration tests. I’ve broken them down into three types for reference.

    • Type A – The “Breach and Reach”: This type of test starts with the low hanging fruit and gains access as quickly as possible, just as a malicious hacker would. The goal is then to pivot, gain additional access to other systems, ensure retention of the foothold, and finally exfiltrate data. This is a true penetration test and demonstrates exactly what would happen in the event of a real-world breach. Some companies call this a “deep” penetration test as it gains access to internal systems and data. It’s the type of test that we prefer to do and what I would recommend as this is what the real adversarial hackers are doing.
    • Type B – The “360 Lock Check”: This test searches for every possible entry point and validates that it actually is exploitable. This validation is most often completed by performing the exploit and gaining additional privileges. The focus with this type is to find as many entry points as possible to ensure they are remediated. The underlying system might be compromised, but the goal is not to pivot, breach additional systems, or to exfiltrate data. This type is often useful for regulatory requirements as it provides better assurance that all known external security vulnerabilities are uncovered.
    • Type C – The “Snapshot”: This is more of a vulnerability scan in which the results from the scanner report are validated and re-delivered within a penetration testing report. Many lower-cost firms are calling this a penetration test, but that is not what it is. However, it may be all you need. If so, Raxis offers a vulnerability scan on an automatic, recurring basis, and it is very useful in discovering new security risks that are caused by changes to the environment or detecting emerging threats. (And no, it’s not a pen test.)

    If you’re serious about security, I strongly recommend testing that ensures both Type A and Type B are part of the scope. That means testing even a small range of IPs can often take a week. However, it is the most comprehensive way to pentest your environment and meet regulatory requirements as well. Type A tests for the ability to pivot and exfiltrate information. Type B will get you that comprehensive test of any vulnerabilities found to ensure that you’re fixing real issues and not false positives.

    In an upcoming post we’ll tell you about a new capability offered through Raxis One. This is pentesting that leverages the power of AI to extend and enhance the capabilities of our talented team of elite ethical hackers. Raxis Pentest AI is considered a hybrid of all three types of testing mentioned above in that it combines continual monitoring and random testing to find and exploit vulnerabilities as soon as they appear.

    The most important advice I can offer anyone shopping for penetration testing services is to ask a lot of questions. High-quality, reputable companies like Raxis will be happy to put experts on the phone with you to provide answers. You can draw your own conclusions about any who won’t.

     

  • Helping Nonprofits and Other Growing Businesses Understand Security Risks

    I’m excited that NTEN, the Nonprofit Technology Network with more than 50,000 community members, invited me to be a guest blogger this week.

    It’s important that nonprofits avoid the mindset that leaves so many businesses vulnerable. Specifically, I’m talking about the idea that they are too small or have too little money to be of interest to scammers, hackers, and other cyber criminals. The truth is that the bad guys often don’t discriminate, and you may have something they want more than money.

    For example, if you keep detailed donor records, that personally identifiable information (PII) might be devastating in the wrong hands. A skilled hacker or social engineer can do a lot with names, email addresses, and phone numbers alone. Add in Social Security numbers or bank account information, and you may be sitting on a gold mine for a malicious actor.

    Some of today’s most serious threats are driven by political goals more than financial interests. In many cases, these are well-financed state-sponsored attacks, and your organization may have data that can help them breach a government agency’s security or social engineer their way into a large corporation.

    And forget about hackers leaving you alone because of your mission. After my years in the cybersecurity sector, I’m no longer shocked at how low some of these black hats will go. We’ve seen hospitals and health care organizations, charities, churches, schools, and other do-good groups fall prey.

    The saddest part is knowing that some of these attacks were successful for the very reasons the organizations thought they would never happen. To a hacker, the idea that you’re too small to notice may mean they see you as an easy target, even if you’re only one step toward their larger goal.

    If you’re a nonprofit leader, board member, or even a volunteer, please take a moment to check out the article above. You may find some nuggets that will help you help your organization avoid a breach. And that may be the most important contribution you can make to your favorite cause.

  • Top Five Actions NOT to Take When Your Pentest Results are High Risk

    Monday Morning Voicemail:

    Good morning high-powered CSO, this is Brian with Raxis. I sent over a draft of the most recent assessment report as you requested. Just to recap, there were seven critical findings, 5 severe, and a menagerie of others that we can discuss at your convenience.

    You’re the CSO of a major enterprise. You’ve hired us to perform a penetration test, and the results aren’t pretty.  What now?The team at Raxis brings a rich depth of experience in articulating risk to all audiences. We can talk technical with the engineering groups and discuss strategy with C-level executives. It’s how someone deals with adversity that defines them as a leader. We’ve seen leaders emerge from the fire to rise above the fray. We’ve also witnessed the fallout when leadership decisions are made in ignorance or for political expediency.A security assessment is only one step in a process, and its value is largely determined by what happens after we’re out of the fray, so to speak.  So, there you are; you have an unexpectedly thick and verbose penetration test report sitting in your inbox. Here are the 5 worst things you can do, based on what we’ve seen happen in the real world.

    5. Sweep it Under the Rug

    It may be tempting to just quietly file that report away because you think it might tarnish your reputation or because, “that only happens to other companies.” Maybe you would prefer to fix the findings with minimal political overhead. Here’s the problem. The report you received is a bona-fide disclosure of risk. When it landed in your inbox, all level of plausible deniability left the building. If you do anything less than boldly embrace it, and the company is breached, you are going to be in a rough spot with tough questions to answer. By owning the problem, you can own the resolution. Let that be the focus.

    4. Play the “Blame Game”

    It is easy in the world of corporate culture to get bogged down in political maneuvering.  A corporate leadership role requires a certain level of posturing, but there are few things less productive than finger pointing. The fact that you were against rolling out the vulnerable application or platform that was compromised may carry weight in your inner circle of colleagues, but your stockholders only want to know their investment has underlying value and that effective leadership is at the helm. It’s helpful to acknowledge mistakes and learn from them, but keep the emphasis on moving forward.

    3. Cling to Penny Wise and Pound Foolish Remediations

    The findings in the assessment report are not a checklist to be ticked off and call it a day. Yes, of course they should be fixed, but it’s critical to understand that a penetration test is opportunistic. The findings that are presented are probably not the only significant exposure. Look at the bigger story that they tell and formulate remediations at a systemic level. Were all the findings related to applications?  If so, the problem probably is not the applications but more likely with their development and deployment. Yes, fix the symptom, but do not neglect the underlying problems that led to it.

    2. Rain Down Fire and Wrath

    We see this far too often. A phishing email is sent out, and an employee clicks on the link, which then becomes the bridgehead for a compromise. When the report is delivered, specific individuals are identified as the source of the compromise and are promptly fired. That is absolutely the wrong course of action. Look at it this way. Once they understand the ramifications of their action, that person is the most secure person in the company at that moment. It’s likely that they will continue to operate under a heightened level of vigilance and will be the last person to click on a suspicious link in the future. Replacing them with someone who has not learned that lesson, simply presses the reset button for future phishing attacks. Help them understand the attack and how their actions contributed, and they may become a power advocate among their peers for better security.

    1. Silo Solutions

    Would a capable attacker limit themselves to a single application, network, or technology?   The answer, of course, is that they would not. Lateral movement is a huge component of privilege escalation.  It’s important to scrutinize specific elements of any environment. We conduct assessments regularly against a single application or system, but what we always try to underscore is that rarely are attacks vertical. Rather, the attack chain tends to zigzag across technologies and business units within an organization. Just because you tested and remediated a specific web application does not mean that the app no longer presents a risk. It means that the direct exposure created by the app has been mitigated. Maybe there is another vulnerable application running on the same server that can be used as a point of compromise?The point is that attackers do not silo their efforts, so don’t silo your defenses.

    Your Decisions Make the Difference

    Fortunately, these observations are more the exceptions than the rule, but they do happen. And they happen in surprising large and mature organizations. Most of these mistakes can be attributed to a knee-jerk moment of self-preservation. When our lizard brain steps in, sometimes we don’t make the best decisions for our career.The best way to avoid these pitfalls is to never put yourself in that situation in the first place. Yes, some pentests are horrific. In leadership, it’s not how you fall.  It’s how you rise above.

    A security assessment is not a chance for someone to make you look bad. It’s a learning exercise. Embrace it and use it for a platform from which to build positive change..

    Raxis CTO, Brian Tant

  • Goodies for Hoodies: TCP Timestamps

    The Picts were a tribal culture in northern Scotland that history has relegated to the realm of myth and enigmatic legend. Largely forgotten, the Picts fought off the military superiority of Rome’s army and built a sophisticated civilization on the whole before disappearing from history. These were a people dismissed by the advanced thinkers of the day as unimportant and trivial in their capabilities, only to rise up unexpectedly to great effect. What does this have to do with Security? Nothing really, unless your data center is staffed by Roman centurions on horseback. If that’s you, then I am ripe with envy. But all levity aside, so it was with the Picts, it is today with the humble and unassuming TCP Timestamp.

    What is a TCP Timestamp?

    If you’ve ever run a vulnerability scan, you’ve probably seen a low or informational severity finding associated with TCP Timestamp responses. The recommendation is always to disable them, but rarely is any background information provided. What are those little timestamps doing there and who really cares anyway? Like the Picts, much lies below the surface, and we dismiss them at our peril. Before we can get into the ramifications of this misunderstood protocol option, we must understand the mechanics behind TCP Timestamps, and what they actually are. The basis of TCP is that it is a stateful, reliable means of sending and receiving IP packets. In order for reliable communications to take place, there must be bidirectional communication between the sending and receiving nodes so that, in basic terms, the sender can know that the target system received the communication correctly, and the receiving node has confidence that the message it received was correct. To such ends, TCP communications are session-based, and the two nodes employ features in the protocol as a framework to manage the reliability of communications. This involves things like resets, syn-acks, re-transmissions, and the like, that you’ve probably seen in any number of network captures. TCP was designed to communicate reliably over any transmission medium at any speed; it provides the same level of communications integrity over dial up as it does on a LAN.

    It is important to understand that TCP was originally designed to overcome the challenges of unreliable communication channels. Not much thought was given to excessively reliable and fast communications.

    It seems counter intuitive, but, because TCP is synchronous and keeps track of packets, it can break down over high bandwidth connections. It sounds crazy, I know, but let’s look at how this might happen.

    Grab your pocket protector here, folks. We have to get a little nerdy.

    If you asked President Trump about packet loss on TCP communications, he might respond, “It’s bad, very, very, very bad.” And he would be correct. But packet loss does occur for any number of reasons, and TCP maintains reliability by using selective acknowledgments to tell the sending node what TCP segments are queued on the receiving node and what segments it is still waiting for. These segments are, like anything else in network communications, numbered in finite sequence numbers. This value occupies a 32 bit space and exists within the confines of a Maximum Segment Lifetime (MSL), which is enforced at the IP level by something we’re more familiar with, the Time to Live (TTL). This MSL is usually adjusted based on the transfer rate so that faster speeds have smaller MSLs. This works pretty well until we introduce things like fiber optics. The bandwidth on a fiber connection can be so high that a TCP session can exhaust all of its sequence numbers and still have segments queued up in the same connection, leading to sequence number reuse, aka TCP Wrapping. This causes problems.

    In short, as things get faster, it becomes more error prone to use timeout intervals to manage reliability.

    The number of sequence numbers can not exceed the 32 bit value of 4,294,967,295 so as transmission speed increases, the MSL values must get shorter to compensate. With enough bandwidth, they can shrink to the point that they are no longer able to provide message integrity. If only there was a way to identify whether packets were dropped based on actual timing rather than a sequence number, but how?

    Behold the mighty TCP Timestamp!

    TCP Timestamps are an important component of reliable high speed communications because they keep TCP from stumbling over its own sequence numbers!Officially, this benefit is referred to adoringly as “PAWS” or Protection Against Wrapped Sequence Numbers. PAWS operates within the confines of a single TCP connection under the assumption that the TCP timestamp value increases predictably over time. If a segment is received with an older timestamp than one that was expected, it’s discarded. In doing so, PAWS protects against sequence numbers being reused in the same connection. It’s worth pointing out that there are a lot of weird exceptions and math around how that actually takes place, but for purposes of a blog post, we’ll steer clear of that rabbit hole. It should be clear at this point that TCP Timestamps serve a purpose in network communications, and that disabling them as a standard practice is a perilous endeavor.

    Still awake? Good! Now we can talk about security!

    Strictly speaking, TCP Timestamps are no more a security risk than the TCP protocol itself. Why then are they subject to all the bad press and mob calls for their disablement? The security concerns arise with the underlying mechanisms that are used to populate the values within the timestamp option itself. As the name suggests, the timestamp makes use of a virtual “timestamp clock” in the sender’s operating system. This clock must approximate real time measurements in order to remain compatible with other RTT measurements. There is no requirement for the timestamp clock to match the system clock, but it often maps to it for ease of design. After all, why make a new clock if you can just use the existing clock to derive values to be presented as those belonging to the new clock?

    This leads to the one thing for which we hackers profess a deep and undying love for, unintended and predictable behavior. Am I right?

    By measuring multiple timestamp replies, we can determine what the clock frequency is of the target system. The clock frequency is how many “ticks” the timestamp clock increments per unit of real time. For example, if we measure 5 timestamp replies each 1 second apart, and each timestamp value increases by 100 with each reply, we can infer that the clock increments 100 ticks for every second of real time processed by the system clock.Since most (not all!!) clocks start at 0, we can compute the approximate uptime of the system. Using the above example, if the timestamp value is 60000, we know that each 100 ticks of that value equate to one second of real time. We can assume that 600 seconds have elapsed since the clock was started. In laymen’s terms, the system was rebooted 10 minutes ago. We’re using small whole numbers here for purposes of illustration, but you get the idea.

    In the real world, accurately fingerprinting the system will help with establishing timestamp validity, since clock specifications are documented.

    System uptime by itself is an arbitrary value and doesn’t give away much on it’s own. But consider that patch cycles almost always include mandatory reboots. By surveying these values over time, one might be able to determine patching intervals by correlating reboot times across systems. What if you surveyed the same IP address multiple times and received different but consistently disparate values in the timestamp responses? That might allow you to identify systems that are behind a NAT or a load balancer, and may even allow you to draw conclusions about the load balancing configuration itself. Suppose you were testing a customer for susceptibility to DOS attacks. You may be able to use timestamps to determine with certainty whether the target system was knocked over, or whether you were just shunned by the IPS.

    TCP Timestamps grant the hacker insight into a given system’s operational state, and how we use that information is limited only by our imagination.

    But to dismiss their presence as a low severity security finding just to be remediated is inappropriate, and it may do more harm than good. When to use TCP timestamps should be determined by operational requirements, not by blanket assumptions of their importance. Are you listening, vulnerability scanners?So next time you find yourself knee deep in informational findings from a vulnerability scan, put your ear close to a network cable. It’s possible you may hear the faint battle cry of a forgotten hero. Want to keep reading? Learn the difference between vulnerability scans and penetration tests, more about Vulnerability Management, and how a penetration test can help you understand which risks are most relevant to your network.

  • 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
    ike-scan in Kali Linux

    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
    ike-scan
    psk-crack

    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.

  • Raxis API Tool

    At Raxis we perform several API penetration tests each year. Our lead developer, Adam Fernandez, has developed a tool to use for testing JSON-based REST APIs, and we’re sharing this tool on GitHub to help API developers test their own code during the SDLC process and to prepare for third-party API penetration tests.This code does not work on its own… it’s a base that API developers can customize specifically for their code. You can find the tool at https://github.com/RaxisInc/api-tool.

    Here’s a basic overview of the tool from Adam himself:

    The Raxis API tool is a simple Node.js class built for assessing API endpoints. The class is designed to be fully extensible and modifiable to support many different types of JSON-based REST APIs. It automatically handles token-based authentication, proxies requests, and exposes several functions designed to make it easier and faster to write a wrapper around an API and associated test code for the purposes of a penetration test. This tool is not designed to work on its own, but to serve as a building block and quickstart for code-based API penetration testing.

     

  • Hopefully You’re Not Next

    Recently in the news, our national security director explained that we’re under constant attack from foreign adversaries. These attacks are at the nation-state level and they are attacking “virtually everything”. This isn’t limited to the super critical power generation companies and government institutions- they mean everything, including your website, email, and personal workstation. To make matters worse, there are still many of attacks originating from other bad actors, such as credit card and personal information thieves.

    Many people think they are not targets because they have nothing of value. However, the contrary is true.  At a minimum, your computer and internet connection can be leveraged to attack other systems to cause an outage or hide the tracks of a real attacker.  Unfortunately, the worse case scenario might involve an installed key logger to capture credentials for your banking and retirement accounts.We’ve seen this first hand.  

    Raxis performs hundreds of penetration tests and breach responses a year, and 2017 proved to be no exception.  There have been many occasions where we would breach a customer network only to find the door was left open and clear evidence that someone had already been there.  After a system has been breached, there are only two viable options: to restore from a known good backup, or a complete reinstall of any software.  Recovering from a breach is very difficult as in many cases the attacker will control many or all of the systems within an organization, resulting in a massive undertaking to rebuild.

    Do something to make sure you’re not next.  Reach out to us, we’ll help you understand how a penetration test can shed some light on where the risks really are.

  • Penetration Testing is a Critical Tool For Your Business

    Penetration testing is so important for businesses today. Almost every day we see companies in the news after the result of a big hack. The aftermath is ugly – lawsuits, loss of trust, downtime and, in many cases, the hacked entity finds itself out of business.In a recent interview with an IT management firm, I was told that many of their customers (mostly SMB) didn’t want a penetration test because they knew they would fail. I see this same reaction in larger companies as well.

    This fear of failure is the wrong way to look at penetration testing. At Raxis, we say it all the time, “You can’t fix what you don’t know is broken.” Penetration testing should not be looked at as something that points out your failure; rather it should be embraced as something that helps you get better.

    Vulnerabilities are common

    We see many of the same vulnerabilities across the nation. Many of them are simple to remediate. Most of them have escaped the attention of the IT team for any number of reasons, but most of all because the IT team is simply busy. Most teams are over worked and under staffed. The workload is high. As a security professional you have to get it right 100% of the time – however, the hacker only has to get it right once.The fear of failing is misplaced. Almost every penetration test will show vulnerabilities or, at the very least, likely attack vectors that could be exploited given more time. Finding vulnerabilities should not be seen as a failure but rather as a responsible approach to better security.

    Penetration testing should be about partnership

    A penetration test is a valuable tool to help a security team more efficiently locate vulnerabilities, and, if you’ve partnered with a good company, it will offer remediation recommendations helping you efficiently fix the vulnerabilities.A good penetration testing company offers insight and help, not a judgment.I like to call our penetration tests an assessment. That’s truly a better word. We don’t test our customers as much as we partner with them. Raxis is the watchful eye that helps your company stay out of the news. We help you safeguard your data, and we help you maintain trust with your customers.

    Penetration testing should be a holistic approach

    When a hacker looks at your company, they are taking a holistic approach, and they are going to go for the easiest method with the least amount of risk that they can find. Common attack vectors include:

    • Social Engineering
    • WiFi Systems
    • Internal and External Networks
    • Mobile Applications
    • Web Applications
    • API’s

    Each of these areas allows escalation to others. While often viewed as independent systems, the reality is that a weakness in one often leads to a breach in another.Security is hard. This is why it’s so important to partner with a reputable penetration testing company that you can trust. I urge you to not look at penetration testing as the enemy but rather the relief you and your team so desperately need.Learn more about how our penetration tests work.