A lot of people like to bash MS for this that and the other, but my reasons for switching to Linux as my primary OS were pretty much due to what you've described above; all too often I'd find that I couldn't do what I wanted to (at least, not legally). I'll admit that Windows does have its place which is why I still have XP on a second partition on this machine...but to be honest, the only time I ever boot into it anymore is to do reverse engineering. If you download Ubuntu and Automatix2, you'll be up and running with just about everything you need for school/mutimedia/internet/whatever.

Arguments over the security, stability, or support of Linux vs Windows are completely irrelevant to me: they both have security holes, and they can both be effectively locked down and protected by someone who isn't an idiot. I've never had stability problems with XP or Ubuntu. Google is my support no matter what OS I'm using (I hate talking to people . I just need something that lets me do what I want, and maybe, just maybe, even helps me do what I want.

I relinquish the soap box back to the group...

I won't repeat what Don and Cutaway have said already, but definately heed their advice/warnings - they are both more expirenced with these things than I.

At any rate, for WEP cracking my personal favorite is aircrack. Contains a very nice suite of programs, available for Linux and Windows. I've used it to crack my own WEP keys in 10-15 minutes.

I'm told that Cain & Abel also now supports the Korek WEP attacks (Google this if you don't know what I'm talking about), but is Windows-only. Basically, use anything that implements the Korek attacks and you'll make an easy $25.

I agree with Chris, from a security perspective neither one of those languages is really ideal because they hide a lot of the internal/low-level stuff that goes on.

But, if those are your only choices, here are a few considerations for picking your poison:

1) Chris is right, from what I've seen VB.NET is used more than C#. Also, when reverse engineering, programs written in VB and/or using the .NET framework are also vastly different than those written in C or C++. So learning VB.NET could help you out down the road if you are interested in RE. VB is also a great language for easily writing Windows apps, but it's not that great if you want to do low-level stuff (my experience with it is limited however).

2) I've never used C# so I don't know how similar it is to C or C++, but I do know that it hides a lot of the low-level stuff that C/C++ don't. However, learning C# could help you pick up C more quickly (which is a good language for a security professional).

So I suppose it all really depends on what you want to do. If in doubt, I'd probably go with Chris's suggestion of VB.NET, but you might want to Google for comparisons between the two languages before you decide.

Interesting blurb about a current DMCA case on rootkit.com:



http://www.rootkit.com/newsread_print.php?newsid=697

"Gibson" is a term used to refer to some of the most secure servers in the world. This nickname comes from Steve Gibson of Gibson Research, who created ground breaking programs such as SecurAble and the most advanced port scanner in the world, ShieldsUP. He also accurately predicted the end of the world when MS introduced raw socket support to Windows XP.

If the issue is that your ISP is blocking, then they are probably blocking the incoming connections to the DNS server rather than outbound traffic from the server. From reading your posts on linuxquestions.org, this seems to be the case since you can't telnet into the server on port 53 *although* the server may not be configured to listen for TCP connections as most DNS traffic is UDP. I'd try using netcat to connect to UDP port 53 from outside the your network and see if that works.

Also if I understand what you are saying correctly, I'm not sure if the client would accept a reply packet that had a different UDP source port than the port that they sent a request to (I know this wouldn't work with TCP).

Have you tried setting the DNS server to listen on a different port? If you can connect to it at that point, then the ISP is probably blocking incoming DNS requests and you'll have to use some type of DNS proxy as jimbob mentioned.

I think the first step would be to determine the actual cause of the DoS. For example, if the site was DoS'd due to an error in the Web application code, then patching that would prevent the issue in the future.

If on the other hand it was just that the server or hosting provider couldn't/wouldn't handle that many simultaneous connections, then like you said it will be very difficult to block based on IP. Were they accessing only one particular page? Perhaps you could implement some type script in your pages that limits the number of requests within a specified amount of time. The problem with setting this up at the application level is that it probably won't help much if the DoS is due to server/provider issues. I would definitely check with them first and see if they can help shed some light on the issue.

If you are on a *nix server, you can use the following:


Where:

*page.html is the page that they are repeatedly accessing

*access.log is the log file

*The IP address is the first thing listed on each line in the log file. If it is the third thing for example, change $1 to $3.

This will list each unique IP address that has accessed page.html, as well as how many times the page was accessed by that address. The IP addresses with the highest hits will be shown first.

From what you describe, the attack sounds like it is being made on the Web application itself, although the reason for the DoS may not be due to a failure in the Web app. If you use a shared hosting provider, they sometimes will temporarily cut service if your site is using too many Apache processes (a child process is spawned for each connection). You might want to check with them as well to see if this is the case.

The IP address should be listed in the server logs, assuming you have access to those. If not, then you could write a PHP/ASP script to identify/block the IP address, but this will only work if:

1) The attacks always come from the same IP address.

2) The attack is against your Web application. If they are attacking a problem with the server itself, then this will not help.

If you can configure the firewall to block the IP that would be better, but point #1 still holds true.

If you could provide more details about the attack itself (do you know what they are attacking? can you connect to the server at all? etc...) it would help in providing you with more effective suggestions.

What Chris, you've never hacked a gibson?? They TOTALLY look like that!

I agree that in 2-3 years it will probably be possible to mitigate nearly all (if not all) BOF attacks IF you are using a modern system and IF all your software and hardware has been designed/compiled with all available security features. But I think that new BOFs will be discovered in many third party applications and in OSs that don't yet support all available security features for several years beyond that.

Also consider some of the recent BOF exploits that have been circulating for OpenBSD (probably the most secure OS out there) and Vista ("the most secure OS from Windows to date", as many people have stated and I am inclined to agree with). Between them, they implement/support most, if not all, of the protection mechanisms listed by oleDB. In the last month or so, remote BOFs have been discovered and exploited in both of those systems (the ANI exploit for Windows, and OpenBSD's IPv6 exploit).

You also have to consider Mac systems which have (to my knowledge) practically no built in protection mechanisms against BOFs, and Linux systems with 2.4 kernels (stack protection wasn't enabled by default in the Linux kernel until 2.6.12 I believe). Heck, Debian 3.1 still uses the 2.4 kernel, although I think it does have an option to install 2.6 as well. For Windows systems, there is still plenty of software circulating that isn't compiled with the /GS and /SAFESEH features, rendering these protections null and void.

With the exception of safe SEH, I know that all of the suggestions listed by oleDB for preventing BOFs have already been circumvented. Not to say they are bad ideas, in fact they are all excellent ideas and most of the reasons they were circumvented were due to poor implementation, but regardless, they still have not been 100% successful. I think we still have a way to go before rendering the good old BOF completely obsolete, although it is becoming harder and harder to exploit them.

Hehe, yeah, when I first found Johnny Long's site I used to use all their webcam Google dorks to find all kinds of interesting things. When you start finding things like airport security cameras, it *almost* gives credibility to those teenie-bopper hacker movies where they get access to some company's security cameras in under 10 seconds.

Hey t0lomp,

Well, if you don't mind doing some copy/pasting by hand, the easiest way to do this would be to use ethereal to capture session cookies and then request pages by hand using wget. But that's kind of a pain. If you wanted to automate it, here's how it might work on Linux:

1) Fake WAP

Linux allows you to place your wireless card in master mode (i.e., turn it into an AP), and enabling IP forwarding will allow it to forward requests between the wireless interface and the ethernet card (which should be able to access the Internet obviously):
   
   iwconfig eth0 mode master essid "My Fake AP"
   ifconfig eth0 192.168.1.1
   echo 1 > /proc/sys/net/ipv4/ip_forward

A better way IMHO would be to spoof DHCP replies and tell client machines that your computer is their gateway/DNS server. It's harder to track, and you can write some fun NAT rules to redirect connections to your own servers.

2) Downloading all emails

You can use tcpdump/tethereal to capture data and grep for people accessing their Yahoo/Hotmail/whatever email accounts, then extract their cookies from the data (regular expressions would be useful here) and pass those cookies to wget which can recursively download pages on their Inbox page.

Examples of some Perl scripts I've written in the past to perform similar data capture/extraction using tethereal can be found here (http://packetstormsecurity.org/wireless/wlan_webauth.txt) and here (http://www.craigheffner.com/security/aim-jack.zip); there are probably better examples out there though . A quick and dirty tutorial on using wget to perform recursive downloads can be found here (http://linuxreviews.org/quicktips/wget/).

3) Providing access to the account

I've actually written a Perl HTTP proxy (http://www.craigheffner.com/security/httprox.txt) that allows you to specify a random header, which is perfect for this. Put the cookie header into a file, connect to the email account via the proxy, and you're in like a dirty shirt. It's nothing fancy and some of the code was swiped from other Perl scripts floating around the Internet - it just forwards requests through wget, then sends the response back to the browser.

Well, that's kind of like saying you might as well leave the keys in the ignition because someone could steal your car by hotwiring it. There's nothing wrong with SSL, and in fact if the webmail sites used SSL throughout the entire session, this wouldn't be an issue. Honestly I can't believe that Yahoo doesn't properly destroy server-side session data, that seems like a no-brainer to me. But regardless, remember there still are restrictions to session hijacking even in a case such as this because most sessions will be tied to a specific IP or IP range. If you capture a Yahoo mail cookie at a WiFi hotspot, you can't go home and use it like you could if you had the actual user name and password.

That certainly is something...I don't know if it's a good something, but it's something!

I'm not aware of any other programs designed specifically to do this either t0lomp, I was just saying that this program doesn't do anything magical that couldn't be done with tpdump/grep/wget. Not saying it isn't useful as you pointed out, but again, this program doesn't do anything you couldn't do with most default Linux installations - it just makes it much, much easier.

Also, I'm still able to access my account using the cookie issued from yesterday. I've logged out, cleared my cache, and rebooted, still works. Interestingly, I mentioned this issue to one of my friends who does security work and he said he'd heard about it before from somewhere, so Yahoo's failure to properly destroy sessions isn't entirely new apparently.

Good find d1spat3r, thanks for your help in figuring out how this works t0lomp, and if I ever decide to use Windows again I just might find myself using this.

Agreed Kev, anything in plain text is fair game for anyone who happens to be listening in! SSH tunnels all the way!

As far as the program in question is concerned, it's a nice simplified interface for capturing email sessions for certain online accounts (like I said, it didn't seem to recognize gmail, so I don't know what sites/account types are supported) and for spidering a user's Inbox (as stated above though, this will lock out their account, so it's not perfect), but it doesn't seem to do anything that couldn't be done with a shell/perl script.

Basically it just captures the session cookie and uses that to hijack a user's session. The reason you can still log in after the user logs out of the account is that the session cookie is only deleted from the client's browser...it is not deleted from the server however. I verified this by logging in, copying the cookie data, logging out, then requesting the Inbox page using wget which I supplied with the cookie header. Yahoo happily spit back my Inbox.

So, while this app doesn't do anything ground breaking, it seems that Yahoo doesn't destroy session data on the server when you log out of your account, which is quite interesting. There also seems to be a couple of URLs that can be used to redirect users arbitrary sites/pages...could be useful for XSS/CSRF attacks.