Louwrentius - Security

Systemd Forward Secure Sealing of system logs makes little sense

2014-11-22T12:00:00+01:00

Systemd is a more modern replacement of sysvinit and its in the process of being integrated into most mainstream Linux distributions. I'm a bit troubled by one of it's features.

I'd like to discuss the Forward Secure Sealing (FSS) feature for log files that is part of systemd. FSS cryptographically signs the local system logs, so you can check if log files have been altered. This should make it more difficult for an attacker to hide his or her tracks.

Regarding log files, an attacker can do two things:

delete them
alter them (remove / change incriminating lines)

The FSS feature does not prevent any of these risks. But it does help you detect that there is something fishy going on if you would verify the signatures regularly. So basically FSS acts a bit like Tripwire.

FSS can only tell you wether or not a log file has been changed. It cannot tell you anything else. More specifically, it cannot tell you the reason why. So I wonder how valuable this feature is.

There is also something else. Signing (sealing) a log file is done every 15 minutes by default. This gives an attacker ample time to alter or delete the most recent log events, often exactly those events that need to be altered/deleted. Even lowering this number to 10 seconds would allow an attacker to delete (some) initial activities using automation. So how useful is this?

What may help in determining what happened to a system is the unaltered log contents themselves. What FSS cannot do by principle is protect the actual contents of the log file. If you want to preserve log events the only secure option is to send them to an external log host (assumed not accessible by an attacker).

However, to my surprise, FSS is presented as an alternative to external logging. Quote from Lennart Poettering:

Traditionally this problem has been dealt with by having an external secured log server 
to instantly log to, or even a local line printer directly connected to the log system. 
But these solutions are more complex to set up, require external infrastructure and have 
certain scalability problems. With FSS we now have a simple alternative that works without 
any external infrastructure.

This quote is quite troubling because it fails to acknowledge one of the raison d'être of external log hosts. It seems to suggest that FSS provides an alternative for external logging, where in fact it does not and cannot do so on principle. It can never address the fact that an attacker can alter or delete logs, whereas external logging can mitigate this risk.

It seems to me that systemd now also wants to play the role as some crude intrusion detection system. It feels a bit like scope creep to me.

Personally I just wonder what more useful features could have been implemented instead of allowing you to transfer a log file verification key using a QR code to your smartphone (What the hell?).

This whole observation is not original, in the comments of the systemd author's blogpost, the same argument is made by Andrew Wyatt (two years earlier). The response from the systemd author was to block him. (see the comments of Lennart Poettering's blogpost I linked to earlier).

Update: Andrew Wyatt behaved a bit immature towards Lennart Poettering at first so I understand some resentment from his side, but Andrews criticism was valid and never addressed by him.

If the systemd author would just have implemented sending log events to an external log server, that would have been way more useful security-wise, I think. Until then, this may do...

Why you should not use IPsec for VPN connectivity

2014-01-28T12:00:00+01:00

IPsec is a well-known and widely-used VPN solution. It seems that it's not widely known that Niels Ferguson and Bruce Schneier performed a detailed security analysis of IPsec and that the results were not very positive.

We strongly discourage the use of IPsec in its current form for protection of any kind of valuable information, and hope that future iterations of the design will be improved.

I conveniently left out the second part:

However, we even more strongly discourage any current alterantives, and recommend IPsec when the alternative is an insecure network. Such are the realities of the world.

To put this in context: keep in mind that this paper was released in 2003 and the actual research may even be older (1999!). OpenVPN, an open-source SSL-based VPN solution was born in 2001 and was still maturing in 2003. So there actually was no real alternative back then.

It worries me that this research done by Ferguson and Schneier is more than a decade old. I've been looking for more recent articles on the current security status of IPsec, but I couldn't find much. There have been some new RFCs been published about IPsec but I'm not familiar enough with the material to understand the implications. They make a lot of recommendations in the paper to improve IPsec security, but are they actually implemented?

I did find a presentation from 2013 by Peter Gutmann (University of Auckland). Based on his Wikipedia page, he seems to 'have some knowledge' about cryptography. The paper adresses the Snowden leaks about the NSA and also touches on IPsec. He basically relies on the paper written by Ferguson and Schneier.

But let's think about this: Ferguson and Schneier criticises the design of IPsec. It is flawed by design. That's one of the worst criticisms any thing related to cryptography can get. That design has probably not changed much, from what I understand. So if their critique on IPsec is still mostly valid, all the more reason not to use IPsec.

So this is part of the conclusion and it doesn't beat around the bush:

We have found serious security weaknesses in all major components of IPsec.
As always in security, there is no prize for getting 90% right; you have to get
everything right. IPsec falls well short of that target, and will require some major
changes before it can possibly provide a good level of security.
What worries us more than the weaknesses we have identified is the complexity
of the system. In our opinion, current evaluation methods cannot handle
systems of such a high complexity, and current implementation methods are not
capable of creating a secure implementation of a system as complex as this.

So if not IPsec, what should you use? I would opt to use an SSL/TLS-based VPN solution like OpenVPN.

I can't vouch for the security for OpenVPN, but a well-known Dutch security firm Fox-IT has released a stripped-down version of the OpenVPN software (removed features) that they consider fit for (Dutch) governmental use. Not to say that you should use that particular OpenVPN version: the point is that OpenVPN is deemed secure enough to be used for governmental usage. For whatever that's worth.

At least, SSL-based VPN solutions have the benefit that they use SSL/TLS, which may have it's own problems, but is at least not as complex as IPsec.

Redhat explains why chroot is not a security feature

2013-08-07T13:00:00+02:00

I came across this Redhat security blog post that explains why the chroot command has it's uses, but it isn't magic security pixie dust. Running an application from within a chrooted jail or just on a well-configured system would result in the same level of security.

Josh Bressers:

Putting a regular user in a chroot() will prevent them from having access to the rest of the system. This means using a chroot is not less secure, but it is not more secure either. If you have proper permissions configured on your system, you are no safer inside a chroot than relying on system permissions to keep a user in check. Of course you can make the argument that everyone makes mistakes, so running inside a chroot is safer than running outside of one where something is going to be misconfigured. This argument is possibly true, but note that setting up a chroot can be far more complex than configuring a system. Configuration mistakes could lead to the chroot environment being less secure than non-chroot environments.

In the past I've tried to setup a chroot for an application and it was a pain. If you want to do it well, it will take quite some effort and every application has it's own requirements. But why spend all this effort?

Josh continues:

it may not be possible to break out of the chroot, but the attacker can still use system resources, such as for sending spam, gaining local network access, joining the system to a botnet, and so on.

A chroot jail hides the rest of the 'real' file system. But the file system is just one part of the security equation: an attacker that compromised the chrooted application can still execute arbitrary code. Not as the root user, fair enough, but does it really hinder the attacker? The attacker already gained a stepping stone to pivot into the rest of the network¹. As a non-privileged user, the attacker can try to exploit local kernel vulnerabilities to gain root access or stage attacks through the network on other hosts.

If you run some kind of forum or bulletin board, it is probably more likely that this software will be compromised than the web server itself. And the result is often the same: arbitrary code execution with the privileges of the web server software. So the attacker controls the application and thus all it's content, including email addresses and password(hashes).

A chrooted jail does not provide any additional security in this scenario. It may be a bit more difficult to access the rest of the file system, but if the attacker has access as an unprivileged user and file system permissions are set properly, is there a benefit?

I believe it is more wise to invest your time configuring proper file system privileges and propagate them through puppet, chef or ansible. And run some scripts to audit/validate file system privileges.

Update

If applications support chroot, it might still be wise to enable it. It's often very easy to configure and it will probably delay an attacker.

If you implemented network segmentation properly and have a sane firewall, the impact could be limited. ↩

Don't use cloud services if you care about secrecy of your data

2013-06-30T16:00:00+02:00

When you use cloud services, you are storing your data on other people's hard drives. The moment you put your data within a cloud service, that data is no longer under your control. You don't know who will access that data. Secrecy is lost.

Instead of using services like Gmail you may opt to setup some virtual private server and run your own email server, but that doesn't change a thing. The cloud provider controls the hardware, they have access to every bit you store on their platform.

If you encrypt the hard drive of your VPS you need to enter the encryption password every time you reboot your VPS. And how can you remotely type in the password? On the VPS console, a piece of software written by and under control of your cloud provider. They can snoop on every character you enter.

This may all sound far-fetched but it's about the principle of how things work. If you store unencrypted data on hardware that is not owned by you and under your physical control, that data cannot be trusted to stay secret.

If you care about the secrecy of your data, you should never store it with a cloud provider or any other third party.

I believe that the price you have to pay for any decent secrecy of your data is to run your own physical server. This is way more expensive in terms of time and money than using a cloud service, so it's up to you if it's worth it.

Although your own server will probably prevent your data being souped up with dragnet government surveillance, it will still be difficult if not impossible to protect you from a targeted investigation by a government agency.

A government agency can obtain physical access to your server and physical access is often the deathblow to any secrecy / security. Even if you implement encryption in the right manner, you are only decreasing the chance of their success of accessing your data, you are not eliminating their chances.

And in the end, a $5 wrench will probably do wonders for them. It seems that it even does wonders against encrypted hidden volumes.

But there may still be a small benefit. If a government agency requires a cloud service provider to hand over your data, they can do so without your knowledge. A gag order will prohibit the cloud provider from informing you. However, if the servers are your own and are located within a building you own, either privately or as a company, you are at least aware of what's happening. That may or may not be relevant to you, that's up to you to decide.

Linode hacked: the dark side of cloud hosting

2013-04-16T20:00:00+02:00

Linode has released an update about the security incident first reported on April 12, 2013.

The Linode Manager is the environment where you control your virtual private servers and where you pay for services. This is the environment that got compromised.

Linode uses Adobe's ColdFusion as a platform for their Linode Manager application. It seems that the ColdFusion software was affected by two significant, previously unknown vulnerabilities that allowed attackers to compromise the entire Linode VPS management environment.

As the attackers had control over the virtual private servers hosted on the platform, they decided to compromise the VPS used by Nmap. Yes, the famous port scanner.

Fyodor's remark about the incident:

I guess we've seen the dark side of cloud hosting.

That's the thing. Cloud hosting is just an extra layer, an extra attack surface, that may provide an attacker with the opportunity to compromise your server and thus your data.

Even the author of Nmap, a person fairly conscious about security and aware of the risk of cloud-hosting, still took the risk to save a few bucks and some time setting something up himself.

If you are a Linode customer and consider becoming a former customer by fleeing to another cheap cloud VPS provider, are you really sure you are solving your problems?

When using cloud services, you pay less and you outsource the chores that come with hosting on a dedicated private server.

You also lose control over security.

Cloud hosting is just storing your data on 'Other People's Hard Drives. So the security of your stuff depends on those 'other people'. But did you ask those 'other people' for any information about how they tink to address risks like zero-days or other security threats? Or did you just consider their pricing, gave them your credit card and got on with your life?

If you left Linode for another cloud VPS provider, what assures you that they will do better? How do you know that they aren't compromised already right now? At this moment? You feel paranoid already?

We all want cheap hosting, but are you also willing to pay the price when the cloud platform is compromised?

Linode hacked: thoughts about cloud security

2013-04-16T00:00:00+02:00

I bought a Linode VPS for private usage just after the report that Linode had reset all passwords of existing users regarding the Linode management console.

Resetting passwords is not something you do when under a simple attack such as a DDOS attack. Such a measure is only taken if you suspect or have proof of a serious security breach. I should have known.

There are strong rumours that Linode has actually been hacked. Although I signed up for a Linode VPS after the attack, I still checked my creditcard for any suspicious withdrawals.

Linode is as of this writing very silent about the topic, which only fuels my, and every other's suspicion that something bad has happened.

Whatever happened, even it isn't as bad as it seems, such an incident as this should make you evaluate your choices about hosting your apps and data on cloud services.

I don't care that much about rumours that creditcard information may have been compromised. Although in itself quite damning, what I do care is about the security of the data stored in the virtual private servers hosted on their platform.

I like this phase: "There is no cloud, only Other People's Hard Drives".

Everybody uses cloud services, so we all put our data in the hands of some other third party and we just hope that they properly secured their environment.

The cynical truth is that even so, a case can be made that for many companies, data stored in the cloud or on a VPS is a lot safer than within their own company IT environment. But an incident like this may prove otherwise.

And if you believe that data on a VPS is more secure than within your own IT environment, I believe that you have more pressing problems. The thing is that it doesn't tell you anything about the security of those cloud solutions. It only tells you something about the perceived security of your own IT environment.

The cloud infrastructure is just another layer between the metal and your services, and it can thus be attacked. It increases the attack surface. It increases the risk of a compromise. The cloud doesn't make your environment more secure, on the contrary.

So anyway, who performs regular security audits of Linode or (insert your current cloud hosting provider?) and what is the quality of the processes that should assure security at all times?

Questions. Questions.

This incident again shows that you should clearly think about what kind of security your company or customer data warrants. Is outsourcing security of your data acceptable?

Maybe, if security is an important factor, those cheap VPS hosts aren't that cheap after all. You may be better off creating your own private cloud on (rented or owned) dedicated servers and put a little bit more effort in it.

Building your own environment on your own equipment is more expensive than just a simple VPS, but you are much more in control regarding security.

Personal Security: erase your computer or phone before repair

2012-11-04T01:00:00+01:00

Computer nerds are self sufficient when it comes to fixing their computer. Non-computer experts have to find some other person with greater computer knowledge to repair their computer or phone. That person will then be able to access all data stored on their computer or phone.

By handing over their computer to a third party, such as a computer repair shop, they are giving their personal data to a stranger. And it is so easy for that stranger to access this data. So they will.

This is not only true for computers, but especially for phones. If you are a women, you should be extra concerned. It is so easy to obtain access to your photos. And people do.

The only safe thing to do is either:

encrypt your computer with full disk encryption (Truecrypt?);
wipe all internal hard drives.

Both actions will make it impossible for the computer technician to resolve any operating system or software related issues. Also, it will be harder to diagnose hardware failure. And if you erase the computer, who is going to reinstall it?

A third option would be to implement a secure file container where a user would put personal information. But this concept is way too hard to understand and implement for most users.

So in the end most people must find a person they can trust and who is willing to fix their computer. But that is never a safe bet.

So assuming that you must trust your computer to a person you don't know too well, it is smart to never store any content, especially personal pictures or videos on your computer that you would not want them to see.

I had to turn in my iMac for repair because the internal hard drive was dying. So I erased the entire disk by overwriting it with zeros. This takes a few hours, but it guarantees that my data will not fall in the wrong hands. Honestly, I don't have any data I'd really want to hide, but still, it's my data and I don't want it in the hands of unknown people.

Setting up a Squid proxy with Clamav anti-virus using c-icap

2012-08-26T22:00:00+02:00

Security is all about a defence-in-depth strategy. Create multiple layers of defence. Every layer presenting a different set of challenges, requiring different skill sets and technology. So every layer will increase the time and effort to compromise your environment.

A content-scanning proxy server may provide you with one of these defensive layers. A content scanning proxy checks all data for malware. It blocks all content presumed to be infected. This may prevent numerous infections of company computers. Basically, the proxy server is virusscanning all network traffic.

But there is a severe limitation. Any data requested through an SSL-connection (https://) cannot be scanned, precisely because it is encrypted. So if a blackhat is smart and serves all malware through HTTPS, a content scanning proxy will not stop that malware. There are man-in-the-midle solutions that do allow you to inspect SSL traffic, but there are some limitations and this is outside the scope of this post.

As I believe that most malware is still being served through unencrypted HTTP sites, a content-scanning proxy does create an extra layer of defence. I think it is worth the effort.

So I decided to create a content-scanning proxy based on available open-source software. In this case, open-source as in free to use in commercial settings.

So in this post I will document how to setup a content-scanning proxy based on Squid 3.1, c-icap version 1, the Squidclamav module and the Clamav anti-virus scanner.

The basis of this proxy server is Ubuntu 12.10 LTS.

Important:

How does it work?

The Squid proxy server must pass all content to the Clamav daemon. Squid can't do that by itself. It's needs some glue service. For this purpose, a standard protocol has been designed called 'ICAP'. The c-icap daemon, combined with the squidclamav module, is the glue between the proxy server and the anti-virus software. The fun thing about c-icap is that you can add extra content scanning features if you want, just by adding those modules. You can decide to implement additional commercial anti-virus products in addition to Clamav.

Installing Clamav and c-icap + development files

1. apt-get install clamav-daemon c-icap  libicapapi-dev apache2
2. freshclam (update clamav on the spot)

Apache or any other HTTP server with CGI support is required to display virus-warnings to end-users.

Installing squidclamav module for c-icap

Do not install squidclamav with apt-get, this version seems to contain bugs that prevent pages from loading properly. The latest version straight from the vendor does work properly.

1. cd /usr/src/
2. download the source from: 
"http://sourceforge.net/projects/squidclamav/"
3. tar xzf squidclamav-6.8.tar.gz
4. cd squidclamav-6.8
5. ./configure
6. make -j 2
7. make install

Squid configuration

Please download my sample Squid.conf configuration. The icap lines are of interest.

icap_enable on
icap_send_client_ip on
icap_send_client_username on
icap_client_username_encode off
icap_client_username_header X-Authenticated-User
icap_preview_enable on
icap_preview_size 1024

icap_service service_req reqmod_precache bypass=0 \ 
    icap://127.0.0.1:1344/squidclamav
icap_service service_resp respmod_precache bypass=0 \ 
    icap://127.0.0.1:1344/squidclamav

adaptation_access service_req allow all
adaptation_access service_resp allow all

It is the icap:// URL that calls a particular icap service (squidclamav) that processes all data.

Squidclamav icap module configuration

The configuration is stored in /etc/squidclamav.conf, and this is what I used:

maxsize 5000000
redirect http://proxy.company.local/cgi-bin/clwarn.cgi
clamd_ip 127.0.0.1
clamd_port 3310
timeout 1
logredir 0
dnslookup 1

Of interest is the redirect url, which tells the user that a virus is found. That line redirects the user towards a page as shown at the beginning of this post. You can customise this page with CSS, for example, you can add the company logo to make it more official.

c-icap configuration

This is the configuration I use:

PidFile /var/run/c-icap/c-icap.pid
CommandsSocket /var/run/c-icap/c-icap.ctl
Timeout 300
MaxKeepAliveRequests 100
KeepAliveTimeout 600  
StartServers 3
MaxServers 10
MinSpareThreads     10
MaxSpareThreads     20
ThreadsPerChild     10
MaxRequestsPerChild  0
Port 1344 
User c-icap
Group nogroup
ServerAdmin you@your.address
ServerName Anti-Virus-Proxy
TmpDir /tmp
MaxMemObject 1048576
DebugLevel 0
ModulesDir /usr/lib/c_icap
ServicesDir /usr/lib/c_icap
TemplateDir /usr/share/c_icap/templates/
TemplateDefaultLanguage en
LoadMagicFile /etc/c-icap/c-icap.magic
RemoteProxyUsers off
RemoteProxyUserHeader X-Authenticated-User
RemoteProxyUserHeaderEncoded on
ServerLog /var/log/c-icap/server.log
AccessLog /var/log/c-icap/access.log
Service echo srv_echo.so
Service squidclamav squidclamav.so

Configuring Apahce web server

The warning page should be put in /usr/lib/cgi-bin. You may have to copy clwarn.cgi into this directory. Also make sure that your Apache configuration contains a directive like:

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
</Directory>

Automatic proxy configuration through DHCP and WPAD

To make the entire setup extra nice, use your DHCP configuraiton to inform clients about the proxy configuration. Clients must be configured to autodetect proxy settings for this to work.

Put a wpad.dat in the root directory of your http server:

function FindProxyForURL(url, host)
{
    if (dnsDomainIs(host, "localhost")) return "DIRECT"; 
    if (isInNet(host, "127.0.0.0", "255.0.0.0")) return "DIRECT";
    if (isPlainHostName(host)) return "DIRECT";
    if (isInNet(host, "192.168.0.0", "255.255.255.0")) return "DIRECT";
    return "PROXY proxy.company.local:3128";
}

And also add the appropriate mime type for .dat files in /etc/mime.types

application/x-ns-proxy-autoconfig           dat

Restart the apache webserver after these modifications.

Now add the proxy to the DNS configuration of your DNS server like proxy.company.local.

Most important, add this directive to the general portion of the configuration file:

option local-proxy-config code 252 = text;

Add this directive to the particular scope for your network:

option local-proxy-config "http://proxy.company.local/wpad.dat";

Restart your DNS and DHCP server.

Monitoring proxy performance

The cagemgr.cgi file provides very detailed information about the performance of your Squid proxy. This is more relevant regarding actual cahcing performance than for anti-virus scanning, but this may be of interest. Especially the 'general runtime information' is of interest, as it shows the hit-rate, memory usage, etc.

First, make sure you take the appropirate precautions as not to expose this page to the entire company network without some protection, as it can contain sensitive information.

If you have installed squid-cgi just browse to http://your.proxy.server/cgi-bin/cachemgr.cgi

Some example data:

Cache information for squid:
    Hits as % of all requests:  5min: 10.3%, 60min: 4.1%
    Hits as % of bytes sent:    5min: 81.4%, 60min: 5.2%
    Memory hits as % of hit requests:   5min: 0.0%, 60min: 14.8%
    Disk hits as % of hit requests: 5min: 0.0%, 60min: 74.1%

Final words

This whole configuration shouldbe sufficient to setup a content-scanning proxy server. I have no experience how well this solution performs and you may have to do some benchmarks if your own to determine if it is capable of handling the traffic users generate. The fun thing about this setup is that it is modular. For example, you can have one Squid + HTTP box, and a separate host just for the c-icap service and Clamav service.

Besides the whole content scanning part, a proxy server, based on some non-scientific tests, does seem to improve performance for end-users. It may save you an expensive upgrade to a faster corporate internet connection.

Improving web application security by implementing database security

2012-05-18T01:00:00+02:00

Security is about defense-in-depth. It bogles my mind why it is so difficult to implement defense-in-depth security in web applications. 99.9% of applications use a single database account, with root-like privileges. Easiest for the developer of course, and the database is just a data store. It is not understood for what it really is. Your database is your only and last defensive layer that you have before the attacker compromises your data. Use it well.

For example, you can use your database to protect you against high-impact attacks such as SQL-injection.

I created a presentation about this topic a while ago You can download this presentation here:

http://mini.louwrentius.com/static/files/designingsecureapplications.pdf

A short summary of the points made.

Truly understand your application and their requirements.
Do not create a monolithic application, create separate applications. For example, at least separate front office and back office.
Run those applications under different operating system users or ideally on different servers, residing in different network segments.
It suddenly makes sense to put your database server in a separate secure network segment as opposed to running it on the same box as the application server.
Do not use a single database account with root-like privileges.
Create separate database accounts for separate application components. Only assign those privileges required for that application. White-list privileges within the database. This is key.
Understand that for end-user authentication, 'select username,password from user' kinda privs is not required!
Use stored procedures and functions wisely. By only providing access to functions, views and stored procedures, while preventing access to tables, you can significantly reduce the impact of SQL-injection or other application level security breaches.
In any case, understand that an attacker can never obtain more database privileges than the database account used. Even if the entire application server is compromised. This is especially important for your internet-facing applications.
Use your database as an extra layer of defense.

Why security is all about defense in depth

2012-03-24T00:00:00+01:00

Many people asume that if you regularly update your computer, you are safe from hackers. But nothing could be further from the truth. Keeping your systems up-to-date only protects you against exploits for publicly known vulnerabilities.

Your systems are still not protected against privately known vulnerabilities and if hackers have zero-day exploits for such vulnerabilities, you are clearly having a false sense of security.

There couldn't be a better example than a high-risk vulnerability MS12-020 regarding the Microsoft Remote Desktop Protocol interface, as present on TCP-port 3389. Any unpatched Microsoft Windows-based server or desktop system can be compromised through this vulnerability. If the system is vulnerable and TCP-port 3389 is accessible, it is over. Your data is compromised.

Now, how many people knew about this vulnerability and for how long?

As we speak, someone may be reading these very words on your computer, just remotely, because of an undisclosed, unknown vulnerability. That sounds like paranoia, but it isn't.

Zero-day exploit market

There is a whole zero-day exploit market. Exploits are sold at enormous prices, as high as $100.000+ dollars. Only those who have the means (money) and a need for them will pay such prices. Buyers often tend to be government agencies and such.

There is no doubt in my mind that the computer I'm currently working on is affected by high-risk vulnerabilities I don't know of. It is very likely that for some of them, exploits exist. But look at the risk: who is going to spend a $100.000 exploit on me? But is the intelectual property of your company worth that much? Might sound way more realistic already, doesn't it?

You may hope that zero-day exploits are sold to trustworthy governments, but the marked is free. Anyone with sufficient means can buy them. Some sellers may scrutinize to whom they sell, but others?

This whole zero-day exploit market is a problem. Exploit-sellers have nothing to gain and only to loose from public disclosure of the vulnerability. As long it is undiscovered, it can be used by buyers. All parties involved in this market benefit from keeping systems insecure. From keeping systems unpatched.

So instead of informing the vendor of a security vulnerability so the public can be protected, knowledge of the vulnerability is sold to the highest bidder who then does who knows what with it.

For most organisations and people, the upside is that nobody will spend a $100.000 on you if you're not worth it. The reason is that every time an exploit is used, it can be discovered, rendering the exploit useless once a security patch is released.

Protecting against zero-day exploits

The question is then what to do against this kind of threat. What can you do to protect yourself against the risk of zero-day exploits if you perceive the risk as realistic towards your organisation.

The answer is a security strategy of defense in depth. It is not a solution that ends all problems, but it decreases the risk that your organisation gets compromised. It is about trying to diminishing risk to acceptable levels.

Assume that you will get compromised. Then, think about what can be done to reduce the impact of the hack. Will only one server get hacked, or the entire internal company network?

Defense in depth is the principle that you do not rely on one single security measure to protect systems and services from a compromise. There are many ways to implement such a strategy and I will name a few.

Only expose those services towards the internet that are required for production.
Make sure you have proper network segmentation in place, systems should not provide a stepping stone for an attacker to enter your internal company network.
Never expose management interfaces such as RDP towards the internet directly, use an additional security layer (white list IP address or use VPN).
Establish an emergency patch-policy to make sure that all systems are patched outside regular maintenance windows if high-risk vulnerabilities are reported.
Monitor the heck out of your environment. Carefully try to log and alert to those events that may indicate a security breach.
Audit your systems, regularly check for misconfigurations and resolve them.
Select hardware and software vendors based on their security track record.
Use different vendors and brands for different defensive layers.
Consider internet off-limits for end-user systems processing sensitive information

Software is vulnerable so prepare for the worst.

Setting up a VPN with your iPhone using L2TP, IPSec and Linux

2011-12-11T16:00:00+01:00

This blogpost discusses how to setup an IPSec-based VPN between your iPhone and a Linux server.

Updated 16 October 2012 - now compatible with Ubuntu 12.04 LTS

IMPORTANT! (update January 2013)

I find using OpenVPN with the new iOS OpenVPN client a way better solution. OpenVPN actually restores VPN connectivity when returning from sleep.

Why using a VPN with your iPhone?

Security: all data is encrypted and cannot be read by malicious people trying to eavesdrop on your data.
Performance: my subjective experience is that a VPN can speed up web browsing, it seems to reduce latency.

Introduction

I am assuming that you use:

an iPhone as the VPN client
a Debian-based Linux distro, such as Debian or Ubuntu (used here)

We will use the following software:

openswan
xl2tpd
pppd

To setup the VPN, we need to configure the following steps:

install the software
configure IPSec
configure L2TP
configure PPP
open up the appropriate firewall Ports
setup firewall rules to forward traffic between the iPhone and Internet
configuring the iPhone

This set of instructions is 90% based on instructions on peen.net made by Niels Peen (Groeten!). I borrowed some other stuff from this blog.

I use openswan for IPSec support because strongswan does not support NAT by default. I just want to use software as part of the operating system and don't like to have to maintain manually compiled versions. This is why.

Initial assumptions

You are using a Linux host as the VPN server
The server is accessible from the internet or the appropriate UDP ports are forwarded to the box.
You have full control over the box and it's firewall configuration.
Your iPhone has an unfiltered internet connection. If UDP is blocked, this type of VPN is not for you.

Install the software

First, we start with installing all required software:

apt-get install openswan xl2tpd ppp

Configure IPSec

Now we start with configuring the software. First we start with IPSec:

/etc/ipsec.conf

config setup
    nat_traversal=yes
    protostack=netkey
    plutostderrlog=/tmp/log.txt (for debugging)

conn L2TP-PSK
    authby=secret
    pfs=no
    rekey=no
    type=tunnel
    esp=aes128-sha1
    ike=aes128-sha-modp1024
    ikelifetime=8h
    keylife=1h
    left=<INTERNET IP ADDRESS OF ROUTER / SERVER>
    leftnexthop=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    rightsubnetwithin=0.0.0.0/0
    auto=add
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear

Some notes about this configuration:

We use a secret or password for authentication. Sources on the internet seem to suggest that the iPhone cannot handle certificates.
we must configure the dead peer detection rules at the bottom or else you cannot reconnect to the VPN when returning from sleep.

We thus also need to configure an encryption secret (password) for the IPSec tunnel.

/etc/ipsec.secrets

%any %any: PSK "thisismysupersecretpassword"

It is smart to choose a strong (long) password.

Configure L2TP

Inside the directory /etc/xl2tpd you have to edit xl2tpd.conf like this:

[global]
auth file = /etc/l2tpd/l2tp-secrets
debug network = yes
debug tunnel = yes

[lns default]

ip range = 10.0.1.201-10.0.1.240
local ip = 10.0.1.200
require chap = yes
refuse pap = yes
require authentication = yes
name = <ENTER SOME NAME HERE>
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

The "ip range" is within your internal network. It is a range outside of your DHCP-scope. The "ip range" must not include the "local ip". This IP address is dedicated to your Linux host.

Important: once the VPN setup is working properly Turn off all debugging options (set them to 'no'). Otherwise, your logs will fill up very quickly because every time a packet is transmitted, this is logged.

Configure PPP

Now we must configure PPP. Edit /etc/ppp/options.xl2tpd and make it look like this:

ipcp-accept-local
ipcp-accept-remote
ms-dns <ADDRESS OF LOCAL OR REMOTE DNS SERVER>
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute 
debug
lock
proxyarp
connect-delay 5000

Note that you must enter a valid DNS server that must be reachable by the VPN client (iPhone) through the tunnel.

We are almost there. Now we must also configure a password for the PPP connection. Edit /etc/ppp/chap-secrets and make it look like this:

* * thisissomesecretpassword *

This password is not related to the IPSec password. I think it is wise to configure different passwords for IPSec and PPP.

Configuring the firewall

An IPSec + L2TP + PPP VPN requires the following ports to be opened:

500/udp
4500/udp
1701/udp

You must open these ports in your firewall yourself.

Configuring traffic forwarding rules

If you use a Linux box with IPtables, you may already have a functioning configuration. However, this line is required for traffic forwarding to work:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

You must replace the correct IP addresses according to your configuration. You may also have to enable traffic forwarding like this:

echo 1 > /proc/sys/net/ipv4/ip_forwarding

A detailed firewall configuration guide is outside the scope of this tutorial.

If you use IPtables for your local firewall, you may be interested in my "Linux Firewall script" (shameless plug alert).

Configuring the iPhone

To configure a VPN profile, goto settings -> general -> network -> vpn (at the bottom). Choose 'Add VPN Configuration..."

Enter a description
Enter the IP address or DNS name of your Linux box.
The 'account' field can be anything you like.
Leave RSA SecurID off.
The Password is the PPP password configured in /etc/ppp/chap-secrets
The IPSec secret (/etc/ipsec.secrets) goes into the 'Secret' field.
Keep 'Send All Traffic' enabled.

If the connection succeeds, a VPN symbol will show up in the iPhone status bar. All traffic from then on will flow through the VPN.

It may not immediately work. Look in /var/log/auth.log and /var/log/daemon.log for debug messages.

Once it is working properly, disable all debug settings in xl2tpd.conf and restart the daemon.

Final remarks

You may have to tweak the 'dead peer detection' within the IPSec configuration. When the iPhone comes out of sleep, the VPN connection cannot be reinitiated right away, which is inconvenient.

Also, I'm not sure what the impact is on battery life.

Is there an easy and secure way to transfer files?

2011-09-17T09:00:00+02:00

Many organisations just assume that the local physical network is trusted. That their network equipment is physically secure and that it is impossible for an attacker to get on the wire and start eavesdropping on network traffic.

Many organisations do not seem too concerned about a very old vulnerability regarding Ethernet-based networks called ARP-poisoning. Basically ARP-poisoning means that an attacker-controlled system steals the identity of another legitimate server, thus drawing all network traffic away from the legitimate server to the attacker-controlled system. Then, the attacker can do with that traffic as he or she sees fit. The attacker will be performing a man-in-the-middle attack. Please note that such an attack is trivial using tools as Cain and Abel or Dsniff.

It is often the case that many different server systems are placed in a single network segment or VLAN. That implies that any of these systems poses a threat to each other. It takes just one hacked system to compromise network traffic between all the other systems. This is especially a threat to all unencrypted network traffic, but encrypted sessions may also be attacked if clients don't check the sever's identity.

Unless you've actually implemented proper network segmentation using separate (V)LANS and filter traffic between these network segments through firewalling, your environment may be at risk. In that case, please understand that it takes just one single web application containing just one vulnerability to compromise the entire environment.

Not everybody has implemented proper network segmentation and firewalling, preventing these kind of attacks. And it takes quite some labour to change all that. So what can you do, assuming that you want to do something right now?

In general, in a shared network environment, as described, the only way to make sure that data in transit is kept confidential and unmodified is to make proper use of encryption, identification and authentication.

The solution

To secure web traffic, there is already a fairly easy solution: using HTTPS or HTTP over SSL. The most difficult part is getting a valid SSL certificate and configuring the HTTP server to use it.

But if you want to transfer files between servers or between clients and servers? How about that?

Is there actually an easy way to securely transfer files between two hosts? From what I can see, the answer is "no". Security comes with some additional effort and it isn't easy.

The first problem is to understand what 'secure' actually means. To me, it means that data is not stolen or modified by an attacker during transit.

There are three requirements to make sure that confidentiality and integrity is guaranteed:

data in transit is encrypted;
the client authenticates the server;
the server authenticates the client.

Encryption prevents a man-in-the-middle attacker from eavesdropping or altering data. And if the client verifies the identity of the server, the attacker cannot impose the real, genuine server. This part may be overlooked. "I'm using SSL, thus encryption, so I am safe, right?". That is a firm negative. The client is identified with a password, passphrase or client-side SSL certificate. But how does the client identify the server? If the client doesn't verify the identity of the server, you might as well turn encryption off.

For the Windows platform, there is no native solution. Most of the time, files are transfered using SMB and thus your files can be grabbed from the wire and you may be transferring your files to some impostor instead of the genuine host.

The other often-used solution is FTP. And everyone knows that the biggest problem with FTP is the lack data encryption. All communication, including credentials for authentication, are transmitted in plain-text.

Without any additional third-party software, it is impossible to securely transfer files between Windows hosts, except for one solution that I have never seen used: IPsec. IPsec is used to encrypt any network traffic between two host, thus also SMB traffic.

The Unix world has only one solution without using third-party tools and that is transferring files using SSH as a secure transport. But SSH is also used for secure shell access to hosts and it may be difficult to prevent shell access and still allow file transfers.

So now there is a new tendency to use FTP over SSL. You have the same inconvenience as with HTTPS: you need to install a valid SSL certificate on each FTPS server. And although this does improve security, encryption is still useless if the client side system does not properly validate the server's identity.

Furthermore FTP uses a control channel for commands and a separate data channel to transfer the actual data. You want both channels to be encrypted, but that may not be the default. Check your FTP server's configuration to make sure this is the case.

Implementations

To implement FTP over SSL on Windows, you might want to take a look at the Filezilla server. An FTP server that also supports FTP over SSL. It had some security vulnerabilities in the past but not too many. To me, it is a better solution than to expose TCP-port 445 to other systems. The SMB service doesn't have a good security track-record.

For Unix environments, take a look at VSFTPD. The Very Secure FTP daemon, is written by Cris Evans, who works on the security team for Google. The irony is that although VSFTPD itself doesn't seem to be affected by any security vulnerability itself, the hosting provider hosting the software was compromised by an the attacker. This attacker put a back-door in a specific VSFTPD release.

Anyway, I still recommend VSFTPD as it is very well-document and the configuration is simple.

If one of these solutions is not an option for your particular situation, you might think about using your existing insecure file transfer method on top of a VPN connection that handels authentication and encryption, such as OpenVPN. But setting up OpenVPN within such an environment may also be cumbersome.

Recent events regarding compromised certificate authorities show that the trust model SSL-authentication often leans upon may be broken. You must be sure which certificate authorities to trust. If you have your own certificate authority, make sure you take every precaution to keep it secured.

Question: should the client rely on build in CA certificates, the sames as present in your browser? Or are you going to configure the client to accept only the single certificate of the server?

If you have any other suggestions for a simple solution to securely transfer files between hosts, feel free to leave a comment.

Parallel / distributed password cracking with John the Ripper and MPI

2011-02-05T20:00:00+01:00

This article has been updated to reflect the changes for John version 1.7.8 as released in june 2011. The most important change is the fact that MPI support is now integrated in the jumbo patch.

The original John the Ripper off-line password cracker only uses a single processor (core) when performing brute-force or dictionary attacks.

JtR does not use multiple cores (or machines). However, there is a patch available that enables support of MPI. MPI allows you to distribute the workload of a program across multiple instances, thus cores or even machines, but your application must support it.

The fun thing with MPI is that it is very easy to create a password cracking cluster. But for now let's just focus on using all these unused CPU cores to help us with cracking passwords.

I am using Ubuntu and Debian Linux as my platform but Mac OS X works also perfectly.

install MPI support

Note: Mac users have mpi support installed by default and don't need to install this.

apt-get install libopenmpi-dev openmpi-bin

download John the Ripper with extra patches

Get the john-1.7.8-jumbo-2.tar.gz file.

extract John & edit the Make file

tar xzf john-1.7.8-jumbo-2.tar.gz
cd john-1.7.8-jumbo-2/src

uncomment the following lines in the Makefile:

CC = mpicc -DHAVE_MPI -DJOHN_MPI_BARRIER -DJOHN_MPI_ABORT`
MPIOBJ = john-mpi.o`

Compile John the Ripper with MPI support

Run make and choose the most appropriate processor architecture. Example:

make linux-x86-64 (for 64-bit i386)
make linux-x86-sse2 (for 32-bit i386)
make macosx-x86-64 (for 64 bit Mac OS X)

Test john the Ripper

cd ../run
./john --test

Look at the benchmark values of the first test and remember them. Now let's see if MPI does any better:

mpirun -np [number of processor (virtual) cores] ./john --test

Let's asume that you have an iMac 27" with a Core i7 with 4 real cores and hyper threading enabled. This will provide a total of 8 virtual cores.

mpirun -np 8 ./john --test

If you notice a significant increase in performance, you know that MPI is working properly.

Some benchmarks without and with MPI support (Traditional DES)

These are the benchmark test results when using a single core on an old Nehalem Core i7 920:

Many salts: 2579K c/s real, 2579K c/s virtual
Only one salt:  2266K c/s real, 2266K c/s virtual

These are the benchmark test results when using MPI and thus all 8 cores:

Many salts: 11015K c/s real, 11015K c/s virtual
Only one salt:  9834K c/s real, 9834K c/s virtual

And just look at the performance improvement when we overclock from 2,66 to 3,6 Ghz:

Many salts: 15004K c/s real, 15004K c/s virtual
Only one salt:  13232K c/s real, 13232K c/s virtual

That is very significant. Now admire how the Core i7 920 @ 3.6 Ghz is blown away by the Sandy bridge based Core i7-2600 @ 3.4 Ghz:

Many salts: 20007K c/s real, 20209K c/s virtual
Only one salt:  16881K c/s real, 16881K c/s virtual

Setting up an MPI cluster

MPI clustering is based on using SSH keys. There is a single master that uses all nodes to perform the computation. The nodes are put into a text file nodes.txt like this:

node01  slots=2
node02  slots=2
node03  slots=4 
node04  slots=4

In this example, node 2 and 3 are dual-core systems, while node 3 and 4 are installed with quad-core processors. You must create an account on all your nodes with the same name that is used on the master, when running the master process. You also must generate a private SSH key and distribute the public part as the authorized_keys file to all nodes. This is outside the scope of this post. Please note that the SSH private key should be loaded with ssh-agent if used with a passphrase, or do not configure a passphrase on the key. If you do not use a pass phrase, understand that anyone with access to the key can access all nodes.

You may also have to put the nodexx entries in your /etc/hosts file if the names cannot be resolved by DNS.

Now I'm assuming that you are able to ssh into all nodes without requireing a password, thus ssh is properly setup.

* mpirun -np 12 -hostfile nodes.txt ./john --test

Now you should see increased performance, beyond the limit of a single host.

Some benchmarks

I ran a password cracking test on some data using a large dictionary. These are the performance differences when using all 8 cores of my Core i7 920 instead of just one:

single: 0:00:04:48      c/s: 11192K
mpi:    0:00:01:26      c/s: 46568K

The performance increase is significant.

Firewire: the forgotten security risk

2011-01-18T20:43:00+01:00

The battle between Firewire and USB has been won by USB, but Firewire is still arround. It is not that prevalent, cheap computers lack Firewire, but they often have a PCMCIA slot.

The thing is this: Firewire allows direct access to all RAM of your computer. An attacker can:

unlock your screensaver without a valid password;
read the contents of documents or files present in memory;
defeat FDE (Full Disk Encryption) like Truecrypt or Bitlocker;
do nasty things with your computer limited only by skill and imagination.

So if you leave your system unattended for a short duration, consider your system compromised. I mean, if you are a celebrity or something, otherwise, don't worry, nobody would be bothered since it is a risky attack: the attacker needs physical access.

The attacker attacks your laptop by connecting his laptop to yours with a Firewire cable. Firewire must be enabled in the BIOS of the victim, which is the default in most cases. Even if Firewire is disabled, the PCMCIA adapter can also be used to access RAM. The attacker can insert a PCMCIA Firewire controller and use it to attack your laptop.

Basically, the Attacker makes the attacking laptop pretending to be an iPpod, a type of advice which is allowed to access memory through DMA. This allows the attacker READ and WRITE access to memory. The possibilities are endless, but injecting executable code, compromising the laptop is not far fetched.

Many people may already have stopped reading because this attack is very old and widely publicised: it dates back to 2003/2004. However if you are not familiar with this attack and want to know more about it, visit this site.

The mitigation

As far as I know, the only solution to prevent this type of attack is to disable both Firewire and PCMCIA support in the BIOS. It is smart to protect the BIOS with a strong password, so both options cannot be enabled.

I read somewere that most recent Apple Macbook models are no longer vulnerable, but I could just make that up.

LFS - Linux Firewall Script released

2010-12-28T01:15:00+01:00

I started a small new Google project for a new script I wrote called LFS. It stands for Linux Firewall Script.

I run a small Linux box as an internet router that doubles as a firewall. The firewall is configured using iptables. In my opinion, iptables is not the easiest tool to use and may have a steep learning curve for people new to it.

The goal of LFS is to provide an easier interface to iptables. It also adds some features that by default are not or difficult to setup using only iptables. The most important additional feature is the use of objects and groups. Object groups can be used to make a single rule affect multiple hosts, networks or services.

LFS uses a single configuration file which contains the firewall rules. Rules look like this:

nat 192.168.1.0/24 88.32.44.144 eth0
port_forward 88.32.44.144 192.158.1.10 80/tcp 8080/tcp

Or by using variables:

nat "$INTERNAL_NETWORK" "$EXTERNAL_IP" "$NAT_INTERFACE"
port_forward "$EXTERNAL_IP"  "$INTERNAL_HTTP_SERVER" "80/tcp" "8080/tcp"

Please visit the project page for some examples.

Why filtering DHCP traffic is not always possible with iptables

2010-12-27T14:57:00+01:00

When configuring my new firewall using iptables, I noticed something very peculiar. Even if all input, forward and output traffic was dropped, DHCP traffic to and from my DHCP server was not blocked even if there were no rules permitting this traffic.

I even flushed all rules, put a drop all rule on all chains and only allowed SSH to the box. It did not matter. The DHCP server received the DHCP requests and happily answered back.

How on earth is this possible? In my opinion, a firewall should block all traffic no matter what.

But at least I found out the cause of this peculiar behaviour. The ISC DHCP daemon does not use the TCP/UDP/IP stack of the kernel. It uses RAW sockets. Raw sockets bypass the whole netfilter mechanism and thus the firewall.

So remember: applications using RAW sockets cannot be fire walled by default. Applications need root privileges to use RAW sockets, so RAW sockets thankfully cannot be used by arbitrary unprivileged users on a system, but never the less. Be aware of this issue.

Please understand that if a serious security vulnerability is found in the ISC DHCP daemon, you cannot protect your daemon with a local firewall on your system. Patching or disabling would then be the only solution.

The minimum requirements for a secure system

2010-11-26T19:42:00+01:00

The most secure server system is a system that is not connected to a network and turned off. However, little work seems to be getting done this way. So we want to turn systems on and connect them to a network, or even (God forbid) the internet.

The thing is this. A system connected to a network without any running services is almost as as secure as a system that is turned off. They also share a common property: they are useless. A system starts to get useful if you start running services on them. And make these services accessible from the network for clients.

Services

Security on a technical level is all about securing those services. Every service that you enable is an opportunity for an attacker to compromise your system. If a service is not installed or running on your system, it cannot be used to compromise your server.

If a service is enabled and accessible through the network, it is logically of vital importance that you know:

what does this service do?
what can it be used for?
what steps needs to be taken to properly secure it?

If you know what a service does, you can understand the potential security risks. If you understand the product you are using, you can secure it properly. Security is all about understanding. If you don't understand what you are running, then it can't be secure.

Firewalls

So if you only run required services, why do you need to run a firewall? You don't. Yes that's right. Think about it. A firewall protects services that should not be accessible and allows access to services that should be accessible. If you just disable those services that should not be accessible from the outside, why use a local firewall? You don't want the Internet to access the SNMP-service on your system, you say? But then why not bind it only to the management interface instead of the production interface? You have a separate management network, right?

Of course, firewalls are a good thing. They are an ADDITIONAL line of defense. They mostly protect you against yourself. If you make a mistake and, by accident, enable some vulnerable service on a system, a properly configured firewall will prevent access to it and save your behind. That is the purpose of a firewall.

People often wrongly see the firewall as the first line of defense. If you do, you are wrong. The first line of defense is to secure your services.

The whole point is that there are holes in your firewalls. Those holes allow access to services. Those services may be necessary, like a web server, but nevertheless holes. You are exposing services to the Internet.

Web applications (or web-based back doors?)

We are now mostly running web-based applications on the services that we make accessible for the network or the internet. Those applications run on application servers. Yes, these application servers, like Apache Tomcat or IIS ASP.NET need to be secured, but nowadays, they are almost secure by default.

All security depends on the level of security of the application you are running on your application server. Is your application written well, with security principles in mind? Does it protect against SQL-injection or cross- site scripting? Are sessions predictable? Can a user access data of another user?

Firewalls don't protect against vulnerabilities in your web applications. You need to do it right at the core level: the application itself. Just like how you harden a system. You must run secure code.

And be aware that if you run third-party code, watch out for security news. There have been many worms exploiting vulnerable commodity software such as phpBB, Wordpress or similar products.

This is the really hard part. Deploying secure software and keeping it secure during the development life cycle.

Patches

The last fundamental principle of keeping systems secure is keeping up with security patches. Many security vulnerabilities are often only exploitable under specific conditions and may not be that important. But the most important thing is to be aware of vulnerabilities and available patches. Then you can decide for yourself how to act.

There is always a risk that a security patch breaks functionality. But that's not a real problem, because you have this test environment so you can check first, right?

Keep up with security patches and non-security patches. If you first have to install 100+ patches to be able to install the latest high-risk security patch, something might break. So then it's choosing between staying vulnerable or going off-line until you have fixed everything.

Conclusion

So what are the most basic ingredients for secure systems?

only run required services
harden those required services
deploy a firewall as an additional defense layer
deploy secure application code
keep up-to-date with security patches
Audit and review your systems and application code on a regular basis.

With this small number of steps, you will be able to protect against a lot of security threats. I don't say this is everything that is necessary. But it is a good foundation to build on. You still have to identify risks that may apply to your particular situation. These risks may require you to take (additional) measures not discussed here.

'Syslog: the hidden security risk'

2010-03-18T08:23:00+01:00

People sometimes forget that there are also a number of UDP-based services that may pose a threat to the security of your systems. SNMP is a well-known service, notorious for being configured with a default password (or community string).

But there is another service that is often not seen as a risk. This is the syslog service. Syslog is used on virtually all UNIX-like platform for logging messages of the system to one or more log files to disk. The syslog service often listens on the network, on UDP-port 514. Please note that syslog does not perform any authentication of data that is sent to it.

So what does this mean?

An attacker can:

Create a denial-of-service condition (DoS) by sending large amounts of data to the syslog service, filling up disk space.
Once the disk is full, logs can no longer be saved, thus any attack that would leave a trail within the logs would go unnoticed.
by sending large amounts of specially crafted messages, an attacker can cause chaos if logs are monitored by intrusion detection systems or other systems that create alerts.

How to attack? Just use netcat:

nc -u [IP-address] 514

Once you are connected, anything you type will be logged in a log file.

How to mitigate this issue?

Firewall access to UDP-port 514
Make sure that the syslog service does not listen on the network if not required, only on localhost.

Ubuntu and full disk encryption (FDE)

2010-02-22T22:50:00+01:00

Ubuntu is based on Debian Linux. As part of a regular Debian installation, you can choose to create an encrypted disk volume based on LUKS. This is different from the option within the Ubuntu installation to encrypt home directories. To be able to install Ubuntu and use full disk encryption, you need to download the alternate install CD / DVD. Only this version of Ubuntu supports LUKS as an installation option.

You will have either two options:

use the default choice, creating a swap partition, boot partition and the encrypted root file system on top of LVM;
create separate crypted partitions yourself manualy.

Personaly I don't care for separate partitions and use the provided automatic option. If you do care, please read this blog for more info.

disk-encryption/

The security risk of vendor-supplied default SSL certificates

2009-10-30T20:09:00+01:00

Often, software comes supplied with some default SSL certificate, for testing purposes, such as those 'snake oil' certificates (they are called snake oil certificates for a reason). In practice, I often encounter usage of such certificates. People may seem to think that as long SSL is used, authentication and thus credentials are safe, but nothing could be further from the truth.

If you encounter a service that uses a default vendor-supplied SSL certificate, decryption of communication is trivial. Just obtain a copy of this vendor software and grab the private key. This private key can be loaded into Wireshark to decrypt any captured SSL traffic that has been encrypted with this certificate. Please read this link about decrypting SSL with Wireshark.

So it is important to always replace default SSL certificates with a freshly generated, no matter if it is self-signed or not.