The Digital Fortress: How APIs Are Reshaping Cybersecurity in the Age of AI Cybersecurity isn’t just about protecting networks. It’s about understanding the intricate digital highways that connect our most...
The post Innovator Spotlight: Wallarm appeared first on Cyber Defense Magazine.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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 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.
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.
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.
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.
Wade Lance is the Field CISO for Synack.
Are you more secure this quarter than last quarter? Are members of your team learning and getting better? Are you finding deficiencies in your cybersecurity program and fixing them – or are you just swimming along from patch to patch, hoping for the best?
These tough questions are driving many organizations to overhaul their approach to security testing. It’s easy to argue a given security initiative reduces risk. The board is now demanding that you prove it.
Traditional security testing tends to be coin-operated: Perhaps you schedule a one-off pentest, find a vulnerability, fix it, report it to regulators if needed– end of story. There’s no attempt to actually learn about your overall security posture or change your long-term risk level.
Through our Synack Platform, you can review metrics that show the root causes of your security risks, giving you the tools and information to demonstrate to management that you’re actually solving problems. It’s a transformational approach that delivers the kind of information security leadership is demanding.
In one recent case, we tested a customer across an entire year. About 80% of the vulnerabilities we found over that timeframe had to do with authentication weaknesses. Yes, we’re going to keep finding the flaws and yes, members of our elite Synack Red Team of security researchers can keep validating they’re successfully patched.
Finding and fixing bugs is all fine and good. But if you keep seeing fruit flies in your house, shouldn’t you try to find the source rather than brushing them away one by one?
It was clear that this particular organization needed to boost its developers’ understanding of secure authentication practices so they could stop introducing new vulnerabilities. That deeper insight into authentication problems wouldn’t have emerged from piecemeal security testing aimed solely at ticking checkboxes for compliance.
Our Platform isn’t just about tactical advantages of tapping into a global network of 1,500-plus diverse, vetted security pros. Of course, we believe diverse perspectives in security testing are essential to hardening systems against the full spectrum of cyberthreats. But the Platform is also about offering customers adversarial testing that shows patterns and trends, so CISOs or security leadership have answers when the board comes knocking. That’s a game changer in today’s security landscape.
At Synack, we use transformational security testing to:
Yes, we can augment your operational teams with scalable pentests, succinct (and fast) reporting and surge capacity for emergencies like the Log4j vulnerability. But we can also bring the receipts needed to document your security journey and show progress to executives. You won’t get that from traditional testing.
To learn more about the strategic value of the Synack Platform, book a demo or contact us here.
The post Leveling Up Your Security Strategy with the Synack Platform appeared first on Synack.
In the cyber realm, organizations are often running their defensive and offensive security operations with little coordination.
Defensive security techniques, such as firewalls, endpoint detection and response, network access control, intrusion prevention and security information event management, detect and stop attackers. While offensive security offers a way to test the effectiveness of cyber defenses, including techniques and tools such as red teaming, penetration testing, vulnerability assessments and digital reconnaissance. Too often organizations focus on defensive security and not enough on offensive security testing.
By design, security offense and defense teams work separately, with the red team or pentesters probing the attack surface looking for weaknesses, much like malicious hackers might. Without consistent and frequent communication between the two, the defense won’t know where to make improvements.
Security Operations Centers (SOC) focus on defensive cybersecurity. SOCs use many defensive security tools, as such they need a single pane of glass to view and correlate the data points coming from each source. Splunk Enterprise and Splunk Cloud (Splunk) are data platforms at the center of security operations that provide insights across disparate data streams to achieve end-to-end visibility for SOCs. Often missing are the results of offensive security testing into the SOC’s single pane of glass.
To combine offensive security data, Synack offers an add-on app for Splunk, allowing the SOC to view, correlate and receive alerts for the results of offensive security tests and recommended fixes to their defensive security in real time.
When information about security flaws isn’t accessible by the SOC, vulnerabilities and exploits uncovered by offensive security testing are reviewed only occasionally (e.g. in conjunction with periodic events such as yearly security compliance audits). New types of threats appear daily, so an occasional review isn’t sufficient to maintain good security posture. However, given the opportunity, Splunk’s architecture can ingest dynamic offensive security testing results and make such results actionable by security leaders.
An organization’s defenses can, and should, be tested against the latest security threats, not just the ones needed to pass a yearly compliance audit.
Synack helps address these challenges by offering a premier security testing platform, supported by an expert, vetted community of security researchers who run continuous vulnerability assessments and deliver on-demand pentesting as new exploits emerge. The Synack Red Team (SRT)—1,500+ members strong—allows customers to take advantage of a diverse and instantly scalable security talent pool without the overhead of static headcount to accommodate surges in testing demand. Customers get offensive security testing 365 days a year with actionable reports to empower them to tackle new risks as they occur.
The Synack integration with Splunk uncovers exploitable vulnerabilities that can be correlated with network traffic, logs and other data collected by Splunk to recommend more effective security policies and rules on defensive tools (e.g. intrusion prevention systems and web application firewalls). Progress to harden an organization’s attack surface can be made by reviewing results, verifying recommendations and patching fixes (which can be verified by the SRT). The integration automates this process by facilitating continual improvement in security posture.
With the integration between Synack and Splunk, organizations can seamlessly coordinate offensive security into their SOC, enabling continuous defensive improvement in cyber security posture and protection. Splunk and Synack help all your team members work from the same playbook.
To learn more about Synack’s premier security testing please visit our website, to learn about Splunk see their site and to access the Synack Integration with Spunk please visit the Splunkbase.
The post Splunk and Synack Partner to Bring Both a Defense and Offensive Strategy appeared first on Synack.
The U.S. Department of Health and Human Services (HHS) draws on Synack’s trusted security researchers and smart pentesting platform to stay nimble in the face of fast-moving cyberthreats.
With 84,000 federal employees, the agency’s sheer size poses challenges when it comes to addressing the cyber talent gap or pentesting its most critical networks. It’s the largest U.S. civilian agency by spending.
“We have an enormous footprint on the internet,” said Matthew Shallbetter, director of security design and innovation at HHS, during a webinar Wednesday hosted by Synack. “Across the board, HHS is both vast and well-known – and so a good target for troublemakers and hackers.”
He cited constant cyberthreats to the National Institutes of Health, HealthCare.gov and the Centers for Disease Control and Prevention – some of the most recognizable federal research centers and government services. All those resources fall under HHS’s purview.
So how does the agency hire for mission-critical cybersecurity roles, stay on top of shifting zero-trust requirements and satisfy the need for continuous security testing?
Shallbetter shared his insights with Synack’s Scott Ormiston, a federal solutions architect who’s no stranger to the challenges facing public sector organizations globally.
With an estimated 2.72 million unfilled cybersecurity jobs worldwide, government agencies are struggling more than ever to meet diverse infosec hiring needs.
“Attackers are responding so much faster today than they were even five years ago,” Ormiston pointed out. “In the time that a vulnerability is released to the public, within minutes of that release, attackers are out scanning your systems. If you don’t have enough skilled personnel to run a continuous testing program and to continuously be looking at your assets, how do you address that challenge?”
Here are a few themes and highlights from the webinar:
It can take weeks to spin up a traditional pentest to find and fix urgent software bugs. Meanwhile, bad actors almost immediately start scanning to exploit those same vulnerabilities, whether they’re blockbuster flaws like Log4j or lesser-known CVEs.
Against that backdrop, traditional pentesting clearly falls short. But is continuous pentesting realistic?
“The short answer is yes, because your adversaries are doing it every day: They’re continuously testing your environment,” Ormiston said.
Shallbetter noted that HHS has its own set of pentesting teams that are centrally located and focus on high-value assets. But there isn’t enough in-house talent to keep up with regular testing, scanning and patching.
“If we could focus on what’s really, really important and test those [assets], we might have enough bodies,” he said. “But it’s really a challenge to try to patch vulnerabilities… The footprint never shrinks; it’s always expanding.”
To augment his own agency’s workforce capabilities, Shallbetter pulls from Synack’s community of world-class researchers. The diverse members of the Synack Red Team (SRT) allow HHS security testing to keep up with rapid software development cycles and the unrelenting pace of digital transformation.
HHS led 196 assessments using Synack’s platform, adding up to over 45,000 hours of testing on its perimeter services as part of an established vulnerability disclosure process.
That adds up to a lot of actionable data.
“We really couldn’t have done the VDP the way we did… without using a centralized platform like Synack,” Shallbetter said. “The human insight was key.”
He pointed out that HHS has automated tools across the board to help developers weed out vulnerabilities and drive down risk.
But over and over, SRT members would find more.
Shallbetter said his favorite examples are when a system owner engages the Synack Platform to validate that HHS has really fixed a vulnerability. “They ask for a retest and the researcher says, ‘Oh, I did X, Y, and Z, but I did it again…’ And the system owner says, ‘Wow, that’s really cool.’”
Those exchanges also build trust between the SRT community and HHS developers who appreciate researchers’ ability to find the vulnerabilities that matter, cutting through the background noise of automation. An average of 30 SRT members contribute their expertise to each HHS assessment, according to Shallbetter.
“When you put a bunch of humans on a target, even if it’s been scanned and pentested by an automated tool, you will find new problems and new issues,” he said.
The White House early this year unveiled its highly anticipated zero trust strategy, M-22-09, which set federal agencies on a path to achieve a slate of zero-trust principles.
Those five security pillars include identity, devices, applications and workloads, networks and data.
“It’s great to have this architecture,” Ormiston said of M-22-09. “But this also means additional stress on a cyber workforce that’s under pressure.”
Zero trust is a “hot topic” at HHS, as Shallbetter noted.
“It doesn’t feel like a marketing term; people are really beginning to understand what it means and how to implement it in certain ways,” he said.
And pentesting has emerged as “a significant part” of meeting HHS’s zero trust goals.
“I do think the scope and scale of technology now means the real vision for zero trust is possible,” he said. “For HHS, penetration testing has been an important part of speeding our deployment processes.”
Agencies have until the end of fiscal 2024 to reach the pillars of the zero trust paradigm described in the White House memo.
In the meantime, Synack will continue working as a trusted partner with HHS, delivering on-demand security expertise and a premier pentesting experience.
“I love being able to sort of toss the schedule over the fence and say, ‘hey, Synack, we need four more [assessments], what are we going to do?’—and have it happen,” Shallbetter said.
Access the recording of the webinar here. To learn more about why the public sector deserves a better way to pentest, click here or schedule a demo with Synack here.
The post Inside the Biggest U.S. Civilian Agency’s Pentesting Strategy appeared first on Synack.
Application Programming Interfaces (APIs) are the workhorses of the internet. They facilitate the efficient communication of information between applications. They improve connectivity and help in building modern architectures. When an application makes a request to another application over the internet, chances are that those applications are communicating through an API.
Organizations are rapidly adopting APIs to deliver service and data, both internally and externally. API requests in 2021 comprised up to 83% of all internet traffic. And developers are using them more each year. API traffic grew 300% faster than traditional web traffic in 2020 and hits are expected to reach 42 trillion by 2024.
APIs provide developers with powerful interfaces to the organization’s services. But while facilitating communication, the explosion in API use has broadened the attack surface available to hackers. It even spurred the Open Web Application Security Project (OWASP) in 2019 to put together a top 10 checklist for developers. In 2021, 95% of organizations running production APIs experienced an API security incident, according to a survey of 250 companies. Yet, 34% of these organizations report that they don’t have any API security strategy and slightly less than 27% report having only a basic strategy. Unmanaged and unsecured APIs are extremely inviting to attackers. In 2022, API abuse is predicted to be the most frequent attack vector for web applications.
API testing is critical. And the earlier in the development process testing can be done, the better. Almost two thirds of surveyed organizations have had to delay new application rollout due to concerns with API security. In any development project, testing early in the development process–“shifting left” in industry parlance–saves development time and cost. APIs are no exception. You need to test not only for functional problems but also for security issues. Security testing can complement web application penetration testing by directly testing functions not accessible via external GUIs. And early testing can influence the development of functionalities, informing developers and designers about what is feasible and what the risk is with each planned function.
Your API security testing program needs to recognize the differences between web application testing and testing an API directly. While classical web application security deals with threats such as injection attacks, cross-site scripting and buffer overflows, API breaches typically occur through authorization and authentication issues. The problems are most often in the business logic and loopholes in the API code. The end result is unintended access.
Automated testing solutions like scanners and firewalls only go so far in securing your APIs. Injecting human expertise into the process can take API security to the next level with true offensive testing. But not just any tester can effectively perform pentesting on an API. Security researchers skilled in API testing understand API logic and endpoint functionality, and they can develop tests to identify vulnerabilities. They approach testing with the mindset of an adversarial attacker, testing the API one endpoint and method at a time. And they have the API-specific knowledge to properly interpret testing data, allowing them to do a thorough assessment and provide only exploitable vulnerabilities, minimizing false positives. You’ll be identifying security gaps and vulnerabilities in your APIs before they can be exploited by an attacker.
The value that diverse human perspectives bring to your security posture is not to be understated. That’s why the Synack Red Team is integral to providing a true adversarial perspective for your attack surface and bridging the cyber talent gap.
The post Why You Need to Pentest Your APIs appeared first on Synack.
By Kim Crawley
The Artemis Red Team, a new subgroup within the Synack Red Team, was formed to encourage women, trans and nonbinary people to excel in their pentesting careers. There are vast numbers of untapped and underrepresented hacking talent in the world, and the Artemis Red Team is actively seeking these individuals out, giving them a home for mentorship and helping them develop their professional skills.
Members of the Synack Red Team, a large group of carefully vetted security researchers who conduct vulnerability testing and bug hunting engagements through the Synack Platform, play an integral role in improving the security of organizations and businesses of many different sizes and across many different industries.
Women and other gender minorities’ representation remains disproportionately low in tech, which has long consisted mostly of men. For an organization committed to helping solve the cybersecurity skills gap, developing a program to openly welcome women, trans and nonbinary people only made sense.
“It started from the idea that the women researchers should have their own space, their own group to boost interactions and create a safe place for discussions and guidance among the women,” said ART member BattleAngel (her handle on the Platform). “My involvement in the ART as a researcher and a mentor is that I get to share my knowledge with other women on this team.”
Investing Back into the Community with the Diana Initiative
The Synack Red Team is proud to be a 2022 Rainbow sponsor of the Diana Initiative, one of the most important events and organizations supporting women, trans and nonbinary people in cybersecurity, which takes place in Las Vegas on Aug. 10 and 11, conveniently around Black Hat USA and DEF CON.
During the 2015 DEF CON, a group of nine women came together to talk about their struggles in a male-dominated field and ways they could support one another. From that discussion, the Diana Initiative was born.
The Artemis Red Team had a similar origin story in that the SRT community managers knew they needed to create a space just for women and gender minorities if they wanted to help grow the number of security researchers. The energy and momentum behind Artemis is palpable. You’ll see some excited Synack, Synack Red Team and Artemis Red Team people at the Diana Initiative this year.
The Path to Equity
According to (ISC)²’s Women In Cybersecurity report, women are 25% of the cybersecurity workforce. For the Synack Red Team, creating equitable opportunities for members means ensuring that Artemis members have the ability to level up their skills and learn from each other. Taking on tougher missions means a higher payout or reward.
Mentorship is a huge aspect of the Artemis Red Team. Member BattleAngel said her proudest moment was being selected by the larger ART community as its top mentor.
“I am glad that they are able to reach out to me in case of any doubts or queries and I can help guide them,” she said. “I’ve always advocated a lot about empowering women and helping them grow their skills, through ART I have been able to do that for all the women in our team.”
To be a part of the Artemis Red Team, all you need is to have a strong skill set and go through the vetting process. BattleAngel described the type of support and development you receive as a member of ART:
“Even if you’re fairly new to this field, I would suggest you just keep your focus on learning more. There are multiple incentives that Synack provides to women researchers—be it in providing special access to targets or hosting various CTF challenges particularly for women researchers—so they can join this amazing team.”
The post Artemis Red Team Empowers Women, Trans and Nonbinary People in Cybersecurity appeared first on Synack.
By Kuldeep Pandya
Note: This was originally published on Synack Red Team member’s Kuldeep Pandya’s personal website and is republished here with permission.
In this article I detail my recent discovery on Synack Red Team, a NoSQL injection.
Please note that this will not be a technical guide on why NoSQL injections exist and their breakdown. I will share the thought process and approach that I had when testing this particular application.
When I got onboarded to this program, it had one application in scope. It was an authenticated test and credentials were provided by the client. Synack’s quality period was also going on, and it had approximately 8 hours.
As always, I fired up Burp Suite, opened Burp’s in-built browser, went to the login page, and started intercepting.
I was closely monitoring every request after clicking “Login.”
First, there was a login request to the /oauth2/token endpoint. This endpoint returned the JWT token that allowed us to access the application APIs. However, no fun here.
After the login request, there was another request to a metadata endpoint. This also was not very interesting as the endpoint returned data that was going to be used to render the frontend.
But after the first two requests, a request to the/api/[CLIENT_NAME]/Customers was sent. This request in particular was very interesting as it had a parameter named$filter. And the parameter had a long NoSQL string inside it.
The request looked like this:
GET/api/[CLIENT_NAME]/Customers?$filter=(id%20eq%202)%20and%20((is_active%20eq%20%27Y%27)%20and%20(is_deleted%20eq%20%27N%27))&$orderby=name HTTP/1.1
Host: [TARGET_APPLICATION]
…
[SNIPPED_BECAUSE_IRRELEVANT]
If you look at the value of the$filter parameter, the URL encoded string decodes to the following filter:
(id eq 2) and ((is_active eq ‘Y’) and (is_deleted eq ‘N’))
This endpoint returned basic customer information like customer name, last login date, etc.
You can see the full request-response pair below:
I had read a few blogs on NoSQL injection in the past. Especially after the HackIM CTF. So I figured this was something related to NoSQL.
Theeq in the$filter is the same as SQL’s= orLIKE.
What the endpoint really did was that it read the value of $filter and then it evaluated the filter and retrieved the data specified in the filter.
To break down the parameters in the above filter:
–id (This was the customer ID. Our current user had the customer ID of 2. If I had changed it to 1 instead of 2, this would have been an easy IDOR.)
–is_active (This was an attribute our user had. Theis_active attribute would beY if our user was active andN if not.)
–id_deleted (This was another attribute to specify if our user was deleted or not.)
The/api/[CLIENT_NAME]/Customers endpoint took the filter and returned our own user(user ID 2)’s data if and only if our user was active and not deleted.
For testing, I removed the later part which was((is_active eq ‘Y’) and (is_deleted eq ‘N’)) and just sent the following filter:
$filter=(id eq 2)
The application happily returned my data without erroring out.
As I was aware that this was NoSQL, I googled “NoSQL wildcards” and tried to play around with wildcards. I came across the following documentation by MongoDB on wildcard indices: https://www.mongodb.com/docs/manual/core/index-wildcard/
I played around with wildcards, doing things like$filter=($** eq 2), and some of it worked meanwhile some of it did not.
I also tried to forcefully put wildcards in the value and crafted this payload:$filter=(id eq $**)
But it did not have a valid syntax so it also failed.
I honestly did not put much effort into wildcards as I was not getting the syntax right.
Then a thought popped into my mind. There was one operator in the filter calledeq. What if I use some other operator? Is it possible to do it?
I googled “MongoDB syntax” which led me to this awesome documentation again by MongoDB: https://www.mongodb.com/docs/manual/tutorial/query-documents/
The above documentation neatly explains MongoDB syntax with SQL alternative syntax to properly understand it.
However, after going a little further into the documentation, the documentation linked to another documentation page which was about “Query and Projection Operators.” You can find it here: https://www.mongodb.com/docs/manual/reference/operator/query/
And this page was exactly what I needed to craft my exploit! The page listed down all the MongoDB operators and their use cases.
I decided to go with the gt operator because I wanted the endpoint to return user details of all the users whose user ID was greater than 0. I had made an assumption that user IDs will start from zero.
For that purpose, I crafted the following payload:
$filter=(id gt 0)
And the application returned the customer information of the other user as well. Sadly, there were only two users and this was a pre-production application. However, I was still happy because I got the info of the other user.
But I was still not happy with the results because only basic login information was leaked. Any sort of PII or sensitive information was not leaked from this endpoint.
I went back to my Burp history and found all the endpoints that had this$filterparameter. I had gathered a total of seven endpoints.
While closely inspecting the endpoints, I found one interesting endpoint called/api/[CLIENT_NAME]/CustomerLogins. This was interesting because it took the filter and returned PII in the response.
I used the same payload as above and sent the request. And the application leaked an email address, username, password hash and phone number of the administrator user! Not just any random user.
I reported all the endpoints and wrote a nice report. There were few other reports for the same vulnerability after the QR had ended, but my report managed to win.
You can reach out to me at @kuldeepdotexe on Twitter.
The post Exploits Explained: NoSQL Injection Returns Private Information appeared first on Synack.
Vulnerability testing, whether via an automatic scanning program or human-based penetration testing, can find an overwhelming number of vulnerabilities in your system as recent trends would suggest. Since 2017, record numbers of Common Vulnerabilities and Exposures (CVEs) have been reported, with 2022 on track to set a new high.
Sorting through a record number of vulnerabilities to keep your organization secure is a daunting task without additional support and distillation.
The good news is that of all the vulnerabilities that might show up on a traditional vulnerability report, only around 5% of vulnerabilities discovered are ever exploited in the wild. And most of the exploited vulnerabilities are those with the highest CVSS (Common Vulnerability Scoring System) severity score of 9 or 10.
So how do you know which vulnerabilities in your system need to be addressed right now, and which can be put on the back burner? Some vulnerabilities are an immediate risk to the business, while others are highly unlikely to be exploited. Prioritizing critical vulnerabilities can mean the difference between preventing an attack and responding to one.
Finding and triaging critical vulnerabilities is where Synack’s pentesting outperforms traditional models. We continuously prioritize impactful vulns for your organization, surfacing only vulnerabilities that are reproducible and show exploitability.
The Synack Platform is the only solution to harness the best in augmented intelligence for more effective, continuous pentesting. First, the Synack Red Team (SRT), a group of vetted researchers, conducts open vulnerability discovery, while our automated SmartScan provides broad attack surface coverage. Together, they find vulnerabilities across your attack surface.
Next, the Synack Vulnerability Operations team assesses vulnerabilities found by the SRT and SmartScan by using a rigorous vetting process. Noise, such as duplicate submissions by SRT or non-replicable exploits, low-impact vulns, is kept to a minimum during penetration testing and you’re ultimately served vulnerabilities that present a clear risk.
This additional step to triaging is key to faster remediation and minimizing business risk.
The Vulnerability Operations team is a group of seasoned security professionals with hacking expertise. They are full-time Synack employees with extensive vulnerability knowledge–they’ve seen tens of thousands of them. For the most accurate triaging, high impact vulnerabilities are often reviewed by multiple team members. So, when you get a vulnerability report from Synack, you know that it matters.
The Vulnerability Ops team works alongside the SRT 365 days a year to bring order to the thousands of CVEs. When the team receives an initial vulnerability report, they will first validate the vulnerability by replicating it based on details provided in the report. When the vulnerability is confirmed, the Ops team proofreads and formats the report for utility and readability by a development team. Everything needed to reproduce the vulnerability is provided in each report.
After vulnerabilities are deemed exploitable and impactful, and the report has been detailed with steps to reproduce and suggestions on remediation, it will be published to the Synack Platform.
From there, the Synack Platform provides real-time findings on vulnerabilities found–their CVSS score, steps to remediate and evidence of the researcher’s finding. With this information you can address the vulnerabilities that are most important to your organization in a systematic and thorough manner.
Through the Synack Platform, teams are also able to check if their remediation efforts were successful with Patch Verification. Patch Verification can be requested on-demand, and the researcher will provide further communications on the patch efficacy.
Most organizations don’t have the resources to go chasing every vulnerability reported from initial testing. To further safeguard your organization, someone needs to determine which are true vulnerabilities and which of those are exploitable and at what level of criticality. That process is noise reduction, and it is essential for any cybersecurity operation to shoot for the highest level of noise reduction before proceeding to remediation. Synack, through the Vulnerability Operations, team can take on this task for you.
Using Synack’s unique approach to continuous pentesting, your team will be able to proceed with confidence that their remediation efforts are critical to keeping the organization secure. Get started with Synack penetration testing today.
The post Synack Triaging Prioritizes the Vulnerabilities that Matter appeared first on Synack.
Cybersecurity for web apps has never been more important than it is today. Websites and online applications are under constant attack by people and groups looking to penetrate systems to cause damage or steal vital information. And it’s not just criminals and mischief-makers; government-sponsored attackers are at work as well. Consider these cybersecurity statistics compiled by Patchstack:
Even more, telling is a 2019 report that found that 47% of all hacked websites contained at least one backdoor, allowing hackers access to the website. And the costs associated with data breaches continue to climb. The average cost of a data breach among companies surveyed in a 2021 IBM report reached $4.24 million per incident, the highest in 17 years.
Security personnel has a number of tools at their disposal to thwart cyberattacks. One of the most valuable is pentesting — checking for vulnerabilities that could give a hacker access to the system. But although not as reactive as remediating a breach that has already occurred, traditional pentesting is still somewhat reactive in nature. You’re being proactive in checking for vulnerabilities that could potentially be used by an attacker, but the vulnerabilities already exist. It’s like calling in a plumber to check for leaks in your pipes that could potentially cause water damage. The leaks are expected to already be there and be found, just as the vulnerabilities are in a pentest. So, although a valuable tool, pentesting only takes you part of the way to a truly security-hardened organization.
What you need is a way to check your security posture for conditions that might lead to a future vulnerability and remediate those issues as well. Only then can you consider your site truly security-hardened. It’s like that plumber fixing all the leaks in your pipes, then going back and making a systematic check of your pipes for conditions that could lead to a leak, such as rusting, pipes located in places where they are likely to freeze or improperly connected pipes.
ASVS provides for this by listing security conditions analogous to those that might lead to leaky pipes. This is how ASVS benchmarks enable proactive security.
The Application Security Verification Standard (ASVS) was developed by the Open Web Application Security Project (OWASP) to help organizations examine the state of their cybersecurity. The primary aim of the ASVS Project was to normalize the range in the coverage and level of rigor available in the market when it comes to performing Web application security verification using a commercially-workable open standard. The standard provides a basis for testing application technical security controls and technical security controls in the environment that protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection.
The ASVS benchmark provides a compilation of security controls that are expected to be in place in a well-secured application. It also provides developers with a list of requirements for secure development. The ASVS does not provide a framework to check for vulnerabilities. Rather, it provides a framework to check for controls that prevent, and conditions that could lead to, exploitable vulnerabilities. Synack recommends performing ASVS benchmark testing as part of an ongoing security process for maximum cybersecurity.
OWASP lists the following as objectives achieved by ASVS:
The ASVS framework is best suited for organizations that are relatively mature in their security posture. Since the tests don’t actually check for vulnerabilities, it is most appropriate to run ASVS tests after you have examined your system for existing vulnerabilities and remediated them through continuous and effective penetration testing. Once existing vulnerabilities have been discovered and remediated or resolved, then it is time to check your security controls for best practice implementations. Running the ASVS benchmark can then help the organization create a better defense in depth posture.
There are three levels of ASVS benchmarks available in the Synack Catalog – Basic, Standard, and Advanced. You choose the Synack ASVS Campaign to run based on the level that is appropriate for the organization. Across levels, an ASVS Campaign can ensure that an application follows best practices to protect user data and prevent exploitation by adversaries. An ASVS Campaign does this while respecting the appropriate level of security for an application, one that thoroughly protects the application, while not hampering user experience or business needs.
This process to engage Synack to prevent vulnerabilities before they occur is unique. Testing the ASVS framework lets us look for and proactively address the systemic issues that let the vulnerabilities come to an exploitable state and unlock the door for an attacker.
With an ASVS benchmark test, you will receive a detailed report from a researcher on the Synack Red Team, our community of global ethical hackers, regarding their findings on the security posture of your assets. Their mission is to evaluate your assets relative to the ASVS framework. The goal of this assessment is to determine if your security controls are adequate for the application use case your organization has.
This report can offer guidance on where efforts would be best applied to further harden and future-proof assets. It can also be used to show a year-over-year improvement in the asset hardness, and can help quantify the effectiveness with both the ASVS metrics and a reduction in vulnerability findings. Long-term, the ASVS campaign can help support a multi-year effort to reduce the attack surface and improve the controls in assets against flaws.
Completing an ASVS assessment for your organization is easy with Synack Campaigns. The ASVS campaigns are listed in the Security Benchmark section of the Catalog. Once credits are purchased, you can activate your campaign on-demand any time in the Synack Platform.
Synack researchers complete the missions specified by the ASVS benchmark tests. After completing them, your team can leverage Synack’s Custom Report feature for audit-ready reports that will provide you with a view of security issues discovered by our testing.
When you are comfortable that pentesting and resulting remediation has moved your site to a sufficiently secure security posture, evidenced by pentesting not finding a significant number of new vulnerabilities, then you can move on to running the Synack ASVS Campaign. After completing the ASVS Campaign and remediating any discovered issues, it’s time to set up a plan for periodic testing going forward. Then you can be assured that you have applied the most comprehensive security testing to protect your assets.
To learn more about Synack ASVS Campaigns and how it can expose conditions that could lead to exploitable vulnerabilities, contact Synack at sales@synack.com.
The post Get Ahead of Vulnerabilities With Proactive ASVS Benchmark Pentesting appeared first on Synack.
By Kuldeep Pandya
Hi, guys!
This blog will be about all the different kinds of Path Traversals and Local File Inclusion vulnerabilities that I have found in Synack Red Team.
After hacking on Synack Red Team for approximately 9 months, I came to realize that Path Traversal and LFI like vulnerabilities are very common. I reported a few authenticated vulnerabilities and a few unauthenticated. However, I will try to cover both kinds of vulnerabilities.
Before moving forward, I’d like to list all my Path Traversal/LFI submissions.
| Submission | Status |
|---|---|
| Path Traversal Vulnerability Leads To Source Code Disclosure | Accepted |
| Local File Inclusion in VMWare VCenter running at [REDACTED] | Accepted |
| Spring Boot Path Traversal – CVE-2020-5410 | Accepted |
| Local File Inclusion In download.php | Accepted |
| Local File Inclusion In download.php | Rejected (Duplicated my previous report) |
| Local File Inclusion In download.php | Rejected (Duplicated during Initial Launch Period) |
| Path Traversal Allows To Download Licence Keys | Accepted |
This was the very first Path Traversal vulnerability that I had found in Synack Red Team. Also, even though I was pretty new to the platform and to the whole bug bounty thing in general, this report was selected during the Initial Launch Period, where the best write-up is chosen, not necessarily the first valid report.
After logging into the application, the application provided a bunch of sections like manage vendors, manage inventory, etc with a bunch of functionalities.
Upon further inspecting these sections, I came across an interesting functionality that involved importing the data. The file was named DataImport.view.
I tried getting RCE by uploading an ASPX web shell and it actually worked! Reported it and that report got accepted too! However, that’s a different story. We want to discuss Path Traversals here and not RCEs.
So, after successfully uploading a file, we were given the functionality to read the file.
After clicking the “ReadFile” button, it filled the file name field to the current uploaded filename by default. However, we had the ability to change the file name.
Now, I just had to provide a valid file name. For this, I used the Auth.aspx to which the login request was sent. I could be sure that this exists because a login request was sent to this file and it resided in the webroot.
So, I tried to do path traversal using payloads like ../Auth.aspx and ../../Auth.aspx etc.
And, after three ../ sequences, the file was actually returned!
The response looked like this:
The file was broken because some sort of XML parsing was done on it. I still went ahead and reported it because it was still a path traversal issue and disclosed source code contents.
I could do more creative things here like pulling more sensitive files but I stopped here because very limited time was left in the Initial Launch Period. I initially did not care much for this vulnerability as I had already reported an RCE there but then quickly made a report in under 15 minutes putting together all my PoCs and I still had my report selected as the best write-up during the Initial Launch Period.
This was the classic VMWare VCenter /eam/vib LFI vulnerability.
The /eam/vib endpoint in VMWare VCenter instances takes a parameter named id in the GET request. The value to this id parameter is a file name that will be retrieved by the VCenter instance and will be given back in the response.
There are already many resources regarding this particular vulnerability and I do not think much is to be said about it in this particular article.
I used the following payload to retrieve the hosts file off the remote server:
https://[REDACTED]/eam/vib?id=C:/WINDOWS/System32/drivers/etc/hosts
There were some IP to host mappings in the hosts file which I thought was enough for impact but with creativity, more could have been achieved.
I reported the issue during the Initial Launch Period, and this was selected.
This was a known vulnerability in Spring Boot Cloud Config server. For PoC, I referred to this article here: http://www.jrasp.com/case/CVE-2020-5410.html
That article talks in detail about the vulnerability and also explains the source code.
I did not read that much and simply took the PoC from there and used it on the target that I had for testing. And the exploit worked!
I used the same payload as in the PoC which is:
https://[REDACTED]/..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd%23foo/development
The above payload retrieves the /etc/passwd file.
However, this was Java and one odd thing about Java Path Traversals/LFIs is that if you specify a directory instead of a file for opening, it will actually list the content of that directory.
So, for example, if I did not know what files were in the /etc directory, I would simply use the following payload to list all the files:
https://[REDACTED]/..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252F..%252Fetc%23foo/development
This is just the previous payload with the trailing /passwd removed. Now, we are just listing the contents of the /etc directory.
I used this feature to list the contents of the root directory in the affected Linux server. In the root directory, I found a file named application.jar which was potentially the source code of the currently running Spring Boot Cloud Config server.
Also, the root directory had a file .dockerenv so I was quite sure that I was in a docker container.
However, Synack Red Team has the stop-and-report policy according to which, we are not supposed to do post-exploitation.
I reported the issue during the 8 hour initial launch period. And nobody checked for this particular vulnerability, so mine was the only report during that time.
I have already discussed this vulnerability in my previous article and you can find it here: Local File Inclusion In download.php
This path traversal was also very interesting. This was in a custom-built application and it did not require any authentication.
When we visited the webroot, the web application redirected us to the login page.
The login page was custom built and there was a brand logo along with the login page so I cannot show you the screenshots.
Upon visiting the login page, a request to the /web/product_logo endpoint was sent. The request contained a GET parameter named logo.
Overall, the request URL looked like this:
https://[REDACTED]/web/product_logo?logo=logo.png
The parameter logo took a file name as the input and returned that particular file in the response. In this case, it was logo.png.
Now, as this is functionality to read files, there may be a potential LFI/Path Traversal here. So, I changed the file name to random file names like index.html, index.php, index.js etc. However, none of them worked.
So, I ran ffuf hoping to discover more files but it was a failure. I used the raft-small-files-lowercase.txt provided in the SecLists.
I did not know the underlying technology which is used so it was quite painful to enumerate files.
However, I knew it was a Windows box because of the case-insensitive directory structure. What it basically means is that, in Windows, WinDows and Windows are the same directories/files as it is not case sensitive. And when I was doing my recon, I received the same response when I did /web or /Web so I was quite sure it was a Windows box.
There are other ways to determine this too but I decided to assume it was Windows.
Same as my past submissions, I decided to read the C:/WINDOWS/System32/drivers/etc/hosts file of the remote server.
So, I used a path traversal payload and the final URL looked like this:
https://[REDACTED]/web/product_logo?logo=../WINDOWS/System32/drivers/etc/hosts
However, one ../ sequence did not work. So I kept increasing the ../ sequences.
Finally after 10 ../ sequences, I finally hit the hosts file and the server retrieved it for us.
The final payload looked like this:
https://[REDACTED]/web/product_logo?logo=../../../../../../../../../../WINDOWS/System32/drivers/etc/hosts
Although this was enough for PoC, I decided to dig deeper with this path traversal.
When I was fuzzing the application, I encountered an error that disclosed the full path to the webroot.
I ran ffuf again but now in the webroot of the server using the path traversal that I had found. This way, I was able to enumerate a file named LICENSE that had license keys of the application.
I reported the issue with all my findings and my report was selected during the Initial Launch Period.
Thanks for the read. 
You can reach out to me at @kuldeepdotexe.
The post Path Traversal Paradise appeared first on Synack.
Recently, Microsoft disclosed four zero-day vulnerabilities in Microsoft Exchange Servers. A Research Director from Palo Alto Networks claimed that adversaries were scanning for vulnerabilities within 25 minutes of vulnerabilities being released. Synack customers discovered the critical Apache Log4j vulnerability (CVE-2021-44228) within hours of its disclosure through a Synack CVE check offering. Scanning traffic for the vulnerability piqued just five days after the disclosure and has continued. There has never been a higher need for fast reporting and remediation timelines on high-priority vulnerabilities.
In the 1970s, James P. Anderson invented point-in-time pentests as a public policy and technical innovation to secure communication systems and other networks from malicious hackers. But the threat landscape and the sophistication of digital threats have changed vastly since then, having a significant impact on pentesting. Other major factors include increased attacker sophistication and vulnerabilities, new DevSecOps workflows and collaboration/security software (Splunk, Jira, Slack, SOAR, etc.), and growing adoption of cloud services, infrastructure, and storage. With these macro changes, the traditional way of doing pentesting is too slow, disruptive, and ineffective. The good news is that Synack has heard these customer challenges and developed an on-demand pentest that’s continuous, performance-driven, and intelligent.
Cloud Services & Providers Are Dynamic
Point-in-time pentesting cannot keep pace with agile cloud services, which are often spun up around specific projects. On average, large organizations add 3.5 new publicly accessible cloud services per day. Remote code vulnerabilities or external misconfigurations can occur at any time and leave organizations’ public and private assets vulnerable.
New DevSecOps Workflows & Security Software Stack
The average security team now uses about 45 cybersecurity-related tools on their network. Collaboration tools have replaced email. Typically, most security, ops, and development teams communicate using Splunk, Slack, Jira, or ServiceNow. Code releases are constant. It’s important to have a DevSecOps process that automates a lot of the work across these platforms, or risk spending time on administrative processes that distract from securing your organization.
Increase In Sheer Number of Vulnerabilities & More Sophisticated Adversaries
Security researchers have found an increasing number of vulnerabilities in recent years. In fact, the number of new vulnerabilities increased by 127% from 2017-2018 compared to single digit growth rates in previous years. An average of roughly 17,416 new vulnerabilities are added each year and point in time pentests can’t keep up. Attackers are more efficient than ever with some popular exploitable vulnerabilities pursued within a hours of when a patch is released (i.e. Microsoft Exchange CVE-2021-26855, Apache Log4j CVE-2021-44228)
Typically, in a traditional pentest model an organization seeks out an established consulting firm to do the work. As the complexity of assets has increased, pentesters specialize; they vary in attack types (reverse engineering, password cracking, etc.), and focus on certain asset types (IoT, mobile, web, IaaS). Hiring enough skilled personnel is a top challenge to implementing and maintaining a pentest program. As a result, pentesters with sought-after skill sets may need to be scheduled months in advance. Scheduling a new program, or launching a new test can take weeks or even months, especially if the team needs to work on site.
Too often, security teams do not receive sufficient support to effectively communicate results. Vendors send pentest reports in PDFs or Excel via email. A security team member needs to copy and paste information into ticketing tools like Jira or ServiceNow, or collaboration tools (i.e. Slack). Reports are written in a way that’s not accessible to other key teams like legal, operations, IT or development. If they have questions, security teams can’t easily communicate with researchers that surface the vulnerabilities. Finally, once a vulnerability is closed, it’s not possible to re-test the vulnerability in a standard pentest. Vulnerabilities can fall between the cracks and take months or years to remediate.
One of the most frustrating aspects of penetration testing is the inability to see meaningful progress over time. How can you create a benchmark for your defenses? What security metrics should you consider to take stock of your various assets besides the CVSS score or quantity of vulnerabilities? Traditional pentesting does not provide holistic risk scores at the asset or company level.
In response to these challenges, Synack offers a continuous, intelligent, and performance-driven on-demand pentest to improve your organization’s security posture overtime.
More than 1,500 vetted security researchers from across the globe are actively working with the Synack Red Team, hunting for vulnerabilities around the clock. The SRT is second to none when it comes to skills and trust, thanks to rigorous vetting and assessment of researcher expertise in the application process. Synack Ops can launch new pentests in as little as 3–5 days and start on-demand security tasks such as asset discovery in seconds.
Organizations need to be wary of new vulnerabilities like Log4J or SolarWinds Orion. It’s never been more important to continually test public and private cloud assets. Synack offers configuration reviews of Azure environments, CVE checks, and testing for dynamic internal and external hosts. Synack integrates with numerous cloud providers (AWS, Azure and GCP). Additionally, our API pulls from major cloud providers daily to help detect any changes to external hosts when Synack is testing.
With traditional pentesting, there are not a lot of great metrics for measuring your security status overtime. Number of vulnerabilities found can be a helpful benchmark, but often don’t include other critical stats such as vulnerability remediation timelines. Synack provides a security risk score that takes a holistic approach based on metrics like attacker cost, severity of findings, and remediation efficiency.
Synack offers 43% more coverage of your assets than a traditional pentest with SmartScan, a scanner that you can use on your medium priority assets to surface vulnerabilities. These “suspected vulnerabilities” are triaged by the researchers in order to provide you with actionable results.
Traditional pentests are built for your organization’s compliance objectives, but lack the agility necessary for digital transformation. Synack provides easily readable and compliance-ready reports on a wide range of metrics (i.e. vulnerability severity, vulnerability status, steps to reproduce, recommended fixes, remediation status) for legal, policy and leadership teams as well as real-time metrics on exploitable vulnerabilities that are the top priority for security, ops and development teams. Synack also integrates with Jira, ServiceNow, Splunk, and offers an API to facilitate faster DevSecOps processes.
Attackers are more vigilant than ever. Security teams need to be one step ahead of their adversaries to help make sure they are keeping their organizations’ environments safe. The choice is clear. Synack provides 159% more ROI than a traditional pentest.
Change your pentest provider today and schedule a demo with our team, or download a solutions overview of Synack 365—our continuous pentest offering.
The post How Synack Is Disrupting Pentesting To Find Vulnerabilities Faster appeared first on Synack.
Since Friday, December 10, 2021, researchers from the Synack Red Team (SRT) have been solving customer needs related to CVE-2021-44228—the CVE that details a critical log4j vulnerability with wide-reaching implications across industries.
Responding to the Critical Vulnerability with Synack Testing
By 8 A.M. PST, when its magnitude and implications became clear to Synack operations, a new CVE entry was created in the Synack Platform to address CVE-2021-44228. Log4j immediately became available for customers to launch, long before most of the world read about the vulnerability in headlines and social feeds.
Synack CVE Checks connect an organization to SRT researchers capable of accomplishing specific security tasks. In this case, organizations can select CVE-2021-44228 within the Synack Platform and have a researcher check for the vulnerability on-demand.
Testing with the Best Researchers on the Planet
Over 30 SRT members assembled to cultivate ideas and improve the entire community’s efficiency and effectiveness. Together, they are bringing a diverse spectrum of perspectives from different backgrounds, ranging from military and government to academia and tech. This collaboration of top researchers allows Synack to improve the quality of testing for all customers with better processes, tools, and payloads.
The SRT often shares best practices within the community to help each other level up and make the entire internet safer. Compared to traditional testers or automated scanning tools, the SRT brings these sorts of advantages: human collaboration, diversity and creativity.
The Landscape of CVE-2021-44228 Across Industries
Since Friday morning, Synack has checked over half a million IP addresses across our customer base, confirming the status of thousands of CVE-2021-44228 checks and providing detailed reports containing proof of work and methodologies. With a combination of human intelligence and automated tools, Synack is addressing the vulnerability at an unprecedented scale and pace.
Vulnerable instances span across countries and industries and exist both in the government and private sectors. The urgency of the vulnerability has not been overstated by news outlets and social media – Synack recommends that customers activate the CVE check as soon as possible.
Checking for CVE 2021-44228 On-Demand—The Advantages of Synack Campaigns
Since the weekend that followed the CVE’s publication, Synack customers have utilized the Synack Platform to activate hundreds of checks from researchers around the world.
Synack beats other models to the punch. Scanners do not yet have the vulnerability’s signature, traditional pentesting engagements take significant time to spin up, and other bug bounty models do not provide the immediacy or certainty of a vulnerability as this one requires. The model provides on-demand services relevant to CVEs today and prepares organizations for the next 0day like CVE-2021-44228. Reach out to a Synack representative today to explore existing CVE checks, as well as other offerings available in the Synack Catalog.
The CVE-2021-44228 testing provided by Synack provides immediate results and reporting. The researcher will provide a clear yes/no answer on an asset’s vulnerability status, as well as details about their methodology, screenshots, and general proof of work.
Activate the Synack CVE-2021-44228 Test Today
Reach out to your Synack representative to activate the CVE-2021-44228 test today. If you’re new to the Synack Platform, reach out to us here and learn how to get started with Synack’s on-demand security platform and pentesting.
Update: Synack was asked whether our systems are vulnerable to Log4j. Synack does not use Log4j and has determined that we are not vulnerable to exploitation. In response to increased attack traffic attempting to exploit the vulnerability, we have taken additional steps to block the malicious traffic accordingly.
The post Providing On-Demand Testing for CVE-2021-44228 (Log4j) with Synack Testing appeared first on Synack.
Login