Category Archives: Application Security

What Do You Get for Waking Up in Vegas at Think 2018? Application Security Testing Knowledge!

In her classic music video for the song “Waking Up in Vegas,” Katy Perry and her boyfriend insert a quarter into a slot machine at the laundromat and wake up to an ephemeral high-roller lifestyle with all of its elegant trappings. At Think 2018, IBM Security can offer you a much safer bet: that you’ll wake up each day brimming with newly minted application security testing knowledge by attending our DevOps track at the event.

To help you plan your schedule, here’s a convenient recap of key application security testing content at Think.

IBM AppSec User Group

Join us on Sunday, March 18, for our special Community Day at Think 2018. You won’t want to miss the AppSec User Group, where you’ll hear about the latest developments in application security testing from IBM’s experts and have an opportunity to share your feedback about our plans for the future.

Client Sessions

Our compelling application security client sessions will take place on Tuesday, March 20, and Wednesday, March 21. You can check out these sessions in our convenient agenda builder tool. To review detailed content summaries for all of our planned application security client sessions, all you need to do is enter the session numbers below into the agenda builder:

  • Session No. 5039: “Digital Banking With IBM Cloud: RBC’s Wealth Management Technology and Solutions Journey”
  • Session No. 3237: “Citigroup Shifts Security to the Left With Static Analysis and IBM AppScan”
  • Session No. 8094: “Security at the Speed of Software Development: Comcast’s DevOps Transformation”

In all these sessions, you’ll hear how actual security practitioners manage application security vulnerabilities on a daily basis.

Core Curriculum and Think Tank Sessions

On Wednesday, March 21, IBM application security experts Eitan Worcel and Anatoly Bodner will present Core Curriculum Session No. 8199: “Shift Your Application and Data Protection to the Left With a Comprehensive DevOps Strategy.”

The core curriculum session will be followed by four brief Think Tank sessions — each of which will be repeated twice for your convenience — that permit you to dig deep on the following topics.

  • Session No. 8196: “Leverage DevOps and Agile Development to Transform Your Organization’s Application Security Testing”
  • Session No. 8197: “Super-Power Your Application Security Testing With IBM’s Cognitive Capabilities”
  • Session No. 7361: “X-Force Red: Still Better Than Mr. Robot
  • Session No. 8194: “Maximize Effectiveness of Your Software Development Lifecycle (SDLC) With an Empowered DevOps Strategy”

IBM Application Security on Cloud Demo

Finally, don’t forget to check out our Application Security on Cloud solution demo at the IBM Security booth in the event expo center. You’ll learn about the latest developments in cognitive application security testing capabilities, such as intelligent finding analytics and intelligent code analytics, as described in our recent video.

Register Now!

As you can see, you’ll wake up each day at Think 2018 with expanded knowledge about application security that you can take home and share with your peers, whether you’re based in Peoria, Illinois, or Lima, Peru.

Click here to register now. While visiting the registration page, review our awesome musical entertainment options for the week, which include The Chainsmokers, Train and Barenaked Ladies.

See you in Vegas!

Register Now for Think 2018

The post What Do You Get for Waking Up in Vegas at Think 2018? Application Security Testing Knowledge! appeared first on Security Intelligence.

If You Care About Data Security, Don’t Leave It in Your Employees’ Hands

By Geraldine Osman, Vice President of  Marketing at StaffConnect, Employees are only human. They like to communicate with each other in convenient ways that fulfill their needs for connection and information—not

The post If You Care About Data Security, Don’t Leave It in Your Employees’ Hands appeared first on The Cyber Security Place.

Three Characteristics of a Successful Agile Security and Risk Management Implementation

The cost of cybercrime damage is skyrocketing. In fact, Cybersecurity Ventures’ “2017 Cybercrime Report” estimated that the total cost will reach $6 trillion annually by 2021. In addition, Verizon’s “2017 Data Breach Investigations Report” noted that 81 percent of breaches recorded in 2017 exploited weak or stolen credentials, and 14 percent involved privilege misuse.

For these reasons, as organizations embrace cloud, automation and orchestration to support digital transformation, security is coming into sharper focus as a priority during app development. In fact, according to F5 Networks, security services account for four of the top five application services currently deployed.

The question now is, how can we create development platforms capable of addressing more frequent, complex, pervasive, disruptive and potentially disastrous security challenges? More specifically, as regulatory requirements mount and C-level leaders are increasingly held personally liable for data breaches, how can we empower organizations to successfully deploy cutting-edge technologies such as artificial intelligence (AI), quantum computing, the Internet of Things (IoT) and blockchain microsegmentation?

Fight Fire With Fire

Although many organizations are making good progress toward improving their security posture, business leaders need to change their approach and embrace new ways of implementing security natively as increasingly complex threats emerge and multiply in 2018.

This requires security teams to move beyond doing the bare minimum to meet compliance and implement proactive measures to protect enterprise data from today’s sophisticated fraudsters. A Bitglass report revealed that 87 percent of organizations had experienced at least one cyberattack during the previous year, suggesting that manual, compliance-centric approaches to data protection are no longer sufficient to address the latest cybercriminal developments, such as the use of weaponized AI in automated spear phishing attacks.

Large enterprises today already face billions of cyberthreats daily — so how can they possibly prepare for the trillions more that will surely result from the increasing use of cognitive technology in cybercriminal campaigns? Agile security and risk management (ASRM) is the only way to address these emerging challenges and empower business leaders throughout the organization to make better, more informed decisions about cyber risks.

By leveraging the power of AI and quantum computing, organizations can fight fire with fire to thwart even the savviest of threat actors. The ASRM approach enables security leaders to reduce their threat and vulnerability exposure via microsegmentation and minimize the cost of cybercrime damage through preventative measures, advanced assessments and contextualization.

What Is Agile Security and Risk Management?

In general, security management involves identifying the company’s assets and implementing policies to protect them. By extension, Agile security management is a continuous, pervasive and proactive method of protecting assets at a microsegmented level. This process involves all team members during all phases of the development life cycle.

ISO 31000 defines risk management as “the effect of uncertainty on objectives.” Correspondingly, Agile risk management is an approach that continuously identifies, assesses, treats, verifies, reports and monitors vulnerabilities through all stages of the life cycle.

Three Key Principles of ASRM

These definitions may be relatively simple, but transitioning from a traditional risk management approach to an Agile framework requires a substantial transformation and a concerted effort from multiple departments and stakeholders. Security professionals should embrace the following principles of ASRM to successfully implement these strategies throughout the enterprise.

1. ASRM Is Everyone’s Job

Although security and risk experts will remain in high demand for the foreseeable future, ASRM must be continuously taught, practiced and verified by all available corporate resources, including humans and AI-powered computing devices. Companies should provide training, nonretaliatory reporting outlets and comprehensive processes to prepare all resources to deal with the upcoming wave of AI-powered cybercrime.

From full-time corporate executives to contractors, suppliers, partners, customers and computing devices, all resources must be engaged in the proactive protection of corporate assets. The IBM X-Force Command Center is a great way to help your team refine its incident response and cyberdefense skills.

2. Continuous, Iterative and Incremental ASRM Delivery

Most current review practices call for hiring a group of security, risk, compliance, governance, business assurance and legal experts to assess the compliance status of various deployments against common regulations, standards and principles. These reviews often involve a pre-established list of questions that are already widely known among business units, causing auditors to miss crucial security gaps.

Organizations are best served by engaging all their resources to implement security and risk practices throughout the entire life cycle. Just as a builder would wire a house for electricity during the early stages of construction, security and risk activities should be conducted from the initial planning and inception through to decommissioning, end-of-life or destruction.

Organizations should also conduct continuous Agile training to implement security and risk in an iterative and incremental manner. Consistent and pervasive delivery are crucial to the success of the ASRM approach. Tools such as IBM Security AppScan are tailored to assist security teams with ASRM detection, protection and prevention.

3. Top-Down and Bottom-Up ASRM Decision-Making

Hierarchical organizations and societies can grow and maintain order, yet they aren’t able to adapt to today’s decentralized, pervasive and multiplying new world of increasingly destructive cyberattacks — they just aren’t Agile enough.

In fact, for fear of being reprimanded, employees often fail to report potential threats and risks. Companies should develop bug bounty programs to promote and celebrate Agile security and risk discussions. As part of Agile daily stand-ups, security teams should test their code and review their architecture and patching posture in the context of ASRM. By generating continuous feedback regarding all Agile activities, teams can release higher-quality and higher-value features at a faster pace.

The Race Is On to Embrace ASRM Modernization

If you are still unsure about Agile security, consider that it only takes nanoseconds to steal trillions of dollars from an infiltrated environment. How many assets and future gains (e.g., intellectual property) can you afford to lose? How much damage could a professional cybercriminal inflict over the standard cyberbreach remediation period of 18 months?

To embrace better corporate agility, organizations must increase communications, create room for small, rapid failures and empower their people and AI-empowered solutions to render and own ASRM decisions. Until ASRM adoption becomes ubiquitous, enterprises of all sizes will continue to suffer data breaches, experience significant staff turnover and be targeted by corporate investment activists.

As shareholders, investors and employees, we are all entitled to true management transparency, visibility and understanding of corporate security and risk posture. In addition to the summaries that are currently published as part of annual reports for publicly traded companies, shareholders should demand evidence of ASRM modernization. Otherwise, how can they justify investing sweat equity into an organization that can be wiped out overnight like a house of cards?

ASRM requires substantial, strategic transformation. Many large organizations have already completed the first phase of transitioning their development practices from waterfall to Agile. Fully embracing ASRM is the next step along the Agile adoption journey.

The post Three Characteristics of a Successful Agile Security and Risk Management Implementation appeared first on Security Intelligence.

CVE-2018-6389 WordPress Parameter Resource Consumption Remote DoS

Yesterday (Monday, February 5, 2018), a zero-day vulnerability in WordPress core was disclosed, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks.

WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit.

The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive.

Some JS files appearing in “script-loader.php” can be retrieved using the load parameter, causing increased resource consumption.

Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesn’t retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com. Hence, appending these JS files to the requested list is useless from an attacker’s perspective.

Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isn’t recommended and a simple authentication-based whitelist will not work either because it may break the login page.

WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall / web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions.

Until today (February 6, 2018), we have only seen a few dozen exploit attempts using this vulnerability, but we might see a steep rise in attacks using this exploit due to the popularity of the platform, unless a mitigation will be applied in the near future.

It is advised to set access restrictions to the “load-styles.php” and “load-scripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources.

Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”. In a testing environment in our lab we didn’t encounter any such errors and thus we assume that altering the “noop.php” is not obligatory for all WordPress users.

We did not extensively test this patch in our lab, and as of today, it wasn’t integrated into the main WordPress repository. Thus, we cannot recommend this solution, as it deviates from the WordPress core source and may cause compatibility issues.

An attack blocked by our system. Since the vulnerability disclosure yesterday our system intercepted a few dozen attacks.

After analyzing the data on our CDN, we have deployed mitigations against this vulnerability, which are enabled by default for all Incapsula sites with protection against “Illegal Resource Access”.

API Security Concerns Are on the Rise

In an application-centric, cloud-native world, businesses have a heightened concern for cybersecurity risk related to API use of late: Specifically, 63% of respondents in a recent survey said they are

The post API Security Concerns Are on the Rise appeared first on The Cyber Security Place.

2017 OWASP Top 10: The Good, the Bad and the Ugly

Since its founding in 2001, the Open Web Application Security Project (OWASP) has become a leading resource for online security best practices. In particular, its list of the top 10 “Most Critical Web Application Security Risks” is a de facto application security standard.

The recently released 2017 edition of the OWASP Top 10 marks its first update since 2013 and reflects the changes in the fundamental architecture of applications seen in recent years. These include:

  • Source code being run on untrusted browsers.
  • The creation of modular front-end user experiences using single page and mobile apps.
  • Microservices being written in node.js and Spring Boot.
  • The shielding of old code behind API and RESTful web services.

At Imperva, we deal with the attack types detailed in the Top 10 on a daily basis. Here, we want to offer our thoughts on the list, including what we agreed with (the good), what we thought was lacking (the bad) and what we disagreed with (the ugly).

But first, let’s see what’s changed since the 2013 list was released.

What’s New About the 2017 Report?

OWASP’s 2017 report includes an updated threat/risk rating system comprised of such categories as exploitability, prevalence, detectability, as well as technical and business impacts.

The attacks outlined below represent the newest web application threats, as seen in the 2017 OWASP Top 10.

A4 — XML External Entity (XXE)

A new category primarily supported by SAST data sets, an XML External Entity (XXE) takes advantage of older or poorly-configured XML processors to upload hostile content in an XML document.

By exploiting processors’ vulnerable code, dependencies or integrations, perpetrators can initiate a remote request from the server, scan internal systems and launch denial-of-service (DoS) attacks. This can render any application accepting XML, or inserts into XML documents, vulnerable.

A8 — Insecure Deserialization

Deserialization, i.e., the extraction of data from a series of bytes, is a constantly occurring process between applications communicating with each other. Improperly secured deserialization can lead to remote code execution, replay attacks, injection attacks, privilege escalation attacks and more.

A10 — Insufficient Logging and Monitoring

Insufficient logging and monitoring, when combined with ineffective incident response, allows attackers to strengthen and prolong attack strategies, maintain their persistence, “pivot to more systems, and tamper, extract, or destroy data”.
To make room for these new editions, OWASP adjusted the following threats:

  • Insecure direct object references and missing function level access control were merged into a new category called broken access control.
  • CSRF was downgraded to number 13 on OWASP’s list of security threats.
  • Invalidated redirects and forwards was downgraded to number 25.

Our Take on the 2017 Top 10

The 2017 OWASP Top 10 report contains a number of changes that we feel better reflect the current application threat landscape. That said, there are several points that could have been better explained as well as several missed opportunities to address additional application threats.

 The Good

The 2017 Top 10 looks sharper than the 2013 version, in that it focuses more on trending topics and technologies.

A number of attacks listed in the 2013 report have since become less of an issue and were removed from the list with good reason. For example, less than five percent of data sets support CSRF today, while less than one percent support invalid redirects and forwards.

Meanwhile, new categories, such as XML external entity (XXE), insecure deserialization, as well as insufficient logging and monitoring allow for a better security posture against new kinds of attacks and threats, such as REST requests, API interactions and XML data transmissions.

 The Bad

There were several categories in the new Top 10 that weren’t described very well. In particular, injection is still too broad a topic and doesn’t add enough background to the types of injections to which vulnerable applications might be exposed.

Regarding “Unvalidated Redirects and Forwards”, which is also an input validation control and a highly probable XSS, we agree with its removal from the Top 10. That said, it’s still a prominent threat that should have been more explicitly mentioned or included as part of another control, and not just downgraded.

 The Ugly

While we appreciate the addition of new controls into the Top 10, “insufficient logging and monitoring” doesn’t seem like it fits the bill.

In our opinion, the Top 10 should be focused on tangible controls that can prevent or minimize the risk of being exposed to a bug. A logging and monitoring solution is an important tool for web application security. That said, it’s a reactive control and doesn’t exactly fit with the other controls on the list, which are preventative.

Download a copy of our e-book “Protect Your Applications Against All OWASP Top 10 Risks” to find out how to you can protect your assets against these threats.

Do you agree with our analysis of the 2017 OWASP Top 10? Please let us know in the comments below.

Open Banking and PSD2: Disruption or Confusion?

If you’re not yet familiar with the concept of open banking, you’re not alone. U.K. consumer advice firm Which? reported that 92 percent of the public is unaware of the initiative, which officially launched on Jan. 13, 2018, to promote the use of application programming interfaces (APIs) to enable developers to build applications to augment banking services.

Open banking is the main driver behind the EU’s Revised Payment Service Directive (PSD2), which requires the largest financial institutions in the U.K. to release their data in a standardized format so that authorized third parties can share it more easily. Despite the lack of public awareness, this initiative has the potential to bring many benefits to the banking industry, including more valuable data insights and improved customer experience. However, it also introduces additional challenges from a cybersecurity, antifraud and data protection perspective.

A Brief History of Open Banking

In October 2015, the European Parliament revised its original Payment Services Directive (PSD1) to get the open banking ball rolling. A year later, the U.K. Competition and Markets Authority (CMA) identified competition concerns in the retail business and consumer current account markets. The agency subsequently issued a ruling that is consistent with PSD2, requiring the nine largest banks in the U.K. to grant licensed providers access to certain types of data. The open banking initiative is designed to comply with PSD2, providing the legal framework for the CMA requirements.

In short, PSD2 aims to increase regulation between banks and approved third-party payment providers (TPPs) regarding data they hold, access and share. It grants these entities access to payment accounts that hold information related to credit cards, mortgages, loans, savings and more via APIs. Another goal of open banking is to increase choice, control and protection over how consumers manage financial transactions and help promote the ongoing development and innovation of digital payments.

TPPs are categorized as Payment Initiation Services Providers (PISPs) and Account Information Services Providers (ASIPs). Banks may already fall into one or both categories, but the initiative opens the market to retailers, insurers, price comparison websites, utility providers, financial technology companies and more.

Key Concerns Related to Open Banking

PSD2 has the potential to be a catalyst for disruption in the banking and financial services industry, but there is widespread confusion about its purpose and benefit to customers. Let’s take a look at some of the key concerns related to open banking.

1. Ethics

Customers will begin to rely significantly on TPP’s to ethically manage their financial transaction data. Some experts are concerned that third-party access to accounts and data will create opportunities for TTPs to intrusively profile customers. This profiling may increase predatory lending, where TPP’s target vulnerable borrowers with invasive advertising to sell products and services. Access to financial data puts significant power in the hands of lenders.

2. Cybercrime

Providing access to multiple core banking platforms will significantly increase attack vectors for cybercriminals, meaning that banks will need to reassess and re-engineer their security controls and processes. Applying these controls on legacy IT systems may be extremely complex and costly. Conversely, some of the smaller new entrants may not be equipped with the expertise required to manage fraud, human error, identity theft and the loss of customer data.

3. Social Engineering

Cyberattacks will not be limited to exploiting technical vulnerabilities. Open banking may trigger an increase in social engineering attacks against customers who may be inexperienced using new technology platforms. Risks include phishing, malware, fraudulent apps, and physical theft or loss of endpoint devices that could provide access to third parties.

4. Compliance

As we have seen in recent years, not even highly regulated banks and financial services organizations are impervious to cyberattacks, and the aggregated customer data held and managed by TPPs via open APIs could be an easy target. There is an increased risk of information asymmetry, which could result in significant fines under various privacy regulations. Reputational risk is at stake if data is lost or tampered with in the chain of TPPs.

5. Privacy

The issues of consent, data privacy and permission need to be carefully reassessed. Consumers must fully understand what they are agreeing to, and where, when, how and with whom their data is being shared. According to McKinsey, “There is a fine line to walk: educating and empowering consumers without confusing, scaring or boring them.”

Potential Benefits of PSD2

Open banking also holds potential to bring numerous benefits to financial institutions and their customers. Below are some of the most significant.

1. Financial Control

Open banking and PSD2 will transform the banking sector much like the insurance industry changed after the emergence of price comparison websites. Customers will have greater visibility into and control of their finances to make efficient and meaningful decisions.

2. Security

PSD2 drives both PISPs and ASIPs to embed security and privacy directly into the APIs they are designing and implementing. However, they must balance security and the user experience. Open banking also provides an opportunity for banks to reassess their business model and security posture.

3. Increased Competition

Open banking will generate increased competition between established providers and innovative new entrants aiming to make existing products more flexible, bespoke and convenient. These entities include the likes of Amazon, Apple, Google and Facebook, who have agility in their investment capabilities as well as an advanced technological architecture to utilize customer data insights at scale.

4. Fraud Reduction

Despite concerns of increased fraud, PSD2 enhances existing consumer protection rules through increased security requirements. This includes the mandatory use of strong customer authentication, such as two-factor authentication (2FA) with biometrics. The data gathered will be enriched to reduce the number of false positives, thus ensuring that the customer experience is not adversely impacted.

5. Innovation

Open banking will also help accelerate the use of blockchain and cryptocurrencies in mainstream financial services. As cryptocurrencies such as bitcoin and Ethereum progressively become acceptable forms of payment, providers can take the opportunity to embed cryptocurrency payment mechanisms in their open banking platforms.

Open Banking Gains Momentum

As we march into 2018, the open banking initiative will gain momentum as banks and financial services organizations in the U.K. change their security, antifraud, and privacy policies and controls to comply with PSD2. These policies must include strong governance as well as robust processes and technical controls to protect the privacy and security of customer data.

Like any initiative that introduces sweeping changes to an industry as vital as financial services, PSD2 will come with its fair share of growing pains. However, organizations that embrace open banking and tailor their security strategies accordingly will unlock the benefits of shared data for their business and their customers.

Read the white paper: Harnessing the power of open banking

The post Open Banking and PSD2: Disruption or Confusion? appeared first on Security Intelligence.

Crypto-Mining: The Next Ransomware

Hackers are opportunistic by nature. As device manufacturers continue to add more CPU cores and gigabytes of RAM to smartphones and tablets as well as enterprise-grade cloud servers, these devices

The post Crypto-Mining: The Next Ransomware appeared first on The Cyber Security Place.

Survey: APIs a Growing Cybersecurity Risk

Like a lot of people, your mobile phone number is probably easily accessible to anyone with a bit of searching. Imagine if someone could take this number and your name and gain access to your mobile phone account including billing, email address and phone IMSI.  Or maybe someone hacked into one of your social accounts and accessed your contact information and all your photos? These very real scenarios at T-Mobile and Instagram both occurred because of application programming interface (API) security vulnerabilities. To learn more about the use of APIs, Imperva commissioned One Poll to study the attitudes of 250 IT managers security professionals.

APIs power the interactive digital experiences users love and are fundamental to an organization’s digital transformation. However, they also provide a window into an application that presents a growing cybersecurity risk. Hackers like APIs because they present multiple avenues to access a company’s data and can be used together in unintentional ways to enable new attacks that exploit web and mobile applications and IoT devices.

The API security survey revealed that on average companies manage 363 different APIs, and that two-thirds (69 percent) of organizations are exposing APIs to the public and their partners.

The API security survey revealed that on average companies manage 363 different APIs, and that two-thirds (69 percent) of organizations are exposing APIs to the public and their partners.

As noted, public-facing APIs are a key security concern because they are a direct vector to the sensitive data behind applications. Asked about their main API security concern, respondents stated they are most worried about DDoS attacks and bots while 24 percent said they are most concerned about authentication enforcement.

Asked about their main API security concern, respondents stated they are most worried about DDoS attacks and bots while 24 percent said they are most concerned about authentication enforcement.

Just over two-thirds of companies treat API security differently than web security, although API security is overseen by IT 78 percent of the time. Eighty percent of organizations use a public cloud service to protect the data behind their APIs with most people using the combination of API gateways (63.2 percent) and web application firewalls (63.2 percent).

Eighty percent of organizations use a public cloud service to protect the data behind their APIs with most people using the combination of API gateways (63.2 percent) and web application firewalls (63.2 percent

Ninety-two percent of IT professionals believe that DevSecOps, the combination of development, security and operations, will play a part in the future of application development. This highlights an increased desire from many organizations for security to be built in from the very beginning of software development rather than as an after-thought.

92 percent of IT professionals believe that DevSecOps, the combination of development, security and operations, will play a part in the future of application development.

Companies need to close the door on security risks from API exposure by deploying a multilayered approach to security. To learn more read, “Six Ways to Secure APIs,” and read our full survey results here.

No Rest for the Weary: Applying Security Lessons From 2017 in the New Year

How can it be that we are already through January and moving into February of the new year? I don’t know about you, but I still have a long list of resolutions to accomplish and I need to focus on what I can realistically get done in 2018.

This makes me think about how everyone in the security industry has been talking about new initiatives and goals for 2018. However, we would be remiss not to look back at the security lessons we learned and the goals we collectively accomplished in 2017. To get a head start on the new year, we should reflect on these insights and apply them to the work we need to complete in 2018.

Taking Stock of Security Lessons From 2017

So what happened in 2017 that required us to work harder and be more diligent than we thought possible? As an esteemed colleague of mine kindly reminded me, these “exercises” are simply “opportunities” to better our cybersecurity skills.

As we in IBM Security, specifically the X-Force Exchange team, take the time to look back, we can appreciate the hard work and collaboration that transpired to help make the world a safer place. Below are a few highlights and accomplishments we were proud to bring to the security industry last year.

  • We worked together to address data breaches and vulnerabilities that kept us all on our toes. A few of the big ones, such as WannaCry, NotPetya and Bad Rabbit, come to mind.
  • IBM produced the “X-Force 2017 Data Breach Review,” which revealed that:
    • Computer services and government agencies were hardest hit by breaches in terms of number of records and incidents;
    • Misconfigurations accounted for the largest number of records breached; and
    • The U.S. was the largest bull’s-eye for breaches in terms of number of incidents.
  • We grew our user base to over 50,000 security professionals around the globe representing all major industries, and provided a go-to resource to research and share threat intelligence, including both indicators of compromise and higher-order insights.
  • Our team supported the Quad9 initiative with the Packet Clearing House (PCH) and Global Cyber Alliance (GCA). We even offered a domain for anyone to use to enhance security and privacy while traversing the web.
  • We listened to our users’ feedback to further improve the user experience of the X-Force Exchange. We incorporated numerous innovations to the platform, including more robust notifications, a customizable experience and more X-Force research on current threats and vulnerabilities.

Don’t Let Your Guard Down in 2018

Even though we are proud of all the progress we made and security lessons we learned in 2017, we can’t afford to slack on our goals and resolutions for 2018. Bad actors will continue to attack our networks and exploit both known and unknown vulnerabilities. That’s why it is good to set achievable goals to ensure that we are doing everything we can to protect what is most important within our companies. It also means that, as a community of security professionals, we need to keep working together to spread security awareness and deal with whatever threats come our way.

To learn more about how you can get ahead of the next cybercriminal trend, check out the X-Force Exchange and start using it today.

Explore the IBM X-Force Exchange Now

The post No Rest for the Weary: Applying Security Lessons From 2017 in the New Year appeared first on Security Intelligence.

Cloud Migration Checklist for Application and Data Security

In the final post of our series on cloud migration, we’ve put together a list of strategic and immediate considerations as you plan to migrate your business to the cloud. From a high-altitude viewpoint, cloud security is based on a model of “shared responsibility” in which the concern for security maps to the degree of control any given actor has over the architecture stack. Thus, the most important security consideration is knowing exactly who is responsible for what in any given cloud project:

  • Software as a Service: Typically, the cloud provider is responsible for the bulk of security concerns.
  • Platform as a Service: The PaaS cloud provider is generally responsible for the security of the physical infrastructure. The consumer is responsible for everything they implement on the platform, including how they configure any offered security features.
  • Infrastructure as a Service: The cloud provider has primary responsibility for the physical security of the servers and the data vulnerability of the network itself. The cloud user is responsible for the security of everything they build on the infrastructure.

A Simple Cloud Security Process Model

The development of a comprehensive cloud security process must consider a wide range of implementation details such as design models and reference architectures. The following high-level process model for managing cloud security contains only the most essential items that must appear in a cloud security process model:

  • Identify enterprise governance, risk, and compliance requirements, and legacy mitigation controls.
  • Evaluate and select a cloud provider, a service model, and a deployment model.
  • Select your cloud provider, service, and deployment models.
  • Define the architecture of your deployment.
  • Assess the security controls and identify control gaps.
  • Design and implement controls to fill the gaps.
  • Develop and implement a migration strategy.
  • Modify your implementation as necessary.

Each migration process should be evaluated based on its own set of configurations and technologies, even when these projects are based on a single provider. The security controls for an application deployed on pure IaaS in one provider may look very different than a similar project that instead uses more PaaS from that same provider.

The key is to identify security requirements, define the architecture, and determine the control gaps based on the existing security features of the cloud platform. It’s essential that you know your cloud provider’s security measures and underlying architecture before you start translating your security requirements into cloud-based controls.

Checklist: Applications and Data Security for SPI

The three commonly recognized service models are referred to as the SPI (software, platform and infrastructure) tiers. Here are the main application and data security considerations for businesses using cloud services.

  • Cloud users must understand the differences between cloud computing and traditional infrastructure or virtualization, and how abstraction and orchestration impact security.
  • Cloud users should evaluate their cloud provider’s internal security controls and customer security features, so the cloud user can make an informed decision.
  • Cloud users should, for any given cloud project, build a responsibilities matrix to document who is implementing which controls and how. This should also align with any necessary compliance standards.
  • Cloud users should become familiar with the NIST model for cloud computing and the CSA reference architecture.
  • Cloud users should use available tools and questionnaires to evaluate and compare cloud providers.
  • Cloud users should use available tools to assess and document cloud project security and compliance requirements and controls, as well as who is responsible for each.
  • Cloud users should use a cloud security process model to select providers, design architectures, identify control gaps, and implement security and compliance controls.
  • Cloud users must establish security measures, such as a web application firewall (WAF), that allow only authorized web traffic to enter their cloud-based data center.

Download our Cloud Migration Guide to learn more about approaches and security considerations for migrating your applications and data to the cloud.

More in the series:

Cloud Migration Fundamentals

Five Cloud Migration Strategies for Applications

Cloud Migration: Technical and Business Considerations

Researchers Warn of Physics-Based Attacks on Sensors

Billions of sensors that are already deployed lack protections against attacks that manipulate the physical properties of devices to cause sensors and embedded devices to malfunction, researchers working in the U.S. and China have warned.  In an article in Communications of the ACM, researchers Kevin Fu of the University of Michigan and Wenyuan...

Read the whole entry... »

Related Stories

Deserialization Attacks Surge Motivated by Illegal Crypto-mining

Imperva’s research group is constantly monitoring new web application vulnerabilities. In doing so, we’ve noticed at least four major insecure deserialization vulnerabilities that were published in the past year.

Our analysis shows that, in the past three months, the number of deserialization attacks has grown by 300 percent on average, turning them into a serious security risk to web applications.

To make things worse, many of these attacks are now launched with the intent of installing crypto-mining malware on vulnerable web servers, which gridlocks their CPU usage.

In this blog post we will explain what insecure deserialization vulnerabilities are, show the growing trend of attacks exploiting these vulnerabilities and explain what attackers do to exploit them (including real-life attack examples).

What Is Serialization?

The process of serialization converts a “live” object (structure and/or state), like a Java object, into a format that can be sent over the network, or stored in memory or on disk. Deserialization converts the format back into a “live” object.

The purpose of serialization is to preserve an object, meaning that the object will exist outside the lifetime of the local machine on which it is created.

For example, when withdrawing money from an ATM, the information of the account holder and the required operation is stored in a local object. Before this object is sent to the main server, it is serialized in order to perform and approve the needed operations. The server then deserializes the object to complete the operation.

Types of Serialization

There are many types of serialization available, depending on the object which is being serialized and on the purpose. Almost all modern programming languages support serialization. In Java for example an object is converted into a compact representation using byte stream, and the byte stream can then be reverted back into a copy of that object.

Other types of serialization include converting an object into a hierarchical format like JSON or XML. The advantage of this serialization is that the serialized objects can be read as plain text, instead of a byte stream.

Deserialization Vulnerabilities from the Past Three Months

In the OWASP top 10 security risks of 2017 insecure deserialization came in at eighth place and rightfully so as we argued in our previous blog about the state of web application vulnerabilities in 2017.

In 2017, major new vulnerabilities related to insecure serialization, mostly in Java, were published (see Figure 1).

Name Release Date (Day/Month/Year) Vulnerability details
CVE-2017-12149 01/08/2017 Vulnerability in the JBoss Application Server allows execution of arbitrary code via crafted serialized data because the HTTP Invoker does not restrict classes for which it performs deserialization
CVE-2017-10271 21/06/2017 Vulnerability in the Oracle WebLogic Server allows execution of arbitrary code due to insufficient sanitizing of user supplied inputs in the wls-wsat component
CVE-2017-9805

 

21/06/2017 The REST Plugin in Apache Struts uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to remote code execution when deserializing XML payloads.
CVE-2017-7504 05/04/2017 The HTTPServerILServlet.java in JMS allows remote attackers to execute arbitrary code via crafted serialized data because it does not restrict the classes for which it performs deserialization

Figure 1: CVEs related to insecure deserialization

In order to understand the magnitude of these vulnerabilities, we analyzed attacks from the past three months (October to December of 2017) that try to exploit insecure deserialization. A key observation is the steep increase of deserialization attacks in the past few months, as can be seen in the Figure 2.


Figure 2: Insecure deserialization attacks over the course of three months

Most of the attackers used no attack vectors other than insecure deserialization. We noticed that each attacker was trying to exploit different vulnerabilities, with the above-mentioned CVEs being the most prevalent.

For a full list of CVEs related to insecure deserialization from the past few years see Figure 3.

Name Relevant System Public Exploit Name Relevant System Public Exploit
CVE-2017-9844 SAP NetWeaver Yes CVE-2016-2170 Apache OFBiz No
CVE-2017-9830 Code42 CrashPlan No CVE-2016-2003 HP P9000, XP7 Command View Advanced Edition (CVAE) Suite No
CVE-2017-9805 Apache Struts Yes CVE-2016-2000 HP Asset Manager No
CVE-2017-7504 Red Hat JBoss Yes CVE-2016-1999 HP Release Control No
CVE-2017-5878 Apache OpenMeetings Yes CVE-2016-1998 HP Service Manager No
CVE-2017-5645 Apache Log4j No CVE-2016-1997 HP Operations Orchestration No
CVE-2017-5641 Apache BlazeDS Yes CVE-2016-1986 HP Continuous Delivery Automation No
CVE-2017-5586 OpenText Documentum D2 Yes CVE-2016-1985 HP Operations Manager No
CVE-2017-3159 Apache Camel Yes CVE-2016-1487 Lexmark Markvision Enterprise No
CVE-2017-3066 Adobe ColdFusion Yes CVE-2016-1291 Cisco Prime Infrastructure Yes
CVE-2017-2608 Jenkins Yes CVE-2016-0958 Adobe Experience Manager No
CVE-2017-12149 Red Hat JBoss Yes CVE-2016-0788 Jenkins Yes
CVE-2017-11284 Adobe ColdFusion No CVE-2016-0779 Apache TomEE No
CVE-2017-11283 Adobe ColdFusion No CVE-2016-0714 Apache Tomcat No
CVE-2017-1000353 CloudBees Jenkins Yes CVE-2015-8765 McAfee ePolicy Orchestrator No
CVE-2016-9606 Resteasy Yes CVE-2015-8581 Apache TomEE No
CVE-2016-9299 Jenkins Yes CVE-2015-8545 NetApp No
CVE-2016-8749 Jackson (JSON) Yes CVE-2015-8360 Atlassian Bamboo No
CVE-2016-8744 Apache Brooklyn Yes CVE-2015-8238 Unify OpenScape No
CVE-2016-8735 Apache Tomcat JMX Yes CVE-2015-8237 Unify OpenScape No
CVE-2016-7462 VMWare vRealize Operations No CVE-2015-8103 Jenkins Yes
CVE-2016-6809 Apache Tika No CVE-2015-7501 Red Hat JBoss Yes
CVE-2016-5229 Atlassian Bamboo Yes CVE-2015-7501 Oracle Application Testing Suite No
CVE-2016-5004 Apache Archiva Yes CVE-2015-7450 IBM Websphere Yes
CVE-2016-4385 HP Network Automation No CVE-2015-7253 Commvault Edge Server Yes
CVE-2016-4372 HP iMC No CVE-2015-6934 VMWare vCenter/vRealize No
CVE-2016-3642 Solarwinds Virtualization Manager Yes CVE-2015-6576 Atlassian Bamboo No
CVE-2016-3461 Oracle MySQL Enterprise Monitor Yes CVE-2015-6555 Symantec Endpoint Protection Manager Yes
CVE-2016-3427 JMX Yes CVE-2015-6420 Cisco (various frameworks) No
CVE-2016-3415 Zimbra Collaboration No CVE-2015-5348 Apache Camel No
CVE-2016-2510 Red Hat JBoss BPM Suite No CVE-2015-5254 Apache ActiveMQ No
CVE-2016-2173 Spring AMPQ No CVE-2015-4852 Oracle WebLogic Yes
CVE-2016-2170 Apache OFBiz No CVE-2015-3253 Jenkins Yes
CVE-2016-2003 HP P9000, XP7 Command View Advanced Edition (CVAE) Suite No CVE-2012-4858 IBM Congnos BI No

Figure 3: CVEs related to insecure deserialization

Deserialization Attacks in the Wild

Most of the attacks that we saw are related to byte-stream serialization of Java objects. Also, we saw some attacks related to serialization to XML and other formats, see Figure 4.


Figure 4: Distribution of vulnerabilities over different serialization formats

In the following attack (see Figure 5) the attacker is trying to exploit CVE-2017-10271. The payload is sent in the HTTP request’s body using a serialized Java object through XML representation.

Attack vector containing serialized java array into XML fig 5

Figure 5: Attack vector containing a serialized java array into an XML

The fact that this is a Java array can be seen by the hierarchical structure of the parameters, with the suffix of “java/void/array/void/string”. The attacker is trying to run a bash script on the attacked server.

This bash script tries to send an HTTP request using “wget” OS command, download a shell script disguised as a picture file (note the jpg file extension) and run it. Few interesting notes can be made examining this command:

  • The existence of shell and “wget” commands indicate that this payload is targeting Linux systems
  • Using a picture file extension is usually done to evade security controls
  • The “-q” parameter to “wget” stands for “quiet”, this means that “wget” will have no output to the console, hence it will be harder to note that such a request was even made. Once the downloaded script runs the server is infected with a crypto mining malware trying to mine Monero digital coins (a crypto currency similar to Bitcoin).

The next script (see Figure 6) tries to exploit the same vulnerability, but this time the payload is targeting Windows servers using cmd.exe and Powershell commands to download the malware and run it.

Attack vector infect Windows server with crypto mining malware fig 6

Figure 6: Attack vector trying to infect Windows server with crypto mining malware

This indicates that there are two different infection methods for Windows and Linux server, each system with its designated script.

Another example is the following payload (Figure 7) that we pulled from an attack trying to exploit a deserialization vulnerability with a Java serialized object.

Attack vector containing java serialized object

Figure 7: Attack vector containing a Java serialized object trying to download a crypto miner

The “bad” encoding is an artifact of Java serialization, where the object is represented in the byte stream.

Still, we can see a script in plain text marked in yellow. Shown as an image below is a variable that defines an internal field separator, where in this case it is just a variable for space. The variable is probably used instead of a space to try to make the payload harder to detect.

Just as in the previous examples, this Bash script targets Linux servers that send an HTTP request using “wget” to download a crypto miner.

Beyond Insecure Deserialization

The common denominator of the attacks above is that attackers are trying to infect the server with a crypto mining malware by using an insecure deserialization vulnerability. However insecure deserialization is not the only method to achieve this goal.

Below (Figure 8) we see an example of another attack payload, this time at the “Content-Type” header.

Attack vector using RCE vulnerability of Apache Struts fig 8

Figure 8: Attack vector using an RCE vulnerability of Apache Struts

This attack tries to exploit CVE-2017-5638, a well-known RCE vulnerability related to Apache Struts which was published in March 2017 and was covered in a previous blog post.

When it was originally published we saw no indications of crypto miners in the attacks’ payloads related to this CVE, and most of the payloads were reconnaissance attacks.

However, in this attack the payload (marked in yellow above) is very similar to the payload from the previous example. Using the same remote server and the exact same script, it infected the server with crypto mining malware.

This old attack method with a new payload suggests a new trend in the cyber arena – attackers try to exploit RCE vulnerabilities, new and old, to turn vulnerable servers into crypto miners and get a faster ROI for their “effort”.

Recommendations

Given the many new vulnerabilities related to insecure deserialization that were discovered this year, and its appearance in the OWASP top 10 security risks, we expect to see newer related vulnerabilities released in 2018. In the meantime, organizations using affected servers are advised to use the latest patch to mitigate these vulnerabilities.

An alternative to manual patching is virtual patching. Virtual patching actively protects web applications from attacks, reducing the window of exposure and decreasing the cost of emergency patches and fix cycles.

A WAF that provides virtual patching doesn’t interfere with the normal application workflow, and keeps the site protected while allowing the site owners to control the patching process timeline.

Learn more about how to protect your web applications from vulnerabilities with Imperva WAF solutions.

5 steps to boost your application security testing ROI

Even in the era of AI hype, spending more does not necessarily means spending wiser.While Gartner forecasts global cybersecurity spending to reach $96.3 billion already this year, Gemalto reports a

The post 5 steps to boost your application security testing ROI appeared first on The Cyber Security Place.

Cloud Migration: Technical and Business Considerations

If you’re like many businesses, you’re moving applications into public and private cloud infrastructures. You’ve seen how the cloud’s agility, resiliency, and scalability drives business growth. Fortunately, rolling out new apps in the cloud is easy when you have containers, microservices, and DevOps supporting your efforts. But what’s not always as easy to figure out is application security—especially if you’re in the midst of migration and need to keep apps secure both on-premises and in the cloud.

Make no mistake: your apps will be attacked. According to the 2017 Verizon Data Breach Investigations Report, web app attacks are by far the number one cause of data breaches—with denial of service attacks the most common of these security incidents.

The good news? You can secure your apps as easily as you can roll them out when you have a flexible, scalable security solution in place.

In this article, we’ll discuss what you need to take into consideration to securely migrate apps to the cloud, and how Imperva FlexProtect can keep your applications secure wherever they live.

Security Model in the Public Cloud

Leading cloud vendors introduced a shared responsibility model for security in the cloud. Amazon states that AWS has “responsibility for security of the cloud,” while customers have “responsibility for security in the cloud.” Microsoft Azure, Google Cloud and other vendors also adopted this model. What does it mean for you? Cloud vendors provide the tools and services to secure the infrastructure (such as networking and compute machines), while you are responsible for things like network traffic protection and application security.

For example, cloud vendors help to restrict access to the compute instances (AWS EC2/Azure VM/Google CE) on which the web server is deployed (by using security groups/firewalls and other methods); they also deny web traffic from accessing restricted ports by setting only the needed HTTP or HTTPS listeners in the public endpoints (usually the load balancer).

But public cloud vendors do not provide the necessary tools to fully protect against application attacks such as the OWASP Top 10 risks or automated attacks. It’s your responsibility to establish security measures that allow only authorized web traffic to enter your cloud-based data center—just as with a physical data center. Securing web traffic in physical data centers is typically done by a web application firewall (WAF) and fortunately, a WAF can be deployed in the public cloud as well.

Choose Flexible Application Security for the Cloud

When choosing solutions to mitigate different web application threats, it’s important to make sure that they offer flexibility to choose the tools you need. The first mitigation layer is usually common for all attackers, it denies access from badly-reputed sources (“malicious IPs”) and blocks requests based on predefined signatures. This solution could be useful against generic types of attacks, like a botnet attack looking for known vulnerabilities. The more targeted the attack is though, the more fine-grained the tools required to mitigate it—and the higher the level of control your security team needs. When an attacker tries to launch an attack tailored to a specific web service, you need customizable tools to block it.

An ideal solution would offer both generic and customizable tools with the flexibility to be deployed within the private network and public cloud while giving your security administrator full control, including deployment topology and security configuration. An application security solution that is deployed in the public cloud should support several key attributes:

Burst capacity: Automatically spawn new security instances which then register with the existing cluster of gateways.

Multi-cloud security: A security solution should support all the major public cloud infrastructures (AWS, Azure or Google Cloud Platform) and your own data center so you can secure applications wherever they live—now and in the future.

DevOps ready: Security solutions should employ machine learning to automatically understand application behavior.

Automation: Dynamic cloud environments require automation to launch, scale, tune policies and handle maintenance operations.

High availability: Business continuity demands that your security solution be highly available.

Centralized management for hybrid deployment: A security solution should have a centralized management solution that can control hybrid deployments in both the physical data center and in the cloud.

Pricing for Applications

Applications are moving to a more automated architecture and they’re being developed and rolled out faster than ever. If any of the following apply to you, then you need a flexible licensing solution for security:

  • Moving to a microservices architecture
  • Planning to use serverless computing such as AWS Lambda
  • Deploying containers instead of traditional virtual machines
  • Have a dedicated application DevOps team in your organization
  • Concerned about your API security
  • Moving your applications from on-premises to public cloud infrastructure like AWS, Azure or Google Cloud Platform
  • Need to keep certain applications on-premises and need security for both cloud and on-premises

Imperva FlexProtect offers a single subscription with the flexibility to mix and match application security tools so you can secure applications wherever they live. FlexProtect security tools protect in-the-cloud and on-premises application portfolios, and keep your applications safe while you navigate the uncertainties of moving to a virtual, cloud-centric architecture.

Imperva application security solutions are available in a flexible, hybrid model that combines cloud-based services with virtual appliances to deliver application security and DDoS defense for the cloud. With FlexProtect, you can choose from the following Imperva security solutions:

Summary

Your organization needs a simple and flexible solution to facilitate a smooth transition from on-premises to the cloud. Imperva offers a solution that scales with your business while allowing you to choose tools based on your application security requirements. With FlexProtect, Imperva removes the dilemma associated with cloud migration planning and future proofs application security investments.

Contact us today to find out how the FlexProtect licensing model can help you keep your apps safe wherever they live, now and in the future.

Security Strategies for DevOps, APIs, Containers and Microservices

More and more IT professionals see DevSecOps, a practice which integrates security measures earlier in the development process to improve production code quality, as a mainstay for future application development.

Much of this stems from the growing trend towards speeding up application development through adopting architectures using DevOps, containers and microservices, as well as supporting automation toolchains and frameworks. This trend presents an opportunity for cybercriminals, who are increasingly turning their attention to security gaps and vulnerabilities in these types of environments. Given the speed and volume of development today and the greater complexity of the environment, it’s never been more important to make DevSecOps a priority.

Whether your role is CISO, developer, security architect, operations engineer, or a different member of the DevOps team, it is important to understand how to take a proactive and preventative approach for application security in these new environments. In particular, this means focusing on:

  1. Securing environments using APIs
  2. Implementing continuous security
  3. Adopting evolving security practices
  4. Securing sensitive data
  5. Maintaining current best practices for application vulnerabilities

Read on to learn more about these five security strategies.

#1: Learn How to Deploy Your Application Security to Environments Using APIs

Web application firewall (WAF) solutions become even more critical for modern application environments, as they add specialized security capabilities that complement components like API gateways, which only inherently perform basic functions of this filtering. To ensure API security, a WAF solution is needed for inspecting the incoming and outgoing HTTP/HTTPS as with any other web application and provide capabilities such as profiling, blocking attacks, bot and DDoS protection, preventing account takeover and more. Read more about what Imperva can do for API security here.

Your WAF should also help secure applications and data in the new application environment, with automatic deployment anytime new services or containers are provisioned.

#2: Implement Continuous Security

A challenge for security teams is to develop secure software while establishing proper security practices that don’t create bottlenecks in the development process and potentially impact time to market. This requires solutions designed to integrate easily and seamlessly into a DevSecOps workflow.

Continuous, Automated Security

DevOps commonly uses a practice known as Continuous Implementation-Continuous Deployment (CI-CD) (Figure 1), which tightly couples the development and launch processes to push out features and applications. From a security perspective, this means that the operational aspects of managing your WAF solution should be automated and templatized, such that your security can be easily scaled out. So, regardless of whether you spin up a new server, deploy a new application, or move an existing service from one server to another, the security policies and provisioning layer linked to that service are automatically deployed.

Programmability of your security solution helps it scale automatically and support rapid deployment of security resources as new applications and microservices are deployed. Leveraging cloud-specific templates such as AWS Cloud Formation or Microsoft Azure Resource Manager (ARM) when integrating your security solution can be one way to achieve this type of auto-scaling in your cloud environment.

devops CI_CD Process example

Figure 1: The process of Continuous Integration-Continuous Development (CI-CD) is an interlocked workflow commonly used in DevOps to build and deploy applications

#3: Insist on Security Solutions That Continue to Evolve

It will be difficult to implement the previous strategies and continue to evolve your security stance unless the security solutions you use are also evolving to keep pace with new application environments and tools.

For instance, modern application approaches and infrastructure—including DevOps, APIs, microservices, public cloud, containers and more—require security solutions that are designed to deliver:

  • High availability: All of your solutions should ensure stable business continuity by allowing your organization to protect sensitive web applications without introducing excessive IT overhead or blocking legitimate web traffic.
  • Integration: Choose security solutions that support appropriate, automated toolchains and other orchestration techniques used in DevOps, so that as new applications, instances and containers are deployed, security functions are implemented automatically, whenever and wherever they are needed. This typically requires exposure of capabilities via APIs that support DevOps workflows, cloud deployment, and orchestration.
  • Feature/function parity: Your solution should be agnostic to whether applications are deployed across public and private cloud, containers or on-premises. This allows you to transition traditional development to agile DevOps without compromising security.
  • Centralized management: Manage on-premises and cloud gateways from a single management console to consolidate and simplify security for hybrid cloud deployments.

#4: Secure Your Data

While most of the focus in DevSecOps is on the application and infrastructure, don’t lose sight of the data. Data security becomes even more critical as the applications and infrastructure become more distributed, with complex interdependencies that potentially span services, APIs, containers and clouds.

One way to protect your data in this increasingly complex application ecosystem is with a data-centric audit and protection (DCAP) solution. A DCAP solution helps you protect data in databases, file stores, and big data repositories with real-time monitoring, auditing, and security and rights management.

With a DCAP solution, you can:

  • Analyze all database activity in real time. You can monitor all users who access the database, whether through a browser, a mobile app or a desktop application.
  • Take action to avoid compromise and data loss, such as blocking access to sensitive data based on security policies.

#5: Keep Doing What You’re Doing

While application development and architecture practices are changing, the same web security vulnerabilities continue to threaten DevOps environments and hence gold-standard security best practices are still relevant. Your attack surface may be larger if you’re exposing APIs, as code is likely deployed far more frequently—including third-party software and services you may have in your stack, which increases your risk and pace of vulnerabilities being introduced.

For all of these reasons, your organization should continue to focus on:

  • Reducing your attack surface by hardening your infrastructure and services
  • Ensuring confidentiality by encrypting communications and data at rest
  • Enforcing granular access control
  • Filtering malware and blocking known bad traffic
  • Monitoring and detecting anomalous behavior to prevent all types of attacks, including: distributed denial of service (DDoS), abuse of functionality, access violation, exploit and more
  • Auditing access and events with logging and analysis

Integrate Security into Your Workflow

Today’s applications, services and APIs are attractive targets for cybercriminals looking to gain access into your environment. Managing and securing new application ecosystems requires applying the same security best practices as in the past, but also using solutions built to handle today’s environment.   

To learn more about how Imperva solutions can integrate into your DevSecOps workflow, download our ebook: “Five Security Strategies for DevOps, APIs, and Microservices“.

PureSec Emerges From Stealth With Security Product for Serverless Apps

Tel Aviv, Israel-based startup PureSec emerged from stealth mode on Wednesday with a security platform designed for serverless architectures and a guide that describes the top 10 risks for serverless applications.

read more

Five Cloud Migration Strategies for Applications

Regardless of your current IT environment or your vision for migrating to the cloud, numerous strategies exist that can accommodate your cloud-migration approach. Fortunately, this range of options allows you to proceed with caution while making progress toward your ultimate objective.

Always keep in mind that transitioning to the cloud need not be an “all or nothing” proposition. It is certainly possible, and indeed in many cases desirable, to leave some applications running in a local, traditional data center while others are moved to the cloud. It’s this “hybrid model” that makes it possible for companies to move applications to the cloud at their own pace.

We looked at service and deployment models for migrating to the cloud in our last post. This article provides summary descriptions of the options available to you when considering your cloud migration initiative.

Top Five Cloud Migration Strategies

1. Re-hosting

Sometimes referred to as “lift and shift,” re-hosting simply entails redeploying applications to a cloud-based hardware environment and making the appropriate changes to the application’s host configuration. This type of migration can provide a quick and easy cloud migration solution. There are trade-offs to this strategy, as the IaaS-based benefits of elasticity and scalability are not available with a re-hosting deployment.

However, the solution is made even more appealing by the availability of automated tools such as Amazon Web Services VM Import/Export. Still, some customers prefer to “learn by doing,” and opt to deploy the re-hosting process manually. In either case, once you have applications actually running in the cloud they tend to be easier to optimize and re-architect.

Re-hosting is particularly effective in a large-scale enterprise migration. Some organizations have realized a cost savings of as much as 30 percent, without having to implement any cloud-specific optimizations.

2. Re-platforming

This strategy entails running applications on the cloud provider’s infrastructure. You might make a few cloud-related optimizations to achieve some tangible benefit with relative ease, but you aren’t spending developer cycles to change an application’s core architecture.

Advantages of re-platforming include its “backward compatibility” that allows developers to reuse familiar resources, including legacy programming languages, development frameworks, and existing caches of an organization’s vital code.

An unfortunate downside to this strategy is the nascent state of the PaaS market, which doesn’t always provide some of the familiar capabilities offered to developers by existing platforms.

3. Repurchasing

This solution most often means discarding a legacy application or application platform, and deploying commercially available software delivered as a service. The solution reduces the need for a development team when requirements for a business function change quickly. The repurchasing option often manifests as a move to an SaaS platform such as Salesforce.com or Drupal. Disadvantages can include inconsistent naming conventions, interoperability issues, and vendor lock-in.

4. Refactoring / Re-architecting

This solution involves re-imagining how an application is architected and developed, typically using the cloud-native features of PaaS. This is usually driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment.

Unfortunately, this means the loss of legacy code and familiar development frameworks. On the flip side, it also means access to world-class developer’s tools available via the provider’s platform. Examples of productivity tools provided by PaaS providers include application templates and data models that can be customized, and developer communities that supply pre-built components.

The primary disadvantage to a PaaS arrangement is that the customer becomes extremely dependent on the provider. The fallout from a disengagement with the vendor over policies or pricing can be quite disruptive. A switch in vendors can mean abandoning most if not all, of a customer’s re-architected applications.

5. Retiring

Typically, the initial step in the cloud migration process is the discovery of your entire IT portfolio. Often, this discovery process entails application metering to determine the actual usage of deployed applications. It’s not unusual to find that anywhere between 10 to 20 percent of an enterprise IT estate is no longer being used. Retiring these unused applications can have a positive impact on the company’s bottom line; not just with the cost savings realized by no longer maintaining the applications, but by allowing IT resources to be devoted elsewhere, and by minimizing security concerns for the obsolete applications.

Download our Cloud Migration Guide to learn more about approaches and security considerations for migrating your applications and data to the cloud.

 

Cloud Migration Fundamentals

The advantages offered by a cloud-based environment make it an easy decision for most companies to make. Still, there are numerous critical choices to be made that can transform the complexities of the migration process into a relatively smooth transition—especially regarding application and data security.

This article describes the options available to you when you are planning a migration of application and data resources to the cloud.

Migration Strategy Fundamentals

As with any nascent methodology, business objectives will most likely drive your migration strategy. In addition, there are fundamental components to a migration strategy that are essential to all cloud migration initiatives:

  • Define an end-to-end strategy that takes into consideration your business objectives as well as the impact of cloud migration on IT operations.
  • Take the opportunity to discover and evaluate your enterprise application portfolio to see where inefficiencies exist, and where they can be remediated and optimized with available cloud services.
  • Redesign your business applications to integrate effectively with the specific service models offered in the cloud.
  • Understand the model of shared responsibility as it relates to security policy and risk mitigation, and develop policies and controls accordingly.

After you have a thorough and accurate picture of your application portfolio, you can start looking at where to start your application migration. There will be “low-hanging fruit” that will be the easiest to migrate, along with other applications that present complexities requiring additional time and attention.

Develop a plan that can be used as a framework for each application that you migrate to the cloud and the order in which they are to be migrated. Since the plan requires input from other departments, keep in mind that it will likely need to be amended and modified as you proceed through your application portfolio review.

Three Leading Service Models

There are three commonly recognized service models, sometimes referred to as the SPI (Software, Platform and Infrastructure) tiers (SaaS, PaaS, and IaaS), that describe the foundational categories of cloud services:

  • Software as a Service (SaaS) can be compared to a one-stop shop that provides everything you need to run an application. Typically, SaaS providers build applications on top of platform as a service (PaaS) and (IaaS) infrastructure as a service to take advantage of all the inherent economic benefits of the IaaS and PaaS service models.
    SaaS examples: Google Apps, Salesforce, Workday, Concur, Citrix GoToMeeting, Cisco WebEx.
  • Platform as a Service (PaaS) provides a platform that offers management of servers, networks, and other system components. Cloud users only see the platform, not the underlying infrastructure.
    PaaS examples: Salesforce Heroku, AWS Elastic Beanstalk, Microsoft Azure, Engine Yard, and Apprenda.
  • Infrastructure as a Service (IaaS) provides a shared pool of computer, network, and storage resources. Cloud providers use the technique of “abstraction,” typically through virtualization, to create a pool of resources. The abstracted resources are then “orchestrated” by a set of connectivity and delivery tools.
    IaaS examples: DigitalOcean, Linode, Rackspace, Amazon Web Services (AWS), Cisco Metapod, Microsoft Azure, Google Compute Engine (CGE), Joyent.

Most, if not all communications between cloud components are typically handled by application programming interfaces (APIs). A set of APIs is often made available to the cloud user so they can manage resources and configuration.

comparison of shared responsibility

Deployment Models

Cloud deployment models apply across the entire range of service models. They describe how cloud technologies are implemented and consumed:

  • Public Cloud – Owned and operated by a cloud service provider and made available to the public or a major industrial sector on a pay-as-you-go basis.
  • Private Cloud – Operated solely for a single organization and managed by the organization or by a third party. A private cloud may be located on- or off-premises.
  • Community Cloud – Shared by several organizations with common concerns. These concerns can include security requirements or governance considerations. The deployment can be managed by the community or by a third party. A community cloud can be located on- or off-premises.
  • Hybrid Cloud – Typically comprises two or more clouds (private, community, or public) and possibly an on-premises infrastructure as well. The different cloud deployments maintain their discrete identities but can interoperate via standard or proprietary technologies. An example of interoperability is “cloud bursting,” which enables an application to run in a private cloud and burst into a public cloud during increased demands for computing capacity.

cloud deployment models

There are several options available to you when you consider migrating to the cloud. Your strategy can cover the big picture considerations and also provision for attention to security issues. We’ll take a look in our next blog post on how to migrate your security policies from on-premises to the cloud, depending on the deployment you select.

Learn more about approaches and security considerations for migrating your applications and data to cloud, download our Cloud Migration Guide.

 

Sensor Shortfall: Mobile Application Security Could Put PINs at Risk

The ideal data that cybercriminals target to compromise mobile devices is user personal identification numbers (PINs). While it’s tempting to consider these PINs secure — especially if they’re regularly changed and don’t occupy the “1111” or “1234” space — researchers from the Nanyang Technological University (NTU) in Singapore have discovered a shortfall in mobile application security: sensor data. Now it’s possible for what devices see, hear and feel to help cybercriminals gain total device access.

Listening In

As noted by Bleeping Computer, most modern mobile operating systems, including iOS and Android, don’t ask for user permission to collect sensor data. The result? Newly installed apps can easily access accelerometer, gyroscope, magnetometer, proximity sensor, barometer and ambient light data. Seems like a hodgepodge of useless information, right? Not quite.

Researchers created a custom Android app that included a sensor data-gathering algorithm. Once installed on test devices, the application gathered device tilt and ambient light data captured when users entered their PINs. Using that data, the algorithm then attempted to predict device PINs from a list of the 50 most common. The result was 99.5 percent accuracy on the first try. However, when using the list of all 10,000 possible four-digit PINs, success dropped to 83.7 percent over 20 tries.

This still marks a significant mobile application security risk. Using a combination of deep learning and agile methodology, the algorithm was able to assign specific weights to sensor data and improve accuracy over time by learning how different users enter their PINs.

PIN Pushback

As noted by the NTU research, current mobile application security makes it possible for attackers to leverage side-channel methods that subvert even strong device security. So how can users stay safe? Start with longer PINs, which increases the amount of data needed by the algorithm to successfully guess user passcodes. Dr. Shivam Bhasin of NTU suggested that, in addition to extra-long PINs, users should also leverage other security methods including two-factor authentication or biometric scans that can’t be subverted by sensor data collection.

Enhancing Mobile Application Security

Ideally, mobile device operating systems will begin regulating sensor permissions, either disabling access by default or giving users the ability to allow or block access on-demand. Given current the current security climate, however — such as the burgeoning Internet of Things (IoT) market, which values speed over security — users shouldn’t expect significant security changes in the near future.

The more likely scenario is grudging device-maker acknowledgment that sensor data could be an issue, coupled with dismissal of the test-app scenario as a viable real-world vector. But as evolving malware and network attacks demonstrate, cybercriminals often enjoy marked success by leveraging supposedly low-risk threat vectors such as air-gapped devices or SCADA systems. As a result, mobile sensor data could quickly roll up the attacker priority list.

Bottom line? Mobile application security has a blind spot. While per-app sensor control isn’t available (yet), users can reduce their risk with longer PINs and two-factor authentication.

The post Sensor Shortfall: Mobile Application Security Could Put PINs at Risk appeared first on Security Intelligence.

The State of Web Application Vulnerabilities in 2017

As a web application firewall provider, part of our job at Imperva is constantly monitoring new security vulnerabilities. To do this, we use internal software that collects information from various data sources such as vulnerability databases, newsletters, forums, social media and more, integrate it into a single repository, and assess each vulnerability’s priority. Having this kind of data puts us in a unique position to provide analysis of all web application vulnerabilities throughout the year, view trends and notice significant changes in the security landscape.

As we did last year, before we enter 2018, we took a look back at 2017 to understand the changes and trends in web application security over the past year.

This year we registered a record high number of web application vulnerabilities including well-known categories like cross-site scripting, but also new categories such as insecure deserialization. In addition, the number of internet of things (IoT) vulnerabilities continued to grow and severely impact the security landscape. WordPress and PHP each continued to “dominate” in terms of vulnerabilities published in the content management system and server side technologies respectively. Apache Struts vulnerabilities, although the framework is less popular in the market at large, had a huge effect and were claimed to be the root cause of one of the biggest security breaches in 2017.

2017 Web Application Vulnerabilities Statistics

One of the first stats we review is quantity, meaning how many vulnerabilities were published in 2017 and how that number compares to previous years.

Figure 1 shows the number of vulnerabilities on a monthly basis over the last two years. We can see that the overall number of new vulnerabilities in 2017 (14,082) increased significantly (212%) compared to 2016 (6,615). According to our data, more than 50% of web application vulnerabilities have a public exploit available to hackers. In addition, more than a third (36%) of web application vulnerabilities don’t have an available solution, such as a software upgrade workaround or software patch.

As usual, cross-site scripting (Figure 2) vulnerabilities are the majority (8%) of 2017 web application vulnerabilities. In fact, their amount has doubled since 2016.

Figure 1: Number of web application vulnerabilities in 2016-2017

OWASP Top 10 View

This year OWASP released their long awaited “Top 10” list, which included two new risks:

Insecure Deserialization

Serialization is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer) or transmitted (for example, across a network connection link) and reconstructed later (deserialization). Serialization is widely used in RPC, HTTP, databases, etc.

Applications and APIs may be vulnerable if they deserialize hostile or tampered objects supplied by an attacker without proper sanitization. Therefore, we thought it would be interesting to view the security vulnerabilities in light of these changes.

Figure 2: Number and type of OWASP Top 10 vulnerabilities 2014-2017

The amount of deserialization vulnerabilities from 2016-2017 (Figure 2) increased substantially from previous years which may explain how they “earned” their spot in the new OWASP Top 10 list. Today, more and more applications and frameworks are using standard APIs to communicate. Some of these APIs take serialized objects and deserialize them in return, which can explain the growing trend of insecure deserialization vulnerabilities.

Insufficient Logging and Monitoring

Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. We have not found any vulnerabilities published in 2017 that are directly related to this category. It will be interesting to monitor it and see if that will change next year.

The Rise of the (IoT) Machines

Nowadays nearly every aspect of our lives is connected to the internet and we can find smart devices everywhere—in our home refrigerator, TV, lights, doors, locks and even the clothes we wear. These devices are designed to send and receive information and thus are usually connected to the internet at all times. In many cases the vendors of smart devices neglect to secure them properly or even “backdoor” them on purpose in order to gain hidden access.


Figure 3: IoT vulnerabilities 2014-2017

2017 registered a record high of 104 IoT-related vulnerabilities (Figure 3), a huge increase relative to previous years. The rising trend in the amount of vulnerabilities can be associated with their increasing popularity in our modern lives and advances in IoT technology that make IoT devices cheaper and accessible to more people.

One of the most popular vulnerability types in IoT devices (35%) is using default or easy to guess credentials in order to gain access to the device and take control of it. Once the device is controlled by the attacker it can be used to mount any kind of attack. Earlier this year the well-known Mirai malware used this kind of vulnerability (default credentials) to spread itself through the network. Once the malware gained access to the device, it turned it into a remote-controlled bot that was used as part of huge a DDoS attack.

Content Management Systems

When analyzing content management system (CMS) frameworks, we decided to concentrate on the four leading platforms that account for 60% of the market share—WordPress, Joomla, Drupal and Magento.

Figure 4: Number of vulnerabilities by CMS platform 2016-2017

WordPress

As suspected, WordPress vulnerabilities continue to be the lion’s share of all CMS-related vulnerabilities. In fact, WordPress vulnerabilities (418) have increased by ~400% since 2016 (Figure 4).

Further analysis of WordPress vulnerabilities showed that 75% of the 2017 vulnerabilities originated from third-party vendor plug-ins (Figure 5).

Figure 5: WordPress third party vendor vulnerabilities in 2017

The rise in the number of vulnerabilities can be explained by the growth of WordPress (Figure 6) and because third party plug-in code is notoriously known for its bad security.

Year Number of WordPress Plug-ins
2015 41,347
2016 48,044
2017 53,357

Figure 6: WordPress plug-in’s trend

Server-side Technologies

PHP is still the most prevalent server-side language, therefore it’s expected be associated with the highest number of vulnerabilities. In 2017, 44 vulnerabilities in PHP were published (Figure 7) which is a significant decrease (-143%) from the number of PHP vulnerabilities in 2016 (107) (see Figure 7). At the end of 2015, PHP released a major version, 7.0, after almost a year and half with no updates, which can explain the growth in the number of vulnerabilities in 2016. Last year PHP released a minor version, 7.1 (December 2016), with slight changes which can explain the decrease in the number of vulnerabilities in 2017.

Figure 7: Top server-side technology vulnerabilities 2014-2017

The Year of Apache Struts

Although 2017 listed fewer vulnerabilities in the Apache Struts framework (Figure 8), their impact was huge as some of them included unauthenticated remote code execution (RCE) which basically means that anyone can hack and take over the server, access private information and more.

Figure 8: Apache Struts and remote code execution vulnerabilities in 2014-2017

We have previously blogged about this specific vulnerability and multiple other Apache Struts vulnerabilities in detail. They’re worth checking out if you haven’t already.

Predictions Toward 2018

As a security vendor, we’re often asked about our predictions. Here are a couple of possible vulnerabilities trends for 2018:

  • Cross-site scripting vulnerabilities will continue to lead mainly because of the rise of cryptojacking and the increasing popularity of server-side technologies that utilize JavaScript (e.g., Node.JS).
  • More authentication-related vulnerabilities from the family of “default/guessable credentials” will be discovered (especially in IoT devices) and exploited in order to herd new botnets. These botnets can be used to mount any kind of large scale attacks—DDoS, brute force and more.

How to Protect Your Apps and Data

One of the best solutions for protecting against web application vulnerabilities is to deploy a web application firewall (WAF). A WAF may be either on-premises, in the cloud or a combination of both depending on your needs and infrastructure.

As organizations are moving more of their apps and data to the cloud, it’s important to think through your security requirements. A solution supported by a dedicated security team is an important requirement to add to your selection criteria. Dedicated security teams are able to push timely security updates to a WAF in order to properly defend your assets.

Women in Tech and Career Spotlight: Jerusalem Bicha

We conclude our series featuring women in tech at Imperva with an interview with Jerusalem Bicha, network operations team lead at Imperva. We talked about her path to a career in cybersecurity.

Tell us how you got into cybersecurity.

JB: I actually don’t have a degree. My career in cybersecurity happened by accident when I served in the Israeli Army. I had no experience with computers before I joined the service, but I was assigned to a computer/network help desk position because of an aptitude test I took.

After my two-year commitment in the Army was over, I acquired a Microsoft Certified IT Professional certification (MCITP) and started working for a private sector ISP. As part of my MCITP training, I took a bonus course and got my Cisco Certified Network Associate (CCNA) certificate. That’s when I basically fell in love with networking.

Jerusalem Bicha

Women in Tech: Jerusalem Bicha, network operations team lead at Imperva

Eventually I moved to the business support team at my job and worked on advanced networking tickets. From there I accepted further promotions to different teams within the business support center until I reached the highest escalation team. I loved what I was doing.

One of my co-workers was Maya Ventura who started working at Imperva. She posted on Facebook that the company was hiring a network engineer position. I wasn’t really looking for a new job but the position looked interesting. I got an interview and really loved the vibe at the office. And here I am!

What do you love about your job?

JB: I love the fact that it’s never boring. There’s rarely a day I can say I don’t have anything to do and I love it. I (still) love the vibe and I love the fact that we keep growing and growing. It’s amazing to see how far we’ve come over the past two years.

What do you find to be the most challenging?

JB: There’s a lot of work to be done to keep growing and improving and maintaining what we have. There are a lot of requests coming from departments and customers and we need to keep up with everything and juggle priorities to keep everybody happy. But it’s all part of the job and it keeps everything interesting.

Who was one of your biggest mentors and why?

JB: That’s a hard question to answer. I don’t have one specific person I can point to. There have been a lot of people along the way who’ve helped me.

There’s my family, of course. They’re a big part of everything I do. They encourage me to do my best and they’ve always believed in me. And there’s my boyfriend of almost eight years. He’s always been there for me and given me support.

Beyond that, I had two managers and a trainer at my first job at the ISP who believed in me and made sure I kept going. My co-workers are great too. I’ve grown so much over the years, both personally and professionally.

How has the cybersecurity industry changed over the course of your career?

JB: Well, I’m less a cybersecurity person and more of a networking person. But my team and I maintain the infrastructure for the Imperva Incapsula service. So, I’ve seen what the changes and challenges have been over the years.

When I joined the company, Incapsula had around 25 PoPs – which equaled about 1Tb of capacity. It wasn’t much data storage, but we worked with what we had. At that time, we had to manually go into the network to mitigate DDoS attacks.

I remember a particular Black Friday event back in 2015. We were up all night fighting the attack, distributing it, and isolating it. Network attacks were becoming more sophisticated and larger. We had to work hard to keep up.

Now our global network is at 40 PoPs and we’re adding more all the time – almost 6Tb and counting. As a company, we’ve worked hard to make sure we can mitigate a network attack automatically. We’re now prepared.

More in the series

Women in Tech and Career Spotlight: Michal Pal

Women in Tech and Career Spotlight: Luda Lazar

Women in Tech and Career Spotlight: Shu White

Women in Tech and Career Spotlight: Candice Carter

Women in Tech and Career Spotlight: Shiri Margel

Women in Tech and Career Spotlight: Inna Shalom

Top Five Trends IT Security Pros Need to Think About Going into 2018

It’s that time of the year when we look back at the tech trends of 2017 to provide us with a hint of things to come. Accordingly, let’s engage in our favorite end-of-year pastime: predictions about the coming year.

Equipped with Imperva’s own research, interactions with our customers, and a wealth of crowdsourcing data analyzed from installations around the world, we’ve looked ahead to the future of cybersecurity and compiled a few significant trends IT security pros can expect to see in 2018.

Here are our top five predictions for 2018 and what you can do to prepare for them:

1. Massive Cloud Data Breach

Companies have moved to cloud data services faster than anticipated even in traditional industries like banking and healthcare where security is a key concern. As shown in Figure 1, take-up of cloud computing will continue to increase, attaining a compound annual growth rate (CAGR) of 19%, from $99B in 2017 to $117B in 2018.

In 2018, in parallel with the take-up of cloud computing, we’ll see massive cloud data breaches—primarily because companies are not yet fully aware of the complexities involved with securing cloud data.

growth of cloud computing - IDC

Figure 1: Rapid Growth of Cloud Computing (Source: IDC)

Data Breaches: A Troubling Past, A Worrying Future

It is estimated that in 2017 alone, over 99 billion records were exposed because of data breaches. Of the various circumstances behind the breaches, hacking of IT systems is by far the most prevalent cause, followed by poor security, inside jobs, and lost or stolen hardware and media.

Major breaches at healthcare and financial services companies indicate a growing trend of vulnerabilities and exploits in these two vital business sectors.

Healthcare was one of the hardest hit sectors in 2017, and that trend is expected to worsen in the coming year. Some 31 million records were stolen, accounting for 2% of the total and up a whopping 423% from just 6 million.

The financial services industry is the most popular target for cyber attackers (see Figure 2), and this dubious distinction is likely to continue in the upcoming year. Finance companies suffered 125 data breaches, 14% of the total, up 29% from the previous six months.

Data breaches in various other industries totaled 53, up 13% and accounting for 6% of the total. The number of records involved in these attacks was a staggering 1.34 billion (71% of the total) and significantly up from 14 million.

It is estimated that the average cost of a data breach will be over $150 million by 2020, with the global annual cost forecast to be $2.1 trillion.

data records stolen or lost top five sectors - IDC

Figure 2: Data Records Stolen or Lost by Sector (Source: IDC)

Critical Cloud-based Security Misconfigurations

Missteps in cloud-based security configurations often lead to data breaches. This is likely to increase as more organizations move some or most of their operations to the cloud.

As organizations and business units migrate to public cloud services, centralized IT departments will find it increasingly difficult to control their company’s IT infrastructure. These enterprises lack the visibility necessary to manage their cloud environments and don’t have the monitoring tools to detect and report on security governance and compliance. Many are not even aware of the specific workloads they’ve migrated to the cloud. And without a doubt, you can’t secure what you can’t see.

For example, an unsecured Amazon Web Services S3 storage bucket has been an ongoing concern for cloud users. The bucket, which can be configured to allow public access, has in the past leaked highly sensitive information. In one instance of a major security breach, a whopping 111 GB worth was exposed, affecting tens of thousands of consumers.

Most significantly, Amazon is aware of the security issue, but is not likely to mitigate it since it is caused by cloud-user misconfigurations.

2. Cryptocurrency Mining

We expect to see a growth of cryptocurrency mining attacks where attackers are utilizing endpoint resources (CPU/GPU) to mine cryptocurrency either by cross-site scripting (XSS) or by malware. It’s increasingly likely that remotely vulnerable/hackable IoT devices will also be used as a mining force to further maximize an attacker’s profits.

Illegal mining operations set up by insiders, which can be difficult to detect, are also on the rise—often carried out by employees with high-level network privileges and the technical skills needed to turn their company’s computing infrastructure into a currency mint.

These attacks will quickly grow in popularity given their lucrative nature. As long as there is a potential windfall involved, such inside jobs are likely to remain high on the list of cybersecurity challenges faced by companies.

Although attacks that attempt to embed crypto-mining malware are currently unsophisticated, we expect to see an increase in the sophistication of attacks as word gets out that this is a lucrative enterprise. We also expect these attacks to target higher-traffic websites, since the potential to profit increases greatly with higher numbers of concurrent site visitors.

3. Malicious Use of AI/Deception of AI Systems

The malicious use of artificial intelligence (AI) will continue to grow quickly. The industry has started to see early traces of attackers leveraging AI to learn normal behavior and mimic that behavior to bypass current user and entity behavior analytics (UEBA) solutions. It’s still very early stage and will continue to mature beyond 2018. However, it will force current UEBA vendors to come up with a 2.0 approach to identifying anomalous behavior.

AI and internet of things (IoT) use cases drive cloud adoption. Artificial intelligence in the cloud promises to be the next great disrupter as computing is evolving from a mobile-first to an artificial intelligence-first model. The proliferation of cloud-based IoT in the marketplace continues to drive cloud demand, as cloud allows for secure storage of massive amounts of structured and unstructured data central to IoT core functions.

Without proper awareness and security measures, AI can be easily fooled by adversarial behavior. In 2018 we will see more:

  • Attacks on AI systems (for example, self-driving cars)
  • Cyber attackers who adapt their attacks to bypass AI-based cybersecurity systems

4. Cyber Extortion Targets Business Disruption

Cyber extortion will be more disruption focused. Encryption, corruption, and exfiltration will still be the leaders in cyber extortion, but disruption will intensify this year, manifesting in disabled networks, internal network denials of service, and crashing email services.

In the last few years, attackers have adopted a “traditional” ransomware business model—encrypt, corrupt or exfiltrate the data and extort the owner in order to recover the data or prevent it from leaking. Fortunately, techniques such as deception or machine learning have helped to prevent these types of attacks and made it more difficult for attackers to successfully complete a ransomware attack.

From a cost perspective, most of the damage associated with ransomware attacks is not the data loss itself, since many firms have backups, but the downtime. Often in the case of ransomware, attackers will start to leverage a disrupt-and-extort method. DDoS is the classic and most familiar one, but attackers will probably adopt new techniques. Examples include shutting down an internal network (web app to a database, point-of-sale systems, communication between endpoints, etc.), modifying computer configuration to cause software errors, causing software crashes, system restarts, disruption of your corporate email or disruption of any other infrastructure which is mandatory for an organization’s employees and/or customers day-to-day functions. Basically, any event that leaves the company unable to conduct business.

While absolute protection is impossible, you can help lower your chance of business interruption due to a cyber-attack. Start by creating a formal, documented risk management plan that addresses the scope, roles, responsibilities, compliance criteria and methodology for performing cyber risk assessments. This plan should include a characterization of all systems used at the organization based on their functions, the data they store and process, and their importance to the organization.

5. Breach by Insiders

Businesses are relying more on data which means more people within the business have access to it. The result is a corresponding increase in data breaches by insiders either through intentional (stealing) or unintentional (negligent) behavior of employees and partners.

While the most sensational headlines typically involve infiltrating an ironclad security system or an enormous and well-funded team of insurgents, the truth of how hackers are able to penetrate your system is more boring: it’s your employees.

A new IT security report paints a bleak picture of the actual gravity of the situation. Researchers found that IT workers in the government sector overwhelmingly think that employees are actually the biggest threat to cybersecurity. In fact, 100% of respondents said so.

Fortunately, security-focused companies have begun identifying these traditionally difficult to detect breaches using data monitoring, analytics, and expertise. The difference being that in 2018, more companies will invest in technology to identify this behavior where previously they were blind.

In fact, 75% of IT employees in government reported that rather than their organization having dedicated cybersecurity personnel on staff (which is becoming more and more necessary with each passing year), an overworked IT team was left to deal with security and employee compliance. As a result, 57% reported that they didn’t even have enough time to implement stronger security measures while 54% cited too small of a budget.

Here’s another fact for you: insider threats are the cause of the biggest security breaches out there, and they are very costly to remediate. According to a 2017 Insider Threat Report, 53% of companies estimate remediation costs of $100,000 and more, with 12% estimating a cost of more than $1 million. The same report suggests that 74% of companies feel that they are vulnerable to insider threats, with seven percent reporting extreme vulnerability.

These are the steps every company should take to minimize insider threats:

  • Background checks
  • Watch employee behavior
  • Use the principle of least privilege
  • Control user access
  • Monitor user actions
  • Educate employees

Insider threats are one of the top cybersecurity threats and a force to be reckoned with. Every company will face insider-related breaches sooner or later regardless of whether it is caused by a malicious action or an honest mistake. And it’s much better to put the necessary security measures in place now than to spend millions of dollars later.

 

Join Imperva on January 23rd for a live webinar where we’ll discuss these trends in more detail and review the security measures necessary to mitigate the risks. Register to attend today.

Imperva’s Top 10 Blogs of 2017

I recently took a step back to review all the content we shared in 2017 on the Imperva blog. We covered a broad range of topics including data security, cloud migration, application and API security, AI and machine learning, cybersecurity research, GDPR, insider threats and more. We were busy! Cybersecurity certainly held the world’s attention in 2017.

Several stories rose to the top as either most read by you, particularly relevant to today’s cybersecurity industry or exceptionally newsworthy (and in some cases, all of the above). For an end-of-year reading shortlist, I’ve compiled our top 10 blog posts from 2017.

1. What’s Next for Ransomware: Data Corruption, Exfiltration and Disruption

The WannaCry ransomware attack caught everyone off guard, infecting more than 230,000 computers in 150 countries by encrypting data on networked machines and demanding payments in Bitcoin. We wrote about how to protect against it, but our post on what’s next for ransomware garnered even more attention—it was our most read post of the year.

2. CVE-2017-5638: Remote Code Execution (RCE) Vulnerability in Apache Struts

Apache Struts made headlines all over the place in 2017. The vulnerability we wrote about in March hit it big and just kept on going. You might remember it reared its ugly head later in the year when it was tied to the Equifax breach. (We also wrote about two other Apache Struts vulnerabilities: CVE-2017-9791 and CVE-2017-9805.)

3. Top Insider Threat Concern? Careless Users. [Survey]

We surveyed 310 IT security professionals at Infosecurity Europe in June on their thoughts on insider threats. The big reveal? More than half (59 percent) were concerned not primarily about malicious users, but about the careless ones who unwittingly put their organization’s data at risk.  (We shared more about insider threats in this infographic.)

4. Uncover Sensitive Data with the Classifier Tool

In July we launched Classifier, a free data classification tool that allows organizations to quickly uncover sensitive data in their databases. The response was immediate—over 500 downloads and counting—not surprising given it helps jump start the path to compliance with the GDPR. Our blog post walked through the steps of how to use the tool.

5. Professional Services for GDPR Compliance

Speaking of the GDPR, the new data protection regulation coming out of the EU was on everyone’s radar this year. We wrote a LOT about GDPR, including who is subject to the regulationwhat rules require data protection technology, and the penalties for non-compliance. However, our post on the professional services we offer for GDPR compliance drove the most traffic on this topic by far.

6. The Evolution of Cybercrime and What It Means for Data Security

Hackers tactics may change, but what they’re after doesn’t—your data. Stealing or obstructing access to enterprise data is the foundation of the cybercrime value chain. We discussed how the changing nature of cybercrime and app and data accessibility create risk and the essentials of application and data protection in this ever-changing world.

7. Move Securely to the Cloud: WAF Requirements and Deployment Options

Moving to the cloud has become an overwhelmingly popular trend even among those who were at first reluctant to make the move. In this post, we discussed requirements and deployment options for evaluating a WAF for the cloud.  (We also wrote about the benefits of a hybrid WAF deployment and the pros and cons of both cloud and on-prem WAFs.)

8. Clustering and Dimensionality Reduction: Understanding the “Magic” Behind Machine Learning

Everywhere you turned in 2017 you heard about AI and machine learning and the impact they’re having, or will have, on essentially everything. Two of Imperva’s top cybersecurity researchers explained in detail some of the techniques used in machine learning and how they’re applied to solve for identifying improper access to unstructured data. (Those two researchers were also awarded a patent for their machine learning work this year!)

9. Can a License Solve Your Cloud Migration Problem?

Gartner published their 2017 Magic Quadrant for Web Application Firewalls (WAF) in August and Imperva was once again named a WAF leader, making it four consecutive years. We stood out for offering security solutions for today’s changing deployment and infrastructure model. In this post we wrote about our flexible licensing program, which lies at the core of the move to the cloud: helping customers secure apps wherever they need, whenever they need, for one price.

10. The Uber Breach and the Case for Data Masking

Last but not least, we couldn’t ignore the Uber breach. Hard to believe in today’s world that log in credentials were shared in a public, unsecured forum, but that’s what happened. The breach did highlight an important issue, that of production data being used in development environments. It’s a bad idea; we explained why in this post. Had data masking been used at Uber, hackers would have been left with worthless data, or as we called it, digital fools gold.

Botnets, Breaches, and the End of Defense in Depth: Our 2017 Cybersecurity Predictions in Review

As 2016 closed out, Imperva once again peered into its crystal ball. As usual, there was much to foretell regarding the ever-changing cybersecurity realm in 2017.

We’ll be doing the same soon as we look ahead into 2018. But before we do, we like to assess how accurate we were against the predictions we made last year. Here’s how we scored ourselves against our 2017 predictions.

1. Botnet of Things (BoT)

We expected to see two distinct types of trends in this area in 2017; a surge in botnet numbers and sizes and even more botnet for hire activity.

Nailed it: We were right on both counts. Mirai was the big IoT botnet news last year. Starting in February, the IEEE reported that one variant ran a DDoS assault against a US college over two-and-a-half days. Also sharing Mirai’s code base, Persirai is an IoT botnet that launched this past April. And that same month researchers discovered yet another Mirai-like botnet, BrickerBot.

Also in April, Imperva researchers intercepted encoded communications from a botnet consisting of 80,000 compromised devices. Their investigation revealed the botnet was used for an innovative spam campaign built to circumvent security countermeasures.

The IEEE says developers have become increasingly more sophisticated in making their botnets more powerful, as well as in cloaking their activity. This past October The Hacker News reported about IoT_reaper (a.k.a., IoTroop), a malware that takes advantage of vulnerabilities in disparate IoT devices, subjugating them into a botnet network. Two million devices ranging from routers to cameras and network video recorders may have been affected. Security journalist Brian Krebs reports that while IoTroop isn’t yet at full attack strength, it takes advantage of nine or more acknowledged vulnerabilities spread across a dozen device manufacturers.

The intentions of another growing botnet discovered this year, Hajime, remain unknown. Ostensibly it’s run by a white hat hacker looking to secure vulnerable IoT devices on our behalf. But researchers are wary—remaining very active, its real purpose may not yet be known.

As we predicted, botnets for hire remain readily available (at the end of 2016 we were already seeing declining costs of DDoS-for-hire services). An amateur with no prior knowledge can run a short attack for a few hundred dollars. A few thousand lets anyone play “Master of the Universe.” There is also significant ’net chatter regarding free tips and help in creating an IoT botnet.

2. Ghosts from the Past

We predicted ghost hacks from prior years would continue to haunt us in 2017.

Solid A: Yahoo was perhaps the biggest of the bad ghosts. We learned this year that every single Yahoo account was hacked, not just those previously reported from the August 2013 theft – three billion in all.

While “ghosts from the past” more specifically referred to hacks that went unknowingly undetected for years, related were the breaches that simply happened in the past, but weren’t made known publicly until this year. Take the Uber breach. Hackers stole the personal data of 57 million customers and drivers and Uber concealed it for more than a year (and even paid hackers to delete the data).

While smaller in scale, there’s also the recently reported data breach at Stanford University. Student financial aid information and the personal information of 10,000 employees were hacked back in June 2016, but the school wasn’t aware of the breach until February 2017 when a business student found sensitive data on a public server and reported it. Disclosure of the breach occurred just now—December. And not coincidentally, the university’s chief digital officer is now out of a job. Adding insult to injury, the student who identified the breach also wrote a 378-page paper exposing the university’s misleading financial aid practices he was able to glean from the data.

The issue here is that, Uber being an exception, most “ghosts from the past” become public because corporate identifiable data is found by third parties and brought to people’s attention. It’s (sadly) fairly rare that companies identify their own breaches. The problem of ghosts will continue to occur as long as companies aren’t watching their data (hopefully GDPR will help here!). Unless they’re watching, how would they know for sure when someone took data they shouldn’t have? Almost never. Data security solutions have been available since the beginning of the last decade, and while we do see more and more companies adopting a data security strategy, many still don’t or have too late, so these ghosts may still come back to haunt them later.

3. The End of Defense in Depth

Too Early to Tell: In 2016 we found many organizations were buying trends rather than mitigating risks and continuing to use outdated solutions out of a commitment to a defense-in-depth strategy that no longer served them (antivirus for example). We predicted enterprises would try to improve usage of their existing security arsenal in 2017 and smarter organizations will rethink their strategy in general.

In 2017, discussions about data security became more frequent and were elevated broadly across many industries such that security experts are now often required to answer questions from senior management about how corporate data won’t be stolen or extorted.  The dialogue is critical to begin the process of change within a traditional security defense in depth framework. Many of the organizations we spoke to throughout the year were ready to rethink their strategy, but it remained unclear what (outdated) solutions they might drop that are no longer serving them.

The good thing about the upcoming GDPR regulation (and the tightening and growth of regulatory controls in general) coming forth is that it’s helped create board level discussions with CIOs and CISOs about how they could avoid having the same problems as Yahoo, Uber and others. This has allowed for both budget allocation and a rethinking within the CISO team around how would they answer questions about where their organization’s personal data resides, who accesses that data and why. Thinking through those answers will help frame a security strategy—or possibly reframe an existing one.

And lastly, in 2017, the results of data breaches saw the ousting of some senior level security management professionals, further emphasizing the priority organizations are beginning to place on the responsibilities of data security professionals and the seriousness with which security is being taken in general.

There are as many possible solutions in the data security space as there are in the network security space, so the “solution” for each customer will be a bit different. Time will tell which technologies and practices work best to detect, if not prevent, breaches in the data core of an environment with more than the traditional layered network and endpoint security solutions used in defense in depth.

Science of CyberSecurity: Reasons Behind Most Security Breaches

As part of a profile interview for Science of Cybersecurity I was asked five questions on cyber security last week, here's question 2 of 5.

Q. What – in your estimation – are the reasons behind the many computer security breaches/failures that we see today?
Simply put insecure IT systems and people are behind every breach, insecure IT systems are arguably caused by people as well, whether it is poor system management, lack of security design, insecure coding techniques, and or inadequate support, it all boils down to someone not doing security right. For many years seasoned security experts have advocated that people are the weakest link in security, even hackers say ‘amateurs hack systems, professionals hack people’, yet many organisations still focus most of their resources and funds heavily on securing IT systems over providing staff with sustained security awareness. Maybe this is a result of an IT security sales industry over hyping the effectiveness of technical security solutions. I think most organisations can do more to address this balance, starting with better understanding the awareness level and risk posed by their employees. For instance, the security awareness of staff can be measured by using a fake phishing campaign to detect how many staff would click on a link within a suspicious email. While analysing the root causes of past cyber security incidents is a highly valuable barometer in understanding the risk posed by staff, all can be used as inputs into the cyber risk assessment process.

A developer’s guide to complying with PCI DSS 3.2 Requirement 6 Article

My updated article on "A developer's guide to complying with PCI DSS 3.2 Requirement 6" was released on the IBM Developer Works website today.

This article provides guidance on
 PCI DSS requirement 6, which breaks down into 28 further individual requirements and sits squarely with software developers who are involved in the development of applications that process, store, and transmit cardholder data.

iBackDoor: High-Risk Code Hits iOS Apps

Introduction

FireEye mobile researchers recently discovered potentially “backdoored” versions of an ad library embedded in thousands of iOS apps originally published in the Apple App Store. The affected versions of this library embedded functionality in iOS apps that used the library to display ads, allowing for potential malicious access to sensitive user data and device functionality. NOTE: Apple has worked with us on the issue and has since removed the affected apps.

These potential backdoors could have been controlled remotely by loading JavaScript code from a remote server to perform the following actions on an iOS device:

  • Capture audio and screenshots
  • Monitor and upload device location
  • Read/delete/create/modify files in the app’s data container
  • Read/write/reset the app’s keychain (e.g., app password storage)
  • Post encrypted data to remote servers
  • Open URL schemes to identify and launch other apps installed on the device
  • “Side-load” non-App Store apps by prompting the user to click an “Install” button

The offending ad library contained identifying data suggesting that it is a version of the mobiSage SDK [1]. We found 17 distinct versions of the potentially backdoored ad library: version codes 5.3.3 to 6.4.4. However, in the latest mobiSage SDK publicly released by adSage [2] – version 7.0.5 – the potential backdoors are not present. It is unclear whether the potentially backdoored versions of the ad library were released by adSage or if they were created and/or compromised by a malicious third party.

As of November 4, we have identified 2,846 iOS apps containing the potentially backdoored versions of mobiSage SDK. Among these, we observed more than 900 attempts to contact an ad adSage server capable of delivering JavaScript code to control the backdoors. We notified Apple of the complete list of affected apps and technical details on October 21, 2015.

While we have not observed the ad server deliver any malicious commands intended to trigger the most sensitive capabilities such as recording audio or stealing sensitive data, affected apps periodically contact the server to check for new JavaScript code. In the wrong hands, malicious JavaScript code that triggers the potential backdoors could be posted to eventually be downloaded and executed by affected apps.

Technical Details

As shown in Figure 1, the affected mobiSage library included two key components, separately implemented in Objective-C and JavaScript. The Objective-C component, which we refer to as msageCore, implements the underlying functionality of the potential backdoors and exposed interfaces to the JavaScript context through a WebView. The JavaScript component, which we refer to as msageJS, provides high-level execution logic and can trigger the potential backdoors by invoking the interfaces exposed by msageCore. Each component has its own separate version number.

Figure 1: Key components of backdoored mobiSage SDK

In the remainder of this section, we reveal internal details of msageCore, including its communication channel and high-risk interfaces. Then we describe how msageJS is launched and updated, and how it can trigger the backdoors.

Backdoors in msageCore

Communication channel

MsageCore implements a general framework to communicate with msageJS via the ad library’s WebView. Commands and parameters are passed via specially crafted URLs in the format adsagejs://cmd&parameter. As shown in the reconstructed code fragment in Figure 2, msageCore fetches the command and parameters from the JavaScript context and inserts them in its command queue.

Figure 2: Communication via URL loading in WebView

To process a command in its queue, msageCore dispatches the command, along with its parameters, to a corresponding Objective-C class and method. Figure 3 shows portions of the reconstructed command dispatching code.

Figure 3: Command dispatch in msageCore

At-risk interfaces

Each dispatched command ultimately arrives at an Objective-C class in msageCore. Table 1 shows a subset of msageCore classes and the corresponding interfaces that they expose.

msageCore Class Name

Interfaces

MSageCoreUIManagerPlugin

- captureAudio:

- captureImage:

- openMail:

- openSMS:

- openApp:

- openInAppStore:

- openCamera:

- openImagePicker:

- ...

MSageCoreLocation

- start:

- stop:

- setTimer:

- returnLocationInfo:webViewId:

- ...

MSageCorePluginFileModule

 

- createDir

- deleteDir:

- deleteFile:

- createFile:

- getFileContent:

- ...

MSageCoreKeyChain

- writeKeyValue:

- readValueByKey:

- resetValueByKey:

MSageCorePluginNetWork

- sendHttpGet:

- sendHttpPost:

- sendHttpUpload:

- ...

MSageCoreEncryptPlugin

- MD5Encrypt:

- SHA1Encrypt:

- AESEncrypt:

- AESDecrypt:

- DESEncrypt:

- DESDecrypt:

- XOREncrypt:

- XORDecrypt:

- RC4Encrypt:

- RC4Decrypt

- ...

Table 1: Selected interfaces exposed by msageCore

The selected interfaces reveal some of the key capabilities exposed by the potential backdoors in the library. They expose the potential ability to capture audio and screenshots while the affected app is in use, identify and launch other apps installed on the device, periodically monitor location, read and write files in the app’s data container, and read/write/reset “secure” keychain items stored by the app. Additionally, any data collected via these interfaces can be encrypted with various encryption schemes and uploaded to a remote server.

Beyond the selected interfaces, the ad library potentially exposed users to additional risks by including logic to promote and install “enpublic” apps as shown in Figure 4. As we have highlighted in previous blogs [footnotes 3, 4, 5, 6, 7], enpublic apps can introduce additional security risks by using private APIs in certain versions of iOS. These private APIs potentially allow for background monitoring of SMS or phone calls, breaking the app sandbox, stealing email messages, and demolishing arbitrary app installations. Apple has addressed a number of issues related to enpublic apps that we have brought to their attention.

Figure 4: Installing “enpublic” apps to bypass Apple App Store review

We can see how this ad library functions by examining the implementations of some of the selected interfaces. Figure 5 shows reconstructed code snippets for capturing audio. Before storing recorded audio to a file audio_xxx.wav, the code retrieves two parameters from the command for recording duration and threshold.

Figure 5: Capturing audio with duration and threshold

Figure 6 shows a code snippet for initializing the app’s keychain before reading. The accessed keychain is in the kSecClassGenericPassword class, which is widely used by apps for storing secret credentials such as passwords.

Figure 6: Reading the keychain in the kSecClassGenericPassword class

Remote control in msageJS

msageJS contains JavaScript code for communicating with a remote server and submitting commands to msageCore. The file layout of msageJS is shown in Figure 7. Inside sdkjs.js, we find a wrapper object called adsage and the JavaScript interface for command execution.

Figure 7: The file layout of msageJS

The command execution interface is constructed as follows:

          adsage.exec(className, methodName, argsList, onSuccess, onFailure);

The className and methodName parameters correspond to classes and methods in msageCore. The argsList parameter can be either a list or dict, and the exact types and values can be determined by reversing the methods in msageCore. The final two parameters are function callbacks invoked when the method exits. For example, the following invocation starts audio capture:

adsage.exec("MSageCoreUIManager", "captureAudio", ["Hey", 10, 40],  onSuccess, onFailure);

Note that the files comprising msageJS cannot be found by simply listing the files in an affected app’s IPA. The files themselves are zipped and encoded in Base64 in the data section of the ad library binary. After an affected app is launched, msageCore first decodes the string and extracts msageJS to the app’s data container, setting index.html shown in Figure 7 as the landing page in the ad library WebView to launch msageJS.

Figure 8: Base64 encoded JavaScript component in Zip format

When msageJS is launched, it sends a POST request to hxxp://entry.adsage.com/d/ to check for updates. The server responds with information about the latest msageJS version, including a download URL, as shown in Figure 9.

Figure 9: Server response to msageJS update request via HTTP POST

Enterprise Protection

To ensure the protection of our customers, FireEye has deployed detection rules in its Network Security (NX) and Mobile Threat Prevention (MTP) products to identify the affected apps and their network activities.

For FireEye NX customers, alerts will be generated if an employee uses an infected app while their iOS device is connected to the corporate network. FireEye MTP management customers have full visibility into high-risk apps installed on mobile devices in their deployment base. End users will receive on-device notifications of the risky app and IT administrators receive email alerts.

Conclusion

In this blog, we described an ad library that affected thousands of iOS apps with potential backdoor functionality. We revealed the internals of backdoors which could be used to trigger audio recording, capture screenshots, prompt the user to side-load other high-risk apps, and read sensitive data from the app’s keychain, among other dubious capabilities. We also showed how these potential backdoors in ad libraries could be controlled remotely by JavaScript code should their ad servers fall under malicious actors’ control.

[1] http://www.adsage.com/mobisage
[2] http://www.adsage.cn/
[3] https://www.fireeye.com/blog/threat-research/2015/08/ios_masque_attackwe.html
[4] https://www.fireeye.com/blog/threat-research/2015/02/ios_masque_attackre.html
[5] https://www.fireeye.com/blog/threat-research/2014/11/masque-attack-all-your-ios-apps-belong-to-us.html
[6] https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html
[7] https://www.virusbtn.com/virusbulletin/archive/2014/11/vb201411-Apple-without-shell