Playing around with ShellShock...

I like so many others have been messing around with the shellshock issue now for a few days. Having seen some very creative ways of attempting to exploit this issue, I decided to look at a few things beyond the modcgi stuff, which you would typically find in appliance type servers, where sane developers don't use modcgi.

In my own testing of an unnamed appliance, I came across something rather interesting.

Consider the following using expect:

spawn scp -P $portnum -o NumberOfPasswordPrompts=1 $localfile $remotefile

This seems innocuous at first, given the nature of tcl and scp, after all we have some kind of credential here right?

Now consider that the source of $remotefile is from a web app, with a non privileged user, who doesn't actually have access to the password/keyfile on the target location.

You can see where this is going I'm sure, in attempting to exploit the source of $remote in this case, I found that using scp in that fashion, led to the exploit firing off on the target of the scp upload, via input from a unprivileged user, where I was able secure myself root login credentials via ssh without issue.

This kind of use of expect is most commonly used to handle remote storage of things like backups and the like in appliance type servers, that have some type of web interface. If you are unfamiliar with expect have a look. The nuts and bolts of it, is that it automates things that are normally interactive with tcl scripting.

This is just another example of just how bad this bug actually is, it creates holes that were otherwise not even there, and don't get me started on the shell command being passed on to the next server, which is not how that syntax should work at all with scp (who's bright idea was that, bug?).

Sanitize your inputs if you're developing web applications of any kind, I can't stress it enough...

Random social engineering attempts.


So let's talk about personal computer security for a few. People seem to not take it very seriously for some reason. Let's start with a story.

I coworker of mine, we'll call him Mr. Smith, answered a call on his home phone ( yeah I know who has a home phone these days ). The person on the other end claimed to be a representative from Microsoft. The caller asked if this was Mr. Smith and proceeded to tell Mr. Smith that his computer has been sending errors to Microsoft.

He proceeded to tell Mr. Smith he could show him what he was talking about, and instructed him on how to pull up his event viewer so he could see the errors, which Mr. Smith did confirming the callers intent. The caller told Mr. Smith that they could fix these errors by proceeding to delete a few files and make some other miscellaneous changes.

At this point the caller asked "Are you the owner of the machine?" To which Mr. Smith responded "No, it actually belongs to my employer Tech Inc. I'm not allowed to make any changes, but I can get you in touch with our IT security and I'm sure they would be more than happy to work with you on this issue."

Jolted by the response the caller stated "No No You're the administrator on this machine you can make the changes required to fix the issues" To which Mr. Smith responded "I'm afraid I can't, there are strict policies that I have to comply with, let me get your information and I'll have IT security get in touch with you." At this point the call ended rather abruptly.

Little did the caller know, Mr. Smith only had one Windows machine in the house, which was a corporate machine, the rest of the machines in his house are actually personal Macs. Mr. Smith is a avid Mac user, so there was little credence to the call, particularly on a personal land line.

Mr. Smith promptly gave me a call to regale this story to me and ask if he had done the right thing. He seem startled by the fact that they knew his name, and also knew there were errors in the even viewer. I explained to him that they figured out his name because it's listed ( I check on that ) and it's a given that there will be errors in event viewer on any windows machine, which is more that enough to make it seem to a technical laymen that they were legit.

He followed a good practice, as we had just prior in the week discussed the need to get more people trained on social engineering and that talk was fresh in his memory. I told him that he should loop ITSec in just to be safe, now that they know he's a corporate target, however unlikely it is that he divulged anything that would allow the attackers access.

This is a fine example of just how prevalent and easy social engineering is. Your organization can have all the right encryption solutions, the best two factor authentication money can buy, and it all is at the mercy of the end point users wise or unwise behavior.

Given the recent rise in attacks on corporate assets, companies should be investing in getting their users trained properly on how to repel social engineering assaults. This example shows that it doesn't necessarily even have to happen when the end point user is on the clock.

Tips:


  • OS vendors will not call you regarding errors on your machine. You're going to have to call them if you need assistance. The example case explained that they were calling a random sampling of consumers exhibiting the errors, which is simply not the case. I've never herd of a corporation that has this practice.

  • Just because they know your name or something specific about you doesn't make them legitimate. These days, given social media, and the readily available nature of information, it's not particularly hard to divine some simple details. Example: Geotag data in conjunction with a picture posted to facebook can give an attacker your home address. It's very common to dig up some details on a target before getting on the phone with them, so that as an attacker you seem more legitimate. "Is your address still 555 Washington Ave?" goes a long way towards making the caller seem legitimate.

  • Get a callback number. You can set the difficulty higher for them simply by saying, let me call you back. If they are willing to divulge that info it will be much easier to track them down, if not, it's obvious they are not as altruistic as they make themselves out to be.

  • Answer questions with questions. There are social engineering workflow applications these days, that tell the attackers exactly what to do next following a script of sorts. Most of these workflows don't include answers to out of context questions. Most of these attackers will give up once they figure out that the scope of the call falls outside their script. With any luck you will have put yourself on a list of users to difficult to actually get anywhere with and they wont bother you anymore. Social engineering is based on simplicity, once it gets difficult, attackers move on, though this doesn't really apply if you aren't a target of opportunity but rather a specific target.

  • Don't divulge any relevant information. This probably goes without saying, however even tipping them off to where your work, might make you a more interesting target ( such as the example provided ). The more you give them the more likely it might be they can use that information to better engineer you next time they call. Perhaps next time they will pretend to be Tech Inc's ITSec ( which goes back to the earlier tips, call back number and lots of questions ). Sure a return call means they might have to get more creative, but you probably haven't heard the last of them if the access you have is valuable enough.

Social Engineering workflow app: https://github.com/OpenSecurityResearch/fsflow/releases/

Moving to jekyll as my blog platform.

Testing the new blog thingy. Moving on to testing different types of editors for something I like. There is no shortage of markdown editors around at the moment on OSX.

At first I was going to just use Sublime Text, as it's really my editor of choice at the moment. But oddly enough it doesn't feel right for proper blog posting. I can't really explain why sadly, but I decided to give ByWord a run and see how it goes.

I like the simplicity of Jekyll, with the ease of republishing the content, and the extensibility. I see why they call it blogging like a hacker, it so easy to be distraction free this way.