Tag: Awareness

  • Hackers See Opportunity Where You See Only a Button

    People are often surprised to find that a hacker doesn’t only attack a website through the authentication process. Our team members are experts at demonstrating why just enforcing password policies and lockout times doesn’t fully protect applications.

    In this article, we’re going to pull back the curtain and show you how hackers use web proxy tools to help exploit applications in ways you might never expect.

    How the Proxy Tool Works

    The proxy tool is software that follows the path data takes step-by-step from your device to the application server. Several such tools exist, but Burp Proxy (included in all versions of Burp Suite) is one of the most popular. Using Burp Proxy, hackers can bypass the user interface – the page you see when entering data – and change the information before it is sent to the application server. This makes it possible to avoid client-side controls, such as those that check that a phone number is only numeric or that an email address is formatted correctly. If the application server expects the client-side controls to have already validated data, the server code may not have all of the proper protections in place.

    In the image below, Burp Proxy, in “Intercept” mode, shows each step along the path that data follows from your device to an application server. The tool allows a user to tab from step to step and change the data that was input originally. If security features are built into the client (the interface you see) but not present on the application server, the proxy enables hackers to enter compliant data first, but change it however they want before it reaches the server.

    Burp Proxy in Intercept Mode shows the path your data travels

    One example of how hackers exploit this setup is through the commonly used buttons or checkboxes found in many apps. Most app developers are cautious about user input fields, but, because buttons, checkboxes, and radio buttons apparently limit data entry to “on-off” or “yes-no” choices, they often see little inherent risk. The problem is that, even though the user options are limited at the interface (client-side), they may not be limited by the code on the server itself (server-side).

    How a Proxy Tool can Reveal a Vulnerability

    The three illustrations below show how even a simple “submit” button can present opportunities for hackers.

    The choice here seems straightforward — either you click the button or you do not. But that choice masks what happens after you click “submit.”

    Save credit card information checkbox and submit button

    “Submit” is really just a request being sent to the server. Here, using Burp Proxy to intercept the data, we can see the request as it will appear to the application server.

    Unmodified GET request intercepted

    Now, rather than a simple yes-or-no choice, a user can modify the data any way they’d like and enter it by pressing the “Forward” command.

    Request modified with longer text
     How Hackers Turn the Exploit into an Attack

    With the ability to effectively bypass safeguards on the client-side interface, hackers can send information directly to the application server. Here are a couple of examples of the types of attacks they can execute if the application server is not secure. (For clarity, we’ll use text-based fields, rather than check-boxes in these examples.)

    Example 1: Cross-Site Scripting (XSS)

    Cross-site scripting (XSS) is a reflected attack that injects malicious client-side executable code into web application parameters to be returned by the application output and ultimately executed by the browser. Because it appears that the script is from a trusted source, the end-user’s browser accepts it and runs the script, permitting the attacker to take actions on the application’s behalf, such as accessing cookies and session tokens as well as other sensitive data. (Source: Raxis Glossary).

    The following walk-through demonstrate how a simple guestbook submission form request works normally and then how an attacker can use a web proxy to insert malicious code.

    This is the submission form as it appears to users:

    Guestbook submission form as it appears to web users

    Our Burp Proxy tool reveals the actual request sent to the application server:

    Captured form submission

    Here the attacker enters an innocuous submission that should not be caught by client-side injection controls:

    Attacker enters submission on web form

    And now the attacker captures the entry using Burp Proxy:

    Unmodified form submission in proxy tool

    Before allowing the proxy tool to move to the next step, the attacker replaces the original harmless data with a malicious script:

    XSS Payload inserted into form submission

    The application server, without server-side controls to stop it, accepts the script and returns the payload to the browser. This is what the attacker sees in Burp Proxy:

    JavaScript Payload Returned in Response Body

    And here we see the successful cross-site scripting result in the browser:

    XSS script executes when entry is displayed on the resulting webpage
    Example 2: SQL Injection (SQLi)

    In this attack, a SQL query is injected into the application via input parameters. A successful attack could read sensitive data from the database, modify data in the database, execute operations on the database (including administrative operations), recover files on the DBMS file system, or issue commands to the operating system. (Source: Raxis Glossary)

    Here we demonstrate how a user ID field can be manipulated to enable a SQLi attack.

    We start with a simple user ID entry field with a submit button where we enter a name and submit:

    Web form with textbox and submit button

    Again the attacker intercepts the submission using Burp Proxy en route to the application server.

    Unmodified GET request intercepted

    As above in the XSS exploit, the attacker then modifies the data in Burp Proxy, this time to include escape characters and a SQL query:

    Request modified to contain SQL injection payload

    With no server-side controls in place to stop the attack, the server returns the data requested in the SQL database query. This is what the attacker sees in Burp Proxy:

    Request returns all users from database

    And here we see the successful SQL injection result in the browser:

    All user records returned from database
    Summary

    It’s tempting here to focus on the Burp Proxy tool and its capabilities, but the more important point is to recognize that vulnerabilities can exist in places we as users might not think. Something that seems innocuous, like a simple submit or on/off button, can be manipulated by a hacker with relative ease. The same is true for any field, button, or widget that sends a request to an application server.

    Remember that the mindset of a hacker is always to look at something as it’s expected to be used, then attempt to use it differently. That’s why pentesting by skilled professionals is so important. It takes trained, ethical hackers to prevent the work of their malicious counterparts.

    Would you like to learn how Raxis can help your organization? Reach out. We have a guaranteed, no-pressure approach, and – after all – we’re all on the same side.

  • 2021 OWASP Top 10 Focus: Injection Attacks

    This is the first in a series of blog articles that will provide some deeper insight into the vulnerability types that made the latest OWASP Top 10 list.

    The Open Web Application Security Project (OWASP) recently released a draft of its periodic Top 10 vulnerabilities list. The open-source list is based on both raw data collected through automated testing, as well as the real experiences of cybersecurity and other IT professionals. 

    How Raxis uses the OWASP Top 10

    The OWASP Top 10 isn’t an exhaustive accounting of all the potential vulnerabilities in applications. Instead, it’s intended as a guide to help security professionals prioritize the most common and urgent threats they or their clients are likely to face. By collecting and analyzing data over time, OWASP is a source of both intelligence and awareness for the people responsible for building secure applications.

    As a penetration testing company, Raxis uses the OWASP Top 10 as a reference, ensuring that its customers are protecting against each of the most common threat categories. Of course, our testing goes well beyond the items on the list, but it is an effective starting point for security assessments.

    Why injection is a major concern

    In 2017, the last time the list was published, injection was the number-one concern. In 2021 this vulnerability moved down into the third position and now includes Cross-Site Scripting (XSS), which was its own category in 2017. However, that doesn’t necessarily mean it has diminished in severity; only that other vulnerabilities have increased in frequency.

    How an injection attack works

    The underlying cause of injection attacks is from user-supplied data that is not properly sanitized or filtered from an application. This can include various attacks such as SQL-injection, command injection, XSS, and more. While each of these attacks are different, they are all successful because of an application trusting user-supplied data, which led OWASP to combine Injection and XSS in this version of the Top 10.

    Raxis is well-versed in Injection attacks and has continued to see a high presence of these vulnerabilities in 2021. In particular, we have continued to see XSS be prevalent in applications, as evidenced by the five XSS CVEs I discovered and helped remediate this year: 

    How to prevent injection vulnerabilities

    The best defense against an injection attack is to not trust user-supplied data. Specifically, applications should sanitize or filter all user-supplied data before processing it, reflecting it back to users, or sending it to a database. In addition to user-supplied data, applications should not trust data coming from third parties such as external APIs, Active Directory, or other external sources. Four of the above CVEs involved data coming from an external source, which demonstrates the need for applications to not trust any outside data.

    Want to learn more? Take a look at the first part in our 2021 OWASP Top 10 Series.

  • Realistically Assessing the Threat of Clickjacking Today

    Clickjacking is an easily preventable but sometimes difficult to understand vulnerability. In this article, we’re going to talk about the different ways this vulnerability can be exploited, the associated risk, and how to defend yourself against these types of attacks.

    Let’s start with an explanation of how this attack works.

    What is Clickjacking?

    At its core, clickjacking is an attack that is made possible when the web application does not implement the proper protections against embedding its pages in an iframe. An attacker leverages this behavior to “hijack” a user’s click and trick them into executing an action in their account.

    I’ve set up an instance of bWAPP, an intentionally vulnerable web application by ITSec Games, that will allow us to look at a clickjacking attack in practice. Our vulnerable web application is running at “bwapp.raxis.local,” and you’ll see this reflected in the screenshots and sample code below.

    Finding a Target

    The first thing we’ll need to do is find a page we can target. When looking for a page that might be vulnerable to clickjacking, it should allow for an action that meets three criteria:

    • It can be executed in a single click (or very few);
    • It affects a logged in user; and
    • It could have an undesirable effect on the user or the organization.

    It looks like our vulnerable web application has a page that meets all three criteria:

    A buggy app

    This page allows authenticated users to purchase movie tickets in a single click with a default of 10 tickets. No confirmation is required, and without manipulating the forms on this page, this will result in an unwanted purchase of €150 worth of movie tickets.

    This behavior might seem unlikely to exist in the wild, but there are many different types of susceptible pages, from order confirmations like this to functionalities allowing a user to delete entire databases. Some of these susceptible pages may even incorporate parameters in the URL, which can be passed by an attacker. For example, an application might use a URL like the one below to create an order confirmation page dynamically:

    http://example.com/order/confirm?product=jetski&quantity=10&payment=saved
    Checking for Clickjacking Protections

    Now that we have our target page, let’s look at how to use it in an attack.

    The first thing we need to determine is whether the target page can be embedded in an iframe. While there are several methods of doing this, the easiest and most reliable by far is to try to embed a target page into an iframe on an attacker-controlled web page and see if it works. Let’s code up the web page now.

    Code to test if the target page can be embedded in an iframe

    As we can see, there’s nothing very complex to this code. It’s a barebones HTML file, which includes an iframe referencing the page we want to embed. Let’s open up our HTML file in our browser and see if this works.

    Webpage can be embedded in an iframe

    The web page loads into the iframe without issue. We can also see that, since we were already logged in to bWAPP, our session carried over.

    Executing the Attack

    Now that we have a good idea that the page is vulnerable, all we have left to do is code up a page designed to trick the user into clicking the Confirm button and convince the user into visiting to our malicious page.

    To build this malicious page, we’re going to construct an enticing user interface:

    The clickjacking user interface

    Then, we’ll stick the iframe on top and align the Confirm button with the View button. I’ve made the iframe partially transparent in the screenshot below so you can see the multiple layers.

    Webpage showing both the embedded page and the iframe page partially transparent

    And finally, we’ll make the iframe completely transparent so that the user doesn’t even know that it’s there.

    Completely transparent iframe with invisible embedded clickjacked website

    Now, when the user clicks the view button, they’ll actually be clicking the invisible Confirm button and purchasing 10 movie tickets, provided they’re logged in to their account.

    Partially transparent clickjacked page showing that a click on the submit button will confirm a purchase on the embedded site.

    Mission accomplished.

    Here is the code that I threw together quickly for the purposes of this demo:

    Clickjacking code

    Perhaps the trickiest part of this attack is coming up with a method that will get users to go to our malicious page. An attacker might:

    • Post a link to the malicious page in social media
    • Email a malicious link to a user or group of users
    • Embed a link in a QR code
    • Attach the malicious HTML file to an email
    • Leverage another vulnerability such as cross-site scripting (XSS) or open redirection
    When Clickjacking isn’t Clickjacking

    Let’s look at a different style of attack that’s popular among some penetration testers. This attack embeds a login page and places input elements on top of the login fields:

    Outdated clickjacking PoC

    The overlaid fields are shown in blue for this article but would normally be completely invisible to the user. When a user fills out this form and submits it, the login request is instead sent to an attacker-controlled server, giving the attacker access to the user’s unencrypted credentials. You can read more about this style of attack here.

    But is this type of attack really considered clickjacking? It involves an embedded iframe and overlays, but it is drastically different from our previous example. To determine this, let’s put ourselves into the mindset of an attacker.

    As an attacker, our goal here is to capture as many credentials as reliably as possible while evading detection. There are at least two approaches we can take:

    • Embed the target login page in a malicious HTML page as shown in the proof of concept, or
    • Clone the HTML code of the login page and modify the form to send to a malicious server

    These approaches are very similar. Both require hosting the page on a malicious web server, both require misleading the user into visiting a malicious link, and both redirect user input to a malicious server. Both approaches even run the same risk of the malicious web server being reported, blocked, or shut down.

    However, when embedding the login page, there are additional factors that the attacker must consider:

    • The target login page may already have clickjacking protections in place;
    • The target login page could be altered, breaking the malicious page;
    • The target login page could implement clickjacking protections, breaking the malicious page;
    • The target login page cannot be easily modified by the attacker;
    • It’s possible for the target page to determine and report the URL of the malicious page; and
    • The malicious page may not look or function correctly if the window is resized

    When considering the large number of downsides of using an iframe and overlay elements to conduct this attack, it is extremely unlikely that an attacker would attempt to execute it through clickjacking. Far more likely is that an attacker would simply clone the login page using a myriad of freely available tools designed to do exactly this.

    Implementing protections against clickjacking would not stop this attack from occurring. Instead, the attacker would simply clone or recreate the page, which cannot be prevented. The proof of concept itself is also a stretch from the commonly agreed upon definition of clickjacking. For these reasons, Raxis in most cases no longer considers this type of attack to be clickjacking. Instead, we label this as a misconfigured security-related header, which continues to inform the customer of the small but perceptible risk, without blowing what’s essentially a non-exploitable vulnerability out of proportion.

    Protecting Against Clickjacking

    Despite the complex nature of a clickjacking attack and its reliance on phishing, developers should still take a layered approach to protecting their applications from this type of attack. This can be done by properly configuring two response headers and by properly setting flags on cookies.

    Content-Security-Policy

    For the uninitiated, Content-Security-Policy is a highly versatile header which can offer a large amount of protection to the end user when configured properly. You can generate one at https://report-uri.com/home/generate, and verify your existing one at https://csp-evaluator.withgoogle.com/.

    To prevent pages from being embedded in iframes, we can use the frame-ancestors directive. Here’s a few ways this can be properly implemented:

    • Content-Security-Policy: frame-ancestors ‘none’ – Prohibits the page from being embedded anywhere
    • Content-Security-Policy: frame-ancestors ‘self’ – Allows the page to be embedded on the same domain only (exclusive of subdomains)
    • Content-Security-Policy: frame-ancestors https://*.raxis.local https://raxis.local – Allows the page to be embedded on raxis.local and any of its subdomains
    X-Frame-Options

    X-Frame-Options used to be the primary line of defense against iframe embedding but has since been made obsolete by the frame-ancestors directive. Unless, of course, your users are using any version of Internet Explorer. To cover all our bases and take off this 1.1% of users, we need to add this header for legacy purposes. Configure this header in one of the following ways:

    • X-Frame-Options: DENY – Prevent the page from being embedded anywhere
    • X-Frame-Options: SAMEORIGIN – Allow the page to be embedded on the same domain only
    Cookie Attribute – SameSite

    A relatively new cookie attribute, SameSite, can also help protect against clickjacking by restricting the conditions in which cookies (such as a session token or JWT) are sent by the browser.

    As of mid-2020, SameSite is set to Lax by default when the attribute is not set in Set-Cookie. This value prevents cookies from being sent in iframes, which essentially breaks any clickjacking attack that relies on the user being logged in.

    To use the SameSite attribute as an additional layer of protection against clickjacking, configure the SameSite attribute on your session-related cookies to one of the following values:

    • SameSite=Strict – No cross-site cookies, ever
    • SameSite=Lax – Cross-site cookies only when the user is navigating to the original site

    Since Lax is the default, you can leave this value unconfigured, but it’s a best practice to explicitly configure it as one of the above values, both from a documentation and security standpoint.

    You can read more about the SameSite attribute at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite.

    Side Note: Setting SameSite to Strict or Lax also helps defend against cross-site request forgery (CSRF) attacks.

  • NSA, FBI, CISA Statement on Russian SVR Activity

    What does it mean for your business?

    Summary of the Statement

    Last week, the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and Federal Bureau of Investigation (FBI) released a joint statement on five different vulnerabilities that the Foreign Intelligence Service of the Russian Federation (SVR RF) is known to be exploiting currently.

    How does this affect your business?

    Even if your business is not a target of the SVR RF, other threat actors such as ransomware gangs, are taking advantage of the same vulnerabilities. Therefore, if you have been using any of the affected product versions, you should take them offline, upgrade to the most recent version, and begin an incident response process to verify your servers are not compromised. Additionally, Raxis recommends performing the same process on other recently exploited products such as SolarWinds Orion and Microsoft Exchange Server.

    Affected Product Versions & Associated CVEs

    Fortinet FortiGate VPN

    • Version: Fortinet FortiOS6.0.0 to 6.0.4, 5.6.3 to 5.6.7 and 5.4.6 to 5.4.12
    • CVE: CVE-2018-13379

    Synacor Zimbra Collaboration Suite

    • Version: Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10
    • CVE: CVE-2019-9670

    Pulse Secure Pulse Connect Secure VPN

    • Version: Pulse Connect Secure (PCS) 8.2 before 8.2R12.1, 8.3 before 8.3R7.1, and 9.0 before 9.0R3.4
    • CVE: CVE-2019-11510

    Citrix Application Delivery Controller and Gateway

    • Version: CitrixADC and Gateway versions before 13.0.47.24, 12.1.55.18, 12.0.63.13, 11.1.63.15 and 10.5.70.12 and SD-WAN WANOP 4000-WO, 4100-WO, 5000-WO, and 5100-WO versions before 10.2.6b and 11.0.3b
    • CVE: CVE-2019-19781

    VMware Workspace ONE Access

    • Version: VMware One Access 20.01 and 20.10 on Linux, VMware Identity Manager 3.3.1 -3.3.3 on Linux, VMware Identity Manager Connector 3.3.1-3.3.3 and 19.03, VMware Cloud Foundation 4.0-4.1, and VMware Vrealize Suite Lifecycle Manager8.x
    • CVE: CVE-2020-4006

    Remediation

    If your business is running any of the aforementioned product versions, upgrade immediately to the most recent versions following the guides for each product below:

    Fortinet FortiGate VPN

    Synacor Zimbra Collaboration Suite

    Pulse Secure Pulse Connect Secure VPN

    Citrix Application Delivery Controller and Gateway

    VMware Workspace ONE Access

    Solarwinds Orion

    Microsoft Exchange

    Additionally, Raxis recommends beginning an incident response process on any servers exposed to the internet that are running these product versions, as they are actively being exploited in the wild.

    Associated Links

    NSA, FBI & CISA Statement: https://www.nsa.gov/News-Features/Feature-Stories/Article-View/Article/2573391/russian-foreign-intelligence-service-exploiting-five-publicly-known-vulnerabili/

    CVE Links:

  • At Raxis, Learning and Improving are Constants

    In today’s video, you’ll hear from Lead Penetration Tester Matt Dunn, the newest member of our team, about why he appreciates the learning environment we’ve created and continue to nurture at Raxis. 

    Matt actually came to Raxis with several certifications under his belt and another now in progress. That proactive quest for knowledge was a good sign that he would be a great fit on our team and was among the reasons we hired him. As it turns out, we were right: Not only has he done excellent work as a penetration tester, Matt has also published his first Metasploit Module. (For the uninitiated, that is a very big deal in the pen testing world.)

    To be clear, it is certainly possible to be an outstanding penetration tester without professional certifications. Likewise, I’m sure there are bad testers out there with walls full of them. As with Matt, however, taking the initiative and making the effort suggests that you are willing and able to learn – and that is a key differentiator for both pen testers and the companies that employ them.

    Why? Because the threat landscape is constantly evolving, and our knowledge and skills have to keep pace. That means the pros that make up our team have to be smart enough to hit the ground running and humble enough to continue learning once they’re on board. 

    Listen to Matt describe his experience, and you’ll get an idea of what this means in practice.

    At Raxis, we foster a learning environment, not just through research and certification training, but also through open communication among our team members. This group includes people from diverse backgrounds who each bring unique skills to the table. When we hire, we look for individuals who are both willing to share their talents with us and also able to learn from the other accomplished professionals on our team.

    Do you thrive in a learning culture? If so, Raxis might just be for you. Be sure to check out our other videos in this series and see if Raxis is the opportunity you’ve been looking for. 

    Here are some other videos you may find interesting:

    Want to learn more? Take a look at the next part of our Working at Raxis discussion.

  • Three Reasons Why a Penetration Test Won’t Break Your Network

    Myth: A penetration test breaks your network. 

    Reality: A penetration test helps you find vulnerabilities so someone else doesn’t break your network (and your customers’ confidence in you).

    This is actually a common concern we hear from potential customers. Many are worried that a pen test will damage their network by crashing a server, knocking their website offline, causing an eclipse, or maybe releasing a 5G kraken. 

    In the video above I explain how we work with our customers ahead of testing to make them feel at ease and to help them understand that our profession is hacking but that our business is protecting theirs.

    As I explained in the video, our pen testers aim to make as little noise as possible while they’re slinking around in your network. Our whole goal is to get in, and to not get detected or get blocked. Crashing and breaking things is the opposite of that. And we’re simply not going to perform the kind of attacks that cause actual damage.

    The only scary part of our penetration tests are when you realize what might have happened if a hacker found your vulnerabilities before we did. 

    Be sure to also check out this article from Bonnie Smyre: What to Expect When Expecting a (Raxis) Pen Test?

    If you are ready for Raxis’ elite team of professionals to put your security to the test (did we mention they have successfully breached some of the most sophisticated corporate networks in the US?), then reach out to us here.

    Also, if you liked this video, please be sure to subscribe to our YouTube channel for more videos that can help you improve your security posture.

  • A Herring Haunting at Curriculaville Next Wednesday

    To me, the scariest movies are ones where the ghost/monster/alien turns out to be someone we’ve come to know and trust. The same thing is often true with cyberthreats – the people who can do the most damage to your organization, whether intentionally or not, are your own employees. During Raxis red team engagements, company employees are one of the most reliable ways we have to gain access to the corporate network.

    Believe me, after thousands of penetration tests over the years, Raxis has lots of stories – and I intend to tell some.

    Next Wednesday, our friends at Curricula, an Atlanta-based cybersecurity training company, will launch their first annual “Curriculaville” remote cybersecurity summit. The free, one-day event starts at 11 AM and will feature a number of experts from the information security space. I’m proud to represent the Raxis team as part of a panel discussion entitled, “Scary Security Stories” that will begin at 1 PM. 

    This is the time of year for tales that send chills up your spine and raise goosebumps on your skin. If you haven’t trained your employees properly and put effective cyber defenses in place, well . . . let’s just say you might be in for a quite a fright. 

    The good news is that Raxis stories usually have happy endings. We might steal some passwords and take over your domain, but 99% of the time, we leave your soul intact. And, we’ll show you how to avoid the real bad guys who will take that and more if they can.

    Please check out the link and sign up for this informative, educational event at Curriculaville. After all, hearing our scary stories might just keep you from living one of your own.

  • What to Expect When You’re Expecting a (Raxis) Penetration Test

    I made this video to help you understand a little better how Raxis works, and specifically what happens once you engage us. I hope it allays some of your concerns about penetration testing.

    There’s no reason to fear a pen test. Seriously. After all, it’s just a simulated cyberattack, one that you authorize and allow. Yet some CEOs, CIOs, and CISOs are hesitant to allow this ethical hacking for fear that the bad guys will somehow use it against them, that it will cause security issues, or that it will make them look bad. In fact, it’s just the opposite – especially if you choose to engage Raxis.

    We get it, though. It’s natural to be cautious, and it’s prudent to want to know more about the people you’re working with, especially when granting access to your company’s most sensitive data. Whether you choose to work with Raxis or any other firm, we recommend you ask (and answer) plenty of questions up front. You want to know the company has the right experience to offer a range of high-quality services. One size definitely does not fit all. The firm you select should speak to you in advance to understand your specific needs and expectations . . . and then design and deliver the type of test, training, and follow-up that best protects you and makes you more resilient.

    The Raxis team has some of the industry’s most advanced certifications, but we don’t intimidate our customers or hide anything from them. We believe knowledge empowers our clients, and we share it freely. Whether you use us or someone else, penetration testing is a critical part of your corporate cybersecurity strategy that you should not put off or bypass.

    As you can see, we welcome your questions and concerns during every phase of our process. We conclude our pen tests with an executive summary for management and detailed findings and screenshots that can serve as a to-do list for your internal teams.  

    Raxis stands by our processes, our team, and our word. Now it’s up to you to perform due diligence and research the expertise and deliverables of any cybersecurity company you’re considering. Follow us on this blog or social media, read more about our pen testing experience, or contact us directly to learn more about why some of America’s corporations (and small businesses) choose to work with us.

  • Celebrate National Cybersecurity Awareness Month Through Security

    Each October the NICCS (National Initiative For Cybersecurity Careers And Studies) leads National Cybersecurity Awareness Month (NCSAM) . This year the focus is on personal accountability and taking proactive steps both at home and at work. Raxis is joining in the fun by offering tips that we all can try at home and in the workplace (or school), no matter our age or what we do.

    Computer & Smart Phone Basics

    These tips are the same ones you’ve been hearing for years, but it’s always good to have a reminder.

    Apply updates to your devices. The IT department at your office is likely handling this there, but it doesn’t hurt to check and be sure your operating systems and software are running current, patched versions. This is also important for your personal devices. Watch for notifications that it’s time to update your operating system and keep software that you buy up to date. Almost all software has a place (Updates, Preferences, Settings) where you can check to see if you are on the current version. Most vendors watch for security news and provide patches and updates as soon as they fix issues. And don’t forget smart devices, such as phones, tablets and household products like cameras and lighting systems. Such devices can be easy to overlook, and hackers often focus on them because they know that.

    Set passwords/passcodes on your computers and smart devices. Your kids may “hack” your phones by entering the passcode that you’ve told them and posting amusing Instagram photos, but, when you misplace your phone while out, you will appreciate setting that passcode so that a stranger doesn’t have access to your private information including sending texts, reading your emails, or erasing your phone for their own use. The same applies to computers. Step away for a few moments, and you don’t know if someone has stopped by to look at your private downloads or browser history.

    Use strong passwords. While on the topic of passwords, please don’t use 12345 or Password1. It’s often tempting to set easy passwords or the same password for every login to save time and make passwords easier to remember. Hackers count on that. Some websites allowed hackers to guess many passwords until they find the right one, and, once they have it, they may try it to login to your other accounts or even sell the password to other people. Raxis gives tips on setting passwords that are easy to remember but hard for others to guess here: The Weakest Link in the Password Hash.

    WiFi Networks

    Nowadays all sorts of places from coffee shops to hotels have free WiFi guest networks. It’s convenient to join these, and you can do that safely if you follow a few rules. While connected to these networks, there is a chance that a hacker could be watching your internet traffic, including passwords as you login to sites and private information that you enter in websites or upload to the cloud. If you’re logging in to check a score or find the closest pizza parlor, there’s probably nothing for a hacker to steal. But if you plan to stay on the WiFi network for a while or do anything that may be private, Raxis advises you use a VPN tool such as Private Internet Access (PIA) while connected to the guest WiFi network. Tools such as PIA have apps for your phones and tablets as well as software for your computer, and they often charge a low monthly or annual fee so that you can use the service at any time. Once you connect to the guest WiFi network, start PIA, and it will encrypt your internet traffic so that an attacker attempting to watch your secure data only sees gibberish.

    Setting up a home WiFi network. When setting up your WiFi network at home, either through tools from your local cable, phone or satellite service, or with your own wireless router, be sure to set a strong password (see above) on the administrative webpage where you set up the WiFi network. Though these sites appear to be personal for your home, the signal often travels outside and to neighbors’ houses. If you leave the site with no password or an easily guessable password, someone nearby could change your settings. Raxis also advises that you set a password to join your home wireless network. Though you’ll likely share this with friends and family, it makes it harder for someone nearby to join without you knowing.

    Use WPA2. Your router setup likely has several options for the wireless security protocol and sometimes defaults to a weak protocol. The WEP and WPA protocols are about 20 years old, and exploits are easily available on the internet. Several varieties of WPA2 are available on most routers, and any of these should work well for a home network.

    Social Engineering & Phishing

    Many hackers and thieves look for a simpler way to get the information and access they want.

    Email, fax and phone (calls & texts) phishing campaigns have become very realistic and are often difficult to distinguish from legitimate messages. Hackers can steal your information by talking you into telling them, tricking you into entering your private information, such as credentials, on their malicious webpage, or even automatically stealing credentials or infecting your computer when you open a link that they send you. At Raxis we advise our customers to stop and think before acting. Many companies, such as banks and stores, provide contact numbers and forms that you can call to confirm the information.

    It may seem brazen, but the easiest way to get access to businesses, apartment buildings, or other shared spaces, is to act like you belong and see if someone lets you in. Once inside, it’s often rare for people to confront others about whether they belong there. Raxis recommends not holding locked doors for people you don’t know as well as keeping confidential information and keys hidden in case someone does gain access. If someone appears suspicious to you, you don’t have to confront them. Let a security guard, receptionist, or someone in authority know.

    The most important thing to remember is, to quote the Department of Homeland Security, “If you see something, say something.” This is the case whether at work or at home. Check with your manager or IT department or check with your neighborhood watch or HOA. If you are not sure about an email from your bank, contact them about it; if it’s a scam, they may want to inform other customers. If you see someone acting suspiciously, report it or ask around.

    Raxis provides more information in the following series of blog posts:

    Stay Safe & Secure Out There!

    As the holiday season gets closer, focusing on cybersecurity is not just for the month of October. When we focus on security in our daily lives, we can work together to make things more difficult for hackers and thieves. Let’s all do our part

  • Raxis Presents at the (ISC)² Atlanta Chapter Meeting

    Brad Herring and Scott Sailors had the pleasure to present at the (ISC)² Atlanta Chapter Meeting last Thursday. The topic was on Social Engineering and understanding how the high success rates of social engineering impacts network security. Herring and Sailors shared the most common attack vectors, which include phishing, spear phishing, vishing, physical with a pre-text bias and physical with a technology bias.

    The members were shocked at the 90% success rate Raxis sees with social engineering across all verticals and business size. Further sobering is the fact that, once Raxis gains access to an internal network, our team is successful in achieving an “impactful breach” 85% of the time.

    Once the realization hit that determined and skilled hackers are commonly able to breach armed security, card keyed systems, numeric keypads and other physical controls, it became apparent the importance of achieving and maintaining a strong internal network security program.

    This engaging meeting facilitated many conversations about physical security as well as the effectiveness of a mature phishing campaign. The group was able to heighten their awareness of the types of attacks to which businesses often fall prey, understand the behind the scenes actions that take place once credentials or access is achieved, and discuss meaningful remediation steps for combating these attacks.

  • Tailgating & Other Physical SE – SOCIAL ENGINEERING [PART 3]

    In Part 1 and Part 2 of this series, we discussed remote social engineering that an attacker could perform from any location. Those types of attacks rarely are traced back to the attacker who could be located anywhere. The social engineering attack that we’re discussing in this post is much more brazen. In this case the social engineer is actually located onsite, possibly talking with you face-to-face.The stories below are all from ethical physical social engineering engagements that my colleagues and I have performed. Our goal was to help each company find weaknesses so that they could correct them and educate their employees to make the job site more secure. My goal in writing this post is the same. As with all social engineering attack vectors, education is the best defense. For that reason, I’m focusing this post on the interpersonal aspects of SE. Some of my colleagues at Raxis made a video last year explaining some of the technology that can be used on physical SE engagements. Check it out at https://raxis.com/2017-04-19-physical-security-pitfalls/ to learn more about that.

    Getting In

    Companies often put safeguards in place to secure entrances and then hope that the bad guys stay out. Surprisingly, getting in is often much easier than you might expect. I have used platters of cookies and cakes to gain access on some engagements, but often it’s even easier than that.I once was attempting to enter an office building located in the suburbs of a large city and scoped out the building on the Sunday afternoon before the engagement started. I find this to be a good way to find out about the building and security policies in place so that I can make a plan before the Monday morning rush. Also, different security guards are often on duty on the weekends, meaning I likely won’t be recognized the next day when I start the engagement. In this case, a colleague and I checked out the building and discovered that all doors except the main entrance were locked. The main entrance was open during posted hours, and a uniformed security guard was visible behind glass windows. We decided that tailgating during the morning rush was our best option. The next day we arrived and immediately split up. After a few attempts, I saw a woman heading towards a door I was near. I looked upset & riffled through my purse frantically. When she walked up, I told her I couldn’t find my badge anywhere and could she let me in. She was definitely suspicious. “What department do you work in?” I told her IT, a department that is likely to have employees in or to need access to several buildings. She let me in and told me that it was okay because I worked for IT. And then she told me that she disliked the rule that they could not let people in, and IT made that rule, so I had better not tell my coworkers. Once in the building, I plugged a device into a network port in an open cube and called my colleague so that he could begin remote access to the network.I could tell multiple stories of people holding doors for me, especially during busy times of day — morning, lunch, and at the end of the day. On one engagement I was attempting to clone badges and eventually wondered why since every single person who passed me as I obnoxiously stood outside a locked door held the door for me. When you realize that many companies rely on locked doors for security, this starts to become scary.So how about another story that is much the same, but possibly not as expected. On an engagement in the financial district of New York City a few years ago, I had more hurdles to make my way into the office. The large skyscraper I was in had two elevator banks. Each bank had turnstiles that required employee or visitor card access. Two guards were seated at a security desk that had a clear view of both elevator banks. Once I made it to the elevator, I knew a floor number but did not know what security measures were in place. I stood near a snack shop and watched as most people used the elevator bank for the floors I didn’t need. When I eventually saw someone head to my elevator bank, I casually, but closely, followed. No alarm. Later testing showed me that the alarm would go off if I allowed a comfortable distance between myself and the person I was tailgating but the turnstile would still work as long as I followed someone through. I followed my target onto an elevator and discovered that she was going to the floor I needed. She used her card to allow the elevator to go to that floor and then used her card to get into the office area of the floor. Though the floor was designed to lock visitors in the elevator area where they used a phone to request access, my target held the door open for me. Once I was on the floor, I sat in the break room, walked around work areas and file cabinets, and, fifteen minutes in, eventually had to start acting suspicious before anyone asked me who I was and what I was doing. The safeguards in place made everyone believe that they floor was secure and that everyone there must have been fully vetted.

    Staying In

    It’s definitely a win to say that we got into our customer’s building. The test, though, is to see how we can exploit that, and, unless we know exactly what we are looking for, that requires staying in the building for an extended period of time without getting caught. Finding our way around takes a while. I’ll take photos of fire exit maps and then run into restroom to have time to look them over and figure where to go next. Most of the time we’re entering buildings blind and figuring out where to go as we go.Remember that suburban office building I mentioned above? My colleague and I went back at 5pm. We bought coffee at a local spot across the street and stood outside a locked door drinking that local coffee. The first person who walked out the door held it for us. We walked in and walked past rooms labeled with department names. When we found one with no name, we walked in and saw that it housed offices and cubes that appeared to no longer be used. We waited inside an office there for an hour. When we left our hiding space around 6pm, the building was deserted except for the cleaning crew. We ran into the same members of the cleaning crew multiple times, and they never stopped us or reported us. Earlier in the day we had gathered some credentials in a phishing campaign. We were able to use those credentials to login on a customer service representative’s PC and to view customer financial and medical information. We had full access because internal doors were left unlocked after hours and the only employees we met did not report us.Another time I was in a large hospital. As you’d expect, at a hospital, it wasn’t hard to gain access. There were nurses and doctors all around, though, and the computer access and private documents that were my aim, were all behind nurses stations. Luckily I had guessed this might be the case and had bought a cheap pair of scrubs before starting the job. I wore the scrubs along with a lanyard that had a blank white card on it, and I gained full access. To what?

    • Computers
    • Papers on printers and fax machines
    • Medical files and binders with patient information

    I took my time and went from floor to floor. I was not stopped or questioned even one time. In fact, I made a friend in the elevator as I was leaving the building. We chatted about how being a nurse hurts your feet after running around all day. I later found out that the scrubs I was wearing were a color not even used at that hospital.So timing helps and dressing the part helps. One last story on this topic. Back to that skyscraper in NYC. On one occasion there I was tailgating with the lunch crowd to a different floor using the popular elevator bank. I slid through the turnstile following someone but wasn’t quite fast enough. The alarm went off, and a security guard started walking towards me. Just then an elevator opened, and I walked in with the crowd. On the way up, as the elevator stopped at several floors, a man turned to me and asked why I didn’t use my card to go through the turnstile. I pointed to my big computer bag and said that I didn’t feel like looking through there to find it. He laughed and started talking to his buddies about the fight on television the night before.So add confidence to that list. It’s shocking what you can get away with when you expect someone to believe you.

    Getting What You Came For

    In the end, it’s all moot if you don’t demonstrate that a security breach can lead to a compromise. This can be plugging a small device into the network so that you can later gain remote access, it can be photographing private documents found on desks and in file cabinets, and it can even be accessing employee computers that are left unattended. I already mentioned in passing that I have had opportunities to install devices on networks and to access computers on some of the engagements I’ve done, but there’s more!Hospitals often hire us because they have a lot of private information and critical equipment to protect while also often allowing many people through their doors daily. They walk a fine line of being kind to patients and their families while still protecting patient rights by guarding their security. At one busy hospital, I was set on getting access to the files in the Medical Records room. I tried in a doctor’s coat and in scrubs and didn’t make it past reception. I went back in jeans and told them I was from IT to fix a computer. The receptionist let me in without another word. I opened file cabinets and took photos of the papers inside.At another hospital, I walked up to a reception desk that blocked my way to a cancer center. I told the receptionist that I was from IT and had to manually install updates using a USB drive because the automatic security updates were failing. Not wanting to miss a security update, she let me into the locked area behind her and told me to take my time. She left me alone to install payloads to open remote sessions on several machines and photograph patient records that were lying on desks.On one job I had been hired for had an SE engagement and an internal penetration test combined. This is a great idea because it demonstrates how a real attacker might put the pieces together to gain more access. From the penetration test, I already knew of administrative interfaces on the internal network that allowed default credentials. With my SE hat on, I walked into one of the hospital’s specialty buildings. This is where they treated cancer patients and other patients who would be back for multiple visits. There was a very nice room, open to anyone, off the lobby. Computers were provided to allow patients, friends and family to research what they had heard from their doctors. I sat down at one of these computers and proceeded to login to the internal admin websites that were all accessible from those public computers. In this way, I, or an attacker, could access and change administrative controls for the hospitals systems.

    Getting Out

    When we perform physical SE jobs for our Raxis customers, we discuss carefully with the customer to discover what they want us to test and not to surpass those bounds. The customers provide us with a “get out of jail free” letter that we use if we are caught. The letter is on the company’s letterhead and provides information about who to call to verify the testing in the event that we are challenged by a vigilant employee. With this, we can boldly enter company buildings without fear of arrest. True attackers will likely not be as careful as we are in our testing… their goal is to get in, get what they came for and then to get out without being caught, whether they cause other harm or not.Once, at a small insurance office, I had gained access to everything that was in scope, but I still had extra time. I had done it all by staying under the radar the first time, so I went back a second time and tried to talk my way into gaining the same access again so that I could see if the people I spoke to would allow me to have access or would stop me. Kudos to them for not believing my story about performing an audit without calling first. Unfortunately, they did not want to be mean to me, so they placed me in a conference room alone for ten minutes while they attempted to reach someone for confirmation. Because I wanted to test them thoroughly, I stayed and eventually handed them my “get out of jail free” letter. If I had wanted to leave, I could have left the building before they checked on me.Then there was the time that I was in a hospital’s administrative building attempting to gain access to Human Resources. I had already spent time in the hospital itself and read a free hospital newspaper that mentioned three star employees by name and with photos. One was in HR, so I went over to the HR building and told the receptionist that the star employee had told me I could wait in their conference room so I could work until my flight arrived. The receptionist happily took me right over to see this star employee. She looked me in the face and told me that she had never seen me before. Since I had nothing to lose, I told her that we had only met twice and I was sorry that she didn’t remember me. I didn’t offer to leave. I stood next to the receptionist and just stared after that. My target told me that she had never met me but that I could stay in the conference room anyway. I stayed long enough to plug a device into the network and then walked out telling everyone that I got an earlier flight. Sometimes the best way to be able to get out is to act like you are comfortable staying… as if you belong there so fully that you have nothing to hide.In my SE career, I have only been forced to show my “get out of jail free” letter once (without me forcing the situation into that). This was an example of an employee doing everything right. I had discovered that a high level manager at the small firm we were tasked with assessing, as well as his wife, had public Facebook profiles. I learned all about them, bought a cake that said “Congratulations, Dad!” and walked up to the receptionist saying that I was his daughter in town to surprise him for his anniversary (which happened to be coming up according to Facebook). I knew my mother’s name and my siblings names, and I had a whole story set up. It was enough to get me into his office, but the receptionist called his assistant to escort me, and the assistant didn’t take her eyes off me. When I tried to catch a coy photo of a paper on my target’s desk, she entered the room and told me that she was calling security. After a brief attempt to talk my way out of it, she stood her ground. Upon receiving my letter, she called the people on the letter to verify that the letter was true. While a lot of these stories make this sound easy, this was an example of a situation where a real attacker could have ended up talking to the police. And it shows what diligence from employees can do to protect the company.

    What You Can Do

    Hopefully this article was a fun read, and hopefully it scared you a little as well. When someone wants something from your company, they can be very convincing, but you don’t have to be an unwitting accomplice. What can you do?

    • Many companies have physical security policies. Ask what yours is. It likely includes several of the following items as well.
    • Don’t allow people to tailgate behind you. If a door is locked or protected in some way, let people unlock the door themselves. If they complain, explain that it’s company policy (if it’s not it should be!) and tell them where they can go to sign in and gain access if they don’t have the key or badge needed at your door.
    • If you see people you don’t recognize in your internal office space, ask who they are. Ask to see a visitor badge if your company provides those. Many visitor badges have blurry photos and small “approved for” dates. Check the badge closely.
    • If you find someone to be suspicious and don’t want to or don’t know how to confront them, call security. That’s what they’re there for. Tell them as much information as you can and keep an eye on the suspicious person until they arrive if possible.
    • Keep private and critical documents in locked drawers. Don’t leave them on desks or in unlocked cabinets. Remove these documents from printers and fax machines as quickly as possible as well.
    • Let your IT department know of any network ports that are not being used. If an attacker plugs a malicious device into a network port that IT has turned off, you’ve thwarted their remote access to your company’s network.

    While this is my last post in this Social Engineering series for now, we’re always happy to discuss what Raxis can do to help you improve your company’s security in this area. You can find more information at https://raxis.com/redteam/social-engineering, or drop us a line at https://raxis.com/company/contact.I’ve heard a rumor that my colleague, Brian Tant, is working on a related blog post about Neuro-Linguistic Programming (NLP) using cognitive resets, visual cues, and body language. Keep an eye out at the Raxis blog for that coming up soon!

    Want to learn more? Take a look at the first part of our Social Engineering discussion.