August 21, 2006

Security Hacking Conferences: Feeding your Technical Mind

Obviously, due to professional, personal and financial reasons, security professionals cannot attend all the multiple security and hacking conferences that are held out there, worldwide, throughout the year. In order to stay current on the latest security threats, tools, research and improvements, trying to feed our hungry technical minds, we can instead (although being there in person cannot be compared to...) access the conferences main homepages.

Almost all conferences have an archive section from where you can download the presentations (commonly in PDF or PowerPoint format) or even the event audio and video recordings. The following is an incomplete list of all the major technical security hacking conferences all over the world:

NOTE: This list is continuously updated with new infosec conferences I hear about! [UPDATED: June 3, 2009]

But, if you are interested on being notified about new upcoming conferences and events, I strongly recommend these Web sites and their feeds:


BTW, the official BlackHat US 2006 and DEFCON 14 archives will be completely released any time now. Meanwhile, you can access all the material here. Thanks Mr.X for providing this early access!

Now, you have tons of material to read, listen and watch. Enjoy it!!

posted by Raul Siles at 12:53 PM 4 comments

August 15, 2006

Sandboxing with SELinux in FC5

Since in November 2004, Joanna Rutkowska published "Red Pill... or how to detect VMM using (almost) one CPU instruction", tools for detecting when a program is running in a virtual machine have improved a lot. Pioneer or the programs mentioned by Ed Skoudis and Tom Liston are good examples of those tools. Using them (or the concepts behind them) malware authors can check if the program is running in a virtual environment and behave in a unsuspicious way. This concept has been previously demonstrated by us as a small example in RaDa.

But if we can not trust behavioral analysis running a binary in a virtual machine, how can you safely incorporate software from untrusted sources? This may happen very often to you independently of the platform that you use. There are a lot of useful programs that come from untrusted sources, and you just can't spend the time reading its source code (in case it is available).

Don't worry! SELinux comes to your rescue. Among the different approaches to this problem, SELinux is the one that offers real control over the binary and as much isolation as needed for Linux binaries. SELinux takes advantage of the Linux Security Modules (LSM) framework to implement mandatory access control (MAC) in the Linux kernel. It is supported by most major distributions (i.e. all but SuSE that uses AppArmor.)

SELinux enforcement is coded in a kernel module, but the policy used can be changed dynamically allowing to implement different security models. Fedora Core 2 was, as far as I remember, the first distribution that included SELinux and a strict policy file. That policy tried to restrict undesired behavior so much that using it was too complex for normal users. It is still available for later versions of Fedora, but the team that developed the policies decided to simplify the model to be able to achieve their goal: having a system where the user was protected from system applications that were listening on the network. That was the origin of the targeted policy that tries to isolate the programs that are used by malware for remote access, each one running in a different domain, while keeping the rest of the system as if SELinux was not running.

Thus, what we can do is define our own domain for suspicious binary execution. In order to be able to do so, you need the checkpolicy package installed. If you are using yum, which I definitely recommend, the command "yum install checkpolicy" should do. Then, the easiest way is to run the policygentool:
cd /usr/share/selinux/devel/
policygentool mybinary /path/to/mybinary

After some questions about the program, it will create three files (mybinary.{fc,if,te}). The file context, used to label the files, the public interfaces, that define the transitions to and from other domains, and the type enforcement, that contains the rules for this domain. You can edit these text files later. By now just try to compile them using:
make -f Makefile

A policy module file will be created mybinary.pp. That module can be loaded using semodule, and relabel the executable using restorecon:
semodule -i mybinary.pp
restorecon -v /usr/sbin/mybinary

Since the default policy is very restrictive for the binary, SELinux will prevent it from doing much when running. However, this is exactly what you need to debug your policy. Execute the binary and collect avc (Access Vector Cache) messages. In Fedora Core 5, the audit daemon is not installed by default, and the avc messages can be found in /var/log/messages. But if you choose to install and enable the audit daemon, the messages will be in /var/log/audit/audit.log.
audit2allow can then be used to translate the avc messages to allow rules to fix the policy files (mainly the type enforcement). audit2allow -R will attempt to find interfaces that match the allow rule.
Some help to edit your policy:
Some additional hints:
  • Limiting read access is only based in contexts. When you allow read or write access to a context, all the files in that context are allowed. You can relabel some files, but then be sure that you can easily reinstall the system.
  • SELinux works mainly for Linux, but there are some ports of this solutions to FreeBSD and Mac OS X. There are some propietary solutions for Windows, like CA's eTrust Access Control, too.
  • There is a performance impact in running SELinux, but you are probably running it anyhow and using a VM isn't a better alternative in terms of performance.

Enjoy your sandbox!

posted by Jorge Ortiz at 3:30 AM 0 comments

August 08, 2006

Fake "Cannot find server" Web Pages

This is probably old news to many but it might save you some time if you didn't know before.

I've come across this simple trick to simulate having taken down a web server, being used in a real case I was investigating: suppose you find a trojan that steals information and sends it to a central web server; suppose you contact the ISP of the web server and ask them to take the server down; suppose they respond accepting the request; finally, suppose you try to connect to the server using your Internet Explorer and you get the following response:


Does that mean the web server is down? Well, not necessarily. The page you are seeing is just a regular HTML page. It may have been displayed by Internet Explorer itself because it wasn't able to contact the server OR it may have been sent back by the same server that pretends to be down!

Looking at your network traces will leave no doubt of which of the two possibilities you are facing, but the point is: you need to check your traces. In my case, it was the last one.

By the way, if you look at the source code of the page and see this javascript code, don't freak out: it's been copied from an original IE error page. It's the code that allows the user to click in the "Detect Network Setttings" link (see the screenshot) and have IE autodetect the proxy settings:

[...]
<[REMOVETHIS]SCRIPT>function doNetDetect() {
saOC.NETDetectNextNavigate();
location.reload();
}
<[REMOVETHIS]/SCRIPT><[REMOVETHIS]body bgcolor="white">
<[REMOVETHIS]object id=saOC CLASSID='clsid:B45FF030-4447-11D2-85DE-00C04FA35C89' HEIGHT=0 width=0><[REMOVETHIS]/object>
[...]

The "object" tag creates an instance of the SearchAssistantOC object, represented by that CLSID and contained in shdocvw.dll, and the script invokes one of its methods, NETDetectNextNavigate(), that while officially undocumented it is known to do the proxy autoconfiguration I referred to before.

References:

1.- Documentation on DHTML:

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/dhtml_reference_entry.asp

2.- Documentation on the "object" tag:

http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/object.asp

3.- List of objects, properties and methods contained in shdocvw.dll (unofficial):

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/tsleft.web+WinBatch/OLE~COM~ADO~CDO~ADSI~LDAP/OLE~with~MSIE+SHDOCVW~dll~.txt

posted by David Perez at 12:53 PM 0 comments