ADVISORIES | March 9, 2016

Authenticated OS Command Injection on TP-LINK Cloud Cameras

By Tao Sauvage

An attacker with Administrator (admin) access to the administrative web panel of a TP-LINK Cloud Camera can gain root access to the device, fully compromising its confidentiality, integrity, and availability. (more…)

penetration testing

RESEARCH | February 24, 2016

Inside the IOActive Silicon Lab: Reading CMOS layout

By Andrew Zonenberg

Ever wondered what happens inside the IOActive silicon lab? For the next few weeks we’ll be posting a series of blogs that highlight some of the equipment, tools, attacks, and all around interesting stuff that we do there. We’ll start off with Andrew Zonenberg explaining the basics of CMOS layout.

Basics of CMOS Layout

When describing layout, this series will use a simplified variant of Mead & Conway’s color scheme, which hides some of the complexity required for manufacturing.

Material	Color
P doping
N doping
Polysilicon
Via
Metal 1
Metal 2
Metal 3
Metal 4

The basic building block of a modern integrated circuit (IC) is the metal-oxide-semiconductor field effect transistor, or MOSFET. As the name implies, it is a field-effecttransistor (an electronic switch which is turned on or off by an electric field, rather than by current flow) made out of a metal-oxide-semiconductor “sandwich”.

(Terminology note: In modern processes, the gate is often made of polycrystalline silicon, aka polysilicon, rather than a metal. As is the tradition in the IC fab literature, we typically use the term “poly” to refer to the gate material, regardless of whether it is actually metal or poly.)

Without further ado, here’s a schematic cross-section and top view of an N-channelMOSFET. The left and right terminals are the source and drain and the center is the gate.

Figure 1: N-channel MOFSET

Cross-section view

Top view

Signals enter and exit through the metal wires on the top layer (blue, seen head-on in this view), and are connected to the actual transistor by vertical connections, or vias (black). The actual transistor consists of portions of a silicon wafer which have been “doped” with various materials to have either a surplus (N-type, green) or lack (P-type, yellow) of free electrons in the outer shell. Both the source and drain have the same type of doping and the channel between them has the opposite type. The gate terminal, made of poly (red) is placed in close proximity to the channel, separated by a thin layer of an insulator, usually silicon dioxide (usually abbreviated simply as “oxide,” not shown in this drawing).

When the gate is held at a low voltage relative to the bulk silicon (typically circuit ground), the free electrons near the channel in the source and drain migrate to the channel and fill in the empty spots in the outer electron shells, forming a highly non-conductive “depletion region.” This results in the source and drain becoming electrically isolated from each other. The transistor is off.

When the gate is raised to a high voltage (typically 0.8 to 3.3 volts for modern ICs), the positive field pulls additional electrons up into the channel, resulting in an excess of charge carriers and a conductive channel. The transistor is on.

Meanwhile, the P-channel MOSFET, shown below, has almost the same structure but with everything mirrored. The source and drain are P-doped, the channel is N-doped, and the transistor turns on when the gate is at a negativevoltage relative to the bulk silicon (typically the positive power rail).

Figure 2: P-channel MOFSET

Cross-section view

Top view

Several schematic symbols are commonly used for MOSFETs. We’ll use the CMOS-style symbols (with an inverter bubble on the gate to denote a P-channel device and no distinction between source and drain). This reflects the common use of these transistors for digital logic: an NMOS (at left below) turns on when the gate is high and a PMOS (at right below) when the gate is low. Although there are often subtle differences between source and drain in the manufacturing process, we as reverse engineers don’t care about the details of the physics or manufacturing. We just want to know what the circuit does.

Figure 3: Schematic symbols

NMOS PMOS

So, in order to reverse engineer a CMOS layout to schematic, all we need is a couple of photographs showing the connections between transistors… right? Not so fast. We must be able to tell PMOS from NMOS without the benefit of color coding.

As seen in the actual electron microscope photo below (a single 2-input gate from a Xilinx XC2C32A, 180nm technology), there’s no obvious difference in appearance.

Figure 4: Electron microscope view of a single 2-input gate

We can see four transistors (two at the top and two at the bottom) driven by two inputs (the vertical poly gates). The source and drain vias are clearly visible as bright white dots; the connections to the gates were removed by etching off the upper levels of the chip but we can still see the rounded “humps” on the poly where they were located. The lack of a via at the bottom center suggests that the lower two transistors are connected in series, while the upper ones are most likely connected in parallel since the middle terminal is broken out.

There are a couple of ways we can figure out which is which. Since N-channel devices typically connect the source to circuit ground and P-channel usually connect the source to power, we can follow the wiring out to the power/ground pins and figure things out that way. But what if you’re thrown into the middle of a massive device and don’t want to go all the way to the pins? Physics to the rescue!

As it turns out, P-channel devices are less efficient than N-channel – in other words, given two otherwise identical transistors made on the same process, the P-channel device will only conduct current about 30-50% as well as the N-channel device. This is a problem for circuit designers since it means that pulling an output signal high takes 2-3 times as long as pulling it low! In order to compensate for this effect, they will usually make the P-channel device about twice as wide, effectively connecting two identical transistors in parallel to provide double the drive current.

This leads to a natural rule of thumb for the reverse engineer. Except in unusual cases (some I/O buffers, specialized analog circuitry, etc.) it is typically desirable to have equal pull-up and pull-down force on a signal. As a result, we can conclude with fairly high certainty that if some transistors in a given gate are double the width of others, the wider ones are P-channel and the narrower are N-channel. In the case of the gate shown above, this would mean that at the top we have two N-channel transistors in parallel and at the bottom two P-channel in series.

Since this gate was taken from the middle of a standard-cell CMOS logic array and looks like a simple 2-input function, it’s reasonable to guess that the sources are tied to power and drains are tied to the circuit output. Assuming this is the case, we can sketch the following circuit.

Figure 5: CMOS 2-input circuit

This is a textbook example of a CMOS 2-input NOR gate. When either A or B is high, either Q2 or Q4 will turn on, pulling C low. When both A and B are low, both Q1 and Q3 will turn on, pulling C high.

Stay tuned for the next post in this series!

RESEARCH | February 17, 2016

Remotely Disabling a Wireless Burglar Alarm

By Andrew Zonenberg

Countless movies feature hackers remotely turning off security systems in order to infiltrate buildings without being noticed. But how realistic are these depictions? Time to find out.

Today we’re releasing information on a critical security vulnerability in a wireless home security system from SimpliSafe. This system consists of two core components, a keypad and a base station. These may be combined with a wide array of sensors ranging from smoke detectors to magnet switches to motion detectors to create a complete home security system. The system is marketed as a cost-effective and DIY-friendly alternative to wired systems that require expensive professional installation and long term monitoring service contracts.

Looking at the FCC documentation for the system provides a few hints. It appears the keypad and sensors transmit data to the base station using on-off keying in the 433 MHz ISM band. The base station replies using the same modulation at 315 MHz.

After dismantling a few devices and looking at which radio(s) were installed on the boards, I confirmed the system is built around a star topology: sensors report to the base station, which maintains all system state data. The keypad receives notifications of events from the base station and drives the LCD and buzzer as needed; it then sends commands back to the base station. Sensors only have transmitters and therefore cannot receive messages.

Rather than waste time setting up an SDR or building custom hardware to mess with the radio protocol, I decided to “cheat” and use the conveniently placed test points found on all of the boards. Among other things, the test points provided easy access to the raw baseband data between the MCU and RF upconverter circuit.

I then worked to reverse engineer the protocol using a logic analyzer. Although I still haven’t figured out a few bits at the application layer, the link-layer framing was pretty straightforward. This revealed something very interesting: when messages were sent multiple times, the contents (except for a few bits that seem to be some kind of sequence number) were the same! This means the messages are either sent in cleartext or using some sort of cipher without nonces or salts.

After a bit more reversing, I was able to find a few bits that reliably distinguished a “PIN entered” packet from any other kind of packet.

I spent quite a while trying to figure out how to convert the captured data bytes back to the actual PIN (in this case 0x55 0x57 -> 2-2-2-2) but was not successful. Luckily for me, I didn’t need that for a replay attack.

To implement the actual attack I simply disconnected the MCUs from the base station and keypad, and soldered wires from the TX and RX basebands to a random microcontroller board I had sitting around the lab. A few hundred lines of C later, I had a device that would passively listen to incoming 433 MHz radio traffic until it saw a SimpliSafe “PIN entered” packet, which it recorded in RAM. It then lit up an LED to indicate that a PIN had been recorded and was ready to play back. I could then press a button at any point and play back the same packet to disarm the targeted alarm system.

This attack is very inexpensive to implement – it requires a one-time investment of about $250 for a commodity microcontroller board, SimpliSafe keypad, and SimpliSafe base station to build the attack device. The attacker can hide the device anywhere within about a hundred feet of the target’s keypad until the alarm is disarmed once and the code recorded. Then the attacker retrieves the device. The code can then be played back at any time to disable the alarm and enable an undetected burglary, or worse.

While I have not tested this, I expect that other SimpliSafe sensors (such as entry sensors) can be spoofed in the same fashion. This could allow an attacker to trigger false/nuisance alarms on demand.

Unfortunately, there is no easy workaround for the issue since the keypad happily sends unencrypted PINs out to anyone listening. Normally, the vendor would fix the vulnerability in a new firmware version by adding cryptography to the protocol. However, this is not an option for the affected SimpliSafe products because the microcontrollers in currently shipped hardware are one-time programmable. This means that field upgrades of existing systems are not possible; all existing keypads and base stations will need to be replaced.

IOActive made attempts through multiple channels to contact SimpliSafe upon finding this critical vulnerability, but received no response from the vendor. IOActive also notified CERT of the vulnerability in the normal course of responsible disclosure. The timeline can be found here within the release advisory.

SimpliSafe claims to have its units installed in over 300,000 homes in North America. Consumers of this product need to know the product is inherently insecure and vulnerable to even a low-level attacker. This simple vulnerability is particularly alarming because; 1) it exists within a “security product” that is trusted to secure over a million homes; 2) it enables an attacker to completely own the system (i.e., disable it, change PIN codes, etc.), and; 3) many unsuspecting consumers prominently display window and yards signs promoting their use of this system…essentially self-identifying their home as a viable target for an attacker.

ADVISORIES |

SimpliSafe Alarm System Replay Attack

By Andrew Zonenberg

The radio interface for the SimpliSafe home burglar/fire alarm systems is not encrypted and does not use “rolling codes,” nonces, two-way handshakes, or other techniques to prevent transmissions from being recorded and reused. An attacker who is able to intercept the radio signals between the keypad and base station can record and re-play the signal in order to turn off the alarm at a time of his choice in the future. (more…)

penetration testing

RESEARCH | February 3, 2016

Brain Waves Technologies: Security in Mind? I Don’t Think So

By Alejandro Hernandez

INTRODUCTION

Just a decade ago, electroencephalography (EEG) was limited to the inner rooms of hospitals, purely for medical purposes. Nowadays, relatively cheap consumer devices capable of measuring brain wave activity are in the hands of curious kids, researchers, artists, creators, and hackers. A few of the applications of this technology include:

· EEG-controlled Exoskeleton Hope for ALS Sufferers

· Brain-controlled Drone

· Brain Waves Used as a Biometric Authentication Mechanism

· Translating Soldier Thoughts to Computer Commands (Military)

· Detect Battlefield Threats via Brain Waves (Military)

· Car Operated by Brain Waves

· First Human Brain-to-brain Interface (using EEG and TMS)

· Music Created with Brain Waves

· Neurowear (Clothing)

I’ve been monitoring the news for the last year, searching keywords brain waves, and the volume of headlines is growing quickly. In other words, people out there are having fun with brain waves and are creating cool stuff using existing consumer devices and (mostly) insecure software.

Based on my observations using a cheap EEG device and known software, I think that many of these technologies might contain security flaws that make them vulnerable to Man-in-The-Middle (MiTM), replay, Denial-of-Service (DoS), and other attacks.

RESEARCH BACKGROUND

A few months ago, I demonstrated some of the risks associated with the acquisition, transmission, and processing of EEGs at the Bio Hacking Village at DEF CON 23 (slide deck) and BruCON. I consider this pioneering research a wakeup call for vendors and developers. I see this technology in a similar position as industrial systems. Ten years ago, only a few people were talking about SCADA/Industrial Control System (ICS) security; today it’s a whole sub-industry. Even so, programmable logical controllers are still crashing due to basic malformed packets, and other ICS critical systems are vulnerable to replay attacks due to a lack of authentication and encryption. A similar scenario is playing out with brain wave/EEG technology.

It’s important to mention that some technologies such as Neuromore and NeuroElectrics’ NUBE can be used to upload your EEG activity to the cloud. I do not address this in depth, other than to note that privacy is an important concern. Is your brain activity being sent to the cloud securely? Once in the cloud, is it being stored securely? Place your bets.

In the following sections, I explain some of the security concerns I observed while playing with my own brain activity using a Neurosky Mindwave device and a variety of EEG software. Because I only present a few examples here, I encourage you to take a look to my full DEF CON slide deckfor more examples.

I should note that real attack scenarios are a bit hard for me to achieve, since I lack specific expertise in interpreting EEG data; however, I believe I effectively demonstrate that such attacks are 100 percent feasible.

DESIGN

Through Internet research, I reviewed several technical manuals, specifications, and brochures for EEG devices and software. I searched the documents for the keywords ‘secur‘, ‘crypt‘, ‘auth‘, and ‘passw‘; 90 percent didn’t contain one such reference. It’s pretty obvious that security has not been considered at all.

NO ENCRYPTION / NO AUTHENTICATION

The major risk associated with not using encryption or authentication is that an unauthorized person could read or impersonate someone’s brain waves through replay attacks or data tampering via MiTM attacks. The resulting level of risk depends on how the EEG data is used.

Let’s consider a MiTM attack scenario where an attacker modifies data on the fly during transmission, after data acquisition but before the brain waves reach the final destination for processing. NeuroServeris an EEG signal transceiver that uses TCP/IP and EDF format. Although the NeuroServer technology is old and unmaintained, it is still in use (mostly for research) and is included in BrainBay an open-source bio and neurofeedback application.

I recorded the whole MITM attack (full screen is recommended):

For this demonstration, I changed only an ASCII string (the patient name); however, the actual EEG data can be easily manipulated in binary format.

RESILIENCE

Resilience is the ability to support or recover from adversity, in this case, DoS attacks.

Brain waves are data. Data needs to be structured and parsed, and parsers have bugs. Following is a malformed EDF header I created to remotely crash NeuroServer:

I recorded the execution of this remote DoS proof of concept code against NeuroServer:

I couldn’t believe that 1990s techniques are still killing 21^st century technology. I used an infinite loop to create as many network sockets as possible and keep them open.

The following two videos show applications crashing as a result of this old technique:

– Neuroelectrics NIC TCP Server Remote DoS

– OpenViBE (software for Brain Computer Interfaces and Real Time Neurosciences) Acquisition Server Remote DoS

THE “TOWER OF BABEL” OF EEG FILE FORMATS

From its conception, EEG vendors created their own file formats. As a result, it was very difficult to share patients’ brain waves between hospitals and physicians. Years later, in 1992, the EDF format was defined and adopted by many vendors. It’s worth mentioning that EDF and its improved version EDF+ (2003), are now old. There are more recent file format specifications and implementations in EEG software; in other words, it’s a new playing field.

I spent some time inspecting brochures, manuals, and technical specifications in order to identify the most commonly used file formats. The following table shows that the most common formats are proprietary and EDF(+):

Physicians use client-side software to open files containing EEG data. The security problems associated with these applications are similar to those found in any software that has been developed insecurely. In the end, parsing EEG data is just like parsing any other file format, and parsing involves security risks.

I performed trivial file format fuzzing on some EDF samples containing brain waves in order to identify general software flaws, not only security flaws. Most applications crashed within a few seconds from this malformed data, and most crashes were caused by invalid memory dereferences and other conditions that may be security bugs.

For instance, I was able to force an abnormal termination in Persyst Advanced Review (Insight II ), commercial software that opens “virtually all commercial EEG formats,” according to its website.

In the following video, I demonstrate other bugs I found in Natus Stellate Harmonie Viewer, BrainBay, and SigViewer (which uses the BioSig open-source software library):

I think that bugs in client-side applications are less relevant. The attack surface is reduced because this software is only being used by specialized people. I don’t imagine any exploit code in the future for EEG software, but attackers often launch surprising attacks, so it should still be secure.

MISC

When brain waves are communicated over the air via Bluetooth or WiFi, what about jamming? Easy to answer.

What about SHODAN, the search engine for the Internet of Things? I did some searches and found a few pieces of EEG equipment accessible on the Internet. The risk here is that an attacker could perform automated password cracking to gain unauthorized access through a Remote Desktop. I also noted that some equipment uses the old and unsupported Windows XP operating system. Hospitals, do you really need this equipment connected to the Internet?

STANDARDS

What about regulatory compliance? Well, some efforts have been made to treat EEG data properly. For example, the American Clinical Neurophysiology Society (ACNS) has created some guidelines.

· (2008) Standard for Transferring Digital Neurophysiological Data Between Independent Computer Systems

· (2006) Guideline 8: Guidelines for Recording Clinical EEG on Digital Media. Nevertheless, “magnetic storage and CD-ROMs” is mentioned here.

However, the guidelines are somewhat dated and do not consider the current technologies.

CONCLUSIONS

We need more security “in mind” for brain wave technology. Best practices, including secure design and secure programming, should be followed. I think that regulators should issue security requirements to ensure products treat brain waves in a secure manner.

We also need new standards and guidelines for the secure treatment of brain waves, not only from and for the health care industry, but for a wide range of industries where brain waves are used. To prevent an unauthorized person from reading or impersonating EEG data, vendors should implement authentication mechanisms before EEG data or streams are read or updated. Also, there must be authentication between the acquisition device, the EEG middleware, and the endpoints. Endpoints use decoded brain wave to perform tasks; possible EEG endpoints include a drone, prosthesis, biometric mechanism, and more.

The security of this technology is not keeping pace with the risks. By now, security could be improved by implementing the controls surrounding EEG technology such as SSL tunnels to encrypt brain waves in transit. Perhaps in the future we will have layer 7 bio-signal firewalls, sounds crazy right? But let’s consider that ten years ago nobody imagined an ICS / SCADA firewall / Intrusion Prevention System with Deep Packet Inspection in layer 7 to identify malformed packets while inspecting the network. The future is coming fast.

If you’re a developer, I encourage you to adopt more secure programming practices. If you’re a vendor, you should perform security testing on the medical devices and software you supply.

Finally, if you’re hooked on this topic and planning a trip to Spain, Alfonso Muñoz, a fellow Security Consultant at IOActive, will present “Cryptography with brainwaves for fun and… profit?” on March 3, 2016, at Rooted CON in Madrid.

Also, feel free to check out these explanatory articles, in which my research is mentioned:

· Hackers Can Steal your BRAIN WAVES

· The EEG Headband & Security

Happy brain waves hacking.

– Alejandro

RESEARCH | January 26, 2016

More than a simple game

By Daniel Correa & NullLifeTeam

EKOPARTY Conference 2015, one of the most important conferences in Latin America, took place in Buenos Aires three months ago. IOActive and EKOPARTY hosted the main security competition of about 800 teams which ran for 32 hours, the EKOPARTY CTF (Capture the Flag).

Teams from all around the globe demonstrated their skills in a variety of topics including web application security, reverse engineering, exploiting, and cryptography. It was a wonderful experience.

If you haven’t competed before, you may wonder: What are security competitions all about? Why are they essential for information security?

Competition, types, and resources

A security competition takes place in an environment where the contestants try to find a solution to specific problems through the systematic application of knowledge. Each problem (or challenge) is worth a different number of points. The number of points for each challenge is based on its level of difficulty and the time needed to reach the solution (or flag).

Security competitions help people to develop rare skills as it requires the use of lateral thinking and a low-level technical knowledge of many topics at once, this is a small list of some of their benefits:

Fun while learning.
Legally prepared environments ready to be hacked; you are authorized to test the problems.
Recognition and use of multiples paths to solve a problem.
Understanding of specialized attacks which are not usually detectable or exploitable by common tools.
Free participation, typically.
Good recruiting tool for information security companies.

You will find two types of competitions:

CTFs (Capture the Flag) are restricted by time:
1. Jeopardy: Problems are distributed in multiple categories which must be solved separately. The most common categories are programming, computer and network forensics, cryptography, reverse engineering, exploiting, web application security, and mobile security.
2. Attack – defense: Problems are distributed across vulnerable services which must be protected on the defended machine and exploited on remote machines. It is the kind of competition that provides mostly a vulnerable infrastructure.
Wargames are not restricted by time and may have the two subtypes above.

Two main resources can help you to get started:

Also, you can see solutions for many CTF problems in the following github repository:

CTFs github repository

EKOPARTY CTF 2015

We proposed thirty challenges across six categories:

Trivia problems: questions about EKOPARTY.
Web application security: multiple web application attacks.
Cryptography: classical and modern encryption.
Reversing: problems with the use of different technologies and architectures.
Exploiting: vulnerable binaries with known protections.
Miscellaneous: forensic and programming tasks.

To review the challenges, go to the EKOPARTY 2015 github repository.

Category	Task	Score	Description and references
Trivia	Trivia problems	~	Specific questions related to EKOPARTY
Web	Pass Chek	50	PHP strcmp unsafe comparison using an array Type Juggling
	Custom ACL	100	ACL bypass using external host
	Crazy JSON	300	Esoteric programming language with string encryption JSON esoteric programming language
	Rand DOOM	400	Insecure use of mt_rand, recover administrator token via seed leak PRNG seed leak PHP mt_rand seed cracker
	SVG Viewer	500	XXE injection with UTF-16 bypass and use of PHP strip_tags vulnerability to disclose source code XXE injection UTF-16 bypass PHP strip_tags bug
Crypto	SCYTCRYPTO	50	Scytale message decryption Scytale
	Weird Vigenere	100	Kasiski analysis over modified vigenere Beaufort cipher
	XOR Crypter	200	XOR shift message decryption Reversing shift XOR operation
	VBOX DIE	300	VBOX encrypted disk password recovery VirtualBox Disk Image Encryption password cracking
	Break the key	400	Use of CVE-2008-0166 to get the plaintext from an encrypted message CVE-2008-0166
Reversing	Patch me	50	MSIL code patching
	Counter	100	Dynamic analysis of a llvm obfuscated binary
	Malware	200	Break RSA key to send malicious code to the C&C server
	Dreaming	300	SH4 binary
	HOT	400	Blackberry Z10 application and exploitation of a SQL injection which was protected through a modified HMAC algorithm
	Backdoor OS	500	Custom kernel where you need to find the backdoor authentication key
Exploiting	Baby pwn	50	Buffer overflow with restricted input format
	Frequency	100	BSS buffer overflow with a directory traversal which leaks data from files through character frequencies
	OTaaS	200	ARM syscall override which leaks information if appropriate parameters are passed
	File Manager	300	Stack based buffer overflow produced by strncat while listing files inside a folder, need to bypass multiple protections such as ASLR, NX, PIE, and FULL RELRO
Miscellaneous	Olive	50	VNC client key event recovery VNC KeyEvent
	Press it	100	Scancodes recognition Key Scan Codes
	Onion	200	Use of CVE-2015-7665 to leak user’s IP CVE-2015-7665
	Poltergeist	300	AM frequencies generator using screen waves Tempest

Example of reversing problem – HOT 400 points

We provided competitors with a BlackBerry 10 binary with the following description:

Our Blackberry application can accurately show you the weather status of the city! may you be able to get something more?

The binary uses a SOAP-based web service to retrieve weather information from the selected city (either Buenos Aires or Mordor), so we need to reverse the binary and find out if we are able to retrieve more information.

First, let see how the binary is composed:

Great, the binary is not stripped and it seems to contain debug information, so we can use an ARM disassembler and see its behavior:

The main execution flow starts within the requestWeatherInformation method from WeatherService class, and city zipcode is its unique argument. It is converted from QString to QByteArray for further processing:

QByteArray key is filled with a loop, key[i] = i:

Then a message authentication code is calculated using the key and zipcode MAC(key, zipcode):

The binary is using a slightly modified version of HMAC-SHA1 as a message authentication code, and outer and inner padding are now 0x13 and 0x37 respectively (instead of 0x5c and 0x36):

Then a SOAP message is built using the following data:
- Host: ctfchallenges.ctf.site
- Port: 10000
- Action: http://ctfchallenges.ctf.site:1000/ekoweather/GetCityWeatherByZIP (no longer active)
- Argument 1: ZIP
- Argument 2: verification

You can see an HTTP request with a valid SOAP message for the web service:

And its response:

Now let’s take a look at the web service source code (which was not available to the contestant):

You can notice two important things:

Zip argument is vulnerable to SQL injection.
Description is always trimmed to 16 chars.

The contestant need to be able to reverse engineer the binary and then inject SQL sentences to retrieve information from the database using valid verification codes within the SOAP message.

The answer for this problem is stored as the description for the city FLAG, however it exceeds 16 chars, so the web service only shows the first 16 chars (an incomplete answer):

Request:

ZIP: -1 or 1=1– –
verification: biNa0y7ngymXd6kbGMmNhOYiNQM=

Response:

Success: true
ResponseText: City Found
Description: EKO{r3v_with_web

After getting the correct number of columns and the tables and columns used by the database, you need to identify the column used as the description:

Request:

ZIP: -1 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14– –
verification: B2LDiOPSSCOCK0tJvidyyo1d1HI=

Response:

Success: true
ResponseText: City Found
Description: 7

At last, an injection to get the other half of the flag could be as follows:

Request:

ZIP: -1 union select 1,2,3,4,5,6,substr(description,16),8,9,10,11,12,13,14 from data where zipcode != 1010 and zipcode != 1337– –
verification: r7WuMbNcbvncnJc8HwKnqM4q9kA=

Response:

Success: true
ResponseText: City Found
Description: b_is_the_best!}

The final answer for this problem was: EKO{r3v_with_web_is_the_best!}. It was solved by one team. Amazing job, More Smoked Leet Chicken team!

Some numbers

From the summary below of solves and failed attempts per each problem, we can infer three things:

Trivia challenges often involves guessing; failed attempts are higher on trivia problems.
The most difficult problems contain fewer failed attempts, and the number of solves are somehow proportional to failed attempts.
In this CTF, reversing and exploiting were the most difficult problems.

We also have some results from the competition:

Scoreboard

After 32 hard hours, we had the winners:

More Smoked Leet Chicken, from Russia, who led during the competition!
!SpamAndHex, from Hungary.
samurai, from United States.
Shellphish, from United States.
SecuritySignal, local winner from Argentina.

As you have seen, CTFs are more than a simple game. From the point of view of the organizer, they involve a lot of planning and monitoring, and from the point of view of the contestant they involve a lot of applied knowledge and fun. CTFs are getting harder and harder. Do not miss the chance to learn from them!

We hope you have enjoyed this and we hope to see you next year at EKOPARTY CTF 2016!

RESEARCH | January 6, 2016

Drupal – Insecure Update Process

By Fernando Arnaboldi

Just a few days after installing Drupal v7.39, I noticed there was a security update available: Drupal v7.41. This new version fixes an open redirect in the Drupal core. In spite of my Drupal update process checking for updates, according to my local instance, everything was up to date:

Issue #1: Whenever the Drupal update process fails, Drupal states that everything is up to date instead of giving a warning.

The issue was due to some sort of network problem. Apparently, in Drupal 6 there was a warning message in place, but this is not present in Drupal 7 or Drupal 8.

Nevertheless, if the scheduled update process fails, it is always possible to check for the latest updates by using the link that says “Check Manually“. This link is valuable for an attacker because it can be used to perform a cross-site request forgery (CSRF) attack to force the admin to check for updates whenever they decide:

http://yoursite/?q=admin/reports/updates/check

Since there is a CSRF vulnerability in the “Check manually” functionality (Drupal 8 is the only one not affected), this could also be used as a server-side request forgery (SSRF) attack against drupal.org. Administrators may unwillingly be forcing their servers to request unlimited amounts of information from updates.drupal.org to consume network bandwidth.

Issue #2: An attacker may force an admin to check for updates due to a CSRF vulnerability on the update functionality

An attacker may care about updates because they are sent unencrypted, as the following Wireshark screenshot shows:

To exploit unencrypted updates, an attacker must be suitably positioned to eavesdrop on the victim’s network traffic. This scenario typically occurs when a client communicates with the server over an insecure connection, such as public WiFi, or a corporate or home network that is shared with a compromised computer.

The update process downloads a plaintext version of an XML file at http://updates.drupal.org/release-history/drupal/7.x and checks to see if it is the latest version. This XML document can point to a backdoored version of Drupal.

The current security update (named on purpose “7.41 Backdoored“)
The security update is required and a download link button
The URL of the malicious update that will be downloaded

However, updating Drupal is a manual process. Another possible attack vector is to offer a backdoored version of any of the modules installed on Drupal. In the following example, a fake “Additional Help Hint” update is offered to the user:

Offering fake updates is a simple process. Once requests are being intercepted, a fake update response can be constructed for any module. When administrators click on the “Download these updates” buttons, they will start the update process.

This is how it looks from an attacker’s perspective before and after upgrading the “Additional Help Hint” module. First it checks for the latest version, and then it downloads the latest (malicious) version available.

As part of the update, I included a reverse shell from pentestmonkey (http://pentestmonkey.net/tools/web-shells/php-reverse-shell) that will connect back to me, let me interact with the Linux shell, and finally, allow me to retrieve the Drupal database password:

Issue #3: Drupal security updates are transferred unencrypted without checking the authenticity, which could lead to code execution and database access.

You may have heard about such things in the past. Kurt Seifried from Linux Magazine wrote an article entitled “Insecure updatesare the rule, not the exception” that mentioned that Drupal (among others) were not checking the authenticity of the software being downloaded. Moreover, Drupal itself has had an open discussion about this issue since April 2012 (https://www.drupal.org/node/1538118). This discussion was reopened after I reported the previous vulnerabilities to the Drupal Security Team on the 11^th of November 2015.

You probably want to manually download updates for Drupal and their add-ons. At the moment of publishing there are no fixes available.

TL;DR – It is possible to achieve code execution and obtain the database credentials when performing a man-in-the-middle attack against the Drupal update process. All Drupal versions are affected.