/var/log/messages

This section contains the latest news, announcements and thoughts from the MWR InfoSecurity team.

Assessing the Tux Strength: Part 2 - Into the Kernel

Sep 02, 2010

Introduction

The previous article in this series on Linux security described different userspace protection mechanisms that can be applied to protect binaries on a Linux system. Unsurprisingly, without additional kernel settings and protections most of the previously described mechanisms cannot be utilised to their full extent. This article will therefore focus on kernel features that have a direct impact on security of running binaries. Specific security frameworks such as SELinux, Grsecurity RBAC, AppArmor and others will not be discussed here although they may feature in future articles.

Most of the kernel features described here will be related to the addition of protection within userspace; however, a few of them will also have a direct impact on the security of the kernel itself. The security of the kernel is also very important as once an attacker is able to execute their own code in the kernel space there's very little that can be done to maintain the security of the system. The Linux kernel is subject to rapid development with many new features being added or existing functionality being amended and support for new devices is added on a regular basis. It should be noted that the direct and indirect impact of these issues on the security of the kernel can be easily overlooked. It is also not uncommon for a security feature that is enabled in the kernel to have an impact on its performance and the overall performance of the system as well.

Testing

The testing that was conducted to provide the information presented in this article was performed against the same distributions as in the previous research. Output from the following settings and tools were reviewed during this assessment:

'mmap_min_addr' (/proc/sys/vm/mmap_min_addr)
'randomize_va_space' (/proc/sys/kernel/randomize_va_space)
paxtest-0.9.9.tgz

The first setting is responsible for setting the minimal virtual address that can be allocated in userspace. This has certain security implications; for example, if an attacker can trigger a NULL pointer dereference kernel vulnerability. If a page at an address of 0 is mapped and filled with data of their choice the kernel would access the memory page prepared by an attacker. Unsurprisingly, this can quite easily result in arbitrary code execution and the techniques for exploiting systems in this manner have previously been published. The use of this kernel setting should prevent this types of exploitation by enforcing the lowest possible address to a safer value (usually 64KB).

The second setting specifies which process memory sections will have their addresses randomised upon start up. If it's set to 0 randomisation is completely disabled. If it's set to 1 the base addresses of the stack and VDSO pages and mmap requests are all randomised. This also means that shared libraries will be loaded at random addresses as well as the binaries that are compiled as Position Independent Executable (of a type ET_DYN rather than ET_EXEC). When the value is set to two, in addition to all the aforementioned protections, the base address of the heap is also randomised. It should be noted that for PaX enabled kernels (http://pax.grsecurity.net/), the heap is randomised regardless whether the setting is set to 1 or 2.

Paxtest is a test suite initially developed by Peter Busser from the Adamantix project and further developed by Brad Spengler, the author of the Grsecurity patch. The paxtest suite tests various memory protection mechanisms, more details on its workings can be found in its README file. In summary, it performs a number of checks to determine whether it is possible to execute arbitrary code using different memory regions and attack techniques; it also assesses the amount of randomisation of different memory areas. The results are then provided back to the user in a consistent manner allowing comparison between and benchmarking of different systems.

Results

The results of assessing these settings on the target platforms are included here: -

	Debian	Fedora	Gentoo	OpenSuse	Ubuntu
Kernel version	2.6.26-2-686	2.6.33.6-147.fc13.i686	2.6.32-hardened-r9	2.6.31.12-0.2-default	2.6.32-23-generic
mmap_min_addr	4096	4096	65536	65536	65536
randomize_va_space	2	2	2	1	2

The results that were identified are described below.

"mmap_min_addr"

All tested distributions have this parameter set to a non-zero value with the two most common defaults being 4096 and 65536. The latter value will prevent user programs from accessing the first 64 kilobytes (the first segment) of memory. It should be noted that even when set at 4 kilobytes it effectively protects a user from mapping page 0 thus making the exploitation of NULL pointer dereferences significantly harder but not impossible. It should also be noted that some programs will not work correctly if they cannot map a page below the first 64 kilobytes of memory.

"randomize_va_space"
All of the tested distributions except one had this setting set to 2. This is the highest level of randomisation that the Linux kernel can provide without external patches such as Grsecurity. The only distribution that had this value set to 1 was OpenSuse and it is assumed that this is due to the CONFIG_COMPAT_BRK setting being enabled in the default kernel. This option allows the running of legacy binaries (ie. linked against libc.so.5) that would not otherwise be possible. The result of having this value set to 1 is that the base address of the heap is not randomised for binaries not compiled as Position Independent Executables (ET_EXEC instead of ET_DYN).

It was also discovered that on Debian, although the value was set to 2, the heap base addresses were not randomised. This behaviour is the same as if the value was set to 1! This has been reported as a bug and can now be tracked here. All other distributions behaved as expected, with the value set to 2 which provided the best available randomisation on a default kernel.

Paxtest results - arbitrary code execution

Paxtest runs a number of checks to identify if certain memory regions are (or could be made) executable. This checks whether an attacker is able to execute their code if they are able to inject it into a running process. It also checks the randomisation of various memory regions. A detailed description for the tests is included in the README file within the paxtest archive. The results of running this tool on the target platforms are included below.

	Debian	Fedora	Gentoo	OpenSuse	Ubuntu
Executable anonymous mapping	Vulnerable	Killed	Killed	Vulnerable	Killed
Executable bss	Vulnerable	Killed	Killed	Vulnerable	Killed
Executable data	Vulnerable	Killed	Killed	Vulnerable	Killed
Executable heap	Vulnerable	Killed	Killed	Vulnerable	Killed
Executable stack	Vulnerable	Killed	Killed	Vulnerable	Killed
Executable shared library bss	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Executable shared library data	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Executable anonymous mapping (mprotect)	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Executable bss (mprotect)	Vulnerable	Killed	Killed	Vulnerable	Vulnerable
Executable data (mprotect)	Vulnerable	Killed	Killed	Vulnerable	Vulnerable
Executable heap (mprotect)	Vulnerable	Killed	Killed	Vulnerable	Vulnerable
Executable stack (mprotect)	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Executable shared library bss (mprotect)	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Executable shared library data (mprotect)	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Writable text segments	Vulnerable	Vulnerable	Killed	Vulnerable	Vulnerable
Return to function (strcpy)	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Vulnerable
Return to function (memcpy)	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Vulnerable
Return to function (strcpy, PIE)	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Vulnerable
Return to function (memcpy, PIE)	Vulnerable	Vulnerable	Vulnerable	Vulnerable	Vulnerable

As can be observed from the results above, all of the distributions were vulnerable to 'return-to-function' classes of attack. These attacks involve an attacker calling legitimately loaded functions (or pieces of code) in order to achieve their goal. This is an extremely difficult attack scenario to protect against (as programs need to call their own functions, including those included in other libraries) and at the moment there's no “on or off” protection against them. The highest protection can be achieved using a high level of randomisation, which would require a 64 bit address space rather than 32 bit. According to this article a 32 bit address space would allow an attacker to bruteforce the location of certain memory regions thus providing them with a greater chance of successful exploitation.

Another conclusion is that other than the Gentoo Grsecurity enabled kernel, all other distributions are vulnerable, at least to some extent, from known exploitation techniques. In particular Debian and OpenSuse do not offer any additional protection and as a result fail on every paxtest check.

The notable exceptions in the results are Fedora and Ubuntu. Both distributions do not allow the ability to write code to a certain memory region and then execute it. This can be observed from the results of the first five tests. Fedora goes one step further and also prevents the bss, data and heap sections from being marked as executable using the ’mprotect’ system call. It should be noted that there would still be numerous other memory regions where an attacker could upload their code and then use the ‘mprotect’ function to mark it as executable.

It must also be noted that all four distributions - Debian, Fedora, OpenSuse and Ubuntu provide a writable text section. The text section is the section of the binary that holds the program code that is executed. If an attacker can write to this region, they can obviously gain control over the execution flow, by overwriting existing code with that of their choice. It is advisable to have the text segment as read-only; however, it should be noted that this could prevent some the binaries from running when text relocation is required. Text relocation happens when not all of the code (usually a shared library) is compiled as position independent code (PIC) which then forces the linker to write the location of a specific symbols into the text segment at run time.

Another example where a writable memory section is required (in this case the stack) are gcc trampolines. Trampolines are created for nested functions which are functions that are defined inside another function body. More information about nested functions and trampolines can be found here and here.

Paxtest results - randomisation

The paxtest suite checks the level of randomisation for different process sections as well as process types - whether compiled as a standard executable or as a Position Independent Executable.

The more memory that is randomised (and as such has a higher level of entropy), the more difficult it is for an attacker to guess the correct value and thus successfully exploit the vulnerability. It should be noted that 16 bit randomisation gives 2^16 = 65536 possibilities, which means that on average 32,768 tries would be needed to guess the correct value. It is also worth noting that for 32 bit systems, the 32 bit addressing scheme would be an upper theoretical limit of entropy. However, in reality this is further limiter by reserved memory areas (such as the kernel space), the need to align memory mappings to page boundaries (for effective memory management) and the need to map large consecutive memory regions. These factors will further limit the overall entropy associated with the randomisation of different memory regions. It should be noted that the values included in the following table for results are only estimates and not strict results in a scientific sense. That means that running the test multiple times may result in slightly different results being obtained.

	Debian	Fedora	Gentoo	OpenSuse	Ubuntu
Anonymous mapping randomisation test	9 bits	12 bits	17 bits	12 bits	12 bits
Heap randomisation test (ET_EXEC)	No randomisation	14 bits	23 bits	No randomisation	13 bits
Heap randomisation test (PIE)	12 bits	18 bits	23 bits	12 bits	14 bits
Main executable randomisation (ET_EXEC)	No randomisation	No randomisation	15 bits	No randomisation	No randomisation
Main executable randomisation (PIE)	12 bits	12 bits	15 bits	12 bits	12 bits
Shared library randomisation test	10 bits	3 bits	17 bits	10 bits	12 bits
Stack randomisation test (SEGMEXEC)	10 bits	19 bits	23 bits	19 bits	19 bits
Stack randomisation test (PAGEEXEC)	10 bits	19 bits	23 bits	19 bits	19 bits

As can be seen in the table above, Debian, Fedora, OpenSuse and Ubuntu provide a similar level of randomisation for most of the tests. Debian does not provide randomisation for the heap due to the previously mentioned bug. The same result for OpenSuse is a result of the 'randomize_va_space' value being set to 1. It should also be noted that in general, the results indicate that the Debian kernel provides less entropy than other three previously mentioned distributions. An exceptionally low value of randomisation is produced by Fedora for shared libraries. This would make it easier for an attacker to successfully exploit a vulnerability using ‘return-to-libc’ or ‘return-to-code’ attack as the addresses would be easily guessable or possible to bruteforce. The results for Gentoo with its PaX kernel shows that it is possible to achieve better randomisation as every result shows more entropy that of any of the other tested kernels. It should also be noted that the higher values for Gentoo are also the result of the gcc settings which in this case are configured to create Position Independent Executables (ET_DYN) by default.

Conclusion

As described in this article, kernel security settings have a critical impact on the overall security of processes that are executed on Linux systems. Also, a default Linux kernel facilitates the success of a number of exploitation techniques which are because of low randomisation entropy, a vulnerability is therefore not as difficult for an attacker to exploit. A more positive conclusion from this testing is that with patches like Grsecurity, it is possible to significantly improve the security of the kernel and thus the security of the whole system. The installation of this component is therefore something that is highly recommended as part of any Linux deployment. The conclusion can also be reached that whichever distribution you choose to run there are tools available to improve the security over that of the default install as well as those that can help you to measure the robustness of your systems.

The next article in this series will describe different attack strategies that could be used to achieve successful exploitation if control over execution has been gained by an attacker. The assessed software will include the popular OpenSSH daemon and a known vulnerable version of Firefox. To make sure you get to see the results as soon as they are published be sure to subscribe to our RSS feed here, or follow us on twitter here.

Recent Palm webOS Vulnerabilities - MWR InfoSecurity Clarification

Aug 16, 2010

MWR InfoSecurity have recently published information about vulnerabilities affecting several mobile platforms. Owing to errors in the reporting of these issues MWR are publishing this statement to clarify the situation and answer questions that have arisen about the issues and their current status.

In May 2010 MWR Labs identified and reported two vulnerabilities in Palm's mobile operating system "WebOS". One of these vulnerabilities has recently been used by us to demonstrate the impact of security flaws in smartphones to the press. Following on from the publications, articles and blog posts published by various sources have led to some confusion regarding the response to these issues by Palm and their current status. Both vulnerabilities reported by MWR were originally identified in Palm WebOS 1.4.1 and were immediately reported to Palm's Security Team. They speedily responded to our reports, acknowledging the vulnerabilities. Since the disclosure of these issues to Palm MWR InfoSecurity have taken the decision to discuss the presence of vulnerabilities in smartphone platforms. This decision was taken to highlight the risk to users of smartphone vulnerabilities and to ensure the issues are correctly represented within the public domain.

With the WebOS 1.4.5 release Palm fixed one of the vulnerabilities reported to them by MWR InfoSecurity. This vulnerability is an issue in a local service running on the phone and full details of this are yet to be released by MWR. This information will be released once all users have had a chance to install Palm's fix.

The issue that Palm has not currently addressed is the vulnerability in the vCard parsing, which was demonstrated by MWR InfoSecurity on the 11th of August. However in recent conversations with members of Palm's security team they stated that a fix is planned for Autumn 2010. Owing to the current situation users are therefore advised to exercise caution until an appropriate vendor supplied patch has been provided.

Just Arrived! - Max Pwnage

Jul 16, 2010

After much anticipation we are pleased to announce that the new Max Pwnage cards from MWR Labs are now available. The cards highlight the impact of a number of high profile security vulnerabilities that have affected systems and networks over the past 30 years. It has also been identified that the Max Pwnage cards can also be used to play an exciting game of skill and chance although this is purely a coincidence.

How do I get my hands on a set?

If you are an existing client of MWR InfoSecurity then speak to your contact within the company and they will be able to provide you with your own set. If you aren’t fortunate enough to already work with the company there are a number of ways you can get your hands on a set. Simply speak to an MWR consultant at one of the many public security conferences that they will be attending in the coming months. You will find consultants either attending or speaking at the following events:

Black Hat Briefings – Caesars Palace Hotel and Casino, Las Vegas, Nevada, USA (July 28th, 29th 2010)
Defcon 18 – Riviera Hotel and Casino, Las Vegas, Nevada, USA (July 30th – August 1st 2010)
Sec-T Security Conference – Rio Theatre, Stockholm, Sweden (September 10th, 11th 2010)
Making Sense of Risk (Invite Only) – Altitude 360, London, England (September 23rd 2010)
T2 Security Conference – Radisson SAS Royal Hotel, Helsinki, Finland (October 28th, 29th 2010)

Further events will be announced in the near future so please keep checking the MWR Labs website for an opportunity to get your hands on these highly sought after cards.

Who is Max Pwnage?

Max is a shadowy character who is responsible for finding and exploiting vulnerabilities in computer systems. Keep your eyes open for him as he is always on the trail of emerging threats and issues that could affect the security of your computer or your business.

Palm webOS 1.4.5 fixes security issue found by MWR InfoSecurity

Jul 07, 2010

Palm has released version 1.4.5 of its mobile operating system, this release fixes an issue found by MWR InfoSecurity. Most mobile carriers have started to push the update to their customers. As soon as the majority of devices have been fixed we will release a detailed advisory on this issue.

The Palm release notes are available here:

http://kb.palm.com/wps/portal/kb/na/pre/p100eww/sprint/solutions/article/68919_en.html#145

Assessing the Tux Strength: Part 1 - Userspace Memory Protection

Jun 29, 2010

Introduction

This is a first of a series of articles describing different security mechanisms and exploitation mitigation techniques available in Linux environments and their use across various Linux distributions. This article focuses solely on userspace protections. Subsequent articles will focus on specific software such as web browsers or network daemons and their security exposure as well as additional kernel security mechanisms and frameworks that are available.

Memory corruption attacks are still a very common way to compromise a modern computer system. However, the once basic techniques of buffer overflows have evolved into more sophisticated memory corruption attacks and at the same time the mechanisms to protect the integrity of processes and system memory has also improved.

Probably every attack mitigation technique that has been developed over time to mitigate memory corruption exploits can be implemented and used in one form or another in a Linux operating system. Many people argue that some of the protection mechanisms are more effective than others, for example by mitigating against a larger number of different attacks. Furthermore, a number of them arguably have a performance impact on the system and could also produce some challenges in terms of compilation of the specific software as well as in ensuring compatibility with the rest of the system.

It is probably safe to say that these two factors (the impact on performance and the maintenance overhead) are the biggest obstacles to have all of these mechanisms implemented and enabled by default in any given Linux distribution. As with any complex software and development effort (particularly those that are open source), it comes with no surprise that it is possible to find some political or at least ideological issues at play as well (e.g. the wide ranging discussions between Grsecurity and the main kernel development teams). Therefore, as we will see within this document different distributions have different mechanisms and protection enabled by default. A comparison has been completed between the default stable releases of five popular Linux distributions - Debian, Fedora, Ubuntu, OpenSUSE and Gentoo Hardened relating to key protection mechanisms which can contribute to the overall security of the system. The author believes that the first four named distributions would be most prevalent across enterprise environments; Gentoo Hardened has been chosen as a comparison point, as this distribution aims to provide the user with the ability to have all of the considered security mechanism enforced system wide with relative ease, although with much greater time requirements due to the need of compilation of the software.

The exact versions of Linux distribution that have been assessed are as follows:

•    Debian 5.0.4
•    Fedora 13
•    Gentoo - hardened stage 3 tarball and stable portage tree
•    OpenSUSE 11.2
•    Ubuntu 10.04

Stable x86 32-bit releases were used and all systems were tested within virtualised environments using KVM virtualisation. All systems were tested on an Intel processor with native support for the NX bit and virtualisation.

The following security mechanisms were considered:

•    Non Executable memory mappings (use of the hardware NX bit)
•    Position Independent Code/Executable (PIC/PIE)
•    FORTIFY_SOURCE feature of modern glibc implementations
•    Stack Smashing Protection (SSP) - also known as stack canaries
•    RELRO - enables hardening of the ELF executable by reordering certain file sections and marking them read-only

The following tools have been used for comparison:
•    checksec.sh - with a small modification to show status of FORTIFY_SOURCE.
•    Custom python script that expanded on the ‘checksec.sh’ functionality

All sample data was taken with a user logged into an X session with a running sshd daemon and Mozilla Firefox browser. As the distributions varied in the number of processes that were started by default, in some case a single process had a bigger impact on the overall percentage score as for instance Ubuntu was by default running 96 processes versus 34 processes on Gentoo!

According to its Wikipedia entry, the Linux kernel has NX bit support since the 2.6.8 release in October 2004. It is enabled for both 32-bit and 64-bit kernels for hardware that has the NX bit. In order to take advantage of non-executable memory mappings on hardware that does not support the non-execute bit, it is necessary to use the grsecurity patch or alternatively the Exec Shield patch from Red Hat. It should also be noted, that without additional protections an attacker could easily bypass the NX bit for instance by manually adjusting the permissions that are set on a given memory page. Nevertheless, as this is a realm of the Linux kernel and will therefore be discussed in greater detail in future articles.

It should also be noted that apart from the NX bit support, all of the protection mechanisms discussed here are to be implemented in the userspace and not at the kernel level. It is important to acknowledge that a vulnerability within the Linux kernel could be exploited regardless of the protection mechanisms that are enabled for the user space processes. It is possible to compile modern kernel with Stack Smashing Support (SSP) (using the gcc -fstack-proctector option enabled in kernel configuration), although additional kernel security enhancements would often require applying external patches such as the grsecurity patch. Some distributions tend to maintain their own set of kernel patches that include some additional security features. Nevertheless, as mentioned earlier kernel security issues are excluded from this article and will be included in a future part.

A closer comparison of all of the five distributions revealed differences in approaches to security mechanisms that are enabled by default. The detailed results of the testing are presented and described below (all graphs are shown as a percentage of all running binaries).

RELRO

RELRO protects internal data structures of an ELF file from being used by an attacker to gain control of the execution flow. This is achieved by modifying the PLT (Procedure Linking Table) or GOT (Global Offset Table) sections of the ELF file. When full RELRO is used, the whole GOT is marked as read-only when the process is running and therefore cannot be modified by an attacker. For partial RELRO, only PLT-GOT is marked as read-only. Both options also reorder internal ELF data structures, such that internal structures precede other sections and as such are protected should an attacker be able to overflow other ELF sections. It should be noted that full RELRO requires all symbols to be resolved during the start-up of a binary (so the GOT can be marked as read only) and as such could result in a longer start-up time for big applications that would need to load large number of symbols for all shared libraries.

As can be noted from the diagram above, Debian and Fedora do not take full advantage of this mechanism, having it enabled in partial mode only for a small percentage of binaries. In our test case, Fedora and Debian did not support full RELRO for any of the binaries that were run by default. On the other hand, OpenSUSE and Ubuntu supported at least partial RELRO for all processes and full RELRO for small number of them (with Ubuntu reaching about 14% of all tested binaries). Gentoo Hardened had the full RELRO option enabled for all processes but one, which had partial RELRO enabled (Xorg). On the other hand, the only running binary in OpenSUSE during our test which had full RELRO enabled was pulseaudio. Given previous security issues in pulseaudio this is a good thing; however, it is worth noting that OpenSUSE does not use the setuid bit on this binary. The only binary on Debian that had partial RELRO support was the ‘dbus-daemon’ process.

Stack Canaries

Stack Smashing Protector makes it more difficult to exploit buffer overflow vulnerabilities by implementing additional security checks on the process stack. The SSP extension has been available in the GCC compiler since the 4.1 release.

As can be observed on the graph above, it is quite prevalent in Fedora, OpenSUSE and Ubuntu, with all of these distributions varying around 80% of all processes that have this feature enabled. Remarkable differences can be observed in Debian and Gentoo, where about 10% of checked processes have it enabled. In case of Gentoo Hardened this is due to internal issues which needed to be addressed before this functionality could be made available globally. This has been recently addressed and is currently available in a testing release of the gcc compiler and is expected to be moved into stable tree after a 30 days of testing period.

FORTIFY_SOURCE

The FORTIFY_SOURCE is a protection mechanism that attempts to prevent buffer overflows by replacing insecure functions with their secure equivalents as well as terminating execution of a process if an overflow has been detected. It should be noted that where buffer sizes cannot be determined during compilation or runtime, some exploits might be undetected by this mechanism. It also adds additional protections against format string vulnerabilities. More information about FORTIFY_SOURCE can be find here and here

It should be noted that the script used to assess the presence of the FORTIFY_SOURCE only checked if a symbol for an 'armoured' version of a function is present in a given binary. In theory, it is possible for a binary not to use any 'fortified' function, or a condition which cannot be fortified (unknown buffer sizes prior to execution) which could result in a false positive result. Also, if the sizes of all buffers are known before compilation, there is no need to use fortified function and as such it will not be replaced. This again could result in a false positive. For the FORTIFY_SOURCE option to be used, the binary needs to be compiled with the optimisation flag set to at least value of two. This is done by passing the '-O2' option to gcc during compilation.

As can be observed from the graph above, all compared distributions except for Debian make good use of this protection with the amount of enabled binaries reaching around 80% percent. Gentoo reaches around 90% which could indicate that other distributions could potentially enable it for few more binaries, although it should be appreciated that Gentoo runs far fewer processes by default than its counterparts. In this test, Debian had this feature enabled on two processes (3%) of all those that were tested, both of which belonged to the kerneloops package.

Position Independent Executables (PIE)

The ability to predict memory addresses of a process and its sections is a great aid for an attacker attempting to exploit a system. Although in recent years more memory randomisation support has been incorporated into operating systems, most of the binaries will still be loaded under the same address in any given Linux system. Unless they have been compiled as a Position Independent Executable (PIE) that is. Having a binary compiled as PIE allows the operating system to load and map all of the process sections at random addresses during runtime. This makes exploitation much more difficult provided that randomisation provides an acceptable level of entropy; a 64 bit system will be able to provide much better randomisation than a 32 bit system due to bigger address range available to the operating system.

All modern kernels have the ability to randomise certain memory segments of a process address space even if it has not been compiled as a position independent executable (PIE). This is controlled via the randomise_va_space setting in the proc filesytem. When set to 2, Linux will randomise stack, heap and mmap() requests, when set to 1, only stack space will be randomised. Nevertheless, as mentioned earlier, there could be a number of other memory sections of a process that would be mapped at the same memory addresses. Hence compilation of code as PIE/PIC allows the loader to run an entire binary from different memory regions each time, thus forcing an attacker to guess or bruteforce the correct memory mappings. It should be noted that Position Independent Code can have performance hit on x86 architectures, which is assessed by different sources to be usually between 1% and 5%. This can especially occur if a compiled binary needs to use non-PIC code using so called text relocation mechanism (TEXTREL). Moreover, some software, specifically if using machine specific assembly code, might refuse to compile as PIE all together.

As can be seen on the graph above, most of the compared distributions do not take advantage of this mechanism on the large scale. Values differ from 8% (Debian) to OpenSUSE (21%) while Gentoo Hardened achieves 100%. It should be noted that other distributions have this feature enabled for ‘high risk’ processes such as network enabled services like SSH. However, apart from Gentoo Hardened, only Ubuntu enables PIE by default for the Mozilla Firefox browser. Given the track record for vulnerabilities that have been discovered in a number of different browsers and attackers interest in them, one could expect that the binary is better armoured to withstand such attacks. Experience shows that the end user will very likely rely on and never change the default security measures that are enabled by a vendor. It would therefore be a good practice to embed in a rollout process of at least most critical binaries, an assessment of security measures that are enabled during package creation by distribution maintainers.

Conclusion

As has been discussed within this paper a number of effective and well tested security measures exist in a Linux environment; however, with minor exceptions they are not widely used or deployed by default. Also, different Linux vendors tend to have different approaches to using specific mechanism in their distribution. Although in some case more exposed binaries (like network daemons) have additional protection enabled (mostly PIE), others, like web browsers, mostly didn't. Where they were enabled, apart from instances mentioned earlier, it seemed that this was more of an accidental use or a mainstream developer decision rather than a consistent distribution policy.

As proved many times before there are no silver bullets to all security woes for Linux users. Different distributions will have different security mechanisms enabled by default and there seems to be no clear winner in this contest. While the Gentoo Hardened project can provide you with the highest use of the available userspace memory protection mechanisms, it is definitely not for faint hearted and you probably need to get your hands dirty to get the most of it. Maybe it is time to start asking your favourite distribution about their policy for security mechanisms described above?

The next article will focus on default and additional protections within the kernel itself which are enabled in the Linux distributions described above. This will be then followed by closer view on the practical side of exploitation of Mozilla Firefox and OpenSSH binaries running on different distributions with different protection mechanisms enabled.

CanSecWest 2010

Mar 30, 2010

Authors: Adam Bateman and Alex Plaskett

Vancouver, Canada.. Home to this year's winter Olympics but more importantly to CanSecWest 2010! Whether participating to present their latest research to the community or simply to observe, the three day security conference attracts highly respected security professionals from around the globe. The conference consists of a single track of presentations, varying from issues which have been discussed for many years previously to the cutting edge in security research.

This year's Pwn2Own contest challenged applicants to compromise a number of mobile devices and desktop web browsers for a chance to keep the target device as well as a cash prize. Nils from MWR InfoSecurity entered the contest armed with a zero day for the latest version of Firefox and won a Sony Vaio laptop running a fully patched version of Windows 7 using his exploit. Safari was claimed by Charlie Miller and Internet Explorer 8 by Peter Vreugdenhil with Google Chrome being the only browser left undefeated for the second year running. Out of the four mobile devices up for grabs Vincenzo Lozzo and Ralf Philipp Weinmann were the only contestants to submit and successfully exploit a vulnerability. This one was in Mobile Safari on the iPhone which allowed them to retrieve the phone's SMS database. The full details of the contest can be seen at: http://dvlabs.tippingpoint.com/blog/2010/02/15/pwn2own-2010.

In no particular order, below is a summary of some of the talks which stood out to us this year:

:: ShareREing is Caring Halvar Flake and Sebastian Porst, zynamics GmbH
ShareREing introduced the BinCrowd software used for collaborative sharing of reverse engineering information between team members. This software also provided a way to find and match functions which have been previously analysed by the BinCrowd in other software and thus reduce the amount of analysis a reverse engineer would need to repeat. This software was found to be especially useful because it could perform matching across code generated by different compilers. It seems very likely this software will be useful in future reverse engineering projects. More technical information can be found on the zynamics blog:

http://blog.zynamics.com/2010/03/25/shareing-is-caring-announcing-the-free-bincrowd-community-server/

:: Babysitting an army of monkeys: an analysis of fuzzing 4 products with 5 lines of Python - Charlie Miller, Independent Security Evaluators
This talk consisted of discussing the techniques used to find a number of vulnerabilities in certain vendors' software. It discussed Charlie's methods for locating vulnerabilities (fuzzing) and analysis of the results. I found this talk interesting because there tends to be a lack of fuzzing results in the public domain, the methodology used to find the vulnerabilities and what metrics were used to determine the exploitability of them. The trends discussed throughout this presentation demonstrated significant differences between particular software and demonstrated where security had been incorporated into the product's development life cycle.

:: There's a party at ring0, and you're invited. - Julien Tinnes & Tavis Ormandy, Google
There's a party at ring0 talk covered a number of kernel level vulnerabilities used for privileged escalation on both the Windows and Linux platforms. My personal passion for low level technical details was satisfied and the talk was quite thought-provoking on the challenges faced in defensive kernel security. Although the vulnerabilities found here were very impressive it would have been interesting to expand on some of the vulnerabilities and explain the architecture of the kernel subsystems in greater detail. It's expected due to the large amount of vulnerabilities and variations in these that time constraints may have prevented this.

:: Practical Exploitation of Modern Wireless Devices - Thorsten Schroeder and Max Moser, Dreamlab Technologies
Despite the unfortunate technical difficulties which caused the projector to repeatedly cut out throughout the talk, Thorsten delivered a thought provoking presentation that was well received by the audience. Thorsten presented his research into the security issues related to wireless peripheral devices with a primary focus on wireless keyboards. He revealed the results of his analysis of the wireless protocol implemented by Microsoft and Logitech and the implementation of their Keykeriki V2 software which is capable of sniffing keystrokes in real-time as well as performing command injection. The presentation concluded with a demonstration of an attack which successfully executed commands and launched calc.exe on the target system followed by Thorsten stating that "range testing" revealed that the attack could be launched from an impressive 70 meters.

In summary, the high quality of a number of talks, the opportunities to discuss security issues with like-minded people and the motivation produced by the conference all provide a good reason to attend CanSecWest. It is expected that the research demonstrated at CanSecWest will provide a great benefit for the security community and help drive on further work both within MWR InfoSecurity and the industry at large.

Aurora and Web Browser Security

Jan 25, 2010

Germany's BSI (Federal Office for Information Security) recently warned web users not to use Microsoft Internet Explorer. The BSI advised users to switch to an alternative browser in the mean time until a patch was made available. Shortly after this release France's Certa agency also issued a similar warning to users.

What is the implication of these statements? It would seem like an 0day for an "alternative browser" has just substantially increased in value.

But even though these alternate browsers might be safer to use given the current threat, are they actually more secure? To reach a conclusion about whether this is actually the case it is necessary to look at the actual risk of successful exploitation, assuming such 0day exists somewhere. This assumes that entities or groups with sophisticated skills who are capable of writing exploits while sleeping and by-passing DEP at breakfast also exist (which is a fair assumption).

On a current Windows 7 system with fully updated browsers the following situation currently exists: -

DEP/ASLR in browsers on Win 7
	IE 8.0.7600.16385	Firefox 3.6	Opera 10.10	Safari 4.0.4	Chrome 3.0.195.38
DEP	Enabled	Enabled	Enabled	Enabled	Enabled
ASLR	No DLL without ASLR in default process	Not properly used e.g. nspr4.dll	Not properly used e.g. opera.exe	Not properly used e.g. dnssd.dll	Not properly used e.g. icudt38.dll

We tested the default up-to-date installation of each browser in the table above on the Windows 7 Operating System. It should be noted that these results will vary substantially on different operating system versions. The actual ease of exploitation for these targets depends on a number of factors, for example, sandboxing techniques such as the Google Chrome Sandbox or IE 8's protected mode. Also, other weaknesses may allow DEP/ASLR to be bypassed such as the now patched Dowd/Sotirov technique. For the purposes of this assessment a measurement about the effectiveness of ASLR was obtained by observing the addresses of executable modules loaded in the default process.

Aside from the effort needed to produce a reliable exploit, another important factor in the risk exposed by the use of a particular browser is its market share. Internet Explorer is still is in the (un)fortunate situation of being the market leader, which makes it a juicy target for the bad guys.

In order to make web browsing safer, effective OS exploitation mitigations techniques and a fully updated browser are essential. Make sure you apply the Internet Explorer patch which was released on Thursday.

Update:

As of the 31th March 2010 the following updated browser versions still do not opt-in to ASLR properly:

Firefox 3.6.2, Chrome 4.1.249.1045 (42898) (now icudt42.dll), Opera 10.51 and Apple 4.0.5 (AppleVersions.dll).

The recent changes to Safari are notable, as AppleVersions.dll is the only binary left not opting-in to ASLR, hopefuly this will be fixed in the next release. We will continue monitoring the status of the browsers on a regular basis.

Google Forensics (...beta)

Jan 18, 2010

Author: Ben Downton

File carving is a technique that can be used by forensic investigators to recover files from a disk. Forensic software can search through the raw data against a set of known file header signatures and extract items based on content rather than metadata.

This is particularly useful when examining the free space on a disk, as files that may no longer exist within the file system can be recovered. This can be particularly useful if the file system has changed, such as when a Windows system has been rebuilt as a Linux box.

It will not always be possible to recover the full path or original creation dates by file carving, as only the data contained within the file might remain. But the data itself can sometimes contain more information than timestamps could provide...

On the surface, the extraction of a Google logo from temporary internet files might not appear to be of any real relevance to a forensic examination. But what if the Google logo was of the Cookie Monster? This logo was created to commemorate the 40th anniversary of Sesame Street, and replaced the standard Google logo on the site in selected countries on the 5th of November 2009. Similarly, forensic examiners viewing a pumpkin instead of the 'e' of Google can be fairly confident that the site was visited on the 31st of October 2009. A plasma covered logo from Nikola Tesla's birthday indicates activity on the 10th of July.

Whilst this technique cannot, of course, provide indisputable evidence, it demonstrates how the content of web based files can be used to build a more complete picture of how and when a machine has been used. It could even allow other evidence to be collected that may aid a case, particularly when recovering data from file or volume slack.

http://www.google.com/logos/

Solaris Debugging and Bug Hunting at ShmooCon 2010

Jan 18, 2010

Matt Hillman will be presenting the fruits of his Solaris research thus far at ShmooCon in Washington DC on the 6th of February. The abstract for his talk is shown below:

"Lately there has been a lot of excitement over the use of DTrace for bug hunting and reverse engineering purposes on platforms that support it such as Solaris. But there are a plethora of advanced tools and techniques out there for other more common x86 based platforms, so does DTrace really add that much? In this talk that question is examined by introducing RSol, a Ruby based debugging component for Solaris in a similar vein to PyDebug for Windows. RSol allows powerful bug hunting tools to be coded quickly, and using this the pros and cons are investigated of using DTrace vs more traditional debugging techniques to achieve different goals in different circumstances. The ultimate plan is for RSol to become a suite allowing debugging and DTrace based techniques to be used together in a complimentary way."

If you can't make it to DC to see the talk, it will also be streamed live (along with the rest of ShmooCon) via uStream. This is the first year ShmooCon have done this, so lets hope it goes without a hitch!

Demo: Adobe Reader Exploit on Vista and 7

Jan 14, 2010

In response to the recent vulnerability in Adobe Reader MWR InfoSecurity conducted some additional research in this area. We were able to confirm that the issue, otherwise referred to as Adobe Reader "media.newPlayer" vulnerability, is also exploitable on Vista and Windows 7 with ASLR and DEP enabled. This can be observed in the following flash demo: -

Click here to view the demo

The research enabled an exploit to be crafted that works very reliably across multiple versions of Adobe Reader. Given these facts MWR InfoSecurity highly recommend that everyone running the software installs the appropriate patch for the issue using the adobe update software. In addition it is recommended that JavaScript support within Adobe Reader is also disabled.

DeepSec 2009

Dec 03, 2009

Author: Ranjit Sandhu

The DeepSec security conference was held between November 17th and November 20th at the Renaissance Hotel next to the Imperial Riding School in Vienna. MWR InfoSecurity were invited to speak at the event for the second year in a row with Luke Jennings presenting a talk about attacking deployment solutions. The event was well managed and both attendees and speakers were well looked after by the organisers. The conference had a nice intimate feel to it and is focused across a range of topics that would be of interest to security consultants, security researchers and security managers in equal measure. The quality of the talks was of a good standard and some of those that stood out are outlined here:

Top 10 Security Issues Developers Don't Know About
Presenter: Neelay S. Shah

This presentation looked at a number of interesting issues that could assist security consultants when performing security assessments and also help to increase awareness among developers so they can ensure their applications are not vulnerable to them. The talk covered a wide variety of security issues including those associated with the use of IPC, named pipes, cryptography, applications that create new processes and the issues that can be manifested when developing and deploying Active X controls and thick clients. This talk is highly recommended whether you fall into the category of security consultant or developer and want to be aware of wider security issues that fall outside the OWASP top ten.

Ownage 2.0
Presenter: Saumil Udayan Shah

Saumil set the tone of his talk by commenting on how applications and software are becoming more complex and how secure coding practices often get overlooked when deadlines have to be met. He then talked about the different attack surfaces including browser attacks such as the use of a number of browser plugins that could be used to take control of a browser. He gave an example of an exploit that affects the PDF plugin for IE 7 that could be used to execute code on the victims’ host when they access his web page. In addition he talked about how the exploit could be distributed via the use of social networking sites.

He also explained how different security issues could be used to roll out exploits to mass targets by exploiting flaws in other systems. Saumil provided an example where he could use SQL injection to inject malicious code into a vulnerable area which would then execute code on the host of any user with vulnerable software and that used this web application functionality. This talk is recommended to anyone who wants to understand how browser plugins, malicious payloads and client side attacks can be used in combination to perform mass pwnage.

Stoned déjà vu - again
Presenters: Peter Kleissner and Michael Eisendle

The buzz around this talk immediately indicated that it was going to be something interesting due to the media interest and the fact that Peter may be facing a law suit in the near future. As a result of this he was not able to refer to his notebook when writing the talk as this had been seized as evidence. Nevertheless, the talk was still very interesting. Peter talked about the stoned bootkit which is a Windows bootkit that can gain unrestricted access to the entire Windows system even if certain whole disk encryption products are used. This is due to the MBR not being encrypted which is where the stoned bootkit is stored.

The second part of this talk was based on Michael's work on an RST (Remote Surveillance Tool) which is a toolkit that can be used to monitor and manipulate computers through the use of various technologies and Web 2.0 services.

Keykeriki - Universal Wireless Keyboard Sniffing For The Masses
Presenters: Thorsten Schröder and Max Moser

This talk focused on a universal 27 MHz wireless keyboard sniffer called Keykeriki that can allow keyboard strokes to be sniffed and commands to be executed at a distance of up to 75 meters. The guys showed a demo against a Logitech Wireless keyboard using the hardware and software that they have developed. This was a very cool talk and shows the importance of ensuring that hardware development is subject to the same security controls that software is. Further information on the talk can be found at:

http://www.remote-exploit.org/Keykeriki.html

eKimono: detecting rootkits inside Virtual Machine
Presenter: Nguyen Anh Quynh

There have been a number of talks on VM security in recent years so it was interesting to find out about this talk. Nguyen’s talk focused on eKimono, a Rootkit scanner for Virtual Machines that runs in the host machine and runs scans that can detect malware in the guest machine. After giving a introduction to VM architecture and eKimono, he then gave a demo of eKimono in action. This presentation applied to Windows machines running the Xen VM and this talk is recommended for all those who are interested in VM security or have to perform a security audit against VM hosts.

Cracking GSM Encryption
Presenter: Karsten Nohl

This talk focussed on A5/1 encryption and the fact that even though it has a number of flaws, there is still no public exploit available. Karsten hopes to change this in the next few months and this talk explained why GSM should not be used for security systems and how the A5/1 encryption is vulnerable to pre-computed rainbow table attacks. Although A5/1 rainbow tables have been generated in the past, they were never released, but it looks as if the project has picked up again. Only time will tell if they are to be released this time? For further information about his work go to:

http://www.reflextor.com/trac/a51/

A practical DOS attack to the GSM network
Presenter: Dieter Spaar

The first thing what was guaranteed to happen after this talk is an increase in the price of the TSM30 mobile phone. This is because Dieter used this phone to perform his DoS attack against a GSM network. In order to demonstrate this, Dieter had access to a test GSM network which had been appropriately provided by the powers that be. This talk is recommended for all those who have an interest in GSM security.

Presentation: DeepSec 2009 - Weapons of Mass Pwnage: Attacking Deployment Solutions

Dec 03, 2009

Luke Jennings presented at DeepSec '09 in Vienna, Austria regarding the security of deployment solutions and some of the recent vulnerabilities he discovered in Symantec's Altiris Deployment Solution. The slides for this presentation are available from:

http://labs.mwrinfosecurity.com/files/Publications/mwri_deepsec09_weapons-of-mass-pwnage_2009-11-20.pdf

Singing the Mainframe Security Blues?

Nov 17, 2009

Author: Martyn Ruks

As an Information Security Officer what is the one question that the non-technical executives ask you the most? Usually it's as simple as "Are we secure?" - and the answer had better be "Yes". Anyone who's had to back that answer up will have done their background research, been to conferences, read books and talked to their counterparts in other companies. Invariably this will have equipped you with knowledge of IT security from port scans and exploits through to Trojans and viruses. Armed with this knowledge you can understand the need for firewalls, IDS, anti-virus and how their effectiveness should be confirmed through penetration testing.

But what if your most critical data is held on a mainframe? Did they teach you about this at hacker boot-camp or in those hacking text books? But does that matter? After all, you know about IP and the ways that hackers try to attack your systems using it. You have firewalls on your network and have regular pen tests completed against your systems. Given this knowledge, the answer to the question is "Yes, we are secure".

But still there's that worry at the back of your mind - that there is something you haven't thought about. If you are in the information security industry you know about that voice, call it paranoia, call your natural distrust. What is it about the mainframe that makes you nervous? Is it the fact that - in essence - that big metal box downstairs is your business? Just what is it our subconscious trying to tell us.

Well, maybe that little voice in your head is trying to tell you to think outside the Internet Protocol. Your network is routing IP packets around and your firewalls are happily filtering the hostile ones. But what about the other protocols, whether it be IPX, SNA, DECnet, NetBIOS or OSLAN. Do you know what they are doing? Why they are there? What risks they expose? If you're having to think about the answers to those questions, then are you still so sure about the answer you gave to the Chief Exec?

Let's start to get this back into perspective then; for example, what if you have an IBM mainframe and it's not running an IP stack. Well, you‘re going to need to know about the protocols it is running; one that will almost certainly be present is the Systems Network Architecture (SNA). Let's start with a brief history lesson.

SNA was announced by IBM back in the late 1970s and was designed as a unified architecture that could connect user terminals to the mainframe. Whilst various extensions have been added to the architecture, the protocol itself has remained largely unchanged over the years. Indeed, the biggest changes have been in the ways the protocol has been deployed onto corporate networks. In the past, the network infrastructure included various hardware devices such as Cluster and Network Controllers and fixed line, point-to-point network links. In this environment SNA security wasn't a problem, it was reliable (when it wanted to be), and it was less exposed than it is today. But then - the types of threat that we see today just weren't as prominent.

Over the years this older hardware has gradually been replaced and now SNA traffic will probably be bridged over Ethernet or could be encapsulated using protocols such as Data Link Switching (DLSw). However, it is also possible to use an SNA gateway to convert IP traffic into SNA. So, while the core of the SNA protocol has remained essentially constant, new technologies have emerged and evolved around it; and it is for this reason that your network could be at risk.

It is a given that the protocols and technologies used today have their weaknesses (be they known or unknown) and that if they are configured incorrectly this can enable an attacker to gain access to your most critical data. This is equally true when they are used to provide your users with access to your mainframe.

So if SNA is so dangerous in modern environments why do we still use it? Well, firstly it would simply prove too costly to migrate the legacy applications which still use it; secondly, the dangers associated with these protocols are not widely understood, and certainly aren't documented anywhere.

So what can we do to mitigate the risk and ensure that our systems are secure? Before you can apply that good information security practice we mentioned earlier you will need to understand how your network operates. It will be much easier to understand the risks if you understand how SNA works. You should use all the resources at your disposal, including any colleagues or external companies who understand the protocols and their inherent risks. This knowledge is often lacked by those security professionals who have grown up in the age of IP.

So, by correctly identifying the risks that need to be mitigated you will be able to identify methods for introducing additional security controls. Only then will you be in a position to secure your networks in the most appropriate manner, and to know whether this can be accomplished through configuration changes, or if it will require a fundamental redesign of your network.

And, of course, if you are using another protocol rather than SNA, the answer will be the same. Understand the technology and how it operates in your environment as fully as possible, evaluate the associated risk and then minimise it in the most appropriate manner.

The biggest challenge in securing your networks is understanding the source of the risk. Once you understand this it is much easier to take the right approach to securing your network. And that means that the next time you are asked whether you're secure, you can answer with confidence

"Yes, we're secure!".

Attacking Altiris at DeepSec '09

Sep 07, 2009

Luke Jennings will be talking at DeepSec '09 in Vienna, Austria on 20th November 2009 regarding the security of deployment solutions and some of the recent vulnerabilities he discovered in Symantec's Altiris Deployment Solution.

https://deepsec.net/docs/speaker.html#PSLOT39

If you are interested in this, be sure to come along!

USB Research to be Presented at t2'09

Sep 01, 2009

Following the talk presented at Defcon 17 this year, Rafa continued his research in USB attacks and will provide an update of his research at T2 in Finland on Thursday 29th October 2009. The presentation will cover a wide range of security considerations for the use of USB devices. However, it will specifically focus on the evolution of an attack that can be delivered through a malicious USB device. The talk will also include discussion about the methods that can be used to identify and exploit vulnerabilities in USB drivers and their advantages and disadvantages.

Defcon 17

Aug 07, 2009

Author: John Fitzpatrick

Vegas, The Riviera, Hardware Hacking Village, Lock-picking Village, a whole host of talks, iPhone users filling the wall of sheep, fake ATM in the foyer, yep its DefCon17. Here is a quick overview of some of the talks I attended in no particular order:

Locally Exploiting Wireless Sensors & An Open JTAG Debugger - Travis Goodspeed

Travis had two talks lined up this year, "Locally Exploiting Wireless Sensors" and "An Open JTAG Debugger". It would be an understatement to say that Travis knows a lot about microcontrollers and in his wireless sensors talk he showed how you could extract an encryption key from a device in order to give yourself a foothold on the wireless network. In the break out session there was some discussion about how this could enable someone to break into "smart" land mines. As Travis said, its pretty inconvenient if the enemy blow up your land mines whilst you are crossing them!

The talk on JTAG covered Travis' open JTAG project for which he has built an open source USB JTAG adapter, named the GoodFET, which can work with multiple different chips through re-flashing. There were clearly a lot of difficulties to overcome during this project, it sounded like this was primarily down to a lack of publicly available information on the hardware. This talk also looked at methods for getting around a blown JTAG fuse. In the breakout session afterwards we saw how it's possible to use a disposable camera to blow the innards of a chip such that you could no longer use JTAG to debug at all - very cool.

Win at Reversing: Tracing & Sandboxing Through Inline Hooking - Nick Harbour

I saw Nick's talk last year on pescrambler which was pretty cool so this talk was one on my list of 'must attend talks'. This year Nick talked about using inline hooks to monitor a function call and demoed a tool he has written called API Thief which uses DLL injection on a process whilst in a suspended state in order to hook functions. The quality of the data output was significantly better than comparative tools, however, I haven't had a chance to play with it yet.

USB Exploits - Rafael Dominguez Vega

The first thing we learned from this talk is how it feels to be a sardine, it was packed and a lot of people couldn't get in to see it. Despite working with Raf I hadn't had an opportunity to see this presentation before the day. You know a good presentation when the powers that be request that it is censored! Nevertheless, Raf presented some excellent stuff which really should get people thinking about whether they should disable USB by default on their new system builds. The slides are on the Labs website so take a peek for yourselves (http://labs.mwrinfosecurity.com/projectdetail.php?project=12&view=publications) - I believe these differ slightly from those on the DefCon CD.

0-day, gh0stnet and the Inside Story of the Adobe JBIG2 Vulnerability - Matt Richard, Steven Adair

Remember the Adobe JBIG2 vulnerability? These guys know a lot more about it than most and set out to answer some key questions, such as who was behind it, but also whether the disclosure was handled appropriately.

Adobe users were exposed to a vulnerability being exploited in the wild for quite some time, and no patch seemed to be particularly forthcoming. So, ShadowServer went down the partial disclosure route making people aware of the issue and a workaround. This inevitably led to full disclosure and PoC code being posted to Milw0rm. This raised questions about the most appropriate methods for disclosing vulnerabilities responsibly. Is it responsible to not disclose fully? Partially? These questions don't get any easier when something is known to be being readily exploited in the wild.

Router Exploitation - FX

The authority on hacking Cisco was talking... Now, in the past we have seen plenty of Cisco vulnerabilities but a distinct lack of decent exploits; successful compromise of Cisco equipment has traditionally relied on misconfiguration or insecure configuration of the device. FX went through some reasons why this may be the case and covered some of the architectural reasons for the lack of decent exploits and how we can go about writing Cisco shellcode. Perhaps we will start to see more Cisco exploits in the future...

EuSecWest 2009 Run Down

Jun 04, 2009

Author: Luke Jennings

I recently had the good fortune to attend EuSecWest 2009. EuSecWest is one of those great conferences where it’s full of very knowledgeable, like-minded individuals but is small enough that by the end everybody kind of knows everybody, if they didn't already! The talks were all very technical and of good quality I had the pleasure of engaging in many interesting discussions. Here are a few highlights from talks that interested me in particular.

Evolving Microsoft Exploit Mitigations
This covered the main exploit mitigations that have been introduced into Windows over the years, such as DEP, SafeSEH, GS Cookies and ASLR. Information on how effective they have been and where they have conflicted with other quality areas outside of security, such as performance, was included. It was interesting to see exactly which historical exploits would have been made completely unexploitable by these mitigations (and it was the majority).

PCI bus based operating system attack and protections
This covered how to compromise a system if you have physical access to the PCI bus through certain card readers etc. Obviously this is possible (in a similar manner to firewire) but it was interesting how they exploited it because they had to use FPGAs and it gets difficult writing high level code exploits in VHDL. Instead, they wrote a CPU emulator for the FPGA so they could then write conventional high level code that would run on the FPGA. Very cool.

Thoughts about Trusted Computing
An overview followed by criticisms. Conclusions are that at the moment it isn't very effective because the process often only affects the loading and once something has been loaded you can run-time patch it. It isn't very effective practically against full drive crypto either because you can just write a trojaned bootloader that appears the same as the normal login but stores the passphrase on the MBR and then reboots. Then next time you enter the victims hotel room you have the key.

Pwning your grandmother's iPhone
An overview of iPhone history and how it used to be much less secure (everything ran as root etc) and how now there is privilege separation, DEP, signed code and security policy files governing what processes can access. Eventually, with a little ninja action he came up with a clever way to get remote code execution using a staged three call return-to-libc style attack followed by shellcode execution. Sadly nobody has found a remote vuln in the iPhone 2 yet to try it out on in practice.

Exploiting Firefox Extensions
Unsigned code, dubious security code reviews, insecure distribution and no security model separating them from the core code. I'm sure we probably all knew we should be wary of firefox extensions but this gave further reason to be very careful of which extensions to use, if any!

Have you got bad timing?

Mar 13, 2009

Timing attacks have a long and successful history when used against a wide variety of systems and technologies. This is because these attacks can take so many forms, from vulnerabilities related to race conditions, or blind SQL injection vectors which use delays in execution through to the timing of a UNIX login.

One of the classic timing attacks is based on measuring the difference in the time an application takes to complete two different but related tasks. If the code path followed by different inputs varies in its length or in its complexity the execution time for the two different inputs can vary slightly – but measurably. The most common example of this is the time taken by a login mechanism to process authentication attempts. When the username which is supplied is valid, the code path can often be longer than that taken for an invalid user and therefore could allow a timing attack to occur. This type of attack has been widely publicised and there are many examples which are known to work.

These types of attack are indirect and it can be difficult to identify every instance when they are viable. As a result they can occur even in established and widely deployed technologies. The following example was identified on a number of occasions during penetration testing, although the cause could never be isolated.

The issue relates to installations of Citrix Access Gateway where users can authenticate with Microsoft Active Directory (AD) credentials. In these scenarios it has been observed that authentication attempts that use valid AD users take a marginally longer time to return a failed login message to the user's browser. This enables an attacker to identify whether a username is valid which, in turn, provides help with password guessing attacks.

It is worth noting here that a number of attempts were made to replicate this issue in controlled conditions and the vendor was actively involved in this process. However, it was not possible to reproduce the behaviour observed in production environments and with customers being naturally reluctant to disclose details of their internal environments the cause could not be positively identified.

We are raising the issue now for two reasons: to provide security professionals with information about these observations and to encourage further investigation which could lead to the underlying cause or its dependencies being identified. It is hoped that with more open discussion and further testing more information can be uncovered about this issue and a resolution identified.

Presentation: DeepSec 2008 - Behind Enemy Lines: Administrative Web Application Attacks

Nov 15, 2008

Rafael Dominguez Vega presented at DeepSec 2008 about his research into attacking administrative web interfaces. His talk included demonstrations of these kinds of attacks through SSID and DHCP script injection vulnerabilities discovered by in the course of his research. The slides for this presentation are available from:

http://labs.mwrinfosecurity.com/files/Publications/mwri_behind-enemy-lines-presentation-deepsec2008.pdf

Stockholm Sec-T Conference Roundup

Sep 15, 2008

Author: Martyn Ruks

When you talk about attending a major security conference it is tempting to dream of a trip to the lights and glamour of Las Vegas. However, what often gets lost is that it is the speakers and the content that make a conference not just the surroundings. So when considering this important fact the inaugural Sec-T conference in Stockholm was a very exciting prospect for anybody interested in cutting edge security research.

No matter what your role is in the Information Security industry there was a talk that would be of interest. Here is a flavour of what you would have heard if you were an attendee: -

Virtualisation is secure, isn't it? As we have learnt ourselves through John Fitzpatrick's research project the answer as we might have predicted new technologies have new threats. Oded Horowitz works for VMWare and talked about how rather than having to accept new threats you can use Hypervisor technology to catch malicious behaviour within your virtual machines in real-time.

Hacking is all done by misguided teenagers in their bedrooms! That semi-romantic picture is still held to be true by many but in reality is far from the truth. Today's enemy is highly organised, well funded and interested in making lots of money. Mikko Hyponen from F-Secure gave lots of practical examples of this and why we should all be wary.

After hearing about the prevalence of IT related crime around the world it is comforting to hear that there are people trying to bring the to justice. People working in criminal justice still need educating and Bosse Norgren talked about the efforts being made to achieve this in Sweden.

The guys from Outpost 24 demoed their new SockStress framework and at the same time gave a warning about a new class of DoS attacks that are just around the corner. They didn't reveal any details, but using techniques such as client side “SYN cookies” appears to be a fundamental cornerstone of lots of new methods for causing havoc inside IP stacks.

Christer Oberg, Claes Nyberg and James Tusini talked about how even the most venerable Operating Systems are at risk if the assumption is made that they are secure. They presented their talk on OpenVMS hacking that was given at Defcon 16 this year but included further details about some of the previously disclosed vulnerabilities and some new ones.

If you run SAP on your network you should be very concerned, that is the conclusion you will reach if you watch any of Mariano Nunez di Croce's presentations on the subject. He outlined the new improvements to his SAP testing framework (sapyto) and also demonstrated the plugin that can be used to tunnel connections through a SAP router.

The special guest speaker was the worst kept secret at the conference, especially when you are talking to him at breakfast! As usual Felix 'FX' Lindner spoke eloquently and passionately about the crucial role of Cisco security in the majority of network environments including the Internet. It is good to know that the work being done on Cisco forensics includes an understanding of how developments in exploitation techniques and rootkits are progressing and how they can be countered as they evolve.

The other talks that aren't described in detail were also very interesting and covered topics such as how to practically develop a Mac OSX rootkit, how global politics and Information Warfare are now intrinsically linked and of course the best talk was obviously about IBM Websphere MQ security. Or maybe that's just because I haven't got an unbiased opinion! In reality this was a very well organised and run conference and I am just one of many looking forward to a return trip next year.

Presentation: Sec-T - Websphere MQ Security Uncovered

Sep 12, 2008

Martyn Ruks spoke at Sec-T in Stockholm detailing additional research by himself and others on Websphere MQ and Middleware generally. His previous years presentation on MQ security created additional interest in the subject and stimulated further research efforts. His presentation brought together information already in the public domain and new details about Websphere MQ security and the methods for subverting it.

Presentation: DefCon16 - Virtually Hacking

Aug 12, 2008

On Friday 8th August 2008 MWR InfoSecurity's John Fitzpatrick presented the talk 'Virtually Hacking' at DefCon 16 in Las Vegas. The presentation looked at VMware security and can be downloaded from:

http://labs.mwrinfosecurity.com/files/Publications/virtually-hacking_DEFCON16.pdf

Defcon 16 Talk Review: Time-Based Blind SQL Injection Using Heavy Queries and the Marathon Tool

Aug 11, 2008

Author: Matt Hillman

This talk by Chema Alonso and Jose Parada at the Defcon 16 security conference in Las Vegas introduced a method, and a tool, for performing time based blind SQL injection without the need to use delay functions of the database server.

Blind SQL injection allows data to be retrieved form a database through an SQL injection vulnerability even when that data is not directly output by the vulnerable application. The techniques used to accomplish this require repeated queries selecting a small piece of data, such as a single character or the a string length or a field name, and testing its value. Using conditionals, different behaviour is induced depending on whether the condition has guessed correctly about the data. Gradually then, information can be extracted.

For the technique to work however, a visible difference in the result of a true or false condition must be produced. If the application checks the result of the query more strictly, a generic error message may be given in all cases, removing the ability to differentiate between a true or a false condition. In these situations, timing attacks can be used. These traditionally take advantage of timing functions contained in certain SQL servers to cause the query to pause for a measurable length of time, say 10 seconds. The truth of the condition can then be inferred according to whether the query pauses for at least that length of time, or returns quickly.

If the underlying database does not support, or has disabled delay functions, and the only viable attack vector is timing based, SQL injection to extract information may seem futile. Alonso and Parada demonstrated a method for making this possible, inducing the database to pause longer for one condition by causing it to execute a heavy query.

A heavy query is a query which forces the database to do a lot of work. Such queries take the database server a length of time to process such that the difference between a true and a false condition, executing a light or a heavy query, can be measured reliably. Heavy queries take advantage of a problem common to large database design. Applications can grind to a halt processing poorly constructed queries which are usually hunted down by programmers and altered to be more efficient. There should then be many ways to construct a deliberately slow query.

To make the technique work, it is important to understand how the target database processes queries. Databases without optimisation evaluate conditions and clauses in a fixed order, left-to-right or right-to-left. Databases with optimisation however, estimate which part of a nested query or clause will be more expensive and executes the lighter one first. This allows the database to skip the heavy query if it is not needed to fully evaluate the condition. It is important to know how a given database operates to ensure that the outcome of the query returning quickly or slowly can accurately determine the truth of the condition given.

The following is a generic example of a query designed to perform heavy query based SQL injection attack:

http://server/script.aspx?vuln_param=1 and (<heavy query>)>0 and 300>(select top 1 ascii(substring(name,1,1)) from sysusers)

The heavy query is not filled in here, and more details on how heavy queries can be constructed are discussed later. The thing to note at this point is the structure of the query as a whole. The heavy query will only be performed by MSSQL if the last condition is true. This last condition also makes up the query which extracts the information we are interested in, comparing the value of the first letter of data we are interested in the usual manner of blind SQL injection.

As the light query is optimally executed first, the database server evaluates this side of the condition first. If it is false, it does not need to execute the heavy query to know the overall "and" condition is false, so it skips it, and the query returns quickly. If however, the last condition is true, the database must execute the heavy query to fully evaluate the query, and it returns slowly. In this way, it can be determined if the last condition is true or false, and data can gradually be inferred.

As well as providing a viable attack vector to otherwise unpractical SQL injection vulnerabilities, this kind of attack has an advantage in overcoming IDS detection. As there is usually no need for an application to use delay functions, signatures could be written to detect queries containing such functions. Using heavy queries however, no unusual query statements need to be present and the query looks a lot more like a legitimate query. The ability to create heavy queries in a variety of subtly different ways also makes evading signatures easier. Of course the presence of any generic SQL injection string could still potentially be caught by IDS systems, but the ability to leave out other identifying elements of a timing based attack does increase the chances of letting the query slip by.

By default, the marathon tool designed to automate this kind of attack uses default tables from the database it supports (Microsoft SQL Server, MySQL and Oracle) to reliably construct heavy queries independent of schema. For Oracle, the user_details, user_tables or all_objects tables will be used by default; for MySQL, information_schema.columns is used by default; and for Microsoft SQL Server, the default tables used are sys.databases and sysusers. These tables can be changed in the configuration if desired, and if a table name is already known or guessed, using it instead may aid in attempts to bypass IDS, as only tables legitimately used by the application will be included in the query.

To produce the slow processing effect required by this approach, Marathon uses multiple cross-joins on the tables selected for use. Cross-joins instruct the database to combine every record of the table with every other record. Marathon then tunes the query, varying the number of joins until an efficient delay time is found that is long enough to be accurately measured, but not too long so the attack is slowed down more than necessary. Parameters can be set to constrain this tuning both in terms of the minimum and maximum joins to use, and the minimum length of time a heavy query should take.

Marathon also supports useful features like setting cookies or authorisation data, and routing through proxies, to allow it to be used in a variety of circumstances.

The marathon tool is still being developed, and according to the authors is still in an alphas stage. It is functional, but it currently only supports extracting the schema from a database and not the actual data. Still it acts as a good proof-of-concept for this method of heavy query time based SQL injection.

While the Defcon presentation was given by only Chema Alonso and Jose Parada, the work behind it had many more contributors who should also be acknowledged, They include Daniel Kachakil, Rodolfo Bordón and Antonio Guzmán y Marta Beltrán. Further information can also be found at http://technet.microsoft.com/en-us/library/cc512676.aspx.

Defcon 16 Talk Review: The Pentest is Dead, Long Live the Pentest

Aug 11, 2008

Author: Matt Hillman

This insightful presentation at the Defcon 16 conference in Las Vegas commented on the history of the pentest, what worked and what didn't, and the direction which, in the speakers' eyes, the pentest should be moving towards today. The speakers, Taylor Banks and Carric, gave a warning at the start of the presentation that no punches would be pulled and that things which they felt were wrong with the industry and the people in it would be freely discussed.

They laid out what pentesting used to be like and where it came from, what it became, the problems it still faces and looked at what really adds value to a pentest and how we should be developing it as a service. Much of what they said rang true with MWR's experience and current goals and it was certainly interesting to see these ideas laid out. In this article I hope to captures much of what they were expressing in that talk.

The talk harked back to the early days of the pentest and its links with hacker culture. This is an aspect often missed in today's professional world, but acknowledging it allows for a great perspective on why pentesting evolved in the way it did, and contrasting it against the directions it took later helps us keep the good, throw out the bad, and improve the neglected. Just as hacker culture evolved, so did the pentest, as did business use of technology.

The talk described the dark days of early pentesting. They described pentesting as a "black art" in those early days, which much like security itself was little understood by those slowly beginning to use technology.

The only place for early pentesters to learn from was from small, underground communities. If this sounds like the same place hackers learnt their stuff, then its because they probably were the same places. There was no large security industry attracting practitioners; pentesters did what they did for the sheer love of it. Indeed to begin with, the term penetration tester didn't even exist and people would sometimes seek to simply "hire a hacker".

Early pentesting then was a much more obscure process in which someone was essentially let loose on the network to play hacker and see what they could turn up. People paying for pentests understood little about the arcane art and had to place trust in whatever was delivered at the end. This certainly gave the customer a perspective on the safety of their networks and systems they could not have gotten on their own, but the lack of any kind of accepted methodology brought with many shortcomings.

But strong competition tended to incline people away from accepted methodologies. To succeed a pentester or pentesting company needed to deliver the best report with the most findings, so revealing details of any methodology that gave you an edge would only give competitors the chance to yield the same results as you. In the still immature security industry there was little else at the time to act as a differentiator between a good and a bad pentest other than how many results were in a report.

The other major problem with this ad-hoc approach is that pentests were rarely repeatable. The presnters made the point that "if it ain't repeatable, it ain't a pentest... it's just a hack". But what is the difference between a hack and a pentest? An attacker only needs to be successful once to get in, but a pentest ought to cover as many possible weaknesses as possible. A pentest is different from a hack in that it is not just about "getting in", its about evaluating how easy other people might get in. And that means that the people fixing the systems need to know exactly how security was bypassed, and for effective retests to be possible a pentester, perhaps a different tester from the one who originally performed the test, needs to be able to reproduce the "hack" exactly.

As organisations grow, the ability for one person to do everything disappears rapidly. The ability to effectively share information among testers, and to communicate relevant information to the customer, is therefore vital to a good penetration test. The experience of seasoned pentesters should also not go to waste. No longer are we restricted to small underground communities trading bits of information. Progress in this area has been made with schemes such as CHECK and OWASP.

As the millennium approached, pentetration testing started to go more mainstream. The computing world grew massively, technology was being used in ever more sensitive areas, and computers became accessible to many more people. As such, the hacker community grew, and the pentesting community grew. Many tools had been developed to allow scanning and automated assessment, and this again made pentesting a more accessible profession.

Unfortunately, these tools do not solve the security problem. The bar is not raised very high if all that is performed is an automated scan with the results blindly handed on to a customer. It is easy to fall into the trap of thinking that a methodology is a simple checklist which can in time be completely automated with the tools that become available. But these do not give nearly as useful a picture as a test with expert, creative human input.

This issue is found in various training courses that can now be taken in "hacking" or pentesting. They tend to focus a lot on using the tools and specific nuances of technology and tricks of the trade. But a good pentest is also about understanding the process of an attack. How can a random collection of vulnerabilities and tools be combined to create a greater threat, and how do you go about finding all these weaknesses in a system in a reliable way.

What's more, we do not only have to deal with software vulnerabilities or open ports. Architectural or systemic problems in the way a system is designed can be a huge threat as well. Such things cannot easily be rooted out with automated tools, but by following an intelligent process with experience and creativity the flaws in the concepts of a system can be exposed.

So while methodologies capture past experience and allow known issues to be methodically tested for, which is certainly better than a purely ad-hoc approach based on the experience and disposition of whatever pentester you happened to get, it is equally important that these methodologies are flexible. Room must always be left for the human mind to do what it does best and creatively explore ways in which a given security system might be bypassed.

After all, this is precisely what malicious hackers do; they bypass the very restrictions that were in theory supposed to keep them out. So confirming that the restrictions you thought were in place are indeed in place, is only a low level of assurance. In reality, a full blown penetration test needs to go deeper than that and look at the things you *didn't* think of, not just test the things you already put in place.

So a large part of the value of a pentest is in the people performing the test. But knowing this does not by itself help evaluate the difference between good testers and bad testers, and it may seem that we are still stuck with the size of the report being the only differentiator.

So what can we do to fix this and take pentesting to the next level? One thing we can do is put some of that human creativity into reports. Reports should not just be a dry list of vulnerabilities, offering a stark view of your network with no guidance on what to do about it or context about what it all means to you in your environment. Instead it is far better to include personalised descriptions of security weaknesses found, detailing their potential impact to the client based on the knowledge the pentester has of what they do. This means good communication between the client and the pentester is vital, and the service should not stop with the report. Ongoing support and advice is also an important way to add value to a pentetration testing service.

Metrics are also useful in evaluating both the value of a pentest, and the relative risk to which you may be exposed at a given time. A simple vulnerability total is not necessarily enough here. Some vulnerabilities are much higher risk than others, some are more practical than others, or relate to core security architectural failures.

Metrics are certainly not the whole picture, but they do allow tests to be compared, and patterns to be seen over time. Is the security posture improving, staying the same, or actually getting worse? And in what areas are these trends found, perhaps application level issues are being dealt with better than deployment of new infrastructure, and if so perhaps a certain team in the client organisation needs some further training. Such things provide constructive business information that can really be used to help improve security as a process over time.

So what are the ingredients for a good modern pentest?

Repeatability
Process driven not tool driven
Creative, expert input
Strategically focussed, partnering closely with the client in an ongoing relationship

Defcon 16 Talk Review: Advanced Software Armouring and Polymorphic Kung-Fu

Aug 11, 2008

Author: Matt Hillman

At the Defcon 16 conference in Las Vegas, Nick Harbour showed off his new Windows executable packer, PE-Scrambler. It uses some interesting, and sometimes downright devious techniques to make analysis of the binary harder.

Rather than blindly manipulating the bits and bytes of the code to compress or encrypt it as many traditional packers, PE-Scrambler disassembles the code and manipulates it at a logical level to sabotage many of the methods used by disassemblers to analyse instructions and flow. The result is a binary that is hard to get any meaningful automatic analysis of program structure for.

The techniques used to do this include altering function calls to call a single dispatcher function, destroying the call tree; chunking the code into small pieces and relocating them throughout the binary; weaving bytecode together such that they have ambiguous disassembly; and some polymorphic substitution of certain pieces of code for obfuscated alternatives.

To achieve the destruction of the call tree, PE-Scrambler creates a dispatcher function and alters every function call to call this dispatcher instead. The dispatcher needs to know what functionality to jump to for each call without giving a disassembler too many hints, and it achieves this by checking the stack for the return value of that call. This value can identify which call instruction has called the dispatcher, and using this information a lookup table is created so the dispatcher knows what functional code to jump to. In this way, all calls can reach the appropriate functionality but it is impossible for a disassembler to know what function a given call relates to without knowledge of the lookup table mechanism.

For code relocation, a variety of methods are used. The simplest method takes a relocatable chunk, moves it, and the previous chunk connects to it with a simple unconditional JMP jump.

A slightly more advanced technique looks for parts of the code where it is known that the value of the zero flag will always be a certain value. A conditional jump is then added just after this, and the chunk of code following it relocated. We know that jump will always be taken, but most disassemblers performing static analysis will not notice this and will produce two possible code paths, making comprehension of program structure more complex.

The final technique for relocatable chunks is to insert predictable conditionals. This works much like the previous method, except this time the predictable conditional is arbitrarily manufactured and inserted by PE-Scrambler. These conditions do not have to be purely statically predictable and can take advantage of things that a human knows, but a disassembler would probably never assume. The example given in the presentation involves comparing ESP with 0x80000000, and while we as humans know that ESP will always reasonably be less than this, a disassembler does not.

My favourite method used by PE-Scrambler is the production of ambiguous or conflicting disassembly. This involves weaving instructions together such that instructions jump part way into their own bytecode, altering the meaning of those bytes to other instructions. If that wasn't cool enough, PE-Scrambler also takes advantage of the fact that according to Nick most disassemblers evaluate the false condition of a branch first, and once bytes have been disassembled the disassembler won't try to disassemble them again. By using overlapping instructions that form a conditional like this then, incorrect or conflicting disassembly can be produced. The presentation contained several examples of ways similar to this to produce flawed disassembly.

PE-Scrambler also performs some general polymorphic alterations to the code to further obfuscate it. This involves replacing certain instructions with misleading but equivalent instructions. This can break a disassemblers ability to automatically understand what is happening at a given point in the code, adding again tot he effort required to understand the program as a reverse engineer.

Despite these pretty cool tricks, PE-Scrambler is not perfect. As it uses disassembly to perform most of these tricks, there is no margin of error for its own disassembly. If errors occur, the resulting executable may be destroyed and fail to run. Currently there is a significant proportion of files for which this can be the case, but that is expected to drop as more fixes and tweaks are added. When it does work however, it works great. And even if you don't use PE-Scrambler itself, some of the techniques it uses should provide inspiration for things like manual obfuscation of shellcode or the like.

As well as PE-Scrambler, at the end of the presentation Nick demonstrated another tool called FindEvil. This uses the same disassembly engine as PE-Scrambler and measures the size of disassembly compared to the size of the binary. Using various ratios it makes a decision as to whether that binary is packed. Nick claimed that so far, he has had 100% success using FindEvil, though he didn't say how many files it has been tested with. It is, however, an interesting way to detect packers.

Behind Enemy Lines: Administrative Application Attacks White Paper released

Jul 31, 2008

A white paper was released by MWR InfoSecurity discussing the security implications of administrative web applications.

This explains how the use of alternative protocols (such as DHCP and 802.11) can be used to perform web based attacks. The white paper also explains the different methods available for exploiting these issues in practice, and details how tools can be built to test and exploit them.

The paper is based upon original research by Rafael Dominguez Vega and can be downloaded from:

http://labs.mwrinfosecurity.com/files/Publications/mwri_behind-enemy-lines_2008-07-25.pdf

View All
Page: 1 2 3 4 5 6