Critical Flaw Found In Backtrack Linux

chicksdaddy writes "Threatpost is reporting on a critical security flaw in the latest version of Backtrack Linux, a popular distribution that is used by security professionals for penetration testing. The previously undiscovered privilege escalation hole was discovered by a student taking part in an InfoSec Institute Ethical Hacking class, according to the post on the group's Web site. 'The student in our ethical hacking class that found the 0day was using backtrack and decided to fuzz the program, as well as look through the source code,' wrote Jack Koziol, the Security Program Manager at the InfoSec Institute. 'He found that he could overwrite config settings and gain a root shell.' An unofficial patch is available from InfoSec Institute. Koziol said that an official patch is being tested now and is expected shortly."

Comments

Yo Dawg!

[ColdWetDog]

I heard you like pen testing so I put a pen test on your pen test!

Re:Yo Dawg!

[nasalicio]

In Soviet Russia, pen tests pen test you!

Re:Yo Dawg!

[Anonymous Coward]

Who will hack the hackers?

Re:Yo Dawg!

[Anonymous Coward]

... so you can penetrate while you penetrate!

Re:Yo Dawg!

[mcgrew]

When the Raspberry Pi comes out we can have a pen test in a teacup.

The preacher said "Repentest!" so his IT guy ran the test again.

(These jokes are like Metro -- not much good but brand new)

D'oh

[OzPeter]

That's what I clearly heard the admin of the threatpost's web server just exclaim.

From what I heard

[antonymous]

The program in question is wicd, which is a wireless network manager. And it's not like BT is a particularly secure distro - it's for pentesting, so most of it's functionality is only useful if you run as root...

Re:From what I heard

[Taco Cowboy]

Many other distros also carry wicd

Are other distros also affected?

Re:From what I heard

[Anonymous Coward]

install & use network manager instead of wicd :3

Re:From what I heard

[228e2]

True.

And as a pen tester, I've yet to use this on an online network. 100% non-issue for me.

Re:From what I heard

[allo]

wicd is network-manager without the sucking parts.

Re:From what I heard

[Architect_sasyr]

Any good pentester maintains good physical security (because, you know, you carry your laptop with you at all times), firewalls their own machine, and maintains a fairly decent log of what is crossing their interfaces anyway.

Unfortunately most of the people (I'd go as far as 95-99%) on the backtrack forums are neither pentesters nor good. They use wicd because they don't know how to edit a config file or run their own wpa_supplicant. Most of them go as far as trying to use BT for their regular day-to-day stuff. Idiots. But the backtrack team put up with them, so something like this becomes massive news.

I didn't see headlines when the wget vulnerability was in Backtrack 3...

Re:From what I heard

[Vlaix]

As much as I love Wicd, I reckon it has been less reliable than usual for some times on my rig. I might be my wlan drivers, who knows. I went back to Network Manager to get it working, without any joy though. As for BT5 it's not that much of a big deal. It's designed as a tool for penetration, not as an actual set-up && use distro, making it not that much of a liability. It's another thing if the exploitation is really wicd-based.

Usually you run as root

[davidshewitt]

A fair number of the tools on backtrack have to be run as root. If you use the LiveCD or boot it from a flash drive (which is what I usually do), it instructs you to log in as root (with the default password of toor). Unless you were running Backtrack on a server with unpriviledged users, I don't see what the issue is. Just don't open any ports and you'll be fine (and if you're pentesting, why would you - you don't want to be detected).

Re:Usually you run as root

[YrWrstNtmr]

I don't see what the issue is.

The issue is, that one would expect a distro specifically built for security and penetration testing would not have a discoverable security flaw. No matter how obscure.
It might make one wonder what else has been missed?

Re:Usually you run as root

[rgbrenner]

* BackTrack is a Live DVD - when you finish using it, everything is wiped out.
* It's not a server OS
* It's not a desktop OS
* It's an OS for a specific purpose.. you use it for pentesting, and then stop using it.

I don't see what the issue is.

Re:Usually you run as root

[Anonymous Coward]

The issue is, that one would expect a distro specifically built for security and penetration testing would not have a discoverable security flaw. No matter how obscure.
It might make one wonder what else has been missed?

Why would someone have such unrealistic expectations of a complex collection of software packages? Have you somehow managed to develop perfect software with no flaws of any kind?

Re:Usually you run as root

[hobarrera]

Why? They do network penetration testing, not priviledge escalation tests; they're totally unrelated.
No-one expects BT to be safe, it's an "offensive" tool, not one used to secure anything.

Re:Usually you run as root

[davidshewitt]

You mentioned that backtrack is "a distro specifically build for security and penetration testing." I agree that it's built for penetration testing, but it is a bunch of security tools. It is not a hardened operating system. When writing non-trivial software, especially operating systems, there will always be security bugs, and you will always wonder what has been missed. That's why testing is important, and the advantage of open source makes it easier to fix the bugs when they're found.

Reading the TFA (this is ./ I know ;) the vulnerability was in WICD, a daemon used to connect to wifi. I've seen WICD in other linux distros (as a matter of fact you can install it if you don't like network-manager), so those distros are vulnerable as well if they run the affected version. IMHO, I think that the bigger issue is that the other distros are vulnerable, as people running those distros on servers don't want people to get root access, whereas that isn't such a big deal with backtrack (although it's beyond me why anyone would want wifi on a server!).

Re:Usually you run as root

[xvent]

That's crazy; I was just about to burn the iso a few hours ago.

Well I expected it to be safe. I figured since it was for hackers it would be pretty secure. When I want to do online shopping or online banking I boot off a Linux Live cd because I don't trust Windows. And since there are many live distros to choose from why not go with Backtrack, the security focused distro? Silly me thinking it would be a secure live cd.

So anyway, which live cd would be best for online purchases and online banking?

Re:Usually you run as root

[bobbozzo]

AFAICT, this is a local flaw, not one that can be exploited over the internet.

For banking, use something with an up-to-date web browser, otherwise you're still vulnerable to problems in old browsers.

Re:Usually you run as root

[Anonymous Coward]

I don't have the skills but I have the balls. I have so much balls it compensates for my lack of skills.

Re:Usually you run as root

[Anonymous Coward]

ClueOS GetLive Edition.

I wholeheartedly recommend it to you.

Re:Usually you run as root

[detritus.]

You're forgetting that it has the ability to mount local hard disks and write anything to them, gather hardware information, etc.
This is significant because most individuals don't disconnect their hard drives when running it.

Re:Usually you run as root

[Anonymous Coward]

That's not what she said.

Re:Usually you run as root

[hobarrera]

So what's the problem?
Priviledge escalation means that someone with access to the PC can become root. Only you have access to it while running from the liveCD, no-one can you the exploit but you. Specially not over a network.

Re:Usually you run as root

[isCreeper($('Ssss'))]

But that's the same as any LiveDVD. If the attacker has physical access to the computer, there's not much you can do (apart from full-disk encryption, obviously).

Re:Usually you run as root

[eli pabst]

The issue is, that one would expect a distro specifically built for security and penetration testing would not have a discoverable security flaw. No matter how obscure. It might make one wonder what else has been missed?

Do you really think that's a reasonable standard? Even OpenBSD has had security flaws in it.

Re:Usually you run as root

[X.25]

The issue is, that one would expect a distro specifically built for security and penetration testing would not have a discoverable security flaw. No matter how obscure.
It might make one wonder what else has been missed?

No, one would not expect that.

You've probably never done a pen test, nor do you understand how Backtrack works.

Re:Usually you run as root

[Rennt]

Pretty much this. Give the student an "A" for finding it and leave it at that.

Re:Usually you run as root

[allo]

but nearly every livecd has a default root-pw or sudo set up to work without password.

Re:Usually you run as root

[detritus.]

That's presuming none of the scanning utilities that require root have any vulnerabilities in them. For example, there have been plenty of Wireshark dissectors that just by merely sniffing on a network can lead to compromise of the live distribution.

Re:Usually you run as root

[Securityemo]

Thing is, it isn't built for security. Only for penetration testing. It runs as root as default because you want raw packet access etc. And this isn't like OpenBSD where it's a completely different operating system with it's own auditing process, BT is just a customized Ubuntu.

Re:Usually you run as root

[Securityemo]

Get a netbook and install a RedHat-derived distro like CentOS or Scientific Linux. Although really, any Linux distribution will work if your only threat is malware. You still need to take the ordinary precautions regarding non-malware threats like pishing/connection hijacking though, there's no magical pixie protecting you against such things.

Re:Usually you run as root

[detritus.]

Please see my reply to the other responder to my parent post.

it appears

[koan]

Backtrack repository has the fix already.

Re:Penetration testing

[antant007]

Ya, I foolishly did. Don't do it.

Re:Penetration testing

[Ihmhi]

Yeah, I can't believe people fall for th

Oh look. It is a picture of two kittens who are playfully romping in the grass. This picture is really cute.

What? No, it's

So cute!

How useful

[windcask]

Oh noes, someone has pwned my LiveCD linux distribution, running entirely from a ramdisk in memory! Whatevers shall I do?!

*reboots*

Re:How useful

[Shoten]

Actually, a lot of people install Backtrack and run it as the resident install on their hard drives. Not what I would do, but then, not everyone is able to build their own system for pen-testing in the first place.

Re:How useful

[Anonymous Coward]

So "a lot of" people are stupid. What are the doing pen testing for anyway? They are too stupid to understand what this is for. A security flaw like this, while it needs fixing, is a non issue if you are using the tool properly. This is not a secure linux distro. Its just a bunch of tools. Installing it serves no purpose, other than some teenage c00l factor cause you are a 1337 haxor. Which you are not, if you are using out of the box pen testing tools.

Re:How useful

[Anonymous Coward]

but what about your hard drive?

Re:How useful

[Anonymous Coward]

"running entirely from a ramdisk in memory"

As opposed to a ramdisk running not in ram?

; )

(I know, I know... Bla bla bla ramdisk is a misnomer etc. Your sentence still reads funnily ; )

Re:How useful

[Anonymous Coward]

http://xkcd.com/378/

Re:How useful

[laurelraven]

So "a lot of" people are stupid. What are the doing pen testing for anyway? They are too stupid to understand what this is for. A security flaw like this, while it needs fixing, is a non issue if you are using the tool properly. This is not a secure linux distro. Its just a bunch of tools. Installing it serves no purpose, other than some teenage c00l factor cause you are a 1337 haxor. Which you are not, if you are using out of the box pen testing tools.

Or, you have an old, beat up laptop that you use just for pentesting, because it's useless for anything else. Or, you installed it on your good laptop as a VM, so you can more easily save some of the information you uncovered. Just because it isn't something you should do as your permanent, regular install (which I did see a number of dolts in a security class I took do) doesn't mean there aren't perfectly legitimate reasons to install it.

That said, I can't think of any good scenario where this bug would be a concern to people using BackTrack correctly.

Re:How useful

[Rogerborg]

Eh, you can't make scissors that are completely safe for folk that insist on running with them.

Re:How useful

[Anonymous Coward]

You missed a step:

*malware remounts first physical disk as R/W, installs rootkit if suitable OS detected* ..

Re:How useful

[windcask]

I was standing in the shower last night thinking exactly what you're saying. "I guess 'ramdisk in memory' is kind of redundant..."

Is it sad that I think about my Slashdot comments in the shower?

Re:How useful

[RulerOf]

Is it sad that I think about my Slashdot comments in the shower?

Only if they don't make +5.... which is the majority of Slashdot comments. :-\

In-band Signaling Considered Harmful

[CapOblivious2010]

Why oh why do people still make and use systems/apps/tools/interfaces/etc that use in-band signaling and thus require that their inputs be "sanitized"? Can't everyone see that sanitizing inputs is a fool's errand? You'll ALWAYS miss something, or the next version will have a feature you forgot to screen for, or something. In-band signaling is BAD BAD BAD and any system that uses it is doomed to an endless series of X-injection attacks.

For example (and yes, I realize this has nothing to do with SQL, it's just an example) don't even try to sanitize your SQL inputs; use bound parameters instead - not only is it guaranteed 100% safe, it's easier and faster too! As much as I love XKCD, little Bobby Tables really screwed the pooch on that one.

Remember, folks: when it comes to any sort of in-band signaling: JUST SAY NO. If you think you need to sanitize your inputs, you're doing something completely wrong. Stop and figure out what it is, and figure out how to do it right; don't just throw in some half-assed regex or character translation/stripping or whatever and hope that no one is cleverer than you are.

Re:In-band Signaling Considered Harmful

[b4dc0d3r]

Oblivious indeed. All input gets sanitized, even if it's a simple sanity check, for example percentages should be between 1 and 100 (if >100 doesn't make sense). Numeric data should be checked to be sure it's numeric. Null integers and strings should be converted to a NULL database value, instead of an implicit ToString() conversion giving an empty string, depending on the language. Using a pass-through library to connect to the database, allowing nothing to escape unchecked, is what smart programmers do. Some sort of data access layer.

Bobby Tables illustrated one of the most common attack vectors. Not using bound parameters is very common so much so that I have yet to see an introductory text on ASP or ASP.NET that explicitly and routinely uses bound parameters. Most issue a disclaimer that error checking has been omitted for clarity. So you have people who should know better, but don't. Instead, you use a data access layer, that always binds parameters.

Kinda like I said above. Only you claim that you will miss sanitizing something. So what if you forget to use bound parameters? Oh that's right, things work perfectly in your view of the world but everyone else is wrong. Use a data access layer, access everything the same way. And while you're at it, you might as well sanitize the data as well, right? After all, if it looks like an injection attempt, shouldn't you at least log an IP, or user ID, or something? A responsible dev would.

In-band signaling... I'll leave that for others if they want to rip it apart. I assume you mean escape sequences, replacing control characters with escapes specifically. There are common ways of replacing, and common ways to defeat common ways of replacing. It has nothing to do with in or out of band signaling.

If you are talking about creating a protocol, such as TDS or SMB, or TCP, or anything else, it's very easy to add error-checking to ensure OOB data is treated as expected, and in-band signaling is considered an error condition. If you are talking about checking for escape sequences in a protocol and passing that directly, unchecked, you're talking about little Bobby Tables.

"In-band signaling" is, in the case of SQL, a SQL injection attack waiting to happen, and exactly the condition XKCD was describing. Using bound parameters relies on the underlying library to generate the correct OOB escape signals to describe the packet and detect anomalies. IF you have a bug in the binding, such as the case here, it doesn't matter if it's in or out of band. There is a bug, and it will likely be discovered sooner or later.

So I assume you are also saying: Always assume that the lower layer library has a bug, and sanitize your inputs just in case, so your application is not hacked by an underlying bug. That is what you are saying, right?

Re:In-band Signaling Considered Harmful

[Anonymous Coward]

Ummm.. fuck parent straight up the ass for that idiocy.

Validating your inputs is just one of many important parts of a complete security solution.

There is a good reason you'll find "Input Validation" given its own section starting on Page 5 of the OWASP Secure Coding Practices Quick Reference Guide.

But don't be too hard on CapOblivious2010 ... developers like that are the reason you'll still find plenty of work writing security code for decades to come.

Re:In-band Signaling Considered Harmful

[Anonymous Coward]

Hmm. I think what the GP is trying to say is: "Don't allow a user-facing computer system to invoke or access any other computer system using parameters that are the result of a non-finite (is that the right term?) transformation of user input".

For example, say you have a "web app" that serves a page. A remote user (some dude sitting at home in front of his PC) can run the web app by navigating to that page in his web browser. The user input are the "query" strings at the end of the URL (like blah.com/foo?q=a&p=44).

Now to make the web app truly secure against this class of vulnerabilities, it should parse the query string in such a way that only valid, known and expected values of q and p will result in a call to e.g. the database. You might say that the "burden of proof" is inverted; the parser has a "success" return code that defaults to false, as opposed to having an "error" return code that defaults to false..

One of the wrong ways to write the web app would be to run the query string through a regex to check for known erroneous patterns.

Re:In-band Signaling Considered Harmful

[Anonymous Coward]

Clever argument - I'm impressed

If someone wants their userid to be: ' or 1=1 -- why should that be a problem at all? If you use bound params, it's not. No need to 'sanitize' anything!

Re:In-band Signaling Considered Harmful

[CapOblivious2010]

Instead, you use a data access layer, that always binds parameters.

Kinda like I said above. Only you claim that you will miss sanitizing something. So what if you forget to use bound parameters? Oh that's right, things work perfectly in your view of the world but everyone else is wrong. Use a data access layer, access everything the same way.

I don't so much care how "thick" your data access layer is - a thousand layers of code or just a rule - the important thing is that at the bottom you MUST use bound parameters instead of doubling all your quotes and wrapping it in quotes.

In-band signaling... I'll leave that for others if they want to rip it apart. I assume you mean escape sequences, replacing control characters with escapes specifically. There are common ways of replacing, and common ways to defeat common ways of replacing. It has nothing to do with in or out of band signaling.

Poor choice of words, perhaps - what it really boils down to is, don't let your users write your source code. Seems pretty obvious when you say it that way, but so many things like SQL injection attacks, XSS browser problems, etc, all come down to taking a string of user input and putting it into an environment where it gets evaluated as executable code. People see that it's happening (usually the first time Mr. O'Brien registers), and they try to patch it, but they usually fail one way or another.

For example, go back a few weeks and find the slashdot article about the voting machine being hacked (legally, during a public eval period) by some researchers. It turned out to be the wrong kind of quotes used in a shell script, which meant that a carefully crafted input ended up being executed as code. Watch over the next few weeks/months as various as-yet-unknown exploits are discussed in academic or real-world settings, and 99% of the time it ends up that user input is being executed in some way. And more often than not, there was some sort of attempt at "sanitizing" the input, which failed to account for something.

IF you have a bug in the binding, such as the case here, it doesn't matter if it's in or out of band. There is a bug, and it will likely be discovered sooner or later.

Yes, there could always be a bug in an underlying library. If the bug is in a subroutine that supposedly sanitizes your data, you're screwed (and note that there's a decent chance you won't know about the bug until someone else uses it on you). If the bug is in the SQL binding code, and the 8 bytes that's supposed to represent am IEEE floating point number happens to end up containing 'or1=1-- , then it probably doesn't matter, because no part of an SQL driver is likely to be expecting to execute the binary data of a bound parameter. And if there is someone a problem where the data packets DO try to get evaluated, you're far more likely to find it before the system hits production, because the vast majority of such attempted evaluations will fail miserably due to syntactical errors or whatever.

I only know of ONE environment where you really have no choice but to "escape" a bunch of strings, glue them together, and hope for the best: HTML. There's no equivalent of a bound parameter. And this fundamental flaw is why web pages designed by careless people (realistically, that's most of them) will always be easily exploitable, and web pages designed by careful people will also be exploitable, just not as easily and somewhat less often.

Mark my words: ten years from now, if people are still using HTML, there will still be major new types of attacks being discovered and utilized every other month or so. It's inherent in the architecture, and every new feature (javascript, CSS, etc) just introduces new escaping rules for people to fuck up..

Re:root password is toor

[Anonymous Coward]

You think I give a damn about security? I ain't a sucka!

Is that the autobiography,
Of AC? Cuz if you ever fuck with me,
You'll get pwned, by a drunken dope brotha with who will smotha,
Got root on that muthafucka!
Straight Outta Compton!

Tired of the muthafuckin' hackin,
Sweatin' my rig while I spider Imageshack, a nd
DMCA-ing me, and for what?
Maybe it's because I kick so much butt,
...I'm sorry, I'm too drunk to finish it, but Fuck UAC! F-F-F-fuck UAC! :)

Need local access to exploit it...

[seifried]

You need to be able to send arbitrary Dbus messages, so you need either local access or to remotely compromise the system (in which case you already won). This article is ridiculous and much ado about nothing.

Re:Hehe heh hehe

[Anonymous Coward]

Next headline: Professional penetration tester got penetrated thanks to a privilege escalation hole.

This is a complete

[jakeguffey]

non-issue. According to the advisory, this particular issue "Spawns a root shell [and h]as not been tested for potential remote exploitation vectors." As has been stated multiple times earlier already, BT is generally used as root locally and (until someone determines remote exploitability) this is a local-only exploit. TFS is wrong. This is not a "critical flaw in BT," but a flaw in WICD that allows privilege escalation. Still something that definitely needs fixed, but if someone has local access to your box, you can pretty much assume they already have root.

Re:This is a complete

[Anonymous Coward]

According to the article, "These scripts execute as the root user, this leads to arbitrary code/command execution by an attacker with access to the WICD DBUS interface as the root user."

So a user already with root runs scripts as root. OMG. ;)

Re:This is a complete

[Hatta]

Still something that definitely needs fixed

You forgot the infinitive.

Move along, nothing to see here

[Anonymous Coward]

From the official response (http://www.backtrack-linux.org/forums/showthread.php?t=49411):

This post is a bad example of a bug report, for several reasons.

1) The title of this vulnerability should probably be "WICD Priv Escalation". As such, it should probably be reported to the WICD developers, as opposed to the BackTrack development team. If you still felt the bug report should be posted to us, the right place to post it would be "BackTrack bugs" (although it is not), or even better, our redmine ticket system.

2) Giving the pre-requisites for the exploit to function would be helpful. In this case, you would need to create a non root user in BackTrack, have a remote attacker access BT with that non privileged account or have an unprivileged shell from a previous attack against another service, and then have that user attempt to connect to a wireless access point (assuming wicd is running as root). This is far from the default configuration in BackTrack, which further negates the title of this vulnerability.

3) Making a mountain out of a molehill for the purpose of promoting a product or service is generally frowned upon by the security industry, especially when one already has a bad reputation.

4) Once this bug is tended to by the WICD developers, we will use their official patch rather than patching our packages using untrusted sources.

Bootable Backtrack

[kilodelta]

I use a CD to boot BackTrack. It's always safest if you do this on a machine with a disable hard drive.

If you're an infosec pro, it pays to use belt and suspenders.

Re:Critical Flaw

[Anonymous Coward]

It was a honor to read that.

Advanced Pen Testing

[clarkn0va]

1. Advertise 0day on Linux distro
2. Publish unofficial "fix" with trojan payload
3. Pwn all the computers of the world's most paranoid hackers
4. ?
5. Profit!!!!

Re:Critical Flaw

[Anonymous Coward]

It was a honor to create. Since we had 43 million in venture capital it is only fair we provide the source code for the research we have thus far produced. Entire source below.

int main(void)
{
        FILE* data = fopen ("datafile.bin", "r");
        if (!data) return 1;
#if 0
        interpretData(); // not yet implemented
#endif
        return 0;
}

datafile: http://pastebin.com/dPQVppAc

Thanks.

Misprepresentatoin of Security bugs for fame

[Anonymous Coward]

Seems to me Infosec are trying to mis-represent this bug in order to get traffic to their website. Calling it it a "Backtrack 0day" is a blatant attempt to make this into more than it is for the sake of self glorification. People who actually understand security see right past this, which sheds a bad light on the Infosec Institute.

Re:Hehe heh hehe

[allo]

news at goatse

Misinformation

[Anonymous Coward]

This is a Wicd exploit, and accordingly it affects ALL the distros Wicd ships on. Futhermore, Wicd runs as root through the dbus daemon, which the exploit is in. That is open to all users. Please don't downplay the seriousness of this bug, despite the misleading title.

known for a while

[Anonymous Coward]

lol
suckers

This is why...

[Sav1or]

' An unofficial patch is available from InfoSec Institute. Koziol said that an official patch is being tested now and is expected shortly." Linux will always be more secure than macs.

Re:Critical Flaw

[jones_supa]

To be academically correct, you should fclose() the file. :P

B4CKTR4CK L1NUX

[Anonymous Coward]

>Backtrack Linux, a popular distribution that is used by script kiddies
Fixed that for you

Excuses

[Anonymous Coward]

If this happened to a Microsoft OS the long knives would be out, but it's Linux so everyone bends over backwards to make excuses for it.

Re:Excuses

[Anonymous Coward]

If you don't want to partake in our Slashdot Linux-loving group masturbation then leave. No one is forcing you to stay, and there are dedicated forums for WinFags and MacFags too.

Physician–strike that–...

[HTH NE1]

Pentester, hack thyself.