I’ve decided to try to write on this blog again, so fingers crossed!

Now, my personal laptop died on me recently and it’s a bit limited what I can run and test on my work laptop, so first off I’ll just make the readers aware of two pentesting platforms they can try out:
http://www.deftlinux.net/
http://www.remote-exploit.org/backtrack.html

Example

I wanted the application to follow a set of generating rules, but at the same time give the user the option to choose both length and strength. This meant that the program would require:

• All alphanumeric characters
• A set of special characters
• A scale of strength, defining which characters to use
• Repeated generation until length of password is met
• Random choice of characters to use

This part is easy and straight forward, but it does contain the possibility that only a single character will be used, or that it returns a password purely based on special characters. To make the password stronger i had to make sure that the program used all of it’s options; not too much, not too little. I chose to solve this by using a selection array and define how many % of the password would be lowercase, uppercase, numbers and special characters.

The code is far from finished at this stage. It does allow me to pass a length and strength argument to the function,  and based on that it does generate a password according to the rules I’ve set.

However, everything is currently hard coded and not very user friendly. I’ll keep working at it and have the tool up on this site soon. The source code will of course also be available, and a walk through will be posted in the projects section.
Update
Code and project page is finished. You can read about it here.

For those that don’t know; DNS is was converts your typed in URL to a IP address on the internet. It’s structured in a hierarchy, starting with the root domain. When you type in knutee.net in your address bar, a query is sent to your DNS server, which in turn asks it’s parent DNS server and so on, untill it reaches a server that knows about my site and it’s IP. This IP is then returned back to your computer and you connect to it. The problem with this technique, as I wrote about in my DNSSEC paper, is that this data can be corrupted. One way is to intercept the query and send a fake answer back to the host, directing your browser to a different server. The other way (there are more, but keeping it simple here) is to “infect” the real DNS server with the wrong data, which will spread this fake address to other hosts.

The vulnerability in question was a DNS cache poisoning attack. You can read more about these type of attacks here.

Read the full story

Due to Dan not presenting the details of the attack, large parts of the security community attacked him, claiming that his findings where most likely old and that he just used it to hype his own status. After some pressure, he finally gave up the information to Thomas Ptacek and Dino Dai Zovi. Turns out he had the goods, and the appologies started to appear. For the rest of us, we’ll have to wait a bit longer untill the details are released.

Note

Yes, I’m aware I’m quite late with this “news”, but I’m in the process of moving so updates are slow.

Also, I would like to mention something Bre Pettis is working on these days; The history of the Chaos Computer Club. Check out part 1 and part 2 on his blog. I wont repeat the general presentation of the CCC here, but could not resist quoting this gem:

It became a crime to connect anything besides a telephone to the telephone network. If caught, you could go to prison for 5 years for hooking up a modem without an official seal. It was felt that having a computer answer a phone was illegal. The CCC confronted this by asking, “Would it be ok to have a cat answer the phone?” When they got a confused, but positive answer, they built a contraption made of Lego and a Fischer-Technique model sets that would lift the phone and place it on an acoustic coupler. They called it “The Cat.”

Update

Part 3

This is where single packet authorization and port knocking comes in to play. By having the service port closed by default, and only open up to a user after a specific “knock on the door” is performed, the attacker will not be able to reach the service or even see that it’s there. So, whats the difference?

To explain the difference between SPA and port knocking, I will use knocking on a door as a metaphor. Port knocking involves knocking on the door in a specific pattern. Lets say you walk up to a door and knock it rapidly 3 times, wait one second, then 2 more knocks. By doing this, you have told the person on the other side of the door that you know the secret knock needed to gain access. This method however, presents us with two apparent weaknesses. If the time between each knock is too fast, the person on the other side might not be able to distiguish between individual knocks. This means that the speed of knocking has to be lowered, and authorization gets slowed down. The other obvious problem is that a third person might be hiding in the bushes, listening to the knocking pattern you perform. That person could then come back later and repeat the knocking pattern you performed, thus gaining access. This is called a replay attack.

Now lets use the same metaphor to explain SPA. Lets say you walk up to the door and only knock it once. However, this knock is unique due to the shape and speed of your hand, as well as the particular part of you hand hitting the door. To make it even more unique, you add a random element that is only allowed occur once. This knock would be very hard for a third person to replicate, and due to the random element we added. the knock will be dismissed if it’s exactly the same as the previous knock. This is the idea behind SPA.

SPA uses a single packet (hence the name) that can be delivered as fast as your network route allows. To make the packet complex enough, the application payload portion is used. Random data and it’s hash value is added to prevent replay, and the packet is encrypted with a key. There are of course more complex details, but for a general explanation I think this simplified version is enough.

So now, when the attacker scans your ports, the service port your protecting will appear as closed. The authorization data is encrypted to prevent someone from sniffing your packets to gain access. Authorization given is related to your address, but due to NAT and the potential danger of an attacker sitting on the same sub-net as the legitimate user and replicating the knock, the random element and hash is added. If the same random data appears in a subsequent knock, the connection is denied. Thus, your network service is now only accesible by those that know the secret knock on the door!

I hope this short presentation has given you a better understanding of SPA and port knocking. A guide to installing SPA on your system is now up in the guides section. Questions, comments and corrections are very welcome.

The Texas legislature has decided that computer repair folks need a government-issued PI (Private Investigator) license when performing what the state calls “an investigation.” If a computer repair person is analyzing data on a customer’s computer, this would fall under “an investigation”, and without a PI license he or she could face up to one year in jail and a $4,000 fine. Additionally, any customer knowingly enlisting an unlicensed repair person’s help is subject to the same fines. To get the license, one needs either a criminal justice degree or complete a three-year apprenticeship under a licensed PI.

So, when Joe Average gets a spyware infection and acquires help from his local repair shop, the person performing the repair will need a criminal justice degree? I must admit I see what they are getting at, but there must be a better way to solve this privacy issue.

Link here

So to get this running on a single machine, the first thing I did was to set up a tiny Xubuntu virtual machine. Now, you could of course use a even smaller Linux distro, but for testing purposes the Xubuntu was good enough for me. Getting both the server and client application is easy enough. Just head over to OSSEC and download both. Unpack the server files on the virtual machine and run the install.sh script as root. You’ll be asked a series of questions that are well described and should not cause any difficulties. After you have installed the server you should edit /var/ossec/etc/ossec.conf and change the default mail_from value, as my SMTP server rejected the default one. You will need to chmod +w the file to edit it. Finally, run /var/ossec/bin/ossec-control start to get the server running.

Now, you need to add clients to the server list. This is done by invoking /var/ossec/bin/manage_agents. Select (A) to add a new client, and give it a name, ID and an ip address. When this is done, select (E) to extract the authentication key for the client you just added. This key will be needed during the installation of the Windows agent.

Installing the Windows client is even easier. Run the installer and click through the install options. When the install reaches the end you will be asked for a server IP and a authentication key. Type in the IP address for you virtual server and the key you generated earlier. Save and restart.

And thats it! Now you have an IDS running on your machine. Local log files can be found in the installation directory of the OSSEC agent and server logs in /var/ossec/logs. All security events will be mailed to the e-mail address you chose during installation, but consider changing the alert level to avoid spam.

This is of course also possible on a Linux host!

Future work

I’m trying to find a lightweight OS and virtualization solution that starts up with Windows as a service and restores the previous virtual session upon login. I’ll get back to this later!