17.12.2009 von matti.

An analysis of a server offering encrypted communication should always included test for the security of the encryption. Things that spring to mind are of course if the encryption algorithms used are strong enough to withstand a cryptanalysis. So everything under 128 bit should definitely be considered weak. The testing for this can of course be done with openssl s_client –connect [-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1] servername:443. So for going through all the tests (protocol versions times all supported ciphers) you should either script something up or go for tools like sslscan or for windows thc ssl check.

Note: these tools just test for the normal used cipher suites and you will never end up with a complete picture of all the supported ciphers. So going back to manual testing depends if you find something or not with these tools and how far you want to go.

Next thing should of course be to test for weak protocol versions namely SSLv2. Although for SSLv3 there are now also known public weaknesses.

For the testing approach the same techniques as for the weak cipher lengths can be used.

Things that might not spring to mind at a first glance - but should definitely be tested for - are key exchange and renegotiation support.

Key exchange: The security of the communication relies heavily on the key exchange phase. If the exchange has weaknesses an attacker would not need to attack the cipher as he already got the key. Therefore the certificate of the server should be analyzed if the public key has the appropriate strength. Every key length under 1024 bits should be considered weak. Acceptable for new certificates should only be 2048 or even better 4096 bits. Testing for it is easy. Just download the certificate from the server and look at the public key.

Renegotiation support: Basically the renegotiation support with in the TLS protocol allows a man in the middle attack. Not the easiest to exploit but it could allow an attacker to insert traffic in an encrypted channel. In short an attacker sets up a encrypted channel with a server and renegotiates it to be used between the victim and server.

This can be tested again with openssl s_client -connect servername:443 and then

HEAD / HTTP/1.0

R

The single R in a line should do the trick. If the http request gets completed the server is vulnerable.

The last thing that springs to mind for testing ssl is if the certificate is in the right format and is valid. So nothing like a self signed certificate or wrong name or live time expired.

This should give a more complete picture of ssl testing.

Geschrieben in hacking | Drucken | Keine Kommentare »

1.12.2009 von tugrik.

Just started reading “Hacking: The Next Generation”, and disappointed to see piggy-backing receive such a very small amount of coverage. This is such an important issue, and so varied, I think I could write a chapter on it given a chance…

Geschrieben in books, opinion, hacking | Drucken | 1 Kommentar »

27.10.2009 von matti.

http://www.offensive-security.com/metasploit-unleashed/

And do not forget to donate for HFC!!!

Geschrieben in link, hacking | Drucken | Keine Kommentare »

22.10.2009 von matti.

http://www.packetstormsecurity.org/assess/exploits/

http://www.milw0rm.com/

http://www.securiteam.com/exploits/

http://www.securityfocus.com/vulnerabilities

http://www.securityforest.com/cgi-bin/viewcvs.cgi/ExploitTree/

http://securityvulns.com/exploits/

http://osvdb.org/

http://www.vupen.com/english/security-advisories/

http://www.red-database-security.com/exploits/oracle_exploits.html

http://www.joomlaexploit.com/

Geschrieben in link, hacking | Drucken | Keine Kommentare »

22.10.2009 von matti.

I saw a post on mumbix blog and on http://cktricky.blogspot.com/2009/10/btod-importing-nikto-db-to-intruder.html. Basically it is about how to extract nikto db in a file to load into burp. Whilst the extracting is nice:

cat /pentest/web/nikto/plugins/db_tests | awk -F “,” ‘{print $4}’ | sed ’s/^\”*//;s/\”$//’ | sed ’s/^\@CGIDIRS//;s/\@ADMIN//;s/^\@NUKE//;s/^\@POSTNUKE//;s/^\@PHPMYADMIN//’ | sed ’s/^\///’ > ~/nikto_burp.txt

(My version would probably be more like this:

cat db_tests | cut -d “,” -f 4 | sed s/^\”//g | sed s/\”$//g | grep -Ev “^@” > file.txt )

my point is that I do not get it at all. I might understand running nikto via Burp to save a complete logfile in one place but that is it. If I want to change the nikto headers so I will do so in the source code. So why would I load test for files being present on the web server into Burp if nikto already does it? It is not that I would start to use Intruder to search such things…

Any suggestions?

Geschrieben in hacking | Drucken | 6 Kommentare »

20.10.2009 von matti.

http://releases.portswigger.net/2009/10/v1217.html -> XML export -> http://dradisframework.org/

Geschrieben in link, hacking | Drucken | Keine Kommentare »

20.10.2009 von matti.

Most of the firewalls today are actually doing a rather good job. Unfortunately (well this depends on the point of view) some firewall administrators are not. But they should not get all the blame. It might also be that other administrators did not secure there servers, e.g. guys responsible for DNS.

So here is something I need reminding of from time to time.

DNS outbound is most of the time enabled through the firewall but just for UDP. So but by default, if you want to test for a zone transfer, you need TCP to be enabled. Does this mean that zone transfers are not possible because the DNS server is secured or because the firewall blocked you?

Well basically you would try something like this during an assessment:

dig @nameserver.domain domain axfr

So let us go change this a little bit by using an extra flag so that we might be able to do a zone transfer via UDP:

dig @nameserver.domain domain axfr +notcp

There is only one little further thing we might need to think about. So when the request would result in a big reply the DNS server would switch back to TCP. And we would be where we started.

So but maybe we could do something to reduce the packet, something like an incremental zone transfer:

dig @nameserver.domain domain ixfr=serialnumber +notcp

Ok the problem would be the serial number. You would need to send an older version to the server and see that it replies with difference between the old version and the new one. This might result in quite a view requests. But it might not be that bad as the structure is always the same: date+time and you need to do an educated guess how often there will be updates…

Geschrieben in hacking | Drucken | Keine Kommentare »

19.10.2009 von matti.

During a network assessment there should always be some investigation for public information on the Internet. This includes of course a look at the registrars.

One thing that sometimes gets overlooked is the auth method within the whois records:

http://www.ripe.net/db/news/MD5-HOWTO.html

So what could be the issue here ?

Geschrieben in hacking | Drucken | Keine Kommentare »

19.10.2009 von matti.

As it had been mentioned before there some standard tools that can be utilized for assessing a flash based web application.

http://www.nowrap.de/

Offers two different applications. One is flare and the other one is flasm. The first just extracts the ActionScript of a swf file. Nothing else gets extracted. The later disassembles the complete file. Therefore both should be used to get the complete picture.

http://www.owasp.org/index.php/Category:SWFIntruder

Is an OWASP project that helps with the practical application exploitation. Basically you download the flash from the web site and place it on a local running Apache web server. It must be seen more as a framework as you can define your own attacking strings and so for. There are a few exploitation strings that come along but more focused on XSS within the swf file. This should never be the only tool utilized during the assessment and more seen as an exploitation framework. The main problem is of course that you do the exploitation on your on machine and therefore the client can easily argue against it.

https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-5TUVE/index.php?key=swf

SWFScan from HP does a really good job in decompiling the swf file and analyze it for known weaknesses. This should defiantly be part of the assessment.

All this tools have of course the limitation that they do not take the communication with the database into account. SWFScan looks for insecure calls from the swf file but that does not give you a complete picture.

Therefore it is essential to perform a complete web application test. The fash application normally results in quite a lot of post requests.

The problem you are facing with such a test is that you have to scope it. The best approach from my point of view is to look at the application and make an estimate of how many interactions the user has with the application and how many calls the application does to the infrastructure (web server, database, etc.)

Geschrieben in hacking | Drucken | Keine Kommentare »

12.10.2009 von matti.

http://www.librarything.com/tag/geek,+--nerds

http://www.librarything.com/tag/nerds,+--geek

Look at the related tags on the right

And then have fun comparing…But wait:

Ok now that I think about it this is actually not a bad thing.

I just remember http://www.infosecwriters.com/hhworld/hh10/dns.htm especially dnspredict.pl for finding new DNS entries. I used it also to make educated guesses for password attacks. So here is the new idea for educated password guesses. Profile your target and enter it into a search engine that comes up with related tags. Then of course the usual stuff with appending 2 numbers and so on…

Geschrieben in humour, link, hacking, general | Drucken | Keine Kommentare »