Archive for May, 2016

This post is copied from:

As the site is down right now, i just thought it should be replicated at another source.


Reverse shell on a Node.js application

How we obtained a Javascript reverse shell by exploiting a vulnerability on a Node.js application during a security assessment.


We were tasked by a small web developer team to perform a security assessment of their mobile app backend which is a REST API.

The architecture is rather simple there is only three Linux servers.

  • Node.js
  • MongoDB
  • Redis

First we performed a few arbitrary tests without access to the source code and we discovered that a few unexpected input at some endpoints would crash the backend application.
We also noticed that the redis server was accessible from the WAN without authentication.

Our next step was to review the Node.js API code and understand the crashes.

Simplified vulnerable application

We created this small Node.js application with the vulnerable function if you want to try to exploit it yourself.
This Node.js web server will wait for a query such as http://target.tld//?name=do* and search for animal names matching that query.

The vulnerability

After a few minutes of analyzing the buggy endpoints in the code we noticed a bad practice issue that could lead to remote code execution.
The stringToRegexp function is evaluating user input to create a RegExp object and use it to find elements in an array.

We can insert our own Javascript code in the output variable and execute it.
The stringToRegexp function will escape some characters and the output value will be evaluated.

Visiting the address below will print a message on the server terminal.

From there it would be nice to execute code to have an interactive shell such as /bin/sh.

The Node.js reverse shell

The Javascript code below is a Node.js reverse shell.
The payload will spawn a /bin/sh shell, create a TCP connection to the attacker and attach the shell standard streams to it.

To execute the payload gracefully we used a little trick, we encoded our reverse shell payload to hexadecimal and used the Node.js Buffer object to decode it.
http://target.tld/?name=["./;eval(new Buffer('PAYLOAD', 'hex').toString());//*"]


It’s highly recommended to avoid using the eval function in a Javascript project.
The fix was rather simple, they started using using the RegExp object directly.


I realize that much of this is common knowledge on XDA. Still, every day I see people post about how their phone “loses” 10% as soon as it comes off the charger. I also have friends who can’t understand why their battery drains so quickly. Trying to explain this to people without hard numbers is often met with doubt, so I figured that I’d actually plot it out with real data.

So it’s not a piece that is optimized for this audience, but I hope that you find it interesting.


Your Smartphone is Lying to You
(and it’s not such a bad thing)

Climbing out of bed, about to start your day, you unplug your new smartphone from its wall charger and quickly check your email. You’ve left it plugged in overnight, and the battery gauge shows 100%. After a quick shower, you remember that you forgot to send your client a file last night. You pick up your phone again, but the battery gauge now reads 90%. A 10% drop in 10 minutes? The phone must be defective, right?

A common complaint about today’s smartphones is their short battery life compared to older cell phones. Years ago, if you accidentally left your charger at home, your phone could still make it through a weeklong vacation with life to spare (I did it more than once). With the newest phones on the market, you might be lucky enough to make it through a weekend.

And why should we expect anything else? Phones used to have a very short list of features: make and receive phone calls. Today we use them for email, web surfing, GPS navigation, photos, video, games, and a host of other tasks. They used to sport tiny displays, while we now have giant touch screens with bright and vibrant colors. All of these features come at a cost: large energy requirements.

Interestingly enough, improvements in battery management technology have compounded the average user’s perception of this problem. Older phones were rather inelegant in their charging behavior; usually filling the battery to capacity and then switching to a trickle current to maintain the highest charge possible. This offered the highest usage time in the short-term, but was damaging the battery over the course of ownership. As explained at Battery University, “The time at which the battery stays at [maximum charge] should be as short as possible. Prolonged high voltage promotes corrosion, especially at elevated temperatures.”[1]

This is why many new phones will “lose” up to 10% within a few minutes of coming off the charger. The reality is that the battery was only at 100% capacity for a brief moment, after which the battery management system allowed it to slowly dip down to around 90%. Leaving the phone plugged in overnight does not make a difference: the phone only uses the wall current to maintain a partial charge state.

To monitor this, I installed CurrentWidget on my HTC ADR6300 (Droid Incredible), an app that can log how much electric current is being drawn from the battery or received from the charger. Setting it to record log entries every 10 seconds, I have collected a few days worth of data. While many variables are involved (phone hardware, ROM, kernel, etc) and no two devices will perform exactly the same, the trends that I will describe are becoming more common in new phones. This is not just isolated to a single platform or a single manufacturer.

Chart 1 shows system reported battery levels over the course of one night, with the phone plugged in to a charger. Notice that as the battery level approaches 100%, the charging current gradually decreases. After a full charge is reached, wall current is cut completely, with the phone switching back to the battery for all of its power. It isn’t until about two hours later that you can see the phone starts receiving wall current again, and even then it is only in brief bursts.

The steep drop in reported battery seen past the 6.5 hour mark shows the phone being unplugged. While the current draw does increase at this point (since the phone is being used), it still cannot account for the reported 6% depletion in 3 minutes. It should also be obvious that maintaining a 100% charge state is impossible given the long spans in which the phone is only operating on battery power.

Using the data from CurrentWidget, however, it is quite easy to project the actual battery state. Starting with the assumption that the first battery percentage reading is accurate, each subsequent point is calculated based on mA draw and time. Chart 2 includes this projection.

Now we can see that the 6% drop after unplugging is simply the battery gauge catching up with reality.

The phone manufacturers essentially have three choices:
1. Use older charging styles which actually maintain a full battery, thereby decreasing its eventual life
2. Use new charging methods and have an accurate battery gauge
3. Use new charging methods and have the inaccurate battery gauge

Option one has clearly fallen out of favor as it prematurely wears devices. Option two, while being honest, would most likely be met with many complaints. After all, how many people want to see their phone draining down to 90% while it is still plugged in? Option three therefore offers an odd compromise. Maybe phone companies think that users will be less likely to worry about a quick drop off the charger than they will worry about a “defective” charger that doesn’t keep their phone at 100% while plugged in.

Bump It. Or Should You?

One technique that has gained popularity in the user community is “bump charging.” To bump charge a device, turn it off completely, and plug it into a charger. Wait until the indicator light shows a full charge (on the ADR6300, for example, the charging LED changes from amber to green) but do not yet turn the device back on. Instead, disconnect and immediately reconnect the power cord. The device will now accept more charge before saying it is full. This disconnect/reconnect process can be repeated multiple times, each time squeezing just a little bit more into the battery. Does it work?

The following chart plots battery depletion after the device has received a hefty bump charge (6 cycles) and then turned on to use battery power. Note that the system does not show the battery dropping from 100% until well over an hour of unplugged use, at which point it starts to steadily decline. Again, however, it should be obvious that the battery gauge is not syncing up with reality. How could the rate of depletion be increasing over the first 5 hours while the rate of current draw is relatively steady? And why does the projected battery line separate from the reported levels, but then exactly mirror the later rises and falls?

The answer, of course, is that bump charging definitely works. Rather than anchoring our projected values to the first data point of 100%, what happens if we anchor against a later point in the plot?

Aligning the data suggests that a heavy bump charge increases initial capacity by approximately 15%. Note that the only other time that the lines separate in this graph was once again when the phone was put on the charger and topped up to 100%. Just as with the first set of graphs, the phone kept reporting 100% until it was unplugged, dropped rapidly, and again caught up with our projections.

So what does it all mean?

If you absolutely need the highest capacity on a device like this, you will need to bump charge. There are currently people experimenting with “fixes” for this, but I have yet to see one that works. Be warned, however, that repeated bump charging will wear your battery faster and begin to reduce its capacity. If you are a “power user” who will buy a new battery a few months from now anyway, this presumably isn’t a concern. If you are an average consumer who uses a device for a few years, I would recommend that you stay away from bump charging. The bottom line is that you don’t really “need” to do it unless you are actually depleting your battery to 0% on a regular basis.

If you are someone who can top off your phone on a regular basis, do it. Plug it in when you’re at home. Plug it in when you’re at your desk. As explained by Battery University, “Several partial discharges with frequent recharges are better for lithium-ion than one deep one. Recharging a partially charged lithium-ion does not cause harm because there is no memory.”[2]

Beyond that, the best advice I can offer is to stop paying such close attention to your battery gauge and to just use your phone. Charge it whenever you can, and then stop obsessing over the exact numbers. If you really need more usage time, buy an extended-capacity battery and use it normally.