A lot of the testing nowadays goes back to do some account hacking.
The hope of a password being in a dictionary is long gone.
Too many security policies hindering people to chose weak passwords.

But users still have to be able to remember passwords.
So we do mutations and other things:

http://www.randomstorm.com/rsmangler-security-tool.php

http://www.remote-exploit.org/Wyd/

http://awlg.org/index.gen

So if you want to check your own password:

http://www.passwordmeter.com/

Geschrieben in hacking | Drucken | Keine Kommentare »

Hacking: All in one DVD

13.8.2010 von matti.

http://www.hackfromacave.com/katana.html

During Blackhat there has been an update to version two

Fun to have everything along….

Geschrieben in hacking | Drucken | 1 Kommentar »

Browser Malware

27.4.2010 von matti.

Just a quick one…

There is a nice service for testing flash and javascripts of websites:

http://wepawet.cs.ucsb.edu/index.php

If you feel brave enough to test for yourself or want to get to the source of some javascript stuff:

http://malzilla.sourceforge.net/

Geschrieben in hacking | Drucken | 1 Kommentar »

Hacking: Tools

18.3.2010 von matti.

I had a network test lately and was using some newer tools….

Ncrack:

http://nmap.org/ncrack/man.html

Medusa (after two years a new version):

http://www.foofus.net/jmk/medusa/medusa.html

Nsploit (nmap with metasploit)

http://trac.happypacket.net/

Happy hacking everyone…

Geschrieben in hacking | Drucken | 1 Kommentar »

Security: ISMS

18.3.2010 von matti.

I have kind of developed a 13 step program to an ISMS….

ISMS - An information security management system

13 Steps Program:

Purchase a copy of the ISO/IEC standards
Obtain Management Support
Determine the Scope of the ISMS
Identify Applicable Legislation
Define a Method of Risk Assessment
Create an Inventory of Information Assets to Protect
Identify Risks
Assess the Risks
Identify Applicable Objectives and Controls
Set up Policy and Procedures to Control Risks
Allocate Resources and train the Staff
Monitor the Implementation of the ISMS
Prepare for Certification Audit

Den Rest des Eintrags lesen »

Geschrieben in hacking | Drucken | Keine Kommentare »

Pre-loaded picture frames…

5.1.2010 von tugrik.

Just in case you don’t read slashdot… as revealed on http://seattlewireless.net/~casey/?p=13 , the Kodak EasyShare Wireless Digital Picture Frames contain a lovely security issue.

As well as displaying pictures from an SD card, you can point the device at any RSS feed and have it display the contents. You just set up a FrameChannel account using the secret code that comes with the frame, and configure the feeds accordingly. However in the Advanced Settings of this interface there’s a URL that shows a feed of everything being displayed on your frame. This is a very predictable URL, based on the device’s MAC address, So you can see what other Frame owners are downloading to their device…

…and if you look through the comments at that URL, you’ll see that a lot of “informal assessment” of the service has taken place; it’s possible to reset to activation code for frames, determine the RSS feeds used by devices that have yet to be sold… and there’s some code in the comments to do that for you too.

As “Mike” aptly put it: “So Kodak has essentially built a system for letting complete strangers (a) browse your family photos, and (b) beam shock porn directly into your living-room?”

See also http://yro.slashdot.org/story/10/01/05/0413228/Kodak-Wireless-Picture-Frames-Open-To-Public

( on a side-note I was considering another posting, refuting the comments on http://www.altaware.com/articles/pentest.html, which I stumbled across recently. In the end I decided that was best left as an exercise for the reader, as the only retort I have that won’t take me an evening to write is “you’re not very familiar with pentesting are you?” )

Geschrieben in hacking, general | Drucken | 1 Kommentar »

Hacking: SSL testing revisited

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

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 »