Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: vulnerability

Sudo -g privilege escalation (CVE-2011-0010)

I noticed this bug come across the wire earlier today and thought I’d take a few minutes to take a look. There’s been a few bugs in sudo recently, so I thought it was about time I invested a few minutes to see what they’re all about. After all you can never be too sure when these kind of things are going to come in useful 😉

The text of the advisory and source code changes (HERE) make it pretty simple to see what the issue is.

Code diff

--- a/check.c	Mon Jan 10 10:28:59 2011 -0500
+++ b/check.c	Tue Jan 11 10:33:39 2011 -0500
@@ -120,7 +120,13 @@
  if (ISSET(mode, MODE_INVALIDATE)) {
    SET(validated, FLAG_CHECK_USER);
    } else {
-   if (user_uid == 0 || user_uid == runas_pw->pw_uid || user_is_exempt())
+   /*
+    * Don't prompt for the root passwd or if the user is exempt.
+    * If the user is not changing uid/gid, no need for a password.
+    */
+   if (user_uid == 0 || (user_uid == runas_pw->pw_uid &&
+      (!runas_gr || user_in_group(sudo_user.pw, runas_gr->gr_name))) ||
+	user_is_exempt())
  	return;
      }

It looks to my untrained eyes that the addition of the -g (run command as another group) added to the 1.7.x branch doesn’t request a password from the user if the uid isn’t changing (i.e. no username provided at the sudo command line). This can obviously cause issues where a user who is in the sudoers file can change to another group and access files without providing a password.

However, and this is a big however, the exploitable configuration isn’t standard, at least with most stable systems. So it would require an edge case configuration of /etc/sudoers that allows uid as well as gid changes. Thanks to @timb_machine however he can confirm that at the very least the latest Debian testing is vulnerable to this bug in its default configuration.

Standard /etc/sudoers

root  ALL=(ALL) ALL

Edgecase /etc/sudoers

%sudo ALL=(ALL:ALL) ALL

In the edge case scenario the user account (or a user with membership to the sudo group) could run sudo with the -g option to access files/commands as any group on the system.

Example:

deb:/tmp/test# id
uid=0(root) gid=0(root) groups=0(root)
deb:/tmp/test# su testsudo
testsudo@deb:/tmp/test$id
uid=1001(testsudo) gid=1001(testsudo) groups=1001(testsudo)
testsudo@deb:/tmp/test$sudo -g root id
uid=1001(testsudo) gid=0(root) groups=1001(testsudo)

Using this bug to gain access to the system from here is pretty simple. Extracting the passwords from /etc/shadow seems like a good first step.

testsudo@deb:/tmp/test$id
uid=1001(testsudo) gid=1001(testsudo) groups=1001(testsudo)
testsudo@deb:cat /etc/shadow
cat: /etc/shadow: Permission Denied
testsudo@deb:sudo -g shadow cat /etc/shadow
root:$1$R4mDH$aOcFaA9.Dq6Ww2u3XmCfK/:14641:0:99999:7:::
..........

Although the use case for this kind of privilege escalation is quite small, it’s something worth keeping in mind for the future. Adding new functions to applications, like sudo, is always good, but can sometimes expose issues if security checks and balances don’t keep up with the curve in regards to new functions!

Happy Hacking!

Links:

DNS Cache Poisoning against djbdns

I’ve been reading up on the newest DNS cache vulnerability. Hot on the heals of the most over-hyped bug of the year (Sorry Dan), comes an attack that actually works against djbdns.

djbA little history. Djbdns (Daniel J. Bernstein’s DNS) was immune to the 2008 Cache Poisoning attacks from Dan Kaminsky as it already implemented the UDP Port randomisation that was marketed as the (temporary) solution to the issue. Although port randomisation doesn’t solve the problem 100%, it makes the attack considerably harder (read longer) to complete. The theory is, that you’ll see an attacker hammering your DNS serer with UDP packets for hours or days before they manage to poison the cache. That is if you’re paying attention to your DNS server. Anyway, a discussion of the 2008 attack vectors isn’t the point here. There are many sources of this already on the interwebs.

The djbdns attack was released on 09.02.2009 by Kevin Day. Full details of the research and examples can be found on his website. The Basics : By using a number of flaws in the dnscache program provided with djbdns, Kevin was able to prove that djbdns is vulnerable to cache poisoning. The attack centers around SOA records and the fact that these are not cached by djbdns. By filling the buffer (defaulted to 200 open requests) with SOA queries, he was able to attempt a collision (matching ID and UDP Port). By having 200 active SOA requests he is in effect increasing the chances of a collision by 20,000%. This reduces the 40 billion packets required for a 50% collision to around 16.8 million packets (not much in computer terms). If the server has been configured to accept more than 200 simultaneous queries, then the attack could be executed even faster.  By constantly rotating the queries (djbdns drops older queries if the buffer is full and a new request comes in) he was able to force djbdns to ignore the official responses from the nameserver, and keep the dns server from accepting a valid response. This attack requires that communication between the attacker and dns cache being poisoned is quicker than the nameserver of the domain being poisoned.

My explanation is a little hard to follow (it’s hard to cram into 10 lines on a blog). So I suggest you hop over to Kevin’s site, read the excellent paper and apply the 3rd party patch to your djbdns server before a Metasploit module appears. Going by previous vulnerabilities, that won’t be long 😉

DJBDNS –> http://cr.yp.to/djbdns.html

Typo3 Weak Encryption Key

rtemagicc_typo3-logoA few months back I discovered a vulnerabilty in the core of Typo3 (versions  4.0.0 to 4.0.9, 4.1.0 to 4.1.7, 4.2.0 to 4.2.3). Now that the Typo3 security team have responded with a patch against this issue (see the official Security Note from the Typo3 security team) I can release the details of the vulnerability, as well as some proof-of-concept python scripts that I’ve been holding onto now for a while. The Typo3 Security Team were very quick to respond to the issue, and I found them very good to work with during the disclosure process. If only some larger companies were so easyto work with, and responsive.

The following announcement has been made public in co-ordination with the Typo3 Security Team.

Technical Details <— link to release information

PoC Tools <— Link to tools

For those looking for a brief overview in 100 words or less .:

The default encryption key used by Typo3 is create at time of setup using inadequate sources of entropy. This design flaw resulted in there only being 1000 possible keys. If an administrator manually changes the Encryption Key through the administrative install console, then this vulnerability can be avoided.

Alongside this flaw, Typo3 also uses the Enryption Key to create MD5 hashes to protect URL links from being manipulated (see full release information for more details and examples). In this case, the Encryption Key is the only peice of information not directly available to the end-user. This allows an attacker to perform an offline brute-force against the Encryption Key. Breaking this key could allow an attacker to form malicious URL’s containing script commands of their choice.

The PoC scripts for this are available for demonstration purposes only. Any comments are gratefully received.