Year: 2024

  • Tips to Stay Secure at DefCon 2024

    Tips to Stay Secure at DefCon 2024

    The Raxis pentesting team is at DefCon in Vegas this weekend. It’s an awesome conference that has lessons and contests for everything from lock picking and car hacking to new network and application exploits that our team may try on your next penetration test.

    For those of you who may not have attended before (or just the curious) , here are a few guidelines to help ensure that you have a safe and enjoyable experience at DefCon (or if you are anywhere nearby in Vegas this weekend).

    Connectivity

    Trust nothing. DefCon is regarded as the most hostile wireless environment on the planet. Do not connect to the conference wifi – or any wifi network except for those that you verify. I suggest making note of the hotel network’s AP BSSID and confirming that you’re actually connected to it before doing anything. When inside the conference center, Airplane mode is a really good idea. Bluetooth is best left off unless you’re actually using it and disable discovery in such instances. Some folks use burner phones, but that’s not really necessary if you’re smart about phone use. You do you.

    VPN

    When online, use a VPN at all times and enable the ‘killswitch’ feature if you have it. Don’t use a VPN that uses split tunneling because it does not protect all your data in transit. Use a VPN that forces all traffic across the tunnel. Nord, PIA, and ExpressVPN are solid options.

    Cellular

    IMSI catchers (aka stingrays) are in use. When using your phone, make sure you’re on a 4g or 5g connection. Check the cell tower ID against something like Shodan if possible, to minimize the chance that you get MitM’d. Text / SMS messages on a downgraded connection are the easiest to target, so use end to end encryption when messaging. I recommending using a tool such as Keybase.

    Physical Security

    When your laptop is not in use, shut it down fully so that it’s locked by disk encryption. If you leave it in your hotel room, even to go get ice or whatever, put it in the room safe. Alternately, I’ve seen people just leave their work laptop behind with some kind of secure remote access setup.

    ATMs

    Better to just bring cash, but, if you must use an ATM, use one that is a few miles from the conference center. Use one that is actually attached to a bank and check it for skimmers.

    Payments

    Don’t make purchases on a check card. Use an actual credit card to make sure you have fraud protections in place. Personally, I use a single Amex card while there and cancel it afterward.

    Don’t use NFC to pay.

    And Finally

    Keep your hotel key shielded when out and about.

    See You There

    I think that about covers it. Now it’s time to learn some cool stuff and have a blast!

  • Cool Tools Series: NMAP for Penetration Tests

    Cool Tools Series: NMAP for Penetration Tests

    In Scottie’s recent Cool Tools blog about discovery tools, he, like many network penetration testers, starts with Nmap. Nmap is a great discovery tool with many flags and scripts. In this post, I will expand upon Scottie’s ideas and delve more deeply into what Nmap has to offer, specifically for network penetration testing.

    Hosts Marked as Down When They Are Up

    If you find you have problems with Nmap flagging hosts as down, even though they should be up, I would recommend adding these flags to your command:

    • -PS – SYN ping scan. You can optionally add a port number after this.
    • PA – ACK ping scan. You can optionally add a port number after this.
    • -PE – Typical ICMP ping echo request, typically blocked by firewalls.
    • -PP – ICMP timestamp ping query, which can sometimes get around misconfigured firewalls.
    • -PM – ICMP subnet mask ping query, also good for evading misconfigured firewalls.
    • -PO -This issues an IP protocol ping, which seems to work a lot of times when other probes don’t.

    Putting that all together, my typical scans are now starting to look like this:

    sudo nmap -oA [output] -sSUV --unique --resolve-all -PS -PA -PE -PP -PM -PO -T4 -O -p T:-,U:53,161 -vv -iL [targets]

    Some other options present here:

    • -oA [output– Output in all file formats simultaneously.
    • -sSUV – Combo of -sS (TCP SYN scan), -sU (UDP scan), and -sV (service version scanning).
    • –unique – Scan each IP only once (e.g. if raxis.com resolves to 1.1.1.1, and both are targets, only scan 1.1.1.1 once).
    • –resolve-all – If an DNS name resolves to multiple IPs, scan each IP.
    • -T4 – Go a bit faster than default, recommended for modern networks (unless you’re trying to be quiet).
    • -O – Try to determine operating system.
    • -p T:-,U:53,161 – Scan all TCP ports as well as UDP ports 53 (DNS) and 161 (SNMP).
    • -vv – Be very verbose in output.
    • -iL [targets– Use the targets in the specified file.

    Additionally, when using -oA, if your scan gets interrupted, you can use this to resume the scan where it left off:

    nmap --resume

    The Nmap Scripting Engine

    The Nmap Scripting Engine (NSE) provides 604 scripts and 139 libraries at the time I’m writing this. That number grows each year, so, needless to say, this is a very useful tool for penetration testers or for blue teams checking out possible vulnerabilities in their systems. I’ll discuss some Useful NSE scripts here, and I encourage you to take a look to see if there are others that would be helpful for your needs.

    Shodan

    • Queries the Shodan API for the targets. Follow the instructions on the NSE site to setup a Shodan API key.
    nmap --script shodan-api [IP Range] -sn -Pn -n --script-args 'shodan-api.outfile=potato.csv,shodan-api.apikey=SHODANAPIKEY'
    nmap --script shodan-api --script-args 'shodan-api.target=[IP],shodan-api.apikey=SHODANAPIKEY'

    Server Message Block (SMB)

    • Check if SMB signing is disabled:
    nmap --script smb-security-mode -p445 [IP]

    File Shares

    • Attempt to enumerate SMB shares:
    nmap --script smb-enum-shares -p445 [IP]
    • Show NFS Shares (Exports):
    nmap -sV --script=nfs-showmount [IP List or Range]
    • Attempt to get useful information from NFS shares (mimics an -ls command):
    nmap -p 111 --script=nfs-ls [IP List or Range]
    nmap -sV --script=nfs-ls [IP List or Range]

    Databases

    • Attempts to find configuration and version info for a Microsoft SQL Server instance:
    nmap -p 445 --script ms-sql-info [IP]
    nmap -p 1433 --script ms-sql-info --script-args mssql.instance-port=1433 [IP]
    • Looks for MySQL servers with an empty password for root or anonymous:
    nmap -sV --script=mysql-empty-password [IP]

    Domain Name Server (DNS)

    • Perform DNS Cache Snooping:
    nmap -sU -p 53 --script dns-cache-snoop --script-args 'dns-cache-snoop.mode=timed,dns-cache-snoop.domains={host1,host2,host3}' [IP]
    • Checks DNS anti-spam and open proxy blacklists to see if an IP has been flagged:
    nmap --script dns-blacklist --script-args='dns-blacklist.ip=[IP]'
    nmap -sn [IP] --script dns-blacklist

    Virtual Private Network (VPN)

    • Checks if the host is vulnerable to the Cisco ASA SSL VPN Authentication Bypass Vulnerability:
    nmap -p 443 --script http-vuln-cve2014-2128 [IP]

    Network Time Protocol (NTP)

    • Shows an NTP server’s monitor data:
    sudo nmap -sU -pU:123 -Pn -n --script=ntp-monlist [IP]

    Remote Access

    • Attempts to brute-force a VNC server:
    nmap --script vnc-brute -p 5900 [IP]
    • Discovers the security layer and encryption level that is supported by a RDP service:
    nmap -p 3389 --script rdp-enum-encryption <ip>

    Network Protocols

    • Attempts to brute-force a POP3 account:
    nmap -sV --script=pop3-brute [IP]
    • Attempts to brute-force a telnet server:
    nmap -p 23 --script telnet-brute --script-args userdb=myusers.lst,passdb=mypwds.lst,telnet-brute.timeout=8s [IP]

    Java

    • Attempts to dump all objects from a remote RMI registry:
    nmap --script rmi-dumpregistry -p 1098 [IP]
    nmap --script rmi-dumpregistry -sV --version-all -p 443 [IP]

    Weak Ciphers & Algorithms

    • Enumerates all web ciphers that a server accepts:
    nmap -sV --script ssl-enum-ciphers -p 443 <host>
    • Finds the number of algorithms the SSH2 server offers (or lists them with verbosity set):
    nmap --script ssh2-enum-algos [IP]

    Certificates

    • Displays the server’s SSL certificate. Set verbosity to add more details:
    nmap --script=ssl-cert -p 443 [IP]

    Http

    • Checks if HTTP TRACE is enabled:
    nmap --script http-trace -d [IP]

    And Next

    If you enjoyed this Cool Tools post, I hope you’ll take a look at the next post in the series as well.

  • The CrowdStrike Outage: Lessons Learned

    The CrowdStrike Outage: Lessons Learned

    Just a few days ago the world felt the rippling effects of a third-party push to networks across the globe. What would have normally been a routine undertaking instead caused mass disruption of information systems and brought businesses of all sizes to a standstill. Almost everyone was impacted by this incident in one way or another. At the time of this writing, some companies continue to struggle to resume normal business activities.

    As with any incident, we must take a look at our processes to see what lessons we can learn and how we can improve – an after-action report, if you will.

    Third-Party Risks

    Our society is more interconnected than ever before, and third-party vendors increasingly are active on customer production business networks. The advantages businesses receive from these interactions are often worth the risks. However, as with all business decisions, we must understand the risks that we are accepting and take steps to mitigate them to the greatest practical extent.

    One of the key takeaways from this incident is that we need to incorporate third-party risks into our business continuity (BC) plans, incident response (IR) plans, and tabletop exercises. Businesses cannot control every aspect of a third-party integration, but they can control how that risk is incorporated into the environment and put safeguards in place for maintaining continuity when an action fails to go as planned.

    Businesses should not only take this into account with their BC/IR planning but should actively incorporate this into their tabletop simulation drills. At Raxis, we conduct tabletop offerings as a simulated attack intended to model real-world threats. They facilitate cohesion and seek to highlight process gaps and less obvious exposures. A plan is only as good as its execution, and tabletop exercises are an excellent way to identify improvement opportunities in plans and processes.

    A Few Things to Think About

    • Do you have redundant systems in place that would be resilient to a third-party incident?
    • Do you have tested backups (emphasis on tested) that allow you to quickly restore your system?
    • Do you maintain adequate logging, and are these logs stored for a long enough time period to allow your team to review them and determine affected systems?
    • Do you have a current BC/IR plan, and does this plan include incidents that could be caused by third-party vendors?
    • Do you actively review your vendors and their operational processes that could affect your business stability?

    Vince Lombardi once said, It’s not whether you get knocked down, it’s whether you get up. This rings true after every security incident. What do we learn, and how do we improve?

    Need help testing or developing your incident plans? Raxis can help. Reach out to one of our advisors to learn more.

  • Meet the Team: Caroline Kelly, Sales Manager

    Meet the Team: Caroline Kelly, Sales Manager

    I’m Caroline Kelly, and I’m a part of the growing Raxis sales team!  If you reach out through the website, attend a conference we’re sponsoring, or call to talk about what testing options are a good fit, we may end up working together.

    Bonnie: Tell me a little about your background? I know we both grew up in the Atlanta area.

    Caroline: I grew up in Georgia as the oldest of three kids. We had a great time riding bikes around the neighborhood, swimming all summer, and spending time with cousins who lived nearby.   I was a bookworm (still am!) and played a lot of softball and basketball. 

    Bonnie: Atlanta and a softball player – are you a Braves fan?

    Caroline: Oh absolutely! I grew up going to games when they were losing most of them and cheered them on when they really took off!  I’ve watched them in all three home fields in Atlanta. I still have a ball with Tom Glavin’s autograph displayed in my living room, and I even flew back to Atlanta for the last game at Turner Field with my family.

    Caroline and family at the last Braves game at Turner field

    Bonnie: Awesome! So your love of softball & baseball started young! What came next?

    Caroline: When I got to high school, they had a theatre program that I auditioned for, and I was hooked!

    Bonnie: And that’s when you got into theatre?

    Caroline: Yes, I performed in theatre groups all through high school, and I ended up majoring in theatre at Kennesaw State as well (hooty hoo!) & loved it!  The storytelling aspect, the research into creating the stories based on history or legend – it’s so exciting and challenging.

    Bonnie: That sounds so interesting! Would you tell me about your favorite show that you were a part of?

    Caroline: Oh, so hard to choose!  Well, there was a collection of myths that, when put together, told the stages of the Hero’s Journey, based on Joseph Campbell’s writings.  That group of people really connected for me, and it’s still special to me.

    Or maybe the Beowulf show we took to the Edinburgh Fringe Festival – I fell in love with Scotland!

    Caroline in Scotland

    Bonnie: And now you work in tech. How did you make the leap from theatre to technology?

    Caroline: I moved from Atlanta to Memphis to help open a Shakespeare company.  Anyone who has worked on a start-up knows those first employees are head chef and bottle washers!  So, I ended up running the box office, fundraising, updating the website, setting up Wi-Fi to process credit cards securely at off-site performances, and setting up a cloud-based system to keep our files secure and backed up. 

    After a few years I knew I wanted a family and would need a more regular schedule.  A friend offered to teach me about VOIP systems.  I got a job doing that, but that company was eventually bought by a network company, so I learned more about routing and switches as well as Wi-Fi design.  Next I worked for an MSSP, so learned about packet tracing and securing a system beyond a firewall. 

    Bonnie: And that lead to penetration testing?

    Caroline: Well, I was always drawn to the security aspect of things.  It’s constantly changing, and that challenge, plus the stakes for businesses to understand the threats and defend themselves, intrigued me.   I actually knew Raxis’ Brad Herring from my time at Kennesaw State, and we had stayed in touch. You may not know this, but I actually watched Raxis grow for years before interviewing!

    Bonnie: Wait, so you knew about us before we knew about you?

    Caroline: Haha, I guess so!  After watching how you were growing selectively and knowing how Brad and the team treated your clients with such honesty and integrity, I knew I would jump at the chance to join Raxis if it ever came up.

    Bonnie: And then you did!

    Caroline: Right!  I’m so glad it has worked out. Everyone has been great, and I have loved getting to know the other team members. 

    Bonnie: Do you think you’ll ever go back to theatre?

    Caroline: No. Honestly telling the story of security is something I think I do well.  Different industries have different risks and concerns, but at the end of the day everyone just wants to be safe to continue their business.  I get to hear about companies dong incredible work, help Raxis be a part of keeping them secure, and still have dinner with my nine year old every night.  Every day is a new challenge and something to learn, and I love that. 

    Bonnie: Ah, your son is nine now? He’s growing so fast!

    Caroline: Yep, and I love being a “boy mom”!

    Caroline and son at a ball game

    Bonnie: That’s great!  What kinds of things does a “boy mom” get to do?

    Caroline: He plays sports too and loves to climb trees. We go see 901FC soccer games, and I’m trying to get him to help me in the garden – especially with the butterflies.

    Bonnie: You have a butterfly garden?  What does that look like?

    Caroline: Yeah!  We have some native passionflower that is the host plant for the orange Gulf Fritillary. I planted a butterfly bush and some lantana nearby for pollen.  Last year we moved a bunch of caterpillars into a habitat so they wouldn’t get eaten by birds before they emerged. We release them once they can fly. We even sent six to my son’s classroom so they could watch the process.

    A butterfly on Caroline's hand

    Bonnie: That is so neat!  I bet he is really enjoying that.

    Caroline: He is, but gardening is mom stuff.  He’s more interested in teaching me to play Fortnite and Roblox.  I’m still pretty terrible at those, honestly, but I will totally play anytime he likes so I can enjoy bonding with him. We also watch anime and make homemade popcorn.  That’s one of our best weekend nights!  And now he wants to be a video game designer, so we’re figuring out those programs together.

    Bonnie: Training a new little developer, huh?

    Caroline: Right!  I may have to call you for some help once he starts writing his own code though.  And then of course we’ll need to test it!

  • Cool Tools Series: Host Discovery

    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.

  • Ongoing Cyber Attack Disrupts Car Dealerships

    Ongoing Cyber Attack Disrupts Car Dealerships

    On June 18th, 2024, thousands of car dealerships across the United States and Canada fell victim to a cyberattack against an upstream cloud service provider, resulting in widespread outages and significant operational degradation. A second attack occurred a day later and caused further damage, exacerbating an already dire situation.

    What happened?

    The attackers targeted CDK Global, a behemoth in the automobile SaaS industry with services extending into nearly all areas of business.

    CDK Global offers SaaS solutions that help dealerships manage various aspects of their business, including vehicle acquisitions, sales, financing, insuring, repairs, and maintenance. Their services are critical for business continuity of their customers. The downstream impacts of the attack affected over 15,000 dealerships across the continental US and Canada. At this time, no direct impact to any vehicles or vehicle-connected systems has been reported.

    In response to the attack, CDK shut down its IT systems, including customer logins and data center operations. At the time of this writing, three days after the initial attack, dealerships remain severely hampered by the ongoing outage, as noted in numerous X feeds:

    While specific impacts vary or have yet to be determined, at the time of this writing, concerns shared amongst the victims include:

    1. Operational Disruption: CDK’s systems were compromised, affecting dealership operations, inventory management, and customer service for an extended period.
    2. Reputation Damage: Public scrutiny of the breach may erode trust in dealerships and manufacturer brands, affecting customer loyalty and sales.
    3. Legal and Regulatory Fallout: Dealerships may face legal actions, fines, and regulatory scrutiny due to data protection violations.
    4. Financial Loss: Remediation costs, legal fees, and potential lawsuits can strain dealership finances.

    Why were Car Dealerships Targeted?

    Car dealerships pose a uniquely attractive target to malicious actors. Often lacking in dedicated security staff and formal risk management processes, they still handle large amounts of money and store vast amounts of customer data, including sensitive PII.

    Also, dealership systems are often interconnected with other external systems for business processing, which may facilitate additional side channel attacks.

    Recent Trends

    A 2023 report by CDK highlighted that 17% of surveyed dealers experienced cyber-attacks within the past year, up from 15% the previous year. Of those dealerships affected, 46% reported negative financial or operational impacts. The scale and impact of this incident is without prescedent and may be felt for months.

    Response and Recovery

    To their credit, CDK Global promptly shut down affected and potentially affected systems as a precautionary measure.

    • Core document management and digital retailing solutions were prioritized and later restored.
    • At the time of this writing, CDK continues to conduct ongoing tests to bring other applications back online without introducing additional risk.

    CDK also issued a warning to customers on its interactive voice line:

    ‘We are aware that bad actors are contacting our customers posing as members or affiliates of CDK trying to obtain system access. CDK associates are not contacting customers for access to their environment or systems.’
    ‘There is currently no known estimated time frame for resolution and therefore our dealer systems will not be available likely for several days.’

    Looking Forward

    It goes without saying that risk management and business continuity are critical for car dealerships. Dealerships now find themselves facing the stark reality that the two are inseparable. How they choose to move forward will shape the viability and perceived trust of the industry.

    Raxis recommends that car dealerships consider the following steps when designing a robust security program:

    1. Data Protection Regulations:
      • Become familiar with data protection laws such as the Gramm-Leach-Bliley Act (GLBA), which outlines obligations to safeguard consumers’ PII, such as names, addresses, and social security numbers.
      • Implement comprehensive data protection measures, including encryption, granular access controls, and effective monitoring.
    2. Secure IT Infrastructure:
      • Ensure dealership IT systems are secure:
        • Encrypt data at rest and in transit.
        • Use multi-factor authentication for identity verification.
        • Regularly update software and maintain firewalls.
        • Educate employees about phishing scams and secure password practices.
    3. Data Integrity and Governance:
      • Establish strong data governance policies and procedures:
        • Conduct regular audits to identify and reconcile anomalies.
        • Apply layered controls and redundancy to critical systems.
    4. Limit Access and Educate Staff:
      • Using the principle of least privileged access, allow access to dealership data to only what’s necessary for specific functions. This applies to personal and interconnected systems.
      • Train employees to recognize security threats and respond appropriately.
      • User strong, complex passwords and change them regularly.
    References:
    1. https://www.usatoday.com/story/money/cars/2024/06/19/cdk-cyber-attack-hits-automotive-dealers/74150427007/
    2. https://www.ibtimes.com/cyber-attack-cripples-thousands-car-dealerships-us-canada-busy-holiday-3734785
    3. https://www.jmagroup.com/resources/operations/tdawa/8-important-dealership-regulations-how-to-protect-yourself-and-your-customers
    4. https://industrialcyber.co/vulnerabilities/check-point-finds-that-info-stealing-malware-targets-german-car-dealerships-auto-manufacturers/
    5. https://securityboulevard.com/2024/02/top-cyber-threats-automotive-dealerships-should-look-out-for/
    6. https://x.com/CarBusinessMan/status/1803722884134719894
  • Meet the Team: Ryan Chaplin, Lead Penetration Tester

    Meet the Team: Ryan Chaplin, Lead Penetration Tester

    I’m Ryan Chaplin, lead penetration tester at Raxis. If you team with Raxis for a penetration test, social engineering engagement, or a red team, we might get to work together!

    Bonnie: Tell me a little about your background?

    Ryan: When I was a kid, at about 9 or 10 years old, I started building my own computers. By junior high I was in advanced placement software development courses through Indiana University Southeast.

    Ryan Chaplin playing an arcade game

    This continued through college where I took computer science courses. However, due to the job market, after the 2008 crash, I ended up working in marketing right out of college. I read Automate the Boring Stuff with Python, which was absolutely pivotal because it allowed me to automate 80-90% of my job and focus on skills I wanted to improve. Realistically it means I ended up doing everything but marketing. 

    Bonnie: So how did you get into Penetration Testing?

    Ryan: Several years ago the company I was working at was hacked and was actively serving our customers malware. Our main developer locally was on maternity leave, and our offshore devs were all on holiday. I ended up being the main technical resource who was available and familiar with our website, so I was thrown into the fire for my start.

    At the time I helped develop and deploy a patch. Then, in the medium and long term, we came up with mitigation strategies, but, really for me, that started my passion to learn more through platforms like HackTheBox and OffSec.

    Bonnie: What a way to start your journey into cybersecurity!  Did you just manage to find those platforms and come up with mitigations on your own?

    Ryan: Definitely not! One of my closest friends from undergrad introduced me to the community, and I do believe the cybersecurity industry is much more of a community than most industries. We are all learning and building each other up together. The emphasis in the cybersecurity community about giving back is one of my favorite things about this industry. 

    Bonnie: So community is really important to you?

    Ryan: Absolutely! I’m from a very small town of only about 1,500 people. Everyone knows everyone, and, even though I now live outside of a major city, the lessons I learned in that small town about the importance of sticking together have stayed with me.

    Ryan and his wife

    Bonnie: Wow that is a small community! Anything more you can tell me about that kind of community?

    Ryan: When I was growing up there, no one really had much of anything, so we focused on the good times we could have together. I wouldn’t be where I am today without such a great family and community standing behind me. I still visit several times a year.

    Besides that there are all kinds of fun stories that would take up way too much time. Some other time you will have to remind me to tell you about how we used to take jon boats up the highway when it flooded or stories about Larry Bird – you know he was originally from my hometown – if you are into the NBA or basketball.

    Bonnie: Wait, you are from a town of 1,500 people, and one of them was Larry Bird?

    Ryan: Hahaha! Yeah, I guess it’s a pretty atypical town. It’s Indiana so we already have a much higher percentage of people who are into basketball, but I would say my hometown takes it to another level in terms of enthusiasm.

    Bonnie: So I’m assuming that is probably one of your hobbies? Do you have any others?

    Ryan: Playing and watching basketball are two of my hobbies, but, honestly, I have a lot of hobbies. I’ve also consistently been into running and lifting weights for a very long time. Now that I think of it, my first experience “hacking” really was installing a chip in my PlayStation so I could play homebrew and modified games. So video games have always been around in my life too.

    Sourdough bread Ryan made

    Otherwise, I really enjoy a challenge and learning new things. During COVID that meant mastering my sourdough technique. Lately I have been playing piano for a new challenge. Lastly, of course, I’m into computers. The challenges I’ve been looking into recently, when it comes to computers, are working with and understanding low-level code, like assembly, better.

    Bonnie: I could see that being useful for your cybersecurity career as well. What are your plans with your career?

    Ryan: Yeah, I really think becoming better acquainted with low-level concepts will help me to succeed when I take the OSED in the next year or two. I’d love to eventually get my OSCE3 and a CISSP as well.

    Right now, though, I’m just excited to be joining a team like Raxis. This is a goal I’ve worked towards for over six years, grinding through become a top ranked hacker on HackTheBox, getting my OSCP, and watching countless hours of DefCon and Black Hat talks. There really couldn’t be a better company for it to happen at either. Not only does Raxis have amazing clients and great relationships in the security community, but I’ve also been impressed with each person I’ve worked with so far.

    Bonnie: Thanks for the kind words! We are looking forward to having you on the team full time!

  • Password Length: More than Just a Question of Compliance

    Password Length: More than Just a Question of Compliance

    Password length is a topic we’re asked about a lot, and that makes sense because it can be quite confusing. There are several different compliance models that organizations use – from PCI to NIST to OWASP and more. Each has its own standards for password strength and password length.

    When it comes to penetration testing, weak password recommendations often are more rigorous than compliance standards, and this leads to a great deal of stress, especially for organizations that have already spent time and effort in implementing password rules that meet the compliance standards they’ve chosen.

    Why So Many Different Standards?

    First, speaking from experience, penetration testers see firsthand how weak and reused passwords are often a key part of achieving access over an entire domain (i.e. having administrative powers to view, add, edit, and delete users, files, and sensitive data, including passwords, for an organization’s Active Directory environment). While this is the type of success that pentesters strive to achieve, the true goal of a penetration test is to show organizations weaknesses so that they can close exploitation paths before malicious attackers find them.

    For this reason, Raxis penetration tests recommend passwords of at least 12-16 characters for users and at least 20 characters for service accounts. Of course, we recommend more than length (see below for some tips), but Raxis password cracking servers have cracked weak passwords in minutes or even seconds on internal network penetration tests and red team tests several times this year already. We don’t want our customers to experience that outside of a pentest.

    Post-It Notes With Passwords on a Monitor

    On the other hand, compliance frameworks are just that – frameworks. While their aim is to guide organizations to be secure, they do not endeavor to force organizations out of compliance with a stringent set of rules that may not be necessary for all systems and applications. For example, a banking website should require stronger credentials and login rules than a store website that simply allows customers to keep track of the plants they’ve bought without storing financial or personal information.

    If you read the small print, compliance frameworks nearly always recommend passwords longer than they require. It’s unlikely, though, that many people read the recommendations when working on a long compliance checklist when they have several more items to complete.

    Times are Changing

    Of course, time goes on, and even compliance frameworks usually recommend at least ten-character passwords now. The PCI (Payment Card Industry) standards that are required for organizations that process credit cards now require 12 character passwords unless the system cannot accept more than eight characters. PCI DSS v4.0 requirement 8.3.6 does have some exceptions including still allowing PCI DSS v3.2.1’s seven-character minimum length that is grandfathered in until the end of March 2025.

    This is a good example of PCI giving companies time to change. It’s been well known for years that someone who has taken the time and expertise to build a powerful password-cracking system can crack a seven-character password hash in minutes. This leaves any organization that still allows seven-character passwords with a strong threat of accounts becoming compromised if the hash is leaked.

    OWASP (the Open Web Application Security Project), which provides authoritative guidance for web and mobile application security practices, accepts 10 characters as the recommended minimum in their Authentication Cheat Sheet. OWASP states that they base this on the NIST SP 800-132 standard, which was published in 2010 and is currently in the process of being revised by NIST. Keep in mind that OWASP also recommends that the maximum password length not be set to low, and they recommend 128 characters as the max.

    The Center for Internet Security, on the other hand, has added MFA to their password length requirements. In their CIS Password Policy Guide published in 2021, CIS requires 14 character passwords for password-only accounts and eight character passwords for accounts that require MFA.

    Other Factors

    This brings up a good point. There is more to a strong password than just length.  

    Digital screen showing a key

    MFA (multi-factor authentication) allows a second layer of protection such as a smartphone app or a hardware token. Someone discovered or cracked your password? Well, they have one more step before they have access. Keep in mind that some apps allow bypassing MFA for a time on trusted machines (which leaves you vulnerable if a malicious insider is at work or if someone found a way into your offices).

    MFA is a great security tool, but it still relies on the user to be vigilant.

    Raxis’ Recommendations

    In the end, there are a myriad of ways that hackers can gain access to accounts. Raxis recommends setting the highest security possible for each layer of controls in order to encourage attackers to move on to an easier target.

    We recommend the following rules for passwords along with requiring MFA for all accounts that access sensitive data or services:

    1. Require a 12-character minimum password length.
    2. Include uppercase and lowercase letters as well as numbers and at least once special character. Extra points for the number and special character being anywhere but the beginning or end of the password!
    3. Do not include common mnemonic phrases such as 1234567890, abcdefghijkl, your company name, or other easily guessable words. Don’t be on NordPass’s list!
    4. Do not reuse passwords across accounts, which could allow a hacker who gains access to one password to gain access to multiple accounts.

    There are two easy ways to follow these rules without causing yourself a major headache:

    1. Use a password manager (such as NordPass above, BitWarden, Keeper, or 1Password amongst others). Nowadays these tools integrate for all of your devices and browsers, so you can truly remember one (very long and complex) password in order to easily access all of your passwords
      • These tools often provide password generators that quickly create & save random passwords for your accounts.
      • They usually use Face ID and fingerprint technology to make using them even easier.
      • And they also allow MFA, which we recommend using to keep your accounts secure.
    2. Use passphrases. Phrases allow you to easily remember long passwords while making them difficult for an attacker to crack or guess. Just be sure to use phrases that YOU will remember but others won’t guess.

    And I’ll leave you with one last recommendation. On Raxis penetration tests, our team often provides a list of the most common passwords we cracked during the engagement in our report to the customer. Don’t be the person with Ihatethiscompany! or Ihatemyb0ss as your password!

  • Raxis’ Brian Tant Featured on Fox 5 Atlanta

    Raxis’ Brian Tant Featured on Fox 5 Atlanta

    Our very own Chief Penetration Testing Officer, Brian Tant, was interviewed by Dana Fowle and the I-Team at Fox 5 Atlanta regarding the AT&T breach. Brian discusses the original breach by Shiny Hunters and what you can do now that the data has been posted online. Brian’s key take-away is not to get complacent. Use the credit services AT&T offers if you receive a letter, and monitor the activity regularly.

    Click here to watch the video on Fox 5 Atlanta’s website

  • SOC 2 Compliance: Is it Right for Your Organization?

    SOC 2 Compliance: Is it Right for Your Organization?

    What it Means to be SOC 2 Compliant

    AICPA (the American Institute of Certified Public Accountants) developed the SOC 2 (System and Organization Controls) framework in 2010 to provide guidance for evaluating the operating effectiveness of an organization’s security protocols, especially within cloud environments.

    SOC 2 is a compliance and privacy standard that outlines how organizations should manage customer data and related systems to ensure confidentiality, integrity, and availability.

    SOC 2 defines five Trust Services Criteria (TSC) that evaluate various aspects of information security and governance. The first, security, must be a part of any SOC 2 audit, and organizations can choose to include other trust services categories. Organizations tailor their SOC 2 audits based on their specific needs and the services they provide.

    1. Security: Ensures protection against unauthorized access, breaches, and other security incidents by assessing the effectiveness of controls related to data protection, access, and system security.
    2. Availability: Ensures systems are available for use as needed by examining whether the service is available as promised and whether any planned or unplanned downtime occurs.
    3. Processing Integrity: Ensures accurate and complete processing of data as well timeliness and consistently of data processing.
    4. Confidentiality: Ensures data confidentiality by examining data encryption, access restrictions, and confidentiality agreements.
    5. Privacy: Ensures compliance with privacy regulations for personal information.

    Customizing SOC 2 Controls to Best Fit Your Organization

    Organizations design their own internal controls to meet these requirements, as needs and controls are unique to each organization. It’s common for organizations to use a service or consulting company, such as Raxis’ partner Strike Graph, to help them understand the different controls, to assess which are relevant for the organization’s systems and services, and to ensure that they have fulfilled the controls properly before an audit takes place.

    Many organizations focus entirely on the Security TSC, also known as the common criteria, for their SOC 2 audits. The common criteria are required for all SOC 2 audits. These are the areas of focus, created in 2017 and revised in 2022:

    • CC1: Control Environment
    • CC2: Communication and Information
    • CC3: Risk Assessment
    • CC4: Monitoring Activities
    • CC5: Control Activities
    • CC6: Logical and Physical Access Controls
    • CC7: System Operations
    • CC8: Change Management
    • CC9: Risk Mitigation

    During the SOC 2 audit, an independent auditor evaluates the organization’s security posture related to the selected Trust Services Criteria. Organizations provide evidence for the controls they have in place, and, if auditors feel there are deficiencies, organizations can choose to remedy those during the audit or to explain why they accept the risk.

    SOC 2 Type 1 versus SOC 2 Type 2

    While Type 1 provides a foundational layer regarding the control design for the organization, Type 2 offers a comprehensive view of control effectiveness over time. Type 1 is the first step in annual SOC 2 compliance. Organizations can choose to combine Type 1 and Type 2 during their first SOC 2 audit or to become Type 1 compliant the first year and then move on to Type 2 in subsequent years.

    SOC 2 Type 1 evaluates an organization’s cybersecurity controls for their effectiveness at safeguarding customer data at a specific point in time, while Type 2 examines how well the organization’s system and controls actually perform over a period of time (often 3-12 months).

    Compliance Checkmark

    Raxis, for example decided to focus on SOC 2 Type 1 in our first year of compliance so that our team had the time to focus on building out the necessary controls in the most robust manner possible that matched our systems and services. SOC 2 allows organizations (to a certain extent) to setup their controls with as much simplicity or complexity as they see fit. As security is integral to every part of Raxis’ business and goals, our aim in choosing to become SOC 2 compliant was to take the time to build the controls out to best protect the data entrusted to us.

    Honestly, we discovered that we could not discover the best way to implement our controls without building out and testing the systems themselves. In the end, we could have performed our SOC 2 Type 2 audit in 2023 as well, but with the busy end-of-year penetration testing season, we decided to complete our first SOC 2 Type 2 compliance audit this April, covering this past winter and spring.

    How Does Penetration Testing Relate to SOC 2 Compliance

    SOC 2 compliance is essential for demonstrating your commitment to data protection, while penetration testing provides an extra layer of security by identifying vulnerabilities so that your organization can correct them before they are exploited.

    But there’s more… SOC 2 compliance often requires a penetration test (and a retest of critical and severe findings) as one of the controls in order to show that organizations successfully monitor and correct/mitigate security risks to their systems.

    Raxis often performs SOC 2 penetration tests for our customers and is proud to work with SOC 2 partners to perform penetration tests for their customers as part of their framework offerings. Tailoring your penetration test to your specific needs and goals is an important first step in scoping any test.

    Why Choose to Become SOC 2 Compliant?

    While not yet required, SOC 2 compliance helps establish trust between service providers and their customers. With high-profile data breaches becoming more common, many organizations, like Raxis, choose to become SOC 2 compliant both as an exercise to ensure the security controls they’ve created are robust and also to ensure the controls are updated as the threat landscape changes over time.

    SOC 2 compliance is audited annually, ensuring that both the organization’s controls themselves and their implementation are tested regularly to ensure that new risks are accounted for and that security policies and procedures do not become stale. SOC 2 compliance ensures that organizations handle customer data securely and transparently, meeting specific criteria for trust and protection.

  • Raxis Achieves SOC 2 Type 2 Compliance

    Raxis Achieves SOC 2 Type 2 Compliance

    We are thrilled to announce that Raxis has successfully achieved SOC 2 Type 2 compliance. This milestone underscores our commitment to maintaining effective security controls over our information systems and the penetration testing and cybersecurity services we offer.

    Our SOC 2 compliance provides assurance to our clients that their data is handled securely and in accordance with industry best practices. We remain committed to maintaining the highest level of security and privacy, and we will continue to invest in our compliance program to stay ahead of evolving threats.

    We remain dedicated to providing a secure platform and services for our clients. We are pleased to provide our SOC 2 Type 2 report to current customers and prospective customers under NDA. Contact our team for more information.

  • SQLi Series: SQL Timing Attacks

    SQLi Series: SQL Timing Attacks

    In the previous post we built a web page and connected it to a SQL server in order to test and learn about SQL injection. In the previous application the website returned data to the web page making it easy to gather information from the database as the info was printed out.

    What happens if the web application does not print the data from the SQL query. Well, there are still ways to gather data. SQLi attacks where the results are not displayed are referred to as Blind SQL Injection. Of course, this makes the attack more difficult, but these are by far the most common SQLi vulnerabilities, and attackers don’t stop just because they take extra effort.

    One such way is using timing. MySQL servers have a Sleep function which causes the server to sleep for the specified number of seconds. You can use this in conjunction with comparatives allowing the dumping of the database.

    A Refresher

    We’re using basically the same application as last time, except that this time the application only returns success or failure depending on whether the username and password entered are correct or not. As a side note, a success fail message can be used much the same way, but this blog will discuss timing.

    This is the response when the username and password entered were correct:

    A success when the username and password are correct

    And this is the response when the username and password did not match:

    A failure when the password is incorrect

    Now we can login as we did last time by closing the SQL quote and commenting out the rest of the query, but we’ve already gone over that in the first blog in this series. So let’s explore dumping information from the database instead.

    Success when the password is incorrect using a SQLi attack

    Useful SQL Functions & Clauses

    In order to pull information from the database we will use a number of MySQL commands and features.

    SLEEP() Function

    The SLEEP function will cause the server to wait for the specified number of seconds before returning the information.

    Example from the command line:

    The SLEEP function

    As we can see the query takes five seconds to complete.

    SUBSTRING() Function

    We will need a way to test one character at a time, so we need a way to get one character from the returned info so we can compare it. For this we use SUBSTRING():

    SUBSTRING(String, Position, Length)
    The SUBSTRING function

    IF() Statement

    This is how we branch in MySQL.

    IF(Condition, Value if true, Value if false)
    An IF statement

    For the Value if true and Value if false we can do more than just add return values. For instance, we can put the SLEEP function right in the IF function.

    Using the SLEEP function in an IF statement

    We can see that, when the condition was true, the server waited for five seconds.

    COUNT() Function

    There will be times when we need to know how many of a thing we have. For instance, we might need to know how many columns are in a table or how many rows.

    Now, in the database I’m using for testing, I know that there are three columns in the users table.

    Here is an example using COUNT showing that.

    The COUNT function

    DATABASE() Function

    We can get the current database in use by calling the DATABASE() function:

    The DATABASE function

    Querying Database Schemas

    If, for some reason, you need to pull the databases manually, maybe because one isn’t set or you want to see what else is out there, you can use this query:

    SELECT table_schema FROM information_schema.tables WHERE table_schema NOT IN ( 'information_schema', 'performance_schema', 'mysql', 'sys' ) GROUP BY table_schema;
    Querying the database schema

    We should note that default databases are removed by the NOT IN() phrase.

    Getting Tables

    We can query the information_schema database to get tables in a database:

    SELECT table_name from INFORMATION_SCHEMA.tables WHERE table_schema='DATABASE';
    
    Getting tables using the information_schema

    Getting Columns

    We can also query the information_schema database to get the column names in a table:

    SELECT column_name FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA='DATABASE' and TABLE_NAME='TABLE_NAME';
    
    Getting columns using the information_schema

    Comparative Queries with the LIKE & BINARY Functions

    = does not always mean equal. With the equal sign we can see how a capital A and a lowercase a are equal. Which is not true in a case sensitive language.

    An IF statement showing that the equal sign doesn't always mean "equals"

    To get around this we can use LIKE BINARY to compare. Here we find that a capital A and a lowercase a are not the same:

    Using LIKE BINARY to find strings that are exactly equal

    CAST() Function

    Sometimes when comparing things, it helps to cast items to a known type.

    Here is an example of casting 9 to a character:

    The CAST function

    LENGTH() Function

    When trying to figure out what a string is, it helps to get the length of the string:

    The LENGTH function

    LIMIT & OFFSET Clauses

    Given that we are using Blind SQL, we can really only test one thing at a time. This is where limiting the amount of returned data comes in handy with the LIMIT clause.

    The LIMIT clause

    We can step down the list using the OFFSET clause. Note that we increase the offset to one less than the count as that will be the last item.

    Using the OFFSET clause

    Bringing It All Together

    Now that we have all the tools we need, let’s put them together and pull info from the database.

    Basically, we will check character by character. First thing we would want to find is the database name. We should probably first figure out how long the database name is.

    Since we are using conditionals, it might be easier to use the username part of the query, that way we don’t need to have the right password.

    Closing off the SQL code after the username so that we don't need to know the password to perform our attacks

    First we see if the length is 1. It’s not, as the response comes back in less than five seconds.

    Discovering that the length is not 1

    Next we try 2, 3, and 4. We find out that 4 is correct, as the application takes longer than five seconds to respond.

    The Length is 4

    Now we need to figure out the letters in much the same way. Now we use the SUBSTRING function to test one letter at a time.

    Testing Letters for the Database Name

    To make things easier, I used Burp Intruder to send the letters automatically, instead of manually.

    We find that the letter S takes five seconds to respond. Now we know the first letter is S.

    Discovering that the first letter is "S" because there is a delay

    Next step is to test the second character.

    Testing the second character

    And we find that the second letter is Q.

    Finding that the second letter is "Q" using a timing attack

    Now, since I created the application, I know the database name is SQLi so let’s move on to getting table names.

    First we use some weird wizardry to discover the number of tables in the database, combining several of the functions we saw above:

    Getting the number of tables in the database

    Here we are getting the count of tables in the SQLi database. We find that there is only one table.

    Now let’s get the table name.

    Let’s start with getting the length of the table name.

    Getting the Length of the Table Name

    We find that the length of the name is five. With the length we can start grabbing the chars.

    Here’s the query we will use.

    Getting the table name one character at a time

    Basically, we are asking for all the table names for tables in the SQLi database. We grab the first one and then use substring to test one character at a time.

    Using Burp Intruder we find the first character is u. Repeating we find that the table name is users.

    Using Burp Intruder to find the character "u" with a timing delay

    Note:

    When retrieving names with this method, knowing the length is not truly required. When trying to compare to additional characters – say position six in the table name – it will always return false, meaning that the delay will never occur. If all the possible results stay under the delay, we know that we have the entire string. I like the idea of using the length to make sure I don’t miss something, but it’s not absolutely necessary.

    Now that we have the table name, it’s time to start getting data from the table itself. First, we need to know how many columns there are in the table.

    Finding There are 3 Columns

    When using the COUNT function to learn the number of columns, we find that there are three, as that’s when the sever takes more than five seconds to respond. With the number of columns in hand, let’s get those column names.

    This is similar to getting the table name but just querying different information.

    Here we get the length of the first column name:

    Finding Length of First Column Name

    And next the column name itself.

    Getting the Column Name

    Since we are getting information in the same way, this is very repetitive, so I’m going to assume you get the idea and go through this quickly.

    As an example, I’ll show how to get the second column’s information, which just means adding an OFFSET to the limit:

    Getting Length of Second Column

    Here we get the first letter of the second column:

    Testing Name of Second Column

    The second column is password, so, as expected, we find that the first letter is p.

    With all the table information, now we just need to start grabbing the data from the table. We can start by seeing how much data is in a table.

    Since this is a small test database, there isn’t a lot of data, so we can count the number of items and compare it to numbers we retrieve easily. On larger sets you may have to be more careful or smarter in gathering info. But this is a basic writeup giving the ideas, and I’ll leave that as an exercise to the readers.

    With this database, we find that there are only three records in the table:

    Getting Amount of Data in Table

    Now let’s get the first username from the table:

    Getting the Username

    And finally, we get their password:

    Getting the Password

    In Conclusion

    Timing attacks, as with all Blind SQLi, take a good deal of time and patience, but the rewards can be discovering credentials to login to the database or sensitive customer information like PII (Personally Identifiable Information) and financial data, like credit card numbers.

    As with all injection attacks, the remediation is to always validate user input. Raxis recommends keeping a list of whitelisted characters and deleting other characters before they process against the database. Cleansing data to be certain that user input is always treated as text (and not run as a command) is also key to this process.

    Understanding how to perform attacks like these are critical for web and mobile application penetration testers, just as understanding the idea of how they work is key for application developers so that they can build safeguards into their apps to protect their data and their users.