Category Archives: security

Review: The Hacker’s underground Handbook

security, , , , ,

Last week I was contacted by David Melnichuk to offer me a partnership/affiliate account for his ebook "The Hacker's underground Handbook". I said to David that I would prefer to see what's it all about before I would promote anything, but I would be willing to write a review and maybe promote it if he sends me a copy. He did that so here is my review ...

The pitch

I recently created the eBook: The Hacker’s Underground Handbook. It is targeted more towards people that are new to the hacking/security scene and still don’t know where to start. Although it is mainly targeted towards newbies, it also has content that will be valuable for intermediate skill levels. The product is completely legal. Once the product is purchased, the user will be taught to not abuse the knowledge gained, and the penalties if he/she chooses too.

After looking over the book briefly I completely agree that this is an ebook for newbies.

Also the phrase "learn what it takes to crack even the most secure systems" from the cover, over estimates the content. You would most likely not be able to crack the most secure systems only with the information in this book, but the author advices the reader to learn more and not rely only on the information in the book and even provides some links to more resources.

Content

I think the term hacker applies more to someone like Richard Stallman, Alan Cox, Linus Torvalds, etc then to someone like Kevin Mitnik. So in my opinion the book is more about cracking then hacking, but most people(newbies) don't know the difference so I'm not going to insist on this.

The book covers topics from  installing a linux distribution (with screenshots  a la howtoforge ) and password cracking to packet sniffing, using exploits, web site cracking, wifi cracking and social engineering ( which IMO is not really cracking but just a nerdier/l33t word for "lying" )

I like the fact that the book also offers some advices / countermeasures even if in some cases it doesn't present the most secure or all options.

Conclusions

If you're into cracking and you already know how to do a lot of stuff I would not recommend the book as there are no advanced techniques in the book but if you're new to this or you would just like to know how some things are done and how you can prevent some security incidents then the book offers a good collection of common cracking techniques.

The ebook comes with a bonus ebook named "1000 Hacking Tutorials Leaked", so for the price of $18.89 is probably a very good deal.

Click here to get the ebook ( yeah that's my affiliate link )

Have you read this book? I'd love to read your impressions about it in the comments.

Squid 2.5 digest authentication

security, , ,

More then a year ago I wrote a post where I explained how to set up secure digest authentication for Squid proxy server so passwords would not be sent in plain text to the server when authenticating.

That post was written for squid 2.6 but recently I had to set up the same thing on Squid 2.5 and I found out that the setup was a bit different.

Squid 2.5 is really very old and fewer and fewer will be using it in the future as even Squid 2.6 becomes obsolete with the release of Squid 3.0 .
So if you are considering setting up a new proxy server using squid please use Squid 2.6 and take a look at how to set up digest authentication in squid 2.6

The differences are really minor but here there are listed in case I or someone else needs to still set up squid 2.5 with it.

The first difference is in the way you have to specify the "digest program" auth param.

for squid 2.6 it has to be like this :

auth_param digest program /usr/lib/squid/digest_pw_auth  -c /etc/squid/digest_passwd

but for squid 2.5 it has to be :

auth_param digest program /usr/lib/squid/digest_pw_auth  /etc/squid/digest_passwd

The second difference is in how the passwords are stored. In Squid 2.6 the passwords are stored securely as an md5 hash but in squid 2.5 they are stored in plain text in this format "username:password" . ( one more reason to make sure /etc/squid/digest_passwd can't be read by anyone other then squid user )

So for squid 2.5 what you gain in security over the network transmission of the password you lose in security at the password storage. This may still be a good deal if your local security is high but there isn't any way you can control the security of the network between you and the proxy server.

qmail and DKIM

Email, security, , , , ,

DomainKeys Identified Mail (DKIM) is a method for validating the identity associated with a message using using public-key cryptography and key server technology. DKIM is an enhanced version of Yahoo's Domain Keys and Cisco's Identified Internet Mail methods. As of February 2007 an IETF draft was accepted as "Proposed standard", it may take some more time till this will be a standard but the current version is stable ( according to dkim.org ).

Implementations of DKIM in email servers is not available as much as DomainKeys.
For qmail there is a patch that uses libdomainkeys to implement a replacement for qmail-queue that will verify and sign messages but this only works for DomainKeys not DKIM. I have developed a solution for qmail to be able to verify and sign messages with DKIM. Continue reading qmail and DKIM →

squid digest authentication

security, , , ,


If you use authentication in squid you have several mechanisms ( authenticators ) to chose from. The Basic authenticator is the easiest to set up and the most insecure because the client sends the username and password in plain text to the proxy server.

Instead of using the basic you would consider using the digest authenticator. This authenticator does not require the client to send the user and password in plain text but encoded in an MD5 hash so that an attacker that captures the data between the client and proxy server will not be able to use the user and password.

Continue reading squid digest authentication →

TLS for HTTP

security,

On my previous post about wildcard ssl I was complaining that you have to use a different ip for each domain that needs ssl/https and I wondered why there is no TLS feature like there is in SMTPS where you have STARTTLS. Well it seems I was wrong. There is such a feature, actually there are two different features one is described in RFC2817 and the other in RFC3546. Rfc 2817 specifies how a plain text connection can be "upgraded" to a secured connection over SSL:

This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address

RFC 3546 various extensions to TLS and one of them is an extension for server name indication . This extension will allow a client to tell the server which domain is contacting.
That's just great, but there's one problem. Not only that few web server software implement any of the two rfcs but also few web browsers support them.

Apache implements rfc 2817 in mod_ssl since version 2.1 and mod_gnutls implements the server name indication extension in TLS described in rfc 3546.
It seems that IE7 has support for RFC 3546 and firefox may have support for rfc 2817.

easy way to create a random password

freebsd, General, Linux, security

Sometimes you just need a quick way to create a random password without installing special random password generators.

Here is an easy way to create a random password using standard tools that are available on most of the unix flavours:

head -c 10 /dev/random | base64

or if you don't have the base64 program but you have uuencode

head -c 10 /dev/random | uuencode -m -

This will create a password based on a 10 bytes long random sequence.

If you want longer or shorter passwords just replace "-c 10" with "-c x", where x is the number of random bytes you want to use.

freebsd securelevel setup

freebsd, General, security, ,

FreeBSD securelevel is a security mechanism implemented in the kernel that restricts certain tasks depending on the level that is active. Not even the super user will be able to bypass this mechanism if well setup.

From securelevel man page :

-1 Permanently insecure mode - always run the system in level 0 mode.
This is the default initial value.

0 Insecure mode - immutable and append-only flags may be turned off. All devices may be read or written subject to their permissions.

1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded.

2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multiuser.

In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''.

3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted.

Continue reading freebsd securelevel setup →