Nexusguard Certified Pentester (NCP) course was designed by Nexusguard practitioners who have years of experience in exploiting the loopholes of organizations and exposing the gaps that need to be remediated to avoid a compromise.

 

With attackers employing more complex obfuscation techniques, cyberattacks are becoming more sophisticated than ever, leading to more zero-day exploitation than discovery. If your organization's people, process and technology cannot keep up with evolving cyber threats, odds are that your organization is exposed to a much higher risk, especially if it is short of talent who has the right set of strategies, experience and skills to mitigate the risk. Nexusguard Academy was established to offer cybersecurity courses that help the industry address the talent gap.

 

Our Red Team practitioners have created various best practices to give guidance on the mistakes and challenges that organizations face. In this blog post, we focus on vulnerabilities of a static website.

 

Vulnerability Assessment and Penetration Testing on Static Websites

 

Static websites today are mostly used for information dissemination like advertisements and announcements. The demand for content to be constantly updated and flexible has led some websites to use Content Management Systems (CMS) that would generate the static pages from an administrator’s access panel.

 

Some may think vulnerability assessment and penetration testing (VAPT) is not necessary to these sites since they only contain public data and do not contain transactions that can be altered but in the cyber world, everything can be a target. As simple as a website’s reputation is already an asset to threat agents which is why we still need to secure these kinds of sites.

 

How do we test static websites? First is that we need to identify the structure of the target. Does the site use a well-known CMS like Wordpress, Joomla or Drupal? Is it custom made?

 

Well-known CMS' usually have tattletales that reveal which framework is used. This can be done by simple source code analysis. Please see the meta tags in the head section of the page:

 

 

Directory and library naming conventions:

 

 

For illustration purposes, we tested a website built with a custom PHP CMS. After determining the CMS, we fire up tools like directory buster or gobuster to discover hidden or unreferenced contents that can be used as an attack surface. 

 

 

The directory buster tool force browses pages and directories using wordlists that contain commonly used naming conventions. The command for the tool is as simple as dirb <target url> or additional parameters can be supplied such as user agent (-a <agent string>), cookie (-c <cookie string>), header (-H <header string>), and many more to fine tune the results.

 

In the target application, we found sample contents of a plugin named TinyMCE. The plugin gives the user an interface to input and format contents that would be generated for the static page. 

 

 

Upon testing, the discovered module did not have any functionalities attached to its buttons. It’s purely for demonstration purposes but leaving it in the production environment is not advisable as it has now given us an inside knowledge that the administrator panel is using the plugin and, as we researched on the plugin, we found out that it has a vulnerable module located at /plugins/filemanager/. 

 

 

When faced with upload functions like this, we would try to upload web shells to gain access to the web server using the same programming language which in this case is PHP. The simplest web shell in PHP is the following one-liner code:

<?=`$_GET[1]`?>

 

This would execute operating system commands from the parameter named “1”. We saved this to a PHP file and tried uploading it to the module but failed since the module only accepts certain file formats.

 

 

But it was observed that the page did not make any request when it verified the file. This means that the verification was done on the client’s side and can be by-passed by intercepting a valid upload request and altering the request content. To do this, we used the burp suite community edition to intercept the request to upload. 

 

 

This request is altered particularly the “file” parameter to contain the PHP webshell. 

 

The uploaded file is then found in the /uploads directory as the request suggested. We would now execute the following GET request to the uploaded file with the parameter 1 containing operating system commands: https://{redacted}/uploads/test.php?1=uname%20-a. 

 

 

So, what else did we find in this application? Another notable finding is the Cross-Site Request Forgery vulnerability or CSRF. CSRF is an attack where an authenticated user is forced to execute unwanted actions after visiting an external site. A simple test to validate this vulnerability is to look for forms that requires authentication to be processed by the application when submitted. Then, using HTML, replicate the forms with predetermined values to be submitted.

 

In this case, we forged the request to add users to the administrator’s panel with the following codes.

 

 

This would then be saved as HTML and browsed locally and would look like the following. 

 

To test this proof-of-concept code, a valid user should be logged in on a separate tab on the same browser before submitting the form. 

 

 

In a real attack, this form would be hosted in the cloud and is automatically submitted using javascript upon visiting the page which would lower the suspicion that it contains a forged request.

 

These vulnerabilities in a static website typically don’t have data leakages as a consequence since all the data in a static website does not contain confidential information and is meant to be seen by the public. But if these vulnerabilities lead to compromised web servers or administrator panels, the website may be used as an avenue to different attacks such as malware distribution, crypto mining, phishing and many more.