Varun Uppal, founder and CEO of Shinobi Security Over the weekend, airports across Europe were thrown into chaos after a cyber-attack on one of their technology suppliers rippled through airline...
The post When Airports Go Dark: What The Weekend’s Cyber-attacks Tell Us About Business Risk appeared first on Cyber Defense Magazine.
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.
It’s natural to wonder who makes up the Synack Red Team (SRT), our dedicated team of 1,500+ security researchers, and how they ended up finding vulnerabilities in our customers’ IT systems (with permission, of course).
Companies want assurance they’re not opening the front door to just anybody. Much like you wouldn’t want a stranger in your home without a warm introduction from a mutual friend, we’ll explain how SRT researchers become part of an elite, global community of ethical hackers with diverse skill sets.
One of the strengths of the SRT comes from its diverse community; our SRT members are top researchers in their respective fields—academia, government and the private sector. They hail from countries all around the world, including the United States, the United Kingdom, Canada, Australia and New Zealand. Human ingenuity takes many forms, and it’s that richness of difference that makes the SRT able to take on a seemingly endless list of security testing and tasks.
Before joining the team, each prospective SRT member must first complete a 5-step vetting process that is designed to assess skill and trustworthiness. Historically, less than 10% of applicants have been accepted into the SRT, as we strive to add only those trusted individuals who will contribute positive results without excess noise to the platform. While our process loosely resembles bug bounty models, Synack sets the bar higher.
Synack’s community team monitors online behavior from SRT members and removes SRT members immediately when required. Synack maintains a common standard and reward level across the SRT, allowing our clients to benefit from the clear understanding and agreement between SRT members and Synack for what constitutes a thorough report deserving of a high reward. They have collectively earned millions of dollars and have found thousands of vulnerabilities for Synack clients, including the U.S. Army and Air Force, the Centers for Disease Control and Protection and the Internal Revenue Service.
The Synack Platform ultimately powers our researchers. Synack works closely with clients to accurately scope testing and instruct them on how to use the Platform effectively.
The Platform is also where SRT researchers submit findings to be triaged by our Vulnerability Operations team. VulnOps ensures that quality results are delivered to the client in a variety of formats (e.g. easily digestible reports, integration of data into existing security software). Clients are also able to communicate directly with researchers for questions or follow up.
All SRT traffic goes through Synack’s VPN LaunchPoint to provide control and assurance around pentesting traffic. LaunchPoint focuses penetration testing traffic through one source, pauses or stops testing at the push of a button, provides complete visibility into the researcher’s testing activity with full packet capture, time-stamps traffic for auditing purposes and allows for data cleansing and deletion of sensitive customer data by Synack after it is no longer needed for testing.
Setting the bar higher allows Synack to work with clients who need additional assurance. Recently, we completed the requirements to achieve our FedRAMP Moderate “In Progress” level, which allows us to work with almost any U.S. federal agency. In past years, we’ve participated in Hack the Pentagon and several public hacking competitions for U.S. defense agencies, such as a 2019 effort in Las Vegas to find critical weaknesses in the F-15 fighter jet.
Malicious actors don’t need any clearance to hack into systems. Synack takes the task of combatting those bad actors seriously and our teams–from the Red Team to VulnOps–have worked to ensure that our clients receive vulnerability reports with actionable, secure information. We continue to innovate in the security testing and pentesting-as-a-service industry, ensuring privacy and security for all our clients while providing clear visibility into all testing through our trusted technology.
Interested in our work with the public sector? Click here.
The post Building Trust with a Vetted Team of Security Researchers 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.
A paradox of cybersecurity’s function in business is that businesses provide value by creatively sharing and using information, but cybersecurity benefits from less sharing and access to data.
This holds doubly true in the area of third-party security for large organizations that must adhere to stricter regulations, such as banks and government agencies. It is nearly impossible to conduct business without frequently and openly sharing valuable information with, or via, third parties.
Drug developers rely on clinical research partners for essential data. Banks exchange information with credit agencies, other banks, regulators and more. All of this drives software development and infrastructure changes constantly, and some percentage of those changes introduce security vulnerabilities that are detected late in the process, which poses risk for the organizations.
Many feel that they get more security “bang-for-the-buck” through third-party testing—testing the software of others. A 2022 study by the Ponemon Institute found that while 75% of respondents are concerned about the risk of ransomware linked to third parties, only 36% of organizations evaluate their own security and privacy practices. An earlier 2019 Ponemon study found that if it were a third party that caused a data breach, the cost increased by more than $370,000 (raising it to $4.3 million). Shoring up third-party defenses clearly has benefits for multiple parties (and your customers).
Synack has seen customers try different approaches for testing third parties. Tests are either 1) encouraged, 2) required or 3) coordinated.
In the first model, third parties are strongly encouraged to get a security test from Synack and share the results with their partner, usually the larger of the two companies. It’s not forced; ultimately, it’s up to the third party to decide if their relationship benefits from a security test.
In the second model, security testing is a requirement for a relationship to be contractually completed. Finally, the Coordinated Testing model is the one Synack sees growing the fastest. In this model, the larger company with several third parties to test purchases tests on behalf of other companies and mandates testing. Usually, they specify the testing intensity as well, by choosing a basic Synack test or a more comprehensive offering. This secures testing resources and makes it easier to share data via a testing platform built for it.
Whichever model you prefer, there are several things to consider. First, what is the chargeback model, if any, for security tests? Does the third party pay, the first party or someone else? Does the payment happen up front or in a later, internal accounting? The latter helps execute testing faster, which is ultimately what many companies want to reduce risk earlier.
Next, what legal agreements need to be in place? All Synack customers have clear contracts with Synack that cover testing. In some cases, an identical contract is needed with a third party, but more frequently, it’s a simpler agreement. Consult with your legal team to find the simplest but most effective way to expand testing on your assets, regardless of where they reside.
Finally, there is information sharing. Do vulnerabilities found on a third party get reported to the primary party? In most cases, the primary party simply wants to know that vulnerabilities are not present, which can be done with patch verification reports. Synack’s robust role-based access control system and reporting allow for any choice along this spectrum to be securely shared according to the wishes of the companies. Information can be shared via a final report, access to the Synack Portal (with real-time information about testing efforts and results) or both.
Whatever you choose, third-party security testing to clean up potential vulnerabilities advances the ultimate goal for many companies: safer users and data.
The post 3 Approaches to Security Testing for Third Parties appeared first on Synack.
By Kim Crawley
The annual Verizon Data Breach Investigations Report is a wealth of valuable information about the state of cybersecurity today.
Of course, data breaches remain one of the biggest problems in cybersecurity. Many of the worst breaches expose financial data, authentication credentials, and sensitive legal and medical information. In the wrong hands, this data can help cybercriminals access organizations’ and individuals’ most sensitive data and valuable networks.
Ransomware that targets enterprises is also growing. In fact, ransomware incidents are up 13 percent from the previous year, a larger increase than the previous five years combined. Another data breach vulnerability trend is an increase in human exploitation, whether by phishing, stolen credentials or user errors.
The DBIR is a massive report that resulted from Verizon analyzing a large number of data breaches, which they’ve also verified directly for authenticity. Here’s how Verizon determines which breaches to include:
“The incident must have at least seven enumerations (e.g., threat actor variety, threat action category, variety of integrity loss, et al.) across 34 fields or be a DDoS attack. Exceptions are given to confirmed data breaches with less than seven enumerations. The incident must have at least one known VERIS threat action category (hacking, malware, etc.).”
Verizon acknowledges that many data breaches still go undetected. Nonetheless, as organizations improve their systems for detecting indications of compromise (IOCs), there’s a lot of useful data to be analyzed.
Here are five key findings:
Whenever organizations are testing to see how vulnerable they are to a data breach, it’s important to simulate internal, external and supply chain attacks. Web application pentesting is also more important than ever. As DBIR makes clear, it’s critical that every organization test for unauthorized credential exploitation and phishing attacks, too.
Thank you Verizon for helping our industry better understand data breach threats! For more information about how Synack can help organizations prevent data breaches, get in touch here.
The post Five Big Takeaways from Verizon’s 2022 Data Breach Investigations Report appeared first on Synack.
REDWOOD CITY, Calif., May 4, 2022 – Synack, the premier on-demand security platform for continuous penetration testing and vulnerability management, has partnered with Democracy Live, the largest provider of cloud and tablet-based balloting in the U.S., to conduct rigorous and continuous cybersecurity testing for its remote election technology.
This important relationship means that states and localities that deploy Democracy Live to expand access to all voters are relying on technology that has been independently and continuously examined for potential vulnerabilities by some of the most skilled cybersecurity researchers in the world.
The Synack Platform combines the skills of more than 1,500 elite cybersecurity researchers along with cutting-edge smart technology to help Fortune 500 businesses, government agencies as well as leading healthcare organizations protect their most critical assets.
The partnership with Democracy Live extends Synack’s work on election security that has also involved projects for Election Systems & Software, the largest maker of voting equipment in the U.S., as well as the State of Colorado and Tusk Philanthropies a nonprofit organization funding the development of new election technologies.
“We’re committed to making sure any technology that states or localities use for voting is as secure as possible. Our democracy depends on it. We need to make sure these systems are protected against attacks, and it’s imperative that we do everything we can to ensure the trust in the systems people use to cast their votes,” said Jay Kaplan, Synack’s CEO. “We also believe in Democracy Live’s mission of expanding the vote to as many people as possible. Democracy works best when as many people as possible participate.”
Deployed in over 2,000 elections, the Democracy Live “OmniBallot” platform is the most deployed, remote balloting solution in the U.S. OmniBallot is hosted in AWS, a federally approved cloud infrastructure. OmniBallot securely transmits ballots to voters who cannot vote on paper ballots, due to geography or disabilities.
“Our partnership with Synack is a powerful new paradigm in elections security. Through engaging Synack and their independent cybersecurity researchers who work 24/7, Democracy Live is taking every step possible to safeguard our elections technology,” said Bryan Finney, CEO of Democracy Live. “Our mission is to help ensure that all American citizens have equal access to a secure ballot. This includes voters who cannot see, hold, or mark a paper ballot, due to disabilities or geography. Through Synack, Democracy Live is adding an unparalleled level of security and testing, unmatched in the elections industry.”
More than 8,000 elections jurisdictions across all 50 states are required by law to transmit ballots electronically. More than half the states require that qualified, eligible voters can return their ballots electronically. Surprisingly, the majority of election jurisdictions still use fax machines, or email attachments to comply with the law.
The Synack/Democracy Live partnership was developed to ensure state and local elections officials have the latest and most secure option to replace fax machines and email to electronically transmit ballots.
Learn more about the partnership at www.synack.com/elections.
The post Synack partners with Democracy Live to deliver more secure, remote balloting solutions appeared first on Synack.
By Kim Crawley
The latest research from zero-day hunters at Google shows that reporting and detection tools are improving.
Google researchers uncovered more than double the number in-the-wild zero-days last year than any other period since it started tracking these dangerous software vulnerabilities in 2014.
“Is it that software security is getting worse? Or is it that attackers are using 0-day exploits more? Or has our ability to detect and disclose 0-days increased? When looking at the significant uptick from 2020 to 2021, we think it’s mostly explained by the latter,” according to Maddie Stone, a security researcher at Google Project Zero, the company’s team that tracks zero-days.
In a recent blog post detailing the 2021 findings, the group detailed the 58 zero-days that it detected as well as trends, attack patterns and techniques they were able to identify last year, too. Even though the group uncovered more than double the number of the previous high in 2015 (28 found), attacker techniques haven’t significantly evolved.
“With this record number of in-the-wild 0-days to analyze, we saw that attacker methodology hasn’t actually had to change much from previous years. Attackers are having success using the same bug patterns and exploitation techniques and going after the same attack surfaces,” wrote Stone.
It’s tough enough for organizations to manage and mitigate known vulnerabilities, but zero-day exploits pose a unique challenge to all organizations. They are often the attackers’ most powerful tool and when executed against businesses, organizations and individuals can have devastating consequences. As Google noted, there were many reports of zero-day exploits used against journalists, human rights groups and government officials last year.
Essentially, Google wants to make it harder for attackers to carry out zero-days. And there’s some evidence in its research that might be happening. While there’s progress in terms of discovering and disclosing zero-days, Project Zero does say there is still a lot of room for improvement. Specifically, they call on companies to disclose more, share more exploit samples and details of attacker techniques and to work harder to reduce memory corruption vulnerabilities.
It’s also important that once organizations know about a zero-day, they act quickly to find and fix that vulnerability. That requires vigilance and the right approach to testing with an offensive mindset to ensure an organization’s entire attack surface is hardened against the most sophisticated attackers.
Get in touch today to learn how Synack can help.
The post Researchers Uncover Record Number of Zero-Days. That’s Actually Good News. 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.
By Kim Crawley
The impact of some software vulnerabilities is so far-reaching and affects so many applications that the potential damage is near impossible to measure. The series of vulnerabilities known as Spring4Shell is a perfect example.
The vulnerability is found in the Spring Framework, which is used in too many Java-based applications to name. Its framework contains modules that include data access and authentication features, so there’s a potential disaster if an attacker can exploit it.
Vx-underground shared news of the discovery of Spring4Shell and linked to a proof-of-concept exploit via Twitter on March 30. The vulnerability facilitates remote code execution and impacts Spring Core in JDK (Java Development Kit) 9 through 18. Frustratingly, Spring4Shell pertains to a bypass for another remote code execution vulnerability that researchers discovered in 2010. That alone emphasizes how critical Spring4Shell is, and how difficult it is to patch or otherwise mitigate.
Because Spring Framework’s modules have so many functions and because of how Spring Framework is used in so many different types of networking applications, there are many ways to exploit Spring4Shell.
One worrisome example is how Spring4Shell has been used to execute Mirai malware and acquire remote root access maliciously.
First surfacing in 2016, Mirai botnet malware has been used by attackers to execute crippling assaults and now it’s coming back with a vengeance. It works by infecting routers and servers and giving attackers the ability to control massive botnet networks. One of the most damaging Mirai attacks hit the Dyn DNS network hard and took out much of the internet in October 2016.
Now, Spring4Shell is aiding the return of Mirai. Spring4Shell’s bugs have been used to write a JSP web shell into web servers with a carefully coded request. Then remote attackers use the shell to execute commands with root access. Mirai is downloaded to a web server’s “/tmp” folder before execution.
Spring4Shell is similar in many ways to Log4Shell, which was initially discovered in November 2021. Log4J is Apache’s Java logging utility that’s been implemented in a plethora of network logging applications from 2001 to today. It’s a little bit of useful software code that’s run in a wide variety of internet servers and services. Exploiting the Log4Shell vulnerability can give attackers administrative access to all kinds of internet targets. Ars Technica’s Dan Goodin called it “arguably the most severe vulnerability ever,” and Apache started deploying patches on Dec. 6. It has not been an easy job because there are multiple CVEs and they aren’t simple to fix.
Spring4Shell and Log4Shell both pertain to Java’s vast libraries and resources. Java is one of the most commonly used application development technologies on internet servers and on a variety of types of endpoints, especially Android devices. The downside to a technology being so popular and useful is that it’ll also be a prime target for attackers. Inevitably, there will be many more devastating Java library vulnerabilities discovered in the years to come.
Businesses should quickly work to patch Spring4Shell and Log4Shell vulnerabilities across their entire networks.
Rigorous, continuous pentesting can help organizations spot these vulnerabilities quickly. The more traditional approach to pentesting just isn’t robust enough to help organizations find and fix the latest complex vulnerabilities.
Reach out today to discover how Synack can help.
The post What’s the Spring4Shell Vulnerability and Why it Matters appeared first on Synack.
Kim Crawley
NVIDIA. Samsung. Microsoft. Okta. Globant. At least one of these Lapsus$ targets could be in your company’s tech supply chain. Regardless, these high-profile attacks highlight how interconnected and dependent IT systems become as companies grow and innovate, and the need to secure your supply chain.
Lapsus$, a global cybercrime group, has a tendency to go deep into a major tech vendor’s networks, find sensitive data and leak it. The breached data so far has included authentication credentials and encryption keys.
In the case of Lapsus$, they used a smaller vendor as a means of compromising a bigger target, like Okta, which then created a domino effect of having access to hundreds or thousands more credentials of those companies that contract with the bigger company. We saw a similar strategy with SolarWinds, wherein SolarWinds was breached and a vulnerability was pushed to its customers within a software update, leading to additional breaches. The risk of a breach is on both entry and exit: which vendors might lead to a breach within your network and which of your customers might then be breached?
The City of London police arrested several individuals who are alleged to be members of Lapsus$. But Lapsus$ struck Globant after the arrests, which indicates there may be many members who are continuing to execute cyber attacks.
Lapsus$ isn’t the first cybercrime group to wreak havoc upon vendor supply chains, and they definitely won’t be the last. Unfortunately, security researchers know that the proliferation of critical vulnerabilities is growing rapidly, and so too are the number of cyber attackers exploiting them. According to the CVE database, 18,325 vulnerabilities were added in 2020, and 20,149 in 2021. More than 6,000 vulnerabilities have been added in the first quarter of 2022. If this year continues at that rate, we’ll end 2022 with over 24,000 new vulnerabilities.
Traditional, point-in-time pentesting can’t keep up with the pace. When you add the complexity of cloud networks and diverse supply chains to the mix, it’s inevitable to lose visibility into your network’s security.
Cloud networks have been a boon for business, allowing companies to scale IT systems quickly and efficiently. But this also means that companies can add publicly accessible cloud services at will, with little oversight from the security team. Then factor in all of your vendors that provide services and infrastructure beyond security. Their vulnerabilities are also your company’s vulnerabilities. When cybercrime groups like Lapsus$ attack them, they’re also attacking your business up the chain.
You need a solution that will empower your security team to quickly find vulnerabilities wherever they emerge in your supply chain and remediate them with ease.
Synack combines an automated scanner, SmartScan, with the human intelligence of more than 1,500 carefully vetted security researchers from the Synack Red Team to find critical vulnerabilities across your network and tech supply chain. That combination of automation and human intelligence is at the core of the Synack Platform’s ability to bring you a better way to pentest. Within the Synack Platform, you can also request on-demand checks for specific vulns, like the OWASP top 10, or new critical CVEs when they appear, such as log4j.
It’s the most efficient and thorough way to conduct on-demand pentests in today’s complex computer. A few point-in-time pentests per year conducted by just a few people, simply to meet compliance, doesn’t cut it anymore. With densely networked supply chains and rapidly multiplying cloud services, new vulnerabilities are implemented faster than ever before. Whether Lapsus$ strikes one of your vendors, or one of many cybercrime groups that will inevitably emerge, your organization will be ready to defend against the evolving cyber threat landscape.
The post The Lapsus$ Threat Reinforces Critical Need to Secure Your Supply Chain 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 Bruce Kang, Associate Security Operations Engineer
In cybersecurity, the OWASP Top 10 is an invaluable resource for ensuring that web applications are secure. The list changes annually depending on what vulnerabilities become more prevalent. For me, one of the most interesting things about this year’s version is that Broken Access Control vulnerabilities jumped from No. 5 in 2020 to No.1.
Now that it’s the most common weakness on the web, it’s more important than ever to understand how this type of vulnerability works—and how to prevent it. Let’s take a closer look.
What is Broken Access Control?
At its core, Broken Access Control is simply a scenario in which attackers can access, modify, delete or perform actions outside an application or systems’ intended permissions. Many vulnerabilities can be classified as a form of Broken Access Control, such as when normal users are able to access admin-only features by changing parameters in a URL, viewing or modifying another user’s data or privilege escalation.
A Simple Example of Broken Access Control
Let’s say a user can access their account settings for an arbitrary website via this URL:
In this example, the “id” parameter in the URL identifies which user’s settings are able to be changed. Each user has a unique ID number associated with their account.
So, what would happen if this user changed the URL to this?
This simple change could potentially give the user access to settings for a completely different user. In fact, in many web applications that use IDs to identify users, the admin user’s ID will likely be equal to 1. This means the attacker could potentially leverage this Broken Access Control vulnerability to gain full administrative access to the web application.
This vulnerability is called an IDOR (Insecure Direct Object Reference), a subset of Broken Access Control vulnerabilities. This usually occurs when different parts of a web application can be accessed through changing user inputs, such as a parameter inside a URL, as shown in the example above.
Broken Access Control: An Example Found in the Wild
There have been several instances in which Broken Access Control vulnerabilities have led to real-world consequences. In August 2015, for instance, the security researcher Laxman Muthiyah found a Facebook vulnerability that allowed them to become an administrator of any Facebook page. This was done by making a POST request to a vulnerable API endpoint of Facebook.
The request can be found below:
POST /<page_id>/userpermissions HTTP/1.1
Host : graph.facebook.com
Content-Length: 245
role=MANAGER&user=<target_user_id>&business=<associated_business_id>&access_token=<application_access_token>
In this case, anyone can use the graph.facebook.com/<page_id>/userpermissions API endpoint to edit their own permissions for a page. A user who is not already an admin should not have access to this ability to elevate other users’ privileges. However, it appears that this endpoint was not properly configured to prevent this from occurring. It’s an excellent example of Broken Access Control in the wild.
For more information, check out Laxman Muthiyah’s report here.
Broken Access Control: Accessing Restricted Content
Another example of Broken Access Control is one submitted by one of our own Synack Red Team members (sensitive info changed for client and researcher privacy). The researcher accessed premium content on the client’s website that should only have been accessible for paying subscribers. It was possible because even though the base URL of the website was accessible only to paying users, the endpoints were accessible to anyone.
The base URL of this application was:
https://client-website/directory-1/
This was essentially the homepage for a service where users could access different resources under the directory named “directory-1.” If the user did not pay for access, then the content was not viewable.
However, by browsing directly to one particular service of the page, the researcher could access all the content in the sub-directory:
https://client-website/directory-1/service-1/
This technique is referred to as “forced browsing.” This happens when an unauthenticated user browses to a URL that should be accessible only to authenticated users. Attackers can find these endpoints usually through the usage of a directory brute forcing tool that will find the web application directories by using a wordlist to automatically navigate to endpoints and see if they lead to valid responses. If the response is not a 404, then the endpoint likely exists. There is also an OSINT method called “Google Dorking,” where attackers use special Google search queries to find “hidden” endpoints. Normally, the user should be redirected or denied access when attempting to access a directory they do not have access to, but this was not the case in this example.
This is a clear example of Broken Access Control, as a non-paying user should not be able to view content that only those who have paid should have access to.
Broken Access Control: Compromising an Entire Network
Another one of our SRT members found a very interesting and high-impact Broken Access Control vulnerability resulting in the possible compromise of several machines in the client’s network (sensitive info changed for client and researcher privacy). This was done by finding an administrator’s authentication token for an API used for patch management.
The researcher found that the endpoint https://client-website.com/api/userData contained the authentication token of several users, including the main administrator. This in turn gave the researcher the ability to use the API’s more restricted functionality. This included being able to enumerate the users and machines on the client’s network, viewing patch data, and even the ability to execute malicious patches or scripts on these machines. In theory, this exploit could have very well been leveraged to take over the entire internal network that the API had access to.
Enumerating users in Active Directory with the authToken:
In this scenario, this type of user data should not be accessible publicly, especially for an API that has the capability to cause such a massive impact on an entire network. This is the reason why it is best practice to deny by default all resources that are not public.
Broken Access Control: Vertical Privilege Escalation
Broken Access Control vulnerabilities can also result in vertical privilege escalation, as found by another one of our SRT members. In this particular example, a settings page of a lower privileged user was exploited to gain administrative privileges on a web application. This was done by modifying the PUT request that was being sent to an API, which was meant to be used to save any changes the user made to their profile.
The PUT request from the settings page looked similar to this:
PUT /api/v1/management/users/user1 HTTP/1.1
Host: client-website.com
{
“id”:”user1″,
“username”:”Synack”,
“userRole”:”user”,
“firstName”:”Synack”,
“lastName”:”Researcher”
}
As you can see, the PUT request contains various information about the user, including the level of access that they have. When the request goes through, this information is saved for that user in the API. Some of these parameters, such as the “userRole” value, are not able to be edited via the application’s user interface. However, the request can be intercepted using a proxy, which then can be modified to have all of these values changed. The most important value that can be changed is the “userRole” parameter.
Thus, the researcher was then able to send this request to the API instead:
PUT /api/v1/management/users/user1 HTTP/1.1
Host: client-website.com
{
“id”:”user1″,
“username”:”Synack”,
“userRole”:”admin”,
“firstName”:”Synack”,
“lastName”:”Researcher”
}
This small change from “user” to “admin” elevated their role to be an admin user on the application. In turn, this allowed the researcher to be able to view and modify data that they had previously no access to. A normal user should not be able to modify the “userRole” field on the API endpoint, and instead should be met with an error when attempting to do so. This field was only protected on the application’s user interface, but not on the actual API endpoint that stores this information.
Final Thoughts On Testing For Broken Access Control
Broken Access Control vulnerabilities can lead to serious consequences and organizations definitely do not want malicious users having more access to applications than intended.
Luckily, there are many different ways to mitigate the chances of having a Broken Access Control vulnerability in web applications. OWASP has a list of these defenses here. However, it is important to understand how these vulnerabilities work in order to recognize and prevent them from existing in the first place.
Broken Access Control vulnerabilities can be found through crowdsourced penetration testing from Synack. With the elite skills of the SRT and the convenience of the Synack Platform, organizations are able to efficiently perform vulnerability discovery with a truly adversarial perspective.
Synack Campaigns provide an on-demand way to augment internal teams and address specific security tasks with the help of Synack’s elite researchers. Through Synack Campaigns that are based on OWASP testing guidelines, organizations are able to target Broken Access Control—among many other top OWASP vulnerabilities—and receive actionable reports that reveal these and other weaknesses.
Reach out today to get started.
The post Preventing Broken Access Control: The No.1 Vulnerability in the OWASP Top 10 2021 appeared first on Synack.
By Malcolm Stagg
The Microsoft Windows RCE Vulnerability, or CVE-2021-34535, is a Remote Code Execution (RCE) vulnerability in Remote Desktop Client, found by SRT member Malcolm Stagg earlier this year, and patched by Microsoft in August 2021.
I found this vulnerability by looking at the disassembly of several Windows dll’s in IDA debugger for potential memory access flaws. Protocol parsing code, especially code involving multimedia decoding, tends to be a common place for flaws since the protocol decoding is often complex. When raw pointers to memory buffers are used directly, it is easy to make a mistake that can lead to a serious memory access vulnerability.
Looking at occurrences of memcpy, the C function that copies data between two memory buffers, I found one occurrence in the TSMF media decoder that showed signs of having a complex access pattern. TSMF is a legacy plug-in for Remote Desktop, in which the Remote Desktop Server transfers a multimedia file to be played by the Remote Desktop Client.
First, the decoder allocates a heap buffer with the size cbData+63 bytes, where cbData is a field from a packet that attackers can control. Next, cbData+36 bytes of data are copied from the packet into the buffer. The remaining 27 bytes are intended to be filled with data from a separate buffer.
This access pattern looks innocent enough until you look at cases involving an integer overflow. cbData is a 32-bit unsigned integer, so it can represent any number between 0 and approximately 4 billion. By specifying a buffer size just slightly below that upper limit, an integer overflow will occur, causing a very small buffer to be allocated, and a huge amount of attacker-controlled data copied into that buffer. The result is a heap buffer overflow, where structures throughout the program’s memory space are overwritten with attacker-controlled data.
There are two main scenarios for how an attacker could exploit this vulnerability. One of these is by gaining control of a Remote Desktop Server. An attacker could take control of a victim’s machine when it connects to the malicious Remote Desktop Server, exploiting this vulnerability to run code that escapes from the Remote Desktop Client onto the victim’s machine.
The other scenario, which is perhaps even more interesting, is a Hyper-V Client escape. Unless “Enhanced Session Mode” is explicitly disabled by the user, Hyper-V uses Remote Desktop Client dll’s while accessing a virtual machine. By doing so, features like clipboard sharing and printing are enabled, improving the user experience. If a virtual machine is running malicious software, an attacker could exploit this vulnerability to escape from the Hyper-V Client and gain control over the host machine. Since users often run untrusted software inside a virtual machine to provide better security and isolation, this is an interesting case that could have a serious impact.
The vulnerability was fairly difficult to exploit for two reasons: one is that it will always result in a client crash. Approximately 4 GiB of data is copied into an extremely small buffer, so a memory access violation is inevitable. The attacker’s payload must be successfully executed before the client crash occurs.
The other difficulty in exploitation is due to Address Space Layout Randomization (ASLR), a security feature designed to make memory access vulnerabilities more difficult to exploit by providing randomization of memory addresses. Since this vulnerability in itself provides no way of bypassing ASLR, for the purposes of demonstration, it is assumed that the attacker has some other way of bypassing it. A common method would be finding an information disclosure vulnerability where a program’s internal memory pointers are exposed to the attacker.
Ultimately, a proof of concept was developed by finding a target function where Hyper-V Client jumps to a memory address stored within the attack payload. To obtain remote code execution, a couple of “gadget” functions were also found. Gadgets are existing functions within the program which have been repurposed by the attacker to perform a task.
The first gadget causes a memory pointer to jump from its initial, random, location within the attack payload to a specific location known to the attacker. This known location specifies a second gadget function and a program name. The second gadget function causes the program name to be read from the attack payload and executed.
The proof of concept is demonstrated in the following video, showing how executing a program within a virtual machine can result in a Calculator executing on the host machine.
This specific vulnerability could have been prevented by the developers performing several additional validation checks:
Memory access vulnerabilities are most common when using raw pointers directly, so those should be avoided whenever it’s feasible to do so.
If you’re accessing an untrusted virtual machine in Hyper-V or running an untrusted program on your virtual machine, disable “Enhanced Session Mode” whenever you can to reduce your attack surface.
Always be cautious when accessing a Remote Desktop Server you don’t explicitly trust. It is best to only access machines with which you are familiar.
Finally, by keeping your computer up-to-date and installing the latest Windows Update patches, your computer will be protected from many new vulnerabilities, including this one!
The post This Microsoft Windows RCE Vulnerability Gives an Attacker Complete Control appeared first on Synack.
Login