:-) This [1] will help you when it comes to understanding the usage of IPM within OSes. Finally I wouldn't try to understand IP-Masquerading itself only, because you need to gather how the OS makes use out of it. I furthermore assume that you don't care too much about academical stuff. In case you need decision-trees, math. models, code or something like that I recommend you to study IT/CS or read domething like "The Design Of The UNIX Operating System" (Prentice Hall) or become a kernel hacker. ;-))
Alright in regards to Dan's DNS finding
1) Port Randimization allows users to be pushed to incorrect sites or locations for other protocol transfers.
2) The DNS flaw is right because it is part of the underlying source code. No one can change this all that can be done is to hide it aka basically make it time consuming to hack.
3) Simply put it this way if you can point a user that thinks they are going to www.google.com to send them www.sysadmins.google.com and insert and flash or Active X download script you can take control of there network. For example the TTL (Time to live) on a cache of a company may be 24 hours. If you can change this within say the first 19 hours of the ttl then you will have every user and server pushing ppl to www.sysadmin.google.com for 5 hours. This could allow you to push malicious software to every machine that accesses this site.
You could also infect a server with Malicious code this way and allow you to manually at a later time reroute whatever traffic you wanted provided the code you gave the server allows access at any time.
Dan will show examples of how and what to do
I may attend this Security conference however if i do not there will be video streams of this online this way we can watch it.
Basically its explained like this if you are trying to penetrate a home user it is not worth it. The best ones would be an ISP server.
You then have thousands or millions of users pointing to a fake location.
I have done some reverse engineering on the patches from Microsoft and they have done a great job covering up this error in the code.
Since this exploit is in the source code in order to completly fix it you would have to rewrite DNS which is almost impossible considering it is implementing on every router/switch/server/host in the world
regardless of the O/S
Any other questions?
I havent forgot about the email you sent me im on work trip ill be home sunday ill send it to you when i get home
I have the file on my server @ home
Just wanted to update you on the software
Yeah it's over but I have to do some stuff within the next weeks. There's a lot of work to do which I cannot talk about. Finding the balance can be difficult at times... :-/
I never received your email regarding the A+ send it to michaeloconnell3@gmail.com
other then that regarding DNS port randimization allows for mutiple data I/O and allows for updates and upgrades on network access in the future. Dan's DNS flaw has to do with the source level of DNS. I dont really have much more information on that yet since the Convention where he will release the flaw is in the beginning of august once i get more information i can give you an explaination of it.
Ok, I forgot to read your second post. (Btw. let us do it via regular insys mails now - otherwise my wall gets flooded :-)
The problem is the scanning method of these online scanners. Additionally I have to warn you relating to these port conditions. As I already told you "closed" is ok cause it indicates the system wont let any data in through that port. There is some kind of processing but (think logically) whenever there's some kinda attack on your system the leet hacker seeks the ports in a listening state. One open port may be sufficient to cause some buffer overflow or such. Thus its worth more to update the firmware more often and run less services than to waste too much time to stealth some ports. You cannot stealth all of them!
To end this session I suggest you to install an IDS and familiarize yourself with the systems logging facilities. This will improve your overall situation by far. I also recommend a safer OS. If you actually run a server I recommend you one of the following systems:
1] It doesn't matter what your machines desktop filter does as long as your router-firewall-combination blocks everything from the outside. If your firewall for e.g. drops all packets on all ports (which includes 20 and 21) then it doesn't matter whether your machines desktop filter (it's not a firewall) leaves these ports open since no request is being forwarded at all. I therefore assume you have the following configuration:
PROTECTED MACHINE = 192.168.0.100 (I assume its a file server)
ROUTER with FIREWALL (INNER) = 192.168.0.1 (Is a gateway for all the LAN clients as well as the server)
ROUTER with FIREWALL (OUTER) = e.g. 70.155.143.91 (some dynamic IP issued by your domestic ISP)
You need to scan FROM your host (maybe 192.168.0.3) TO 70.155.143.91 ;-)
- Use -F instead of "p 1-65535" to speed things up and perform a realistic scan. It's also recommended if you don't make use of high ports or didn't map anything differently e.g. webserver on port 80 to 65000 or such.
- Decrease -T3 to -T1 (min) if mess occurs on your screen or increase it to -T4 or -T5 (max) to speed things up again.
- Omit SYN or XMAS at first to check out the routers default behavior. We wanna ensure it handles all "regular" requests in a way we expect it to do.
Good Luck!
PS: Local desktop or application filters (again: the thing you call a firewall on your server) are mostly just crap. I guess you run something like ZoneAlarm on there since I assume it's a Win32 NT5.1 (XP) machine. Nevertheless they handle requests on an application basis and are only necessary in rare circumstances. Mostly they mess up your system when not correctly configured. Worst case scenario is that you accidentally permit an app to connect to the outside though it's malicious. Thus the whole thing is worth nothing and only slows your system down and gives you a false warm feeling of security.
I'm referring to the article's code under [http://forum.avast.com/index.php?topic=36621.0].
First I see that everything is being dropped by default and that at least for loopback everything is allowed. Already established connections with related traffic were taken into account. IMCP and SSH seems to be alright too. There is also a NAT section for four protocols established which is fine. Hm. Looks good so far...
There's an extra section to drop IRC related traffic based on the default ports I guess. Is it really necessary? - I don't think so since it's covered by the previous rules mentioned.
Finally there's something for blocked hosts and networks and some logging configuration and "Drop Them All" should make the rest!
Conclusion:
1] Your FTP ports are still in state closed. Are others too or are they really stealthed? From which IP are you scanning from? Do you bounce trough the net and on the public IP/Port combination of your router or are all scans performed from the inner LAN?
2] Is there some FTP service running on your machine? Did you ever suspect the firewall to apply an internal rule to hold the port in that state for something?
3] If your scanning host is listed in the range of the blocked networks try to remove the 3 or 4 lines stating the "--reject-with icmp-host-prohibited" argument.
Hy! Well, I see. The problem is that only the states OPEN, FILTERED and CLOSED "really" exist. What you mean by stealthed is something different. I hope you're using an already well secured GNU/Linux distribution by default. Messing around in iptables only makes sense if your (I guess GUI centric) distro doesn't care about this. Try a port scan first. If there are only ports opened by services you know and all the others are not being listed or as closed you're fine. If you wanna improve security though I recommend you some IDS or maybe Fail2Ban. Such techniques enable you to bring ports in some "stealth" mode. Though this is only a rule to throw every request away (Kernel handled) but not a state in the truest sense of the word.
If you wanna solve it with iptables only try something like this.
iptables -P INPUT DROP
iptables -F INPUT
iptables -N inbound
iptables -A INPUT -i eth0 -j inbound
iptables -A INPUT -i lo -j ACCEPT
iptables -A inbound -m state --state ESTABLISHED -j ACCEPT
iptables -A inbound -m state --state RELATED -j ACCEPT
This allows all desired traffic outward (provided your OUTPUT chain is set up correctly), but only packets that are part of a connection or related to one (ftp, for example) are allowed back in.
Oh and maybe you'd have a look in here: http://www.yourwebexperts.com/forum/viewforum.php?f=35
Happy-Dude's Comments
Comment Wall (16 comments)
You need to be a member of House of Hackers to add comments!
Join this Ning Network
you can search for dumps on that site and dl them FYI
1] http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/c-html/index.html
Patched Immediately
Since i work for the Government we had the patches when the vendors did before they were released to the public.
1) Port Randimization allows users to be pushed to incorrect sites or locations for other protocol transfers.
2) The DNS flaw is right because it is part of the underlying source code. No one can change this all that can be done is to hide it aka basically make it time consuming to hack.
3) Simply put it this way if you can point a user that thinks they are going to www.google.com to send them www.sysadmins.google.com and insert and flash or Active X download script you can take control of there network. For example the TTL (Time to live) on a cache of a company may be 24 hours. If you can change this within say the first 19 hours of the ttl then you will have every user and server pushing ppl to www.sysadmin.google.com for 5 hours. This could allow you to push malicious software to every machine that accesses this site.
You could also infect a server with Malicious code this way and allow you to manually at a later time reroute whatever traffic you wanted provided the code you gave the server allows access at any time.
Dan will show examples of how and what to do
I may attend this Security conference however if i do not there will be video streams of this online this way we can watch it.
Basically its explained like this if you are trying to penetrate a home user it is not worth it. The best ones would be an ISP server.
You then have thousands or millions of users pointing to a fake location.
I have done some reverse engineering on the patches from Microsoft and they have done a great job covering up this error in the code.
Since this exploit is in the source code in order to completly fix it you would have to rewrite DNS which is almost impossible considering it is implementing on every router/switch/server/host in the world
regardless of the O/S
Any other questions?
Anything Specific?
I have the file on my server @ home
Just wanted to update you on the software
What are you doing?
other then that regarding DNS port randimization allows for mutiple data I/O and allows for updates and upgrades on network access in the future. Dan's DNS flaw has to do with the source level of DNS. I dont really have much more information on that yet since the Convention where he will release the flaw is in the beginning of august once i get more information i can give you an explaination of it.
Check it and then you will get the software
buddy
The problem is the scanning method of these online scanners. Additionally I have to warn you relating to these port conditions. As I already told you "closed" is ok cause it indicates the system wont let any data in through that port. There is some kind of processing but (think logically) whenever there's some kinda attack on your system the leet hacker seeks the ports in a listening state. One open port may be sufficient to cause some buffer overflow or such. Thus its worth more to update the firmware more often and run less services than to waste too much time to stealth some ports. You cannot stealth all of them!
To end this session I suggest you to install an IDS and familiarize yourself with the systems logging facilities. This will improve your overall situation by far. I also recommend a safer OS. If you actually run a server I recommend you one of the following systems:
1] OpenBSD (+stack protection +crypto hardware support +systrace policy +IDS mtree +OpenSSH, etc.)
2] TrustedBSD (+acls +UFS2-FS +OpenBSM +OpenPAM +SeBSD (MAC (NSA Flask)) +RSBAC +grsec + Pax)
3] some Hardened GNU/Linux (+SE (MAC (Falsk)) +grsec +Pax +hardened Libs +Userspace hardeneing, etc.)
;-)
1] It doesn't matter what your machines desktop filter does as long as your router-firewall-combination blocks everything from the outside. If your firewall for e.g. drops all packets on all ports (which includes 20 and 21) then it doesn't matter whether your machines desktop filter (it's not a firewall) leaves these ports open since no request is being forwarded at all. I therefore assume you have the following configuration:
PROTECTED MACHINE = 192.168.0.100 (I assume its a file server)
ROUTER with FIREWALL (INNER) = 192.168.0.1 (Is a gateway for all the LAN clients as well as the server)
ROUTER with FIREWALL (OUTER) = e.g. 70.155.143.91 (some dynamic IP issued by your domestic ISP)
You need to scan FROM your host (maybe 192.168.0.3) TO 70.155.143.91 ;-)
Use nmap with the following configuration:
namp -sS -sV -O -p 1-65535 -v -P0 -T3 70.155.143.91
- Use -F instead of "p 1-65535" to speed things up and perform a realistic scan. It's also recommended if you don't make use of high ports or didn't map anything differently e.g. webserver on port 80 to 65000 or such.
- Decrease -T3 to -T1 (min) if mess occurs on your screen or increase it to -T4 or -T5 (max) to speed things up again.
- Omit SYN or XMAS at first to check out the routers default behavior. We wanna ensure it handles all "regular" requests in a way we expect it to do.
Good Luck!
PS: Local desktop or application filters (again: the thing you call a firewall on your server) are mostly just crap. I guess you run something like ZoneAlarm on there since I assume it's a Win32 NT5.1 (XP) machine. Nevertheless they handle requests on an application basis and are only necessary in rare circumstances. Mostly they mess up your system when not correctly configured. Worst case scenario is that you accidentally permit an app to connect to the outside though it's malicious. Thus the whole thing is worth nothing and only slows your system down and gives you a false warm feeling of security.
I'm referring to the article's code under [http://forum.avast.com/index.php?topic=36621.0].
First I see that everything is being dropped by default and that at least for loopback everything is allowed. Already established connections with related traffic were taken into account. IMCP and SSH seems to be alright too. There is also a NAT section for four protocols established which is fine. Hm. Looks good so far...
There's an extra section to drop IRC related traffic based on the default ports I guess. Is it really necessary? - I don't think so since it's covered by the previous rules mentioned.
Finally there's something for blocked hosts and networks and some logging configuration and "Drop Them All" should make the rest!
Conclusion:
1] Your FTP ports are still in state closed. Are others too or are they really stealthed? From which IP are you scanning from? Do you bounce trough the net and on the public IP/Port combination of your router or are all scans performed from the inner LAN?
2] Is there some FTP service running on your machine? Did you ever suspect the firewall to apply an internal rule to hold the port in that state for something?
3] If your scanning host is listed in the range of the blocked networks try to remove the 3 or 4 lines stating the "--reject-with icmp-host-prohibited" argument.
1] http://www.fail2ban.org/wiki/index.php/FAQ_english
2] http://www.fail2ban.org/wiki/index.php/HOWTOs
3] http://www.the-art-of-web.com/system/fail2ban/
If you wanna solve it with iptables only try something like this.
iptables -P INPUT DROP
iptables -F INPUT
iptables -N inbound
iptables -A INPUT -i eth0 -j inbound
iptables -A INPUT -i lo -j ACCEPT
iptables -A inbound -m state --state ESTABLISHED -j ACCEPT
iptables -A inbound -m state --state RELATED -j ACCEPT
This allows all desired traffic outward (provided your OUTPUT chain is set up correctly), but only packets that are part of a connection or related to one (ftp, for example) are allowed back in.
Oh and maybe you'd have a look in here: http://www.yourwebexperts.com/forum/viewforum.php?f=35
HF! ;-)
You can not find them online there shared alot of places
Welcome to
House of Hackers
Sign Up
or Sign In
About
© 2009 Created by pdp on Ning. Create a Ning Network!
Badges | Report an Issue | Privacy | Terms of Service