What are Penetration Testing Services?

Penetration testing (also called pentesting) is a controlled attempt to breach IT systems. Penetration testing is performed on behalf of the organization, in order to discover and remediate security weaknesses. There are two types of penetration testing services: manual and automated.

Manual penetration testing services

Traditionally, organizations contract penetration testing services from ethical hackers or security consulting firms. Manual penetration tests are extensive and methodical, but because of their high cost and complexity, they are performed infrequently, usually once per quarter or even once per year. In addition, manual pentesting can be unpredictable as some testers are very good, and others are not as good so will perform less well.

Automated penetration testing services

A new type of penetration testing service is penetration testing as a service (PTaaS). In this new model, a software as a service (SaaS) platform gives an organization automated tools it can use to perform penetration tests against its own systems. The main benefit of PTaaS is that it is predictable, inexpensive, and enables penetration testing on a continuous basis.

PTaaS can be fully self-service, used by the organization’s security or development teams or it can be delivered in a hybrid model, where the PTaaS provider offers a technological platform, but also helps operate it with its own security experts, guiding penetration testing and recommending remediations.

In this article, you will learn:

• What is Penetration Testing as a Service?
• What are Contract Penetration Testing Services?
• Types of Penetration Testing Services
  • Web Application Penetration Testing
  • Network Penetration Testing
  • API Penetration Testing
  • Mobile Application Penetration Testing

Penetration Testing as a Service (Automated Penetration Testing)

Penetration testing as a service (PTaaS) is performed by utilizing an automated online service, which organizations can use without contracting an external penetration tester.

PTaaS combines manual and automated penetration testing, allowing security teams to identify and fix vulnerabilities faster, better understand security mechanisms, and perform more frequent security testing. Customers use an online interface to manage penetration testing and data, making it easier to define scope of new penetration tests, view test results in real time, and perform continuous testing. 

Benefits of PTaaS services

The main value of PTaaS is that penetration tests can be performed much more frequently. New code and configurations are released daily, and each new version can have new vulnerabilities. With PTaaS, it’s possible to schedule and run a new penetration test for each new release. 

This type of continuous testing proactively improves the security environment, by identifying vulnerabilities, simulating potential attacks, and prioritizing the severity of attack outcomes.

Key features of PTaaS platforms

Here are the most important features potential customers should look at when evaluating an automated penetration testing service:  

• A library of up-to-date recommendations for vulnerability remediation
• Ability for multiple testers to collaborate on the same testing project
• Standard reporting and severity metrics across multiple vulnerability scanners
• Customizable reporting formats
• Long-term tracking of penetration testing activities and remediation of vulnerabilities discovered
• Integration with existing ticketing systems and governance, risk and compliance (GRC)

Related content: read our guide to penetration testing tools

Contract Penetration Testing Services (Manual Penetration Testing)

Unlike PTaaS, traditional penetration testing services are usually contracted to a security firm or individual ethical hacker. This individual or team provides an assessment of potential threats to company systems, in a systematic way, according to a predefined scope. 

Penetration testing starts from the perspective of an outside intruder or malicious insider. Like a real attacker, the pentester performs reconnaissance of the environment, identifies possible exploit paths, and attempts to penetrate the system being tested, without causing damage or exposing sensitive data.

The most important part of a penetration testing service is a final report that provides a list of vulnerabilities discovered during the test, assets or systems related to each vulnerability, an asset-related risk score, and recommendations for mitigating the risk in each of the affected systems.

Key qualifications of penetration testers

A good penetration tester should be:

• Certified in relevant technology systems and compliance standards
• Proficient with IT systems used by your organization
• Experienced with exploit toolkits, and preferably able to customize exploits and malware
• Experienced in social engineering
• Analytical and methodical
• A good communicator, able to provide reports that can communicate vulnerabilities and their impact both to management and technical staff

Types of Penetration Testing Services

Penetration testing services can be applied to several levels of the IT infrastructure. When selecting a penetration testing service, ensure it supports the type of penetration tests your organization needs.

Web Application Penetration Testing

Web application penetration testing looks for weaknesses in data validation and integrity, problems with authentication and session management, and other vulnerabilities. Penetration tests can identify security issues in databases, web application source code, and backend networks.

A web application pentest typically has three phases. Reconnaissance, discovery of security vulnerabilities, and exploiting vulnerabilities, in an attempt to gain unauthorized access to the application or its backend systems.

Learn more in our detailed guide to web application penetration testing

Network Penetration Testing

A network penetration test identifies security weaknesses in network infrastructure, including firewalls, switches, routers, and endpoints like servers and employee workstations. It can help prevent attacks exploiting incorrect firewall configuration, attacks against routers or switches, DNS attacks, proxy attacks, man in the middle (MiTM), and more.

Network penetration testing uses techniques like port scanning, traffic fuzzing, configuration vulnerability testing, virus scanning, and system fingerprinting. 

API Penetration Testing

Application programming interfaces (APIs) play a crucial role in modern information systems. Many IT systems communicate with APIs, or expose APIs, over the public Internet, making APIs a preferred attack vector for many attackers. 

API penetration testing involves learning an API’s structure and commands (some tools can import API commands using standards like OpenAPI), and checking for vulnerabilities like weak authentication, code injection, resource rate limiting, and data exposure. 

Mobile Application Penetration Testing

Many organizations have adopted bring your own device (BYOD) policies, meaning that employee’s personal mobile devices are allowed to connect to the network. Naturally these devices are less secure than corporate devices. 

Mobile penetration testing can test new attack vectors, such as deploying malware through mobile applications or phishing messages sent to personal devices, attacks exploiting weaknesses in WiFi networks, compromise of mobile device management (MDM) protocols, and more.

Penetration Testing Services with Bright

Bright significantly improves the application security pen-testing progress. By providing a no-false positive, AI powered DAST solution, purpose built for modern development environments the pen-testing process can be automated and vulnerabilities can be found faster and at a lower cost. Moreover, integrating Bright into DevOps environments enables you to run DAST scans as part of your CI/CD flows to identify a broad set of known (7,000+ payloads) security vulnerabilities early in the development process. 

In addition to detecting technical vulnerabilities, Bright’s unique ability to detect business logic vulnerabilities offers broader coverage and detection than any other automated solution. 

Learn more about Bright

Table of Contents

1. What is the most Important Must-Have feature of your DAST Tool?

If you’re anything like me, you’re already thinking about what you might want for Christmas (or Chanukah, or Eid – other High Holy days are available).

Whilst my son is thinking about the latest Nintendo Switch game, I know that you are probably (also) thinking about your ideal security testing tool and the key features it should have.

In today’s fast-paced software development world, with DevOps and CI/CD, the need for security testing automation has never been greater.

To enhance DevSecOps, security testing needs to be performed on every build, or merge to master at best, and on every sprint at least. This requires the adoption of effective AppSec tools that can keep up.

We recently discussed DevSecOps Tooling Best Practices, but if you had to choose one key feature for your DAST tool, what would it be?

What is the most Important Must-Have feature of your DAST Tool?

We ran polls on LinkedIn, Twitter and in a recent webinar, to ask this very question – where do you sit..?

With 67% of respondents choosing “NO False Positives”, the need for accuracy is apparent.

In a world of automation, having false alerts that need to be manually verified is debilitating and unscalable, regardless of the size of your team. With tens, hundreds, thousands of accumulated false positives, a decision needs to be made to stop the release or push to production and take the risk. This compounds the security debt issue, but also leads to a distrust of the tooling and decimates any security culture in your organisation.

Receiving fully validated results in an automated way enables security to understand the risk in a snapshot without wasting critical time on manual validation, whilst being able to quickly prioritise remediation. Additionally, developers trust that their build failed for good reason and not a false alert and that their JIRA (or other ticketing tools) ticket is actionable and not ignored.

Nineteen percent would want their DAST tool to be able to test both web apps and APIs. 

Whether you are still using SOAP, have kept up with the times and using REST, or are pushing the innovation and adopting GraphQL, 90% of all web traffic is carried out over APIs. Traditional / legacy DAST tools either do not support API testing at all, or do so in a convoluted way with various proxies that are cumbersome for security teams, let alone developers. This forces the reliance on slow, expensive manual testing.

A DAST tool that is developer and DevOps friendly came in third place on this poll with 14%, but the importance of this feature cannot be underestimated.

Typically built for the security team, DAST tools are notoriously hard to configure and can be as hard to truly integrate into your pipelines. To shift security testing left and put it into the hands of developers, DAST needs to be intuitive to carry out the right tests against the target, without the need for developers and / or QA to be a cybersecurity expert. This enables them to effectively collaborate together to remediate security bugs, without constantly leaning on an overstretched security team. 

Bright’s DAST automatically validates every vulnerability it detects, producing results that everyone in the pipeline can trust, with No false positives, to test your web apps and APIs (SOAP, REST and GraphQL). 

Uniquely integrating into your SDLC with multiple scan optimisation settings out of the box for developers to start scanning, contact us today to learn how Bright can make your Christmas come early or request a demo.

Table of Contents

1. How often are you testing for Application or API vulnerabilities?

Whether you are just starting your DevOps journey, or are fine tuning your processes as you mature, with CI/CD and easy deployment of new microservices, changes to applications and APIs are carried out at breakneck speed, with multiple iterations in a day.

Making sure your security testing can keep up with this pace, is key to a successful AppSec programme. 

Development teams that scan for security issues early and often substantially reduce their security debt and technical debt, as discussed in our blog “Size may not matter…but in DevSecOps, frequency certainly does!”.

How often are you testing for Application or API vulnerabilities?

We ran polls on LinkedIn and Twitter to ask this very question – the results of which are below and are rather telling! 

An overwhelming 71% of respondents are testing their applications and APIs either before a major release (39%), typically carried out with manual VA or PT, or are still relying on periodic penetration testing (32%) – monthly at best, or annually.

Whether carried out internally or via a third party, this is a time-consuming, resource-intensive, and expensive process. This also compounds the security debt problem, which further increases your cyber risk. Not to mention that this practice goes completely against the notion of DevOps.

Most legacy Dynamic Application Security Testing (DAST) solutions, used to test applications for security vulnerabilities, lack the ability to test APIs at all (whether REST or GraphQL), which partially explains these results. 

However, it is an accumulation of several limitations in legacy DAST tools that make it even harder to automate the scanning process. Hence the reliance on manual work, namely:

1. Inability to effectively and seamlessly integrate into the SDLC
2. Not developer friendly – built for security professionals
3. Inability to test every pull request, or merge to master due to speed limitations
4. Lack accuracy – many false positives that need manual validation
5. Delayed feedback loop to developers

This lack of automation creates a human bottleneck which is impossible to scale and explains why so few organizations are able to test every build or commit (17%) or every Merge to Master (12%). 

Without automation and relying on siloed security teams, it is also very hard to cement a culture of security, which underpins DevOps.

Having security champions is important to achieve this culture, but they too will face an uphill struggle to succeed with such a fragmented security testing process. A seamless and timely feedback loop of validated security issues, removing the false positives, is needed for developers to fix issues early, to be secure by design and minimise risk. 

Automation of security testing baked across your SDLC, for both WebApps and APIs, is paramount.

A DAST tool that your developers, security champions, QA professionals and security team are able to use is required, so that they can effectively collaborate to fix security bugs. 

The earlier this can be done in your pipeline the better. Add to this integration with your tooling to achieve comprehensive security compliance on every build to enable you to shift security testing left and you have a winning formula. 

Bright’s no-false positive Application Security Testing automation platform helps achieve these goals. Join the 17% of poll respondents and start running security tests on every build – contact us today to learn how our clients are achieving this success or request a demo.

Table of Contents

1. What is Security Debt?
2. How is Security Debt caused?.
3. When and how often should you be scanning?

With applications driving the global economy, developers are under pressure to deliver software and more features at an unprecedented scale and speed. 

While no developer wants to create insecure products, most software products are pushed into production with vulnerabilities which stay unremediated causing a spiraling technical and security debt and significant risk for the organization.

Application Security scanning frequency really is the key, with development teams that scan for security issues early and often substantially reducing their security debt. 

But what is Security Debt and how early and how often should you be scanning? 

What is Security Debt?

Security debt is the continuing accumulation of security vulnerabilities in your software that compound to make it harder (read: impossible) to catch up with remediation to secure your applications and data from attacks.

Unlike technical debt, which may get in the way of releasing new features for the needs of the business, the growing pile of security vulnerabilities puts your organization at an increased risk of cyber attack. Indeed, in many cases, Medium to High severity vulnerabilities are being deferred, including issues like XSS, SQLi and others in the OWASP Top 10. According to Forrester, the average time to resolve a high vulnerability in production is 4 months. This means that you could be placing your entire business at risk for 4 months. Unfathomable, right? Yet it happens every day!!!

How is Security Debt caused?

Security debt is caused when security testing is not baked across the software development life cycle (SDLC), accumulating when development releases software without testing for or fixing vulnerabilities. 

With most organizations carrying out periodic (monthly, quarterly, annually?) automated, or manual security testing, they make the decision to release now and fix vulnerabilities later.  This results in an increased risk of exposure until the issues are remediated. The main issue is that ‘later’ keeps on getting pushed back and in many cases, ‘later’ becomes ‘never’, making security debt even worse!

When and how often should you be scanning?

Your Security Debt should be treated just like your Credit Card debt – if you keep spending and don’t pay off your monthly balance, eventually it will lead to bankruptcy.

With the sheer volume of iterations to applications and APIs on a daily basis, security testing needs to mirror this cadence, to prevent a security breach and potential bankruptcy too!

Heavy, periodic scanning and quick remediation over a defined limited period to meet a release deadline, forces you to defer issues and add to your security debt.

DevOps and DevSecOps focus on enabling organizations to detect and fix security vulnerabilities as early and as often as possible in the software development life cycle (SDLC). 

This mindset, where everyone is responsible for security, has broken down the barriers between developers, QA and security, facilitated by security champions who know what good looks like in terms of security.

With the increased velocity of development, comes an accelerated introduction of vulnerabilities. Security testing and remediation needs to become a habitual process and part of your accelerated pipelines. Automation of daily security testing is critical to establishing a cadence of secure software

The advantages of daily scanning are clear to see:

With regular testing on every build / commit, or at least daily, everyone can be focused on making better security decisions as part of a unified DevSecOps strategy to deliver software with speed, efficiency and security.

Relying on manual testing simply cannot keep up with accelerated development timelines. The success of this strategy relies on development teams having easy to use, accurate and seamlessly integrated automated testing technology. 

Traditional legacy Dynamic Application Security Testing (DAST) tools are not built for this regular cadence of security testing that demands speed.

Bright’s innovative Bright technology, with no false positives, has been built with a developer first approach, to enable you to effectively integrate security scanning on every build / commit, to enhance DevSecOps and reduce your security debt. Contact us to learn more and request a demo.

Table of Contents

1. So, why is putting the Sec in DevSecOps so important today?
2. How do you Add the Sec to DevSecOps?.

Last week I had the pleasure of presenting at the Pittsburgh Cybersecurity day in partnership with ISACA. It was exciting to see more than 250 cybersecurity and application security professionals interested in discussing and learning how security can be enabled in a world rapidly adopting DevOps practices.

So, why is putting the Sec in DevSecOps so important today?

According to Gartner research, 2020 is the inflection point where more than 50% of organizations will adopt DevOps practices. This adoption is expected to continue at a rate of 20% year over year for the next 5 years. This accelerated DevOps adoption is justified as it offers many advantages including:

• Faster release times
• Higher SW quality
• Reduced failure rates
• Cost savings

However, with all these advantages there are also some disadvantages. First among these is the risk of releasing vulnerable applications and the concern of being hacked. To understand this better, let’s look at an example:

This results in significant vulnerabilities in production as issues are only remediated months after a release is completed!

Now that we understand the problem, where should we focus?

According to the latest Forrester Wave, >70% of security incidents occur at the web layer. With the accelerated adoption of APIs and the less mature threat models for Web Applications and APIs, these risks are continually increasing.

How do you Add the Sec to DevSecOps?

Now that we understand the importance of adding application security into your DevOps environment (adding Sec to DevSecOps), what do you need to do to achieve this?

There are a number of aspects to consider:

• People: Putting the correct organization in place
• Process: Establishing the right processes
• Technology: Implementing solutions that enable you to achieve this

In order to effectively implement DevSecOps an organization needs to share the responsibility (and joy) of security with the development and QA organizations. Due to the increased velocity of development and the ratio between developers and security professionals in the organization (up to 100:1 in many cases), it is impossible to achieve this goal without sharing the ownership for security. You can read more about this in our recent post about security champions and how to create them. 

Once the team is in place you need to make sure you have the correct processes to facilitate effective SecOps. These processes include feedback loops for:

• Defining the correct procedures for ensuring security is timely and effective
• Making sure you have the right coverage
• Identifying vulnerabilities early
• Remediating vulnerabilities when they are identified
• Validating the fixes that were implemented
• Facilitating feedback loops for continuous improvement

To learn more about this, you can follow our blog post about it here: https://brightsec.com/blog/devsecops-tooling-best-practices/

Last but certainly not least, you need to implement the correct technology that will enable the organization to effectively implement DevSecOps. These solutions need to be built from the ground up to enable developers and QA professionals to adopt them and must include these key features:

• Seamless integration into the SDLC
• Making sure scans can complete at the speed of DevOps while effectively identifying vulnerabilities.
• Provide different users with different interfaces that will enable them to adopt solutions as part of their standard workflows and not change their flows.
• Eliminate false positives in an automated manner and don’t delay (and annoy) developers by having them waste hours sifting through false positives. 
• Provide clear and effective remediation guidelines.

Solutions like Bright are specifically built to enable organizations to add the Sec into DevSecOps.

When implemented correctly, organizations can achieve amazing results.

To learn more about effectively implementing DevSecOps please reach out to Bright and speak with our experts

Table of Contents

1. ‘Develop’ a Culture of Security…
2. Empowering your teams to scale security testing, at speed.
3. Security feedback loop
4. Accuracy of and Trust in the Tooling
5. Achieving DevSecOps with Bright

DevOps teams have become successful in releasing code at speed, whether for webapps or APIs, but with the lack of testing automation, are releasing vulnerabilities at speed too.

To achieve DevSecOps, you need to bake security into your rapid-release cycles, requiring the adoption of effective tools and practices, to unify your teams across application development, QA testing, and of course your security teams, under a common DevSecOps methodology.

Below are some key aspects to consider when implementing tooling to your DevSecOps pipelines:

1. ‘Develop’ a Culture of Security…

Not really specific to tooling, but one of the main pillars that is critical to achieving DevSecOps – security culture; once you have management buy-in, it’s about collaboration between your development and security teams, breaking down the silos and creating champions for this change. These champions can serve as the go between that speaks the different languages of the pipeline itself

2. Empowering your teams to scale security testing, at speed

When adopting DevSecOps, you are shifting security testing left, i.e. into the hands of your developers, who need to be the first line of defense, enabling them to detect, prioritise and treat security defects like they do with functional defects, to fix them early.

To do this however, developers need tools they can actually use…not another tool built for security professionals that is going to be disabled and join your other shelfware. For modern development environments, you need a modern DAST with a Dev First security approach, that is simple and intuitive to use where you dont need to be a cyber security expert to configure the tests and understand the output. 

Having a DAST that tests both your WebApps and APIs will give you that single pane of glass, additional buy-in from your teams and longevity, reducing your TCO.

3. Security feedback loop

With scale and speed comes automation, requiring a DAST tool to detect your vulnerabilities early. You need to provide your developers with the ability to scan every build / commit from their dashboard and to then automatically raise tickets with GitHub or Jira for example, into a feedback loop, so that each security player in your team has visibility, from your developers, QA / security team, to the CISO. 

4. Accuracy of and Trust in the Tooling

Having a tool that is easy to use and integrated into your pipeline is great, but if it is setting off false alerts (false positives) and your builds are failing because of these, then your developers will soon make their feelings felt. The results need to be accurate and deliver actionable results with remediation guidelines for your developers to remediate early. The manual validation of vulnerabilities is slow and expensive and so a tool that removes these is essential to maintain the speed of DevOps while delivering security compliance. If you are a CISO, how can you effectively evaluate your risk, on demand, when your results are skewed with these false positives and are draining your internal security team as they scramble to manually validate the findings..?

Achieving DevSecOps with Bright

Bright enhances DevSecOps at its core, with a Dev First approach to test your WebApps and APIs

Key features of our technology include:

• Shallow learning curve: to establish a culture of security testing across your pipelines
• Built for Developers: We empower developers to detect and fix vulnerabilities on every build, enabling them to leverage multiple discovery methods to initiative a scan, including:
  • Crawling – for full automation
  • HAR files – generated per build/commit for scope defined testing or by QA Automation
  • OpenAPI (Swagger) files or Postman Collections – to test APIs or Single Page Applications
• Smart Scanning functionality: leveraging sophisticated algorithms to carry out the right tests against the target, removing complexity for developers whilst ensuring scans are automatically optimised to maximise speed and prevent development drag
• Built for Modern Technologies: Microservices, Single Page Applications, APIs (REST, GraphQL) are all supported 
• 0 (Zero) False Positives: The only tool with fully automated validation of every vulnerability detected, freeing up valuable time for your security team and saving a considerable amount money, to release fast and be secure by design
• Seamless Integration: Rest API, CLI for developers, or with common tools such as CircleCI, Jenkins, Jira, GitLab, Github, AzureDevOps and more

To find out how you can leverage our technology to achieve DevSecOps for your WebApps and APIs, please do get in touch or request a demo here.

Table of Contents

1. The Rise of GraphQL
2. An innovative API, needs an innovative DAST .

Bright’s ability to work with modern technology stacks and API security testing now includes full support for GraphQL APIs, enabling our customers to simplify, automate and scale their security testing even further with our solutions, as they embrace new architectures.

Developed internally by Facebook and released publicly in 2015, the rise in popularity of GraphQL has grown exponentially, and we are excited to support our clients who join the many household names that are embracing GraphQL, including Github, Twitter and Airbnb.

Our GraphQL API security testing support exemplifies our dedication to enabling our clients, at the forefront of modern technology, to integrate application security testing across their CI/CD pipelines and to reduce their reliance on manual testing.

The Rise of GraphQL

What has driven this rise in popularity? Advantages of a GraphQL API include:

Microservices Friendly, just like Bright – GraphQL API handles communication between multiple microservices, merging them into one GraphQL schema, great when migrating from a monolithic application to a microservice architecture.

Single API call, with precise data fetching – Whereas REST APIs lack granular control over data, resulting in the over-fetch or under-fetch of data, GraphQL delivers a modern, simple, efficient and flexible way to improve client-server interactions, by enabling the client to make a single API call to obtain the precise data its needs, maximising performance.

Rapid production iterations – with GraphQL, changes in front end code do not require the restructuring of code by the backend engineers, so frontend developers can promptly respond to user feedback and make the changes.

Eliminates versioning – API evolution with REST results in API versions, however GraphQL eliminates versioning by deprecating APIs on a field level, removing them from the schema without impacting the existing queries. This single, evolving version provides applications with continuous access to new features.

API documentation Automation – Documentation updates are synchronised with API changes. As the GraphQL API is closely coupled with code, once a field, type or query changes, so do the docs, meaning developers spend less time documenting an API, always a good thing!

An innovative API, needs an innovative DAST 

You are at the forefront of technology and have invested in GraphQL for automation, accuracy, superior performance and speed. 

Bright is your security partner with a technology that mirrors these deliverables, with innovative AppSec testing automation built from the ground up with a Dev First approach, to test modern WebApps and APIs as part of your CI/CD.

Supercharge your GraphQL (or REST and SOAP) security testing with Bright. 

Key features of our GraphQL testing include:

We Understand
Unlike any other DAST tools, we automatically parse the data types to understand their context, to leverage sophisticated attacks and analyse the responses to evolve the payloads further.

Full depth parsing
Ability to parse varying interaction definitions, such as an XML object inside a GraphQL query, or vice versa

Sophisticated Payloads
Compliance testing to detect the OWASP API Top 10 and more, or carry out API Fuzz testing with Bright.

CI/CD Integration
Integrate via Rest API, our CLI for developers, or with common tools such as CircleCI, Jenkins, Jira or Github to carry out incremental scanning to empower your developers to detect and fix vulnerabilities on every build as part of your CI/CD, leveraging multiple discovery methods to initiative a security test, including:

• Crawler – proprietary and advanced to detect and parse GraphQL
• HAR files
• OpenAPI (Swagger) files 
• Postman Collections

To find out how you can leverage our technology to test your GraphQL, please be in touch or request a demo here.

Table of Contents

1. Top 5 ways WordPress sites get hacked
2. How to stay secure?

WordPress has many advantages and is not without reason the most popular way to build a website, with 60% of pages on the web based on it. Unfortunately, it is this popularity that makes WordPress a juicy target for malicious users. Every year hundreds of thousands of WordPress and ecommerce sites get hacked.

So, is WordPress secure?

Attackers don’t get in thanks to security flaws in WordPress’s latest core software. Rather, most hacks can be easily prevented by taking simple steps like keeping things updated and securing passwords.

Top 5 ways WordPress sites get hacked

According to data, here are the top 5 ways WordPress websites get hacked:

1. Out-Of-Date Core Software
2. Out-Of-Date Themes and Plugins
3. Compromised Login Credentials for WordPress, FTP or Hosting
4. Supply Chain Attacks
5. Poor Hosting Environment and Out-Of-Date Technology

1. Out-of-date Core Software

According to WPScan Vulnerability Database, ~76% of the known vulnerabilities they logged are in the WordPress core software. But if we look at the version of WordPress those vulnerabilities were found, then we can see that 9 out of 10 most vulnerable WordPress versions are WordPress 3.x.x. Unfortunately only 21.5% of websites run on the latest version of WordPress.

2. Out-Of-Date Themes and Plugins

While themes and plugins are great for extending your site, each extension is a new potential gateway for a malicious actor. While most WordPress developers do a good job at following code standards and patching any updates as they become known, there are still a few issues:

–        A plugin or theme has a vulnerability
–        The developer has stopped working on the theme or plugin but people are still using it
–        The developer patches the issue, but people don’t update

3. Compromised Login Credentials for WordPress, FTP or Hosting

A non-trivial percentage of hacks are from malicious actors getting their hands on WordPress, hosting or FTP account credentials.

Once the attacker has the key to your front door, it doesn’t matter how otherwise secure your WordPress site is.

WordPress does a great job mitigating this by generating secure passwords. It’s still up to users to keep those passwords secure.

4. Supply Chain Attack

There are some instances where hackers used a nasty trick to gain access to sites. The malicious actor would:

–        Purchase a previously high-quality plugin listed at WordPress.org
–        Add a backdoor into the plugin’s code
–        Wait for people to update the plugin and inject the backdoor

It’s hard to prevent such attacks as you are doing something you are supposed to do – you are keeping a plugin up-to-date. WordPress.org team usually quickly spots these issues and removes the plugin from the directory.

5. Poor hosting environment and Out-Of-Date Technology

A whopping ~28% of WordPress websites are still using PHP 5.6 or below. The support for PHP 5.6 expired at the end of 2018, and earlier PHP versions haven’t had security support for years. This opens you up to the potential of unpatched PHP security vulnerabilities. Using a secure hosting environment and recent versions of important technologies like PHP helps further ensure that your WordPress site stays safe. Always make sure your website is well maintained.

How to stay secure?

The only way to be completely sure your website is secure is to test it for vulnerabilities. Automated solutions like Bright are easy to deploy and you don’t have to be a security expert to start a scan. Bright is a SaaS solutions and new payloads are added faster than with any other traditional solution. Request a demo and check out how Bright can help you keeping your WordPress site secure.

Table of Contents

1. How do Magecart attacks work
2. Which vulnerabilities get targeted by Magecart attacks.
3. How to protect yourself and your business

Do you know what “skimming” is? It’s a method that hackers use to gather sensitive information in online payment forums. Credit card numbers, email addresses, and user passwords are stolen. Magecart is a form of data skimming. The targets of these attacks are online shopping cart systems, the most common one being Magento. Attackers get a hold of the customers’ payment card information and abuse it for their own gains. The main way of doing this is compromising a third-party piece of software, usually from a VAR. Magecart hackers implant their malicious code into a website. Then they steal credit card information when a user enters their credentials during the checkout phase of shopping.

But why are shopping carts such an alluring target for these hackers? Because shopping carts collect your payment information. Hackers can do a lot of harm if they manage to tap into this data stream. The problem lies with the eCommerce sites. Why? They don’t check open-source (third-party) code for vulnerabilities when they build their eCommerce site. This is a recipe for disaster as sometimes this code comes with vulnerabilities that can easily be exploited. Are these Magecart attacks dangerous just for individual users? Not exactly. Even gigantic businesses like Ticketmaster’s United Kingdom Website, Puma’s Australian website, and even British Airways got attacked as reported by CNCB. As you can see, Magecart attacks are a huge threat for anyone, be it a small business or a large enterprise.

How do Magecart attacks work

As you can see, Magecart hackers are dangerous. They can easily alter the Magento source or redirect the entire shopping cart to a malicious website by using injections. Is it easy to detect these attacks? It is if you’re ready to compare your entire eCommerce code stack one line at a time to see if anything was altered. A particularly nasty way Magecart attacks have been done includes uploading the malicious code to any unused GitHub project. Hackers that manage to take ownership of this project can then publish a new version of the code. One which contains malware. This propels the malware across a countless number of websites, spreading the infection further. Some security tools won’t even scan GitHub code. This way hackers and their malicious websites remain unnoticed, hiding in plain sight. 

Which vulnerabilities get targeted by Magecart attacks

This is the age of open-source development. Source code is publicly available and anyone can study it, change it, and improve it. A lot of websites today are built based on many open-source components (third-party code). You have 20 companies that make and operate the code you’re using for your website. The problem lies within the privileges granted to the 3rd party code. Third-party code usually has the same level of privilege as your own code. Why is this a problem? Because this third-party code is able to exfiltrate sensitive data that is entered by users. It can even redirect the user to another website. Customers aren’t aware of these technical issues. They don’t know what it means for a website that’s built with code that’s hosted by 50 different development groups/organizations. Any vulnerability that comes from an open-source component leaves your website vulnerable as well.

Some Magecart groups are evolving their techniques. An attack on the Shopper Approved website proved that these attacks are a serious threat. This particular attack abused the vendor’s customer scoring plug-in. The plug-in got used to rate all kinds of websites that displayed badges of honor. Shopper Approved quickly removed the malware once it was identified. But the malware managed to spread across many eCommerce sites nonetheless.

Others stick to attacking shopping carts. However, they use a new method to infect advertising banners. These hackers utilize ad servers. By doing this the ad server places the Magecart code into a specific webserver. Any user that views this ad in their browser gets infected. A code gets downloaded to their computer.

Lastly, you have hackers that plan extremely targeted and complex attacks. Instead of the quantity, they focus on quality. These hackers spend a lot of time studying the code and the infrastructure of one target. British Airways happened to be a victim of this particular attack. Hackers exploited the logic flow of internal applications. The infected script targeted their baggage claim information page. Magecart then stole all the data that wasn’t stored on any of the servers that were owned by British Airways. This is how an XSS attack compromised British Airways’ servers. Testing your applications for XSS vulnerabilities is a much easier task when you use solutions like Bright. You can read more about this specific type of attack on one of our blogs.

How to protect yourself and your business

Now we know how Magecart attacks work and what their primary targets are. How does one protect themselves and their business against them? Protecting against attacks like this can be difficult. Just auditing a website every now and then won’t help. Why? The problem comes from third-party tags which are not detected by auditing. An effective prevention technique is a zero-trust approach with JavaScript on a website. A policy that will block access to any sensitive information entered in both stored cookies and web forums by default is a good start. Then only a selected set of vetted script should be allowed to access sensitive data. This approach makes it so skimming code can’t get access to any sensitive information when it gets on a website.

Web browsers don’t offer this option in most cases. Yet, users can make sure they’re not a victim of Magecart attacks in a couple of ways:

• Avoid smaller websites that may not have a high level of security as bigger, more known websites
• Check your credit cards for charges (Hackers make small test charges to make sure the targeted credit card is still active)
• Use secure payment systems like Apple Pay (They generate unique numbers for each transaction so that attackers can’t re-use an obtained number)