=14.Feb.2010= [Sun] at [21:34] · Filed under Author: Derek Callaway, Digital Security, Exploits, Misceallaneous, Systems Theory ·Tagged access, account, administrators, attack, bash, binary, chmod, chown, chroot, configuration, containers, context, daemon, directory, elf, environment, escalation, filesystem, fileutils, gnu, hackers, internet, kernel, libraries, manual, memory, netstat, network, noexec, oracle, overflow, pathnames, phrack, privilege, processes, procfs, scp, script, sftp, shell, shellcode, solaris, ssh, stack, sun, tcp, twitter, udp, vulnerable, zones
The content of this blog post is intended for the hackers that have found themselves frustrated as a result of privilege escalation difficulties in the context of a chroot(2) jail environment. Such a situation can occur because of shell account access where the environment or shell itself have been restricted, successfully executing shellcode via overflow in the context of a network daemon, etc. Before I begin, I’d just like to mention that newer versions of Sun Microsystems’ Solaris (now, the Oracle Solaris operating system) Containers, also known as zones serve similar purpose to chroot prisons. Also, I won’t be discussing kernel space memory corruption as a means of subverting a jail; this subject was touched upon in a Phrack article entitled Smashing The Kernel Stack For Fun And Profit (P60-6).
First, I’d like to state that sometimes much information can be gathered simply by looking around the jailed directory hierarchy, since system administrators occasionally copy files from the real root filesystem into the jail. For example, /etc/ld.so.cache may contain pathnames to libraries that exist in the real root, allowing network daemons and other programs that are dynamically linked with vulnerable libraries to be targeted.
Second, it is not entirely uncommon for procfs to be mounted at the usual /proc location within the jail since it’s a prerequisite for many useful utilities. This allows more information to be gathered such as network configuration settings, Internet connections, running processes, and more.. For example, information displayed by netstat(8) can be gleaned from /proc/net/tcp and /proc/net/udp even though the netstat binary may not exist in the chroot environment. The bash shell script below demonstrates this ability:
#!/bin/bash
# netstat.bash by Derek Callaway <decal@security-objectives.com>
# Sun Feb 14 15:56:26 EST 2010 DC/SO
function netstat()
{
echo 'Active Internet connections (w/o servers)'
echo -e 'Proto\tLocal Addr\t\tForeign Addr'
while read -r sl la ra st tx rx tr tm rn smt uid
do if [ $sl == 'sl' ];then continue;fi
l1=${la:0:2}&&l2=${la:2:2}&&l3=${la:4:2}&&l4=${la:6:2}&&li=${la:10:4}
r1=${ra:0:2}&&r2=${ra:2:2}&&r3=${ra:4:2}&&r4=${ra:6:2}&&ri=${ra:10:4}
fmt="tcp\t%u.%u.%u.%u:%u\t%u.%u.%u.%u:%u\n"
if [ $r1 == '00' ];then fmt="tcp\t%u.%u.%u.%u:%u\t\t%u.%u.%u.%u:%u\n";fi
printf $fmt 0x$l4 0x$l3 0x$l2 0x$l1 0x$li 0x$r4 0x$r3 0x$r2 0x$r1 0x$ri
done < /proc/net/tcp
# Replace with /proc/net/udp to view UDP info
If the chmod binary is not present in the jail then you can make the script usable by simply running: bash script.sh, source script.sh, . script.sh, etc. These commands will work even if the /home directory is mounted with the noexec option since bash (or whatever shell you’re using) must be in a directory on a partition that allows execution such as /bin. Of course, you’re out of luck in that particular scenario if you want to execute an ELF binary under $HOME, although some combination of indirect attack techniques may still lead to the desired effect.
Similarly, a makeshift route(8) script can be created to display information about the IP routing table which is accessible through /proc/net/route. Lots of useful information can be gathered from procfs in this manner. Refer to the manual pages and /usr/src/linux/Documentation/filesystems/proc.txt for many more possibilities.
If file transfer services such as SCP and (S)FTP are not configured for the prison, then binary files can still be copied to the target system. If SSH access is available then cat file.bin | ssh -l user@host.dom ‘cat>file.bin’ will suffice. If SSH is not an option, then it shouldn’t be very difficult to write a script locally that converts the file contents to hexadecimal and provides the needed echo -ne ‘\x90’ styled commands which will construct the file auto-magically on the remote system.
In the second part of this blog duo I will provide the source code to a custom job shell that has built-in commands based on system call prototypes in order to circumvent the absence of important commands from packages like GNU fileutils, i.e. chmod(1), chown(1), and others. I’ll be demonstrating another shell script that takes advantage of procfs presence as well so check back soon for more useful tidbits. You can find notifications of new System of Systems blog postings on our Twitter feed, @secobjs.
Permalink
=22.May.2009= [Fri] at [16:41] · Filed under Author: Derek Callaway, Misceallaneous, Windows ·Tagged ads, amaya, api, applications, atom, attribute, biztalk, brown, charlie, chromium, dereference, dime, element, encryption, engines, exefilter, exif, explorer, expressions, extensible, firefox, format, functions, good, google, grief, header, http, ie8, images, indexing, ipv6, konqueror, lagadec, libgd, libmagick, lynx, macos, markup, middleware, multipart, navigator, netmask, netscape, new york, opera, oslo, request, resource, rest, ria, rss, safari, sax, security, shellcode, signature, silverlight, smuggling, soap, standards, syndication, tcp, thumbnail, tomcat, transform, twits, uri, validation, w3m, wcf, weblogic, win32, ws-security, xaml, xerces, xml, xml-dsig, xpath
It’s been a little while since we last posted so I wanted to get a blog out there so everybody knows we’re still alive! We just finalized the XML schema for our soon to be released BlockWatch product so with all the XML tags, elements, attributes, and such running through my head I figured I’d blog about XML security. I’m sure the majority of penetration testers out there routinely test for the traditional web application vulnerabilities when looking at Web Services. The same old authentication/authorizations weaknesses, faulty encoding/reencoding/redecoding, session management issues, et al. are still all there and it’s not uncommon for a SOAP Web Service to hand off an attack string to some middleware app that forwards it on deep into the internal network for handling by the revered legacy mainframe. Some organizations process so much XML over HTTP that they place XML accelerator devices on their network perimeter. I have a feeling that this trend will increase the amount of private IP web servers that feel the effects of HTTP Request Smuggling.
Additionally, XML parsers that fetch external document references (e.g. remote URI’s embedded in tag attributes) open themselves up to client-side offensives from evil web servers. Crafted file attachments can come in the form of a SOAP DIME element or the traditional multipart HTTP POST file upload. With those things in consideration, Phillippe Lagadec’s ExeFilter talk from CanSecWest 2008 made some pretty good points on why verifying filename extensions and file header contents or magic numbers isn’t always good enough.
The new manifestations of these old problems should be cause for concern but I personally find the newer XML-specific bugs the most exciting. For example: XPath injection, infinitely nesting tags to cause resource exhaustion via a recursive-descent parser, XXE (XML eXternal Entity) attacks, etc.
A single file format for everything is supposed to make things more simple but the lion’s share of real-world implementations over-complicate the fleeting markup language tags to the point where they become a breeding ground for old school exploits and new attack techniques alike–we’re all familiar with the cliche regarding failure of a “system of systems” with too many moving parts. I’ll touch on some more advanced XML attacks later in the post, but first let’s take a step back and remember XML when it still had a fresh beginning.
Towards the end of the twentieth century, when I first started taking notice of all the hype surrounding XML (the eXtensible Markup Language) I held a fairly skeptic attitude towards it as I tend to do with many fledgling technologies/standards. Perhaps I’ve been over-analytical in that respect but look how long it’s taken IPv6 to amass even a minuscule amount of usage! Albeit, a formal data representation grammar certainly was needed in that “dot-bomb” era, a time when mash-up web applications were near impossible to maintain since consistently pattern matching off-site content demanded continuous tweaking of regular expressions, parsers, etc. The so-called browser war of Netscape Navigator vs. Internet Explorer couldn’t have helped things either. If that was a war, then we must be on the brink of browser Armagaeddon now that there’s Chromium, FireFox3, IE8 RTM, Safari4 Beta, Opera, Konqueror, Amaya, w3m, lynx, etc. The good news? We now have Safari for Win32. The bad news? Microsoft no longer supports IE for MacOS..bummer.
I think it’s fairly rational to forecast continued adoption of XML Encryption and WS-* standards for SOAP Web Services that handle business-to-business and other communications protocol vectors. If you’re bored of the same old Tomcat/Xerces, WebLogic/SAX, etc. deployments then prepare for applications written in newer API’s to arrive soon; namely Microsoft WCF and Oslo, the Windows Communication Foundation API and a modeling platform with design tools (respectively.) From the surface of .NET promotional hype it appears as if WCF and Oslo will be synthesized into a suitereminiscent of BizTalk Server’s visual process modeling approach. WCF has commissioned many Web Services standards including WS-Security but of course not all major software vendors are participating in the all of the standards. The crew in Redmond have committed to REST in WCF and it wouldn’t surprise me to see innovative XML communications techniques arising from the combination of Silverlight 3 and .NET RIA Services; for those of you who still don’t know, RIA is an acronym for Rich Internet Applications! Microsoft is leveraging the interoperability of this extensible markup language for the long-proprietary document formats of their Office product suite as part of their Open Specification Promise. Even the Microsoft Interactive Canvas, essentially a table that provides I/O through touch uses a form of XML (XAML) for markup.
Blogosphereans, Security Twits, and other Netizens alike seem to take this Really Simple Syndication thing for granted. Over the past several years or so there’s been a trend of malicious payloads piggybacking on banner ads. Since RSS and Atom are capable of syndicating images as well, I’d like to see a case study detailing the impact of a shellcode-toting image referenced from within an XML-based syndication format. Obvious client-side effects that occur when the end user’s browser renders the image are to be expected (gdiplus.dll, anyone?) What else could be done? Web 2.0 search engines with blog and image search features often pre-process those images into a thumbnail as a part of the indexing process. A little recon might discover the use of libMagick by one and libgd by another. Targeting one specific spiderbot over another could be done by testing the netmask of the source IP address making the TCP connection to the web server or probably even as simple as inspecting the User Agent field in the HTTP request header. Crafting a payload that functions both before and after image resizing or other additional processing (ex. EXIF meta-data removal) would be quite an admirable feat. Notwithstanding, I was quite surprised how much Referer traffic our blog got from images.google.com after Shane included a picture of the great Charlie Brown in his “Good Grief!” post…but I digress.
Several years ago when I was still living in New York, I became fascinated with the subtle intricacies of XML-DSig while studying some WS-Security literature. XML Signature Validation in particular had attracted my attention in earnest. In addition to the characteristics of traditional digital signatures, XML Signatures exhibit additional idiosyncrasies that require a bit of pragmatism in order to be implemented properly and therefore also to be verified properly as well (ex. by a network security analyst.) This is mainly because of the Transform and Reference elements nested within the Signature elements–References and Transforms govern the data to be provided as input to the DigestMethod which produces the cryptic DigestValue string. A Reference element contains a URI attribute which represents the location of the data to be signed. Depending on the type of Transform element, data first dereferenced from the Reference URI is then transformed (i.e. via an XPath query) prior to signature calculation. That’s essentially how it works. Something that may seem awkward is that the XML being signed can remain exactly the same while the digital signature (e.g. the DigestValue element value) has changed. I’ve decided to leave some strange conditions that often come about as an exercise for the reader:
What happens to an XML Digital Signature if … ?
- No resource exists at the location referenced by the Reference element’s URI attribute value.
- A circular reference is formed because a URI attribute value points to another Reference element whose URI attribute value is identical to the first.
- The URI identifies the Signature element itself.
- A resource exists at the URI, but it’s empty.
- The Reference element has a URI attribute value which is an empty string, <Reference URI=””>
Permalink
=25.May.2008= [Sun] at [15:29] · Filed under Author: Derek Callaway, Digital Security ·Tagged 2600, anti-virus, apple, arp, attacks, dec, dns, hijacking, hope, hp, http, microsoft, mitnick, plaintext, security, spoofing, ssl, tcp, updater, updates, vulnerabilities, wi-fi
Attacks against security components have been fairly common on server operating systems for decades; on PC’s this wasn’t always necessary because of security models that resembled swiss cheese. Since the beginning of the 21st century, Microsoft has been working diligently to close obvious holes (for the most part.) As a result, researchers have shifted their focus to the attack surface of security-centric code on PC’s. Case in point; in the past several years we’ve seen loads of advisories released for vulnerabilities in anti-virus software. Read the Yankee Group’s “Fear and Loathing in Las Vegas: The Hackers Turn Pro” for a more in-depth analysis of this trend. One area in particular where I feel PC protection is lacking is automated software security update mechanisms; there is a lot of room for improvement.
According to Hewlett-Packard, Digital Equipment Corporation was the first in the industry to perform patch delivery in 1983. Prior to this, updates were commonly delivered on tape by private courier. At one of 2600’s HOPE conferences, Kevin Mitnick spoke about an analog attack he had used to compromise this process during the social engineering panel. The gist of it was that he wore a UPS uniform (procured from a costume store) and delivered the “update” tape to his mark with a login trojan on it. Later, Mitnick became known for using SYN floods and TCP hijacking against Tsutomo Shimomura. Some sources even refer to this sort of digital man-in-the-middle as “The Mitnick Attack.”
Many software update components don’t use public key infrastructure to cryptographically verify the validity of the update server (i.e. SSL) or the updated package (i.e. digital signature.) This is a problem. Impersonating the software update server is usually trivial. Wi-Fi access point impersonation, DNS cache poisoning, ARP spoofing, session hijacking, and compromising the legitimate update server are all possibilities.
Some applications–I’m not going to name any names–rely on HTTP (note that I didn’t say HTTPS) for downloading packages after checking for updates instead of using a separate file transfer manager program or internal update component. This is much easier to reverse engineer than a custom update solution. Sometimes the attacker can allow the real update server to carry out most of the process and simply shoehorn their malcode into the update session(s) after initial preconditions are met.
SSL won’t save the day either unless it’s implemented properly. I’ve seen plaintext updaters with digital signatures that are safer than some HTTPS updaters. Gentoo’s Portage Tree (emerge and ebuild) is a good example of an effective plaintext digital signature approach. See SECOBJADV-2008-01 (CVE-2008-3249) for a description of a software updater with an erroneous SSL implementation.
The issue is further complicated because software updaters themselves need to be updated in order to resolve such vulnerabilities. Typically this requires a major architectural modification. What’s worse is that breaking the updater would force users to manually update. Hoyvin-Glayvin!
Permalink
System of Systems 