Sandboxing: Apparmor

Sandboxing: Apparmor

This is the fifth installment on a series of various sandboxing techniques that I’ve used in my own code to restrict an applications capabilities. You can find a shorter overview of these techniques here. This article will be discussing sandboxing with Apparmor.

Mandatory Access Control:

Mandatory Access Control (MAC), like Discretionary Access Control (DAC), is meant to define permissions for a program. Users and Groups are DAC. But what if you want to confine a program with full root? As discussed, root with full capabilities is quite dangerous – and in the case of SyslogParser quite a few of those capabilities are necessary.

Apparmor is a form of Mandatory Access Control implemented through the Linux Security Module hooks in the Linux kernel. MAC is “administrator” defined policy, and can confine even root applications.

Apparmor is a *bit* out of scope for this series, as it doesn’t actually involve any code, but it’s still relevant.

The Code:

While Apparmor itself doesn’t have code in SyslogParse, here’s the profile for the program.


# Last Modified: Wed Aug 13 18:57:15 2014
#include

/usr/bin/syslogparse{

/usr/bin/syslogparse mr,
/var/log/* mr,

/etc/ld.so.cache mr,

/sys/devices/system/cpu/online r,

/lib/@{multiarch}/libgcc_s.so* mr,
/lib/@{multiarch}/libc-*.so mr,
/lib/@{multiarch}/libm-*.so mr,
/lib/@{multiarch}/libpthread*.so mr,

/usr/lib/@{multiarch}/libseccomp.so* mr,
/usr/lib/@{multiarch}/libcap-ng*.so* mr,

/usr/lib/@{multiarch}/libstdc*.so* mr,

}

Apparmor is incredibly straight forward. There is a path, and then there is one or more letters. These letters stand for certain things.

r = read
m = map
w = write

All of this is pretty straight forward. SyslogParse gets the number of CPU cores from /sys/devices/system/cpu/online , so it needs “r” access.

It needs to read some libraries in order to function.

And that’s it. Sort of… apparmor on my system is, unfortunately, quite broken. The tools for enforcing/ complaining crash on me (I have a lot of weird profiles that I experiment with), which is actually why I started building SyslogParse. So this profile is a bit incomplete. It still needs some capabilities defined for chroot, setuid/setgid, and possibly more file access.

Conclusion:

When enabled an Apparmor profile will begin enforcing policy as soon as the process begins. That means that, even if running as root, an attacker is always confined to those files defined in the profile. Apparmor is quite powerful, and combined with the other sandboxing techniques used it’s a very nice reinforcement – writing to the chroot, for example, is denied throughout the process by both DAC and MAC now.

Apparmor is, unfortunately, only available on certain distributions.

Next Up: Final Conclusion

Sandboxing: Chroot Sandbox

Sandboxing: Limited Users

This is the fourth installment on a series of various sandboxing techniques that I’ve used in my own code to restrict an applications capabilities. You can find a shorter overview of these techniques here. This article will be discussing sandboxing a program using Limited Users.

Users and Groups:

Linux Discretionary Access Control works by separating and grouping applications into ‘users’ and ‘groups’. A process in user A is, in terms of DAC, isolated from a process in user B.

There’s also user 0, the root user, which is a privileged user account.

Only a program with root, or with CAP_SETUID / CAP_SETGID can manipulate its own UID/GID. In the case of SyslogParse, we have root, and we definitely want to lose it when we can.

So, after getting the file handles we need, here’s the code for dropping to a limited user account (if you’ve read the previous articles this happens right after the chroot).


if (setgid(65534) != 0)
err(0, "setgid failed.");
if (setuid(65534) != 0)
err(0, "setuid failed.");

Very simple. So here’s a simple explanation.


if (setgid(65534) != 0)
err(0, "setuid failed.");

setgid(65534) sets the GID to 65534. This is the “nobody” group on my system. Nobody is an unprivileged user often used by programs wanting to drop privileges. If 65534 doesn’t exist, all the better – dropping to a GID that doesn’t exist is great.


if (setuid(65534) != 0)
err(0, "setgid failed.");

setuid(65534) is changing the user to 65534, which, as above, is the nobody user. Same as before, if the user doesn’t exist, that’s dandy.

Conclusion:

Dropping privileges is a hugely beneficial thing to do. By separating the code into a “privileged stuff done all at once, then never again” you can drop privileges before doing anything dangerous, and there goes an attackers ability to escalate.

Dropping root privileges is incredibly important. The attack surface and amount of post-exploitation work an attacker can do shrinks drastically.

In the case of SyslogParse, as any attacks would be for local escalation (it does no networking), an attacker would probably lose privileges by exploiting it if going from any normal compromised process. At this stage they are in a chroot with no read or write access, running in an unprivileged user/ group with no capabilities, they have access to 22 system calls and some very nice to have calls, such as read() are denied, and their only chance for getting a few capabilities is by exploiting a few lines of code that involve opening a file.

I was going to have the next section be on rlimit, but it’s really not important and also not viable unless you’ve built the application from the bottom up to never write to a file, which will typically involve a broker’d architecture.

Next Up: Apparmor

Sandboxing: Linux Capabilities

This is the second installment on a series of various sandboxing techniques that I’ve used in my own code to restrict an applications capabilities. You can find a shorter overview of these techniques here. This article will be discussing Linux Capabilities.

Intro To Linux Capabilities:

On Linux you’re likely familiar with the root user. Root is the ‘admin’ account of the system, it has privileges that other processes don’t. But, what you may not have known, is that those privileges given to root are actually enumerable and defined. For example, root has the capability CAP_SYS_CHROOT, which is what allows it to call chroot().

Let’s say a program needs root, but only because it calls chroot at some point. Instead of giving all of the privileges except CAP_SYS_CHROOT.

So, if your program has to run as root (as mine does), you can actually drop some of your root privileges while maintaining others. How effective is this? Jump down to the conclusion below to see – hint: it can go between great and awful.

The Code: (includes should have a # in front, but WP is mean)

include include

capng_clear(CAPNG_SELECT_BOTH);
capng_updatev(CAPNG_ADD, (capng_type_t)(CAPNG_EFFECTIVE | CAPNG_PERMITTED), CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT, CAP_DAC_READ_SEARCH, -1);
capng_apply(CAPNG_SELECT_BOTH);

Let’s break this down ~line by ~line.


include include

This includes the headers for linux capabilities (so that you can refer to them as their type) and cap-ng, the library we’ll be using to actually drop privileges.


capng_clear(CAPNG_SELECT_BOTH);

This line will clear all privileges. If you were to apply this, you’d have essentially dropped all root privileges.


capng_updatev(CAPNG_ADD, (capng_type_t)(CAPNG_EFFECTIVE | CAPNG_PERMITTED), CAP_SETUID, CAP_SETGID, CAP_SYS_CHROOT, CAP_DAC_READ_SEARCH, -1);

This line is where we state which capabilities we’d like. After the capng_clear() we have none, but the program does need a few.

The first two parameters are effectively saying to add these rules.

The third, fourth, and fifth parameters are the defined capabilities to allow.

The last parameter is a -1, which lets capng know that your list of capabilities is terminated.


capng_apply(CAPNG_SELECT_BOTH);

And now, with this call, the rules are applied. Only these capabilities are given to the program… “only”.

Conclusion:
This was really easy to do. Three lines of code and a large number of capabilities are gone. But, what’s left?

CAP_SETUID/ CAP_SETGID : Quite dangerous, as it means you can interact with processes of other UID/GID’s by simply making your UID/GID the same as theirs.

CAP_SYS_CHROOT : Not as scary, you can chroot, and if you retain the ability to chroot you can then break out of that.

CAP_DAC_READ_SEARCH : You can read all files that root can read. Password files, sensitive files, whatever. All yours to read.

So in a lot of ways you’re just dropping from root…. to root. You’re still quite powerful and dangerous if you drop these capabilities, it’s not a very large barrier. An attacker who gains the above privileges still gains quite a lot. But, in the case of SyslogParse, all capabilities are dropped eventually.

The nice thing about capabilities is you can do it as soon as the program starts. After you’ve gotten your file descriptors and all that, you can go ahead and start real sandboxing, then do the actual dangerous stuff. In this case, I had to give a lot of scary permissions. But for someone else, maybe all they need is to bind port 80, and in that case you just give CAP_NET_BIND_SERVICE, drop everything else, and that’s pretty nice.

It honestly feels like a “Well, it’s better than giving it full root” in this case, which is bittersweet. It still pretty much feels like full root. But uh, hey, it’s better than giving it full root.

Sandboxing: Seccomp Filters

This is the first installment on a series of various sandboxing techniques that I’ve used in my own code to restrict an applications capabilities. You can find a shorter overview of these techniques here. This article will be discussing seccomp filters.

What is Seccomp? An Introduction:

System calls are your way of asking the kernel to do something for you. You send a message saying “Hey, open a file for me” and it’ll probably do it for you, barring permission errors or some other issue. But, if you can talk to the kernel, you can exploit the kernel. Many vulnerabilities are found in kernel system calls, leading to full root privileges – bypassing sandboxing techniques like SELinux, Apparmor, namespaces, chroots, you name it. So, how do we deal with this without patching the kernel, as a developer? Seccomp filters.

Seccomp is a way for a program to register a set of rules with the kernel. These rules deal with the system calls a program can make, and which parameters it can send with them.

When you create your rules you get a nice overview of your kernel attack surface. Those calls are the ways your attacker can attack the kernel. On top of that ,you’ve just reduced kernel attack surface – if an attacker requires system call A and you’ve only allowed system calls B through D, they can’t attack with system call A.

Another nice benefit is the ability to restrict capabilities. If your program never writes a file, don’t give it access to the write() system call. Now you’ve reduced the kernel attack surface, but you’ve also stopped the program from writing files.

The Code:

Seccomp code is fairly simple to use, though I haven’t found any really good documentation. Here is the seccomp code used in my program, SyslogParse, to restrict its system calls.


scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(rt_sigreturn), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(tgkill), 0);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(access), 0);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 2,
SCMP_A0(SCMP_CMP_GE, 1),
SCMP_A0(SCMP_CMP_LE, 2)
);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(open), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(close), 0);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mprotect), 1,
SCMP_A2(SCMP_CMP_NE, PROT_EXEC)
);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 2,
SCMP_A0(SCMP_CMP_EQ, NULL),
SCMP_A5(SCMP_CMP_EQ, 0)
);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(munmap), 2,
SCMP_A0(SCMP_CMP_NE, NULL),
SCMP_A1(SCMP_CMP_GE, 0)
);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(madvise), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(futex), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(execve), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(clone), 0);

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getrlimit), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(rt_sigaction), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(rt_sigprocmask), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(set_robust_list), 0);
seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(set_tid_address), 0);

if(seccomp_load(ctx) != 0) //activate filter
err(0, “seccomp_load failed”);

I’ll go through this bit by bit.


scmp_filter_ctx ctx;
ctx = seccomp_init(SCMP_ACT_KILL);

This should be fairly simple to understand if you’ve written basically any code. This instantiates the seccomp filter, “ctx”, and then initializes it to kill on rule violations. Simple.


seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(futex), 0);

This line is a rule for the “futex” system call. The first parameter, “ctx”, is our instantiated filter. “SCMP_ACT_ALLOW”, the second parameter, is saying to allow when a condition is met. The third is a macro for the futex() system call, as that’s the call we want to allow through the filter. The last parameter, “0”, is how many rules we want to add to this that deal with parameters.

Simple. So this rule will allow any futex system call regardless of parameters.

I chose futex in this example to demonstrate that seccomp can not protect you from every attack. Despite the heavy amount of sandboxing I’ve done in this program, this filter will do nothing to stop attacks that use the futex system call. Recently, one vulnerability was found that could do just that – a call to futex would lead to control over the kernel. Seccomp just isn’t all powerful, but it’s a big improvement.

Note: I found all of these syscalls by repeatedly running strace on SyslogParse with different parameters. Strace will list all of the system calls as well as their arguments and makes creating rules very easy.


if(seccomp_load(ctx) != 0) //activate filter
err(0, "seccomp_load failed");

seccomp_load(ctx) will load up the filter and from this point on it is enforced. In this case I’ve wrapped it to ensure that it either loads properly or the program won’t run.

And that’s it. That’s all the code it takes. If the program makes a call to any other system call it crashes with “Bad System Call”.

Seccomp is quite easy to use and is the first thing I’d make use of if you are considering sandboxing. All sandboxing relies on a strong keernel, but as a developer you can only change your own program, and seccomp is a good way to reduce kernel attack surface and make all other sandboxes more effective.

Linux has something like 200 system calls (can’t find a good source, anyone know a more definitive number?), and SyslogParse has dropped that down to about 22. That’s a nice drop in privileges and attack surface.

Next Up: Linux Capabilities

Using CloudNS For DNS Resolution – Integrity, Authenticity, Confidentiality

CloudNS is a DNS host that supports a few cool security features. I’ve set it up, and it’s working for me on Linux Ubuntu 13.04. I think its security features give it the potential to be the preferred choice for those looking for that higher level of security and privacy.

* DNSCrypt Support
We only allow connections to our service using DNSCrypt, this 
provides confidentially and message integrity to our DNS 
resolver, and makes it harder for an adversery watching the 
traffic of our resolver to identify the origin of a DNS query as
all the traffic is mixed together.

* DNSSEC Validation
Our server does complete trust validation of DNSSEC enabled 
names, protecting you from upstream dns poisoning attacks or 
other DNS tampering.

* Namecoin resolution
Namecoin is an alternative, decentralized DNS system, that is 
able to prevent domain name censorship. Our DNS server does local
namecoin resolution of .bit domain names making it an easy way to
start exploring namecoin websites.

* Hosted in Australia
Our DNS Server is hosted in Australia, making it a faster 
alternative to other open public DNS resolvers for Australian 
residents.

* No domain manipulation or logging
We will not tamper with any domain queries, unlike some 
public providers who hijack domain resolution for domains that
fail to resolve. Our servers do not log any data from connecting 
users including DNS queries and IP addresses that make 
connections.

I think those are some really interesting features. For one thing, it forces DNSCrypt and validates with DNSSEC, and it appears to be the only resolver to do both of these things. And it’s also hosted outside of the US, which has its own implications for security.

So I went ahead and set up CloudNS using the following command (and setting this in rc.local) after configuring DNSCrypt from this guide. You can check Cloudns.com.au for the updated information, but as of today (Aug 8th, 2013) this command works for me.

dnscrypt-proxy --user=dnscrypt
--daemonize --resolver-address=113.20.6.2:443 --provider-name=2.dnscrypt-cert.cloudns.com.au --provider-key=1971:7C1A:C550:6C09:F09B:ACB1:1AF7:C349:6425:2676:247F:B738:1C5A:243A:C1CC:89F4

To use the secondary server as well the command is:

dnscrypt-proxy --user=dnscrypt --daemonize --resolver-address=113.20.8.17:443 --provider-name=2.dnscrypt-cert-2.cloudns.com.au --provider-key=67A4:323E:581F:79B9:BC54:825F:54FE:1025:8B4F:37EB:0D07:0BCE:4010:6195:D94F:E330

So the three big improvements for me are DNSSEC, DNSCrypt, and Australia hosting.

DNSSEC

DNSSEC is an extension of DNS that aims to provide authentication and integrity of DNS results; it ensures that you know who the result is from and that no one else has tampered with it. DNS responses are authenticated but they are not encrypted, so DNSSEC does not prevent someone between you and the resolver from viewing the request.

DNSCrypt

DNSCrypt provides encryption of DNS requests, which provides confidentiality of the requests, meaning that an attacker between you and the resolver can not view the traffic between you and your DNS resolver.

Stacking DNSSEC and DNSCrypt works out very well, as you end up covering your bases and achieving confidentiality, integrity, and authentication.

Hosting In Australia

While I’m not particularly familiar with Australia’s laws, hosting outside of the US definitely provides a bit more peace of mind. Just yesterday we learned that Lavabit (the email provider chosen by Edward Snowden) has shut down due to the US government trying to compromise their ability to protect their users. The truth is that hosting in the US just makes a service less trustworthy at this point, and hosting outside is a big plus. This, combined with Namecoin and their pledge to not log, is really somewhat comforting.

So, while I can’t absolutely recommend it at this point (I haven’t been using it long enough) I think there’s a lot of potential here.

Hardening DNSCrypt

DNSCrypt is a DNS Resolver that encrypts the DNS requests between you and the first level DNS resolver. I have a guide for setting it up here. This guide will be about restricting the process and user account, making DNSCrypt more resilient to attack – I will continue to update this guide, I have a few more ideas.

One of the nice features of DNSCrypt is that it actually takes security into account. I wish this weren’t something to be shocked by, but, *gasp* it actually uses compiler security flags. Specifically, it uses the following flags:

-fPIC -fPIE -fstack-protector-all -fno-strict-overflow -fwrapv **

-fPIC and -fPIE tell the compiler to create a relocatable binary, completing the implementation of ASLR. It’s a mitigation technique we rarely seen used, despite it being somewhat critical, and it having been around for years. So right off the bat they’re doing more than most.

-fstack-protector-all (unlike the oft used -fstack-protector, which only protects functions using char arrays/strings) tells the compiler to protect every function with a stack canary. If an overflow occurs the canary may be overwritten, and the function will fail.

-fno-strict-overflow and -fwrapv are essentially the same (in other words, I don’t know the difference) and they tell GCC to not make assumptions about overflows, basically to not assume that overflows won’t occur. Compilers make the assumption that overflows won’t happen when they generate the optimized assembly, so they can build optimizations with that assumption – this prevents that, which is safer.

So these are nice, and we like them. But DNSCrypt also does a bit more.

You can create a new DNSCrypt user with no write rights, and it will chroot itself into that user, and drop rights. This is great, since a chroot’d process with no ability to write is difficult to break out of. And running as a separate user means no X11 access, it gets its own home folder, and it’s generally more isolated from the system – all good things!

But it means some other stuff too. Because it does all of the above we as users can take that protection further – beyond where typical programs allow us to. I think this demonstrates what a strong security model really can do when built from the ground up.

So, on to what we can do.

First thing’s first, we’re going to want some information on our DNSCrypt user.

run ‘id dnscrypt’

You should get something similar to:

id dnscrypt
uid=109(dnscrypt) gid=123(dnscrypt) groups=123(dnscrypt)

We’re going to need this.

IPTables On User

Note that if you’re using UFW this may cause issues, using UFW/GUFW with iptables isn’t recommended, and your mileage may vary  – to remove your UFW rules run ‘iptables -F’. 

Normally I’m not fond of outbound filtering, but because DNSCrypt separates itself into another user, it’s actually not such a bad idea. It means that DNSCrypt can’t just switch its outbound connection to another program under the same user account, and it means that the ports we limit will be limited to that user account specifically. This assumes you are using DNSCrypt under a user called ‘dnscrypt’.

So it’s a lot more worthwhile to set up outbound filtering here.

DNSCrypt should only need outbound access to port 443, with UDP. So we can restrict it to just port 443 and UDP with the following IPTables rules:

iptables -A OUTPUT -m owner --uid-owner dnscrypt -p udp  --dport 443 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner dnscrypt -j DROP

Basically, the first rule allows outbound access to the DNSCrypt user over port 443 and UDP, and the second rule denies everything. If the first rule is hit, and it passes, the second rule doesn’t have to come into play.

***

DNSCrypt is now restricted to UDP over port 443, and all processes running under the dnscrypt user are as well. If you followed the tip then no new connections can be made to your system except over port 53 (you can have dnscrypt use another port, in which case you’ll switch that port to whatever that one is. I have yet to figure the details of this out, I’ll edit it in when I do.)

Trusted Path Execution

If you care about security you’re already running Grsecurity, but if not, see my guide here.

Grsecurity has an option called Trusted Path Execution that allows us to limit a group, preventing it from executing files owned and only writable by root – since our program doesn’t run as root, and can’t write anywhere, it means it won’t be able to execute anything at all.

So check the TPE box and add the GID for untrusted users, in this case 123.

Now this protection is superfluous, DNSCrypt shouldn’t be able to write to the filesystem, so it shouldn’t be able to execute any payloads off of the file system, but it’s still good to have as the protection is now implemented by the user account itself, and doesn’t rely on the program to drop rights properly, or a perfect implementation of chroot.

Chroot Restrictions

While you’re compiling your Grsecurity kernel, you can also go ahead and turn on every single chroot restriction without worry – DNSCrypt works fine with them all. DNSCrypt already can’t write to its chroot, so  as far as I know there’s no known bypass as is, but you can safely enable all of these restrictions. Although some of the protections are a bit redundant due to the aforementioned write restrictions, there are a few that are quite nice, such as:

CONFIG_GRKERNSEC_CHROOT_FINDTASK

CONFIG_GRKERNSEC_CHROOT_CAPS

More restrictions on our exposed service.

Apparmor

Apparmor is an LSM (Linux Security Module) program that restricts a process. If Apparmor is the LSM used on your distribution (Ubuntu derivatives) you can find my profile here. Apparmor will restrict file access, what programs can be executed, what libraries can be loaded, etc. An attacker who winds up in a program that is confined with apparmor must either find a flaw in apparmor, or the profile, or they have to use a local escalation attack. If you’re using everything listed above this is going to be a lot of work for them.

Users of other LSM such as SELinux will need to build their own profiles. This shouldn’t be hard, DNSCrypt needs little file access to work.

Conclusion

Given the situation where an attacker finds himself compromosing the DNSCrypt-Proxy on a system that has done all of the above, they’re going to be pretty pissed off. There is still room for improvement, (seccomp filters) but right now an attacker is going to have to do a lot to get an exploit to be reliable.

For a program like DNSCrypt this level of security is great. It already chroots itself to a directory that it can’t write to, and they use compiler security, so you know they’re taking this stuff seriously. That’s what allows us to spend our time securing it further. If DNSCrypt did not so gracefully run as another user, and if it weren’t built to drop its rights to the extent that it does, then our apparmor profile would be more convoluted, TPE may not be possible, and an outbound Firewall would have been a useless attempt at security through obscurity. But because it’s built from the ground up to be this way we can reinforce it well.

Notes/ Tips

Much of this can be done to any process/ service with a bit of a change, but it’s nice to be able to do this to a process like DNSCrypt.

**

Keep in mind that you can add your own files to the makefile, such as “-march=native”, optimizing for your CPU. I can’t guarantee that this will play nice, or that it won’t add in unsafe compiler optimization! But you may end up using something like AES instructions since this deal swith crypto, and math, and this could speed things up.

***

Tip: The following commands will set your firewall so that:

1) If a connection is new, is over the loopback interface, is udp, and uses port 53, we accept it (allows dns resolution)
2) If a connection is already established from an outbound connection then we allow an inbound connection.
3)All other connections that do not meet the above criteria are blocked.

iptables -A INPUT -i lo  -m state --state NEW -p udp --dport 53 -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -m  state --state NEW,INVALID -j REJECT

PDF.js For Chrome – It Works!

edit: Now available on the Chrome Web Store: (use this! not the one I link later from Opera)

https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?utm_source=chrome-ntp-icon

So Opera recently came out with a PDF.js extension for their latest Blink build of the browser. I kinda thought, hey, Opera and Chrome aren’t all that different anymore… maybe it’ll work? So I downloaded the file from:

https://addons.opera.com/en/extensions/details/pdf-viewer/

And I got a pdf-viewer-0.8.169-1.nex and I changed the file extension to pdf-viewer-0.8.169-1.crx. 

I then launched Chrome with the command flag –easy-off-store-extension-install and opened up chrome://extensions. I dragged the .crx file onto the page, and voila – it installed!

So then I opened up the first PDF I found on Google and…

PDFjschromeSuccess! PDF.js now works in Chrome, with just a little bit of work. The extension almost certainly won’t autoupdate, though perhaps it will. No idea. But there you have it.

One of the benefits of PDF.js is that your entire PDF “program” is implemented in Javascript. Chrome runs Javascript in an incredibly tight sandbox in its renderer, so attacks using PDFs will be restricted to that sandbox.

So there you have it. Chrome now has PDF.js, and it’s available on Firefox and Opera as well. For more on PDF.js in Chrome, see my earlier post.

 

Configuring Grsecurity Is Easier – New Autoconfig

My previous guide on configuring Grsecurity isn’t too difficult to follow, but if messing with those settings is more than you want to do, there’s an autoconfig option.

Open your configuration with make menuconfig and then traverse via:

Security options –>

Grsecurity –>

Configuration Method

 

Set configuration method to automatic.

config1

 

You can state whether you need to run it in a VM, whether it’s for a server or desktop, whether you prioritize performance over security, and your special groups. And you can ‘tweak’ it from there, with the Customize Configuration option.

It takes seconds to configure the kernel with Grsecurity.

For my old guide see: http://www.insanitybit.com/2012/05/31/compile-and-patch-your-own-secure-linux-kernel-with-pax-and-grsecurity/

Windows Hardening Guide

Collaborative post by @0xdabbad00 (0xdabbad00.com) and @insanitybit (insanitybit.com)

 

Audience

This guide is focused on Windows Vista, 7 and 8 systems for personal use.  This guide is not concerned with the following:

– Not Windows XP or earlier because they simply do not have the security features necessary to securely use.  A lack of ASLR and SEHOP, no integrity levels, a kernel with exposed attack surface, and a general lack of privilege separation makes securing XP a task best left to science fiction.

– Not enterprise environments, though some of this information can certainly translate over

– No IDS, DNS log monitoring, or other network related activities that are usually only reasonable to spend time on in enterprise environments.

Strategy

Disrupt, deny, and degrade attacks through reduction of attack surface area and implementation of modern mitigation techniques.  Finally, prepare for the worst, assume APT.

Reduce Attack Surface

Vulnerabilities require one thing – code; if the code exists, so will vulnerabilities. The best way to avoid being exploited is to ensure there as few vulnerabilities as possible for the attacker to exploit.  The simplest and most effective way to do that is to minimize the amount of software on the system – less running code means less places for your attacker to poke at.

There are some key areas that are commonly attacked:

1) PDF Reader:  If possible uninstall Adobe Reader and use Chrome or Firefox’s built in PDF reader.  If you must use Adobe Reader ensure that Javascript is disabled and that Protected Mode is enabled in the security settings. There will be other steps in the guide for hardening your PDF reader further.

2) Java: Java is one of the most highly exploited programs on Windows systems. It’s a very easy target for attackers, and this is unlikely to change for a long time. If you can’t remove Java altogether I highly suggest changing your browser settings to “Click To Play Plugins”.

3) Windows Services: Windows, like any other mainstream OS, comes with a ‘default compatible’ attitude – it has to work for everyone. That means it comes with a large number of services running by default. These services are exploitable, and have been used for local privilege escalation in the past. Disable any Windows services that you don’t need. Deciding which services you do or don’t need requires a bit of research, as different users require different things.

For other software you’ve installed, such as an instant messaging client or torrenting client, always ensure that you have the latest version and keep track of security releases.  Many software applications have their own auto-update mechanisms, make sure you enable it if you don’t think you’ll stay on top of patching yourself.  You can also use software like Secunia’s PSI which will scan the software you have installed to ensure it is up-to-date.  Secunia PSI can be useful to install once and check for out-of-date software, but it’s somewhat awkward to use and have running regularly, so I uninstall it after running it once. Alternatively you can use the FileHippo updater, which is portable and will check for any out of date software in its repository.

 

Disrupt Exploits

Given the possibility that your software may be vulnerable to 0-day threats or known threats that have not yet been patched, the next line of defense is to use techniques that disrupt exploits from being successful.  This is what EMET does.  It takes a bit of configuration, so use insanitybit’s write-up as a guide: http://www.insanitybit.com/2012/07/26/setting-up-emet-3-5-tech-preview-9-2/

 

If an exploit does manage to get execution, the next line of defense is to break it’s ability to work correctly by denying it access to different APIs.  The best solution for this is AmbushIPS by @scriptjunkie1  This will protect best against ROP based exploits (which usually disable DEP as one of their steps which AmbushIPS check for), but also against exploits which have obtained full arbitrary execution.  If the attacker knows your are using AmbushIPS, he could likely modify his exploit to work around it, so to some degree this is security through obscurity, but setting up an IDS/IPS can prove very beneficial to those willing to manage them.  You can also write your own signatures for AmbushIPS to check for, which adds further unknowns for attacks.

 

AmbushIPS cannot only block exploits, but it can also log chosen Windows API calls to a remote server.  This could be helpful in identifying when an attack occurred and how, post-mortem.

 

Block Payloads

Although the stage in which an attacker launches their payload is both optional and late in the game, those looking to improve their security may look into AppLocker, an Anti-Executable security solution available for the more enterprise oriented Windows editions (Windows Server 2008 R2, Windows 7 Ultimate and Enterprise, Windows Server 2012, and Windows 8 Enterprise). Anti-Executable software works by preventing processes from launching based on a whitelist and blacklist. If Firefox.exe is running, and it tries to run evil.exe, and evil.exe is not whitelisted, then it will not run. This is most helpful for preventing malware that uses legacy techniques, and making it more difficult for an attacker to gain persistence.

AppLocker rules come in three types: path, hash, and my favorite, publisher.

A path rule is really quite weak. It basically says that ‘only files from this path can execute’, which means that all an attacker has to do to bypass that rule is write to the path and execute.

Hash rules are much more difficult to get around, but they’re also horribly difficult to maintain. Every time your program updates you need a new hash.

Publisher rules are based on certificate information. This is much easier to deal with, as it’ll only allow specific programs to run, but it won’t have to be updated for every program update.

While AppLocker is not enough for any attack that accounts for it, it can be useful when layered on top of other techniques. Just be sure that you realize its shortcomings.

 

Prepare For The Worst

Given the possibility that your laptop could just simply be stolen, encrypt your data with TrueCrypt (free) or Windows BitLocker (if you have Windows Enterprise or Ultimate editions).  Any and all sensitive information (ex. proprietary code for your company if you are a software developer) should generally be stored in some type of encrypted container.  Be aware that if you try to only encrypt specific data, Windows will still save a hibernation file (a copy of the RAM) to the system partition which may contain your sensitive information.

Here are guides for TrueCrypt and BitLocker.

 

Security advice not specific to Windows

Your browser is your main attack surface on a personal system, so take efforts to secure that by using various extensions (NoScript and HTTPS-Everywhere). You can find guides for securing Firefox and Chrome here and here. As a user if you secure your browser you’re securing the area that most attackers will attempt to exploit.

Many websites now offer dual-factor authentication, such as GMail and Facebook.  Take advantage of these, so you don’t end up getting locked out of your own email and social network sites if you ever get owned.

Do your banking from a different computer that you use infrequently, but still keep up-to-date on patches!  Have your various website accounts send password resets to an email account that you only access from this banking computer. Make sure you’re connecting to these websites through a secure and trusted network.

 

Conclusion

There is a lot of security software for Windows out there: Some legitimately adds protection, and some unfortunately exposes you to more attacks than it protects you from.  It’s impossible to cover it all in a single post, so we tried to stick to the built-in and free tools that are most important.

If you follow this guide you’ll be making an attackers job much more difficult. Though there is no silver bullet, and Windows security software is somewhat limited, you can use this guide to significantly improve your chances when facing the latest 0-day exploit in your browser.

As always, if you have suggestions for the guide, corrections, or general comments, please feel free to leave that all in the comments section and we’ll have a look.

 

Securing Java

It’s become all too clear in the last week that patching Java simply won’t protect you. This has been stated many times in the past, but it is so blatant right now that it needs to be reiterated, and steps need to be taken to keep users secure. For those of you who don’t know Oracle pushed out a patch for an exploit in the wild four days after it was being exploited, only to have a new exploit found the next day. That exploit is already being sold to exploit kits.

So as a user what can you do to stay safe if you can’t rely on patching?

Thankfully, browsers have set Java to Click To Play by default. Both Firefox and Chrome have done so, so make sure you use one of those and keep them up to date.

Another way to secure Java is to go into the Java Control Panel. Turn the security settings all the way up, and then go to the Advanced Settings.

These settings are fairly straight forward – when in doubt, set it to prompt.

Key areas are:

Enable granting elevated access to self-signed apps.

No! Uncheck that. An attacker can sign their applet and run with full execution rights, that’s no good at all.

Make sure that when there’s mixed code you prompt, or default deny the mixed code. This is another key area to secure.

There isn’t much more you can do with Java, but these steps should ensure that all exploits are, at the very least, hidden behind a click.