PHP version 5.3.1 was just released. This release contains a patch for a denial of service condition we’ve reported on 27 October 2009. The problem is related with PHP’s handling of RFC 1867 (Form-based File upload in HTML).
Source: http://www.securityfocus.com/archive/1/507982
Exploit already on PacketStorm…
I’ve been asked to produce a service offering for a Montreal based security specialist contract. The request was generic – make me wonder about the provider lack of the specialized knowledge required to complete a selection. Hiring a consultant, specialist or sme (subject matter expert) should never be left to an ultimate comparison between university degrees. So, for fun, I submit a couples questions, all security related, feel free to answers as comment or by email:
1) what’s wrong with:
void f() {
char buf[2048];
gets(buf)
}
void main() {
f();
}
(note ; this is the modified version of this function. Read comment 1 on this blog post for more info)
2) With current systems, IPV6 is becoming standard feature. What security problems do you see with that statement and how would you go to secure an IPV4 network knowing those problems ?
3) There have been quite a few problems with SSL theory and OPENSSL implementation in the last few years – please, name a few and explain them.
4) What is entropy or prng ?
Note: This is a selection of very early draft of a document I’m writing – As such, those are extract of “working notes” and should be considered as beta (not Google definition of beta ; true beta)… lots will change.
[...]
Internet being a jungle (or a city, whatever you find most dangerous), your infrastructure will be preyed upon. it can be by customers requiring services (too much of them can create difficult situations) or by malevolent individuals wanting to see your service off Internet.
[...]
Of the techniques available, dos/ddos might be the worst. Here’s a quick non technical theory review:
DOS: Denial of services
For a single attacker, cutting access to your services can be accomplished by solving this equation:
Attacker resource * resource(attack function) > Defender resource * resource(defense function)
The defense against the attack is simply the reverse of the equation. Using decent servers (for processing power) in a decent datacenter (for bandwidth) can help solve this equation to the defender advantage without having to modify services. If it doesn’t work, modifying the defense function (such as implementing a firewall correlating a source IP and the attacker function) will allow required resources for defense to be minimal and thus win the fight.
[...]
DDOS: Distributed Denial Of Services
The DDOS add the dimension of multiple (in the order of hundreds or thousands) attackers systems. This will bypass of most of the standard defenses “resource reduction function” since the resulting traffic will be tangent to a normal usage pattern. Randomly blocking visitor (or user) cannot be accomplished without risking blocking valid one and user pattern analysis is generally resource intensive.
[...]
How to survive DDOS
A lot of services and devices are available to mitigate the attack of a DDOS. Some can be implemented by the end user (server administrator) or by the upstream provider. However, most of them must be deployed as a planned feature, not while the network is under attack.
* drop spoofed/invalid packets at upstream provider (packets with invalid source IP (see RFC 1918), implement ingress filtering (see RFC 2267)) – it is also call dark address filtering.
* prepare rate-limiting function ‘per-vhost’ (if service = webpage), or ‘per-services’, and ‘per-source’.
* implement black hole filtering procedure (an in-line router / packet analyzer able to black hole packet will leave your server doing service computing, not routing).
* request analysis. SNORT is a well know and very good ingress filtering agent that can be used to filter traffic that does not match normal usage pattern.
* enable syn cookie (valid only against syn flood).
* always allow establish connections priority over new ones.
* off load as much as you can (mainly: DNS services in separate network, dropping both is harder).
And I’ll allow a bit of additional informations on this last one, because it is often overlooked and can represent your salvation when you are attacked. Either the attacker will use a specific IP, which is easy to mitigate by changing to any other you reserved for that and changing the DNS (5 minutes downtime is nothing in a major DDOS) OR the attacker is resolving your domain name through your DNS. This latest fact is quite important, because it mean the attack can be mitigated by using geo-localisation on your DNS system : different servers will answers requests from different part of the world. MaxMIND does offer a very up-to-date database of IP/Country and IP/Town ; and using Amazon AWS (cloud computing service by Amazon), new servers can be launched at minutes notice and your DNS (when properly configured) can be modified to provide specific IP “to-peoples-outside-your-normal-business-area”. You don’t even have to involve your upstream provider and you will be able to offset a very big part of the attack (as long as your normal business area is not russia + china).
Or, if implementing those recommendation are not a possibility, there is always services/devices available for sales. Be ready to pay a very big price for them.
[...]
Microsoft IIS 5/6 FTP 0Day released
We are aware of an new 0-day exploit that was posted on Milw0rm today.
According the exploit, it was suppose to work on both IIS 5.0 and 6.0, on the FTP module.
Also according it, it affects IIS 6.0 with stack cookie protection.
The latest on this is that HDMoore is porting it to the MetaSploit framework.
We will update this diary with more info as we get it.
source: sans.org
Survived! Well my laptop did – I’m exhausted and work was waiting for me in Montreal, but – let be honest, I can’t really complain.
For those who don’t know, the DEFCON is one of the leading hacker conference with over 8k attendees getting together in Las Vegas to share knowledge on hacking, cracking, social engineering, lock picking and similar discipline. Peoples come from all social group – 14y old video gamer to senior security specialist for the gov, going through consultant, programmer, developer and hobbyist. Fun crowd.
While my trip was flanked by 2 series of 4 vacation days (before and after), I was @DEFCON as the owner of Les Laboratoires Phoenix – my free software consulting firm – and as such, I was confronted to this dichotomy:
* I need Internet access to answer clients requests
* Connecting to Internet at DEFCON is professional suicide if your not up to it
Let me explain this second point a bit: first, the Wall of Sheep, an inline filter tracking unencrypted connections and broadcasting users credentials (including a partially obscured password) on a big screen in the lounge. Generally, the flow is quasi non-stop.
If you think that it’s not that bad, the password being garbled… think again : Wall of Death. It’s an inline switch, freely available, where the 7 ports broadcast a mirror of everything the firewall see (which is.. everything). Live, un-garbled, un-modified feed of everything in the pipe. In other words, if you are on the Wall of Sheep, then someone from the Wall of Death got your credential.
And then, this is only using the standard infrastructure. I am not mentioning peer attack, wireless impersonation and so on.
So, how to survive in such hostile environment ? Here’s a few rules (which should also be taken as golden rules if you work from your client’s office).
1) ‘netstat -lntp‘ ; this command (an output of incoming listing ports on your system) should return nothing. There is no need to have any listening services if you are ‘mobile’.
2) iptables -L -n -v ; this command give you your firewall rules. INPUT should be restricted to established and related connection with a default policy of DROP. OUTPUT, when in a ‘not-so-friendly’ environment, should defaulted to DROP with allowed outgoing on secure protocol only (http:443, ssh:22, …). If you need to connect to an un-encrypted destination, at least forward through a ssh-tunnel/proxy.
3) never auto-connect to unencrypted network. This is exactly what causes the wall of sheep to be full of iPhone user’s credentials. This cute little device can auto-connect to the unprotected network (such as DEFCON) and start sending security credential (un-encrypted) to twitter, facebook, myspace…
4) Do not take anything for granted. PREPARATION is the key. Before the trip, start collecting all your ssh-key fingerprint on your system, this can become really handy if someone tries some ‘not-so-great’ men-in-the-middle attack against you.
Well, thinking about it, number 4 is the best advice. DO NOT TAKE ANYTHING FOR GRANTED. In the last 2 years, there have been 2 attack against the SSL infrastructure disclosed at DEFCON. Btw, this is for GNU/Linux system. If you are using a Microsoft operating system at the DEFCON, you better… well… just don’t use it.