79% of CISOs say continuous runtime vulnerability management is an essential capability to keep up with the expanding complexity of modern multi-cloud environments.

WALTHAM, Mass.--(BUSINESS WIRE)--Software intelligence company Dynatrace (NYSE: DT) announced today the findings of an independent global survey of 1,300 chief information security officers (CISOs) in large-size organizations. The research reveals that the speed and complexity created by using multicloud environments, multiple coding languages, and open source software libraries are making vulnerability management more difficult. 75% of CISOs say that despite having a multi-layered security posture, persistent coverage gaps allow vulnerabilities into production. This highlights the growing need for observability and security to converge, paving the way toward AISecDevOps practices. This will empower organizations with a more effective way of managing vulnerabilities at runtime, and the ability to detect and block attacks in real time. The complimentary report, _Observability and security must converge to enable effective vulnerability management_, is available for download.

Findings from the research include:

*   69% of CISOs say vulnerability management has become more difficult as the need to accelerate digital transformation has increased.
*   More than three-quarters (79%) of CISOs say that automatic, continuous runtime vulnerability management is key to filling the gap in the capabilities of existing security solutions. However, just 4% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments.
*   Only 25% of security teams can access a fully accurate, continuously updated report of every application and code library running in production in real time.

“These findings underscore that there are always opportunities for vulnerabilities to slip past security teams, regardless of how robust their defenses might be. Both new applications and stable legacy software are prone to vulnerabilities that are more reliably detected in production. Log4Shell was the poster child for this problem, and there will undoubtedly be other scenarios like it in the future,” said Bernd Greifeneder, Chief Technology Officer at Dynatrace. “It’s also clear that most organizations still lack real-time visibility into runtime vulnerabilities. The problem stems from the growing use of cloud-native delivery practices, which enable greater business agility, but also introduce new complexity for vulnerability management, attack detection, and blocking. The rapid pace of digital transformation means that already overstretched teams are bombarded by thousands of security alerts that make it impossible to see through the noise and focus on what matters. Teams find it impossible to respond manually to every alert, and organizations are exposed to unnecessary risk by allowing vulnerabilities to escape into production.”

Additional findings include:

*   On average, organizations receive 2,027 alerts of potential application security vulnerabilities each month.
*   Less than a third (32%) of the application security vulnerability alerts organizations receive each day require action, compared to 42% last year.
*   On average, application security teams waste 28% of their time on vulnerability management tasks that could be automated.

“Organizations realize that to manage vulnerabilities in the cloud-native era effectively, security must become a shared responsibility. The convergence of observability and security is critical to providing development, operations, and security teams with the context needed to understand how their applications are connected, where the vulnerabilities lie, and which need to be prioritized. This accelerates risk management and incident response,” continued Greifeneder. “To be truly effective, organizations should look for solutions that have AI and automation capabilities at their core, enabling AISecDevOps. These solutions empower their teams to quickly identify and prioritize vulnerabilities at runtime, block attacks in real time, and remediate software flaws before they can be exploited. This means teams can stop wasting time in war rooms or chasing false positives and potential vulnerabilities that will never make it into production. Instead, they confidently deliver better, more secure software faster.”

The report is based on a global survey of 1,300 CISOs in large-size organizations with more than 1,000 employees, conducted by Coleman Parkes and commissioned by Dynatrace in April 2022. The sample included 200 respondents in the U.S., 100 each in the UK, France, Germany, Spain, Italy, the Nordics, the Middle East, Australia, and India, and 50 each in Singapore, Malaysia, Brazil, and Mexico.

**About Dynatrace**

Dynatrace (NYSE: DT) exists to make the world’s software work perfectly. Our unified software intelligence platform combines broad and deep observability and continuous runtime application security with the most advanced AIOps to provide answers and intelligent automation from data at an enormous scale. This enables innovators to modernize and automate cloud operations, deliver software faster and more securely, and ensure flawless digital experiences. That is why the world’s largest organizations trust the Dynatrace® platform to accelerate digital transformation.

Curious to see how you can simplify your cloud and maximize the impact of your digital teams? Let us show you. Sign up for a free 15-day Dynatrace trial.

Research Reveals 75% of CISOs Are Worried Too Many Application Vulnerabilities Leak Into Production, Despite a Multi-Layered Security Approach

As insurers and brokers reckon with unexpected losses, they're charging more for policies and setting higher requirements.

Chaos reigns in the cyber insurance market. Brokers and cyber insurance carriers — the companies that actually offer the policies — are tightening requirements on what applicants need to do to obtain policies due to losses the insurers have suffered from ransomware coverage. During the past year, premiums grew 18% in the first quarter of 2021 and were up 34% in the fourth quarter of 2021, according to Jess Burn, senior analyst at Forrester. .

Organizations often find they cannot obtain cyber insurance, are not being renewed for coverage they already have, or are faced with soaring prices and shrinking coverage. Despite the value many organizations put on cyber insurance — in some cases, they're required to carry it to comply with regulations — obtaining such policies is getting more difficult.

While raising premiums, some insurers are reducing coverage. If an organization bought $10 million worth of coverage for a given price in 2021, for example, renewing that policy in 2022 might see the coverage amount fall to $3 million and the premiums for that lower coverage rise. This phenomenon is due, in part, to insurers trying to strike the right balance of customers' risk profile versus their risk-mitigation efforts.

In the recently released "2022 Voice of the CISO" report from Proofpoint, just 49% of CISOs at US-based organizations said they have cyber insurance and are confident that it will be there when needed. This is well below the 58% global average; Canada led the study at 88%, whereas the US ranked 11th worldwide. In that same report, 56% of global CISOs specifically cited the increase of ransomware attacks as a main driver of concern and a key reason to obtain cyber insurance.

**Losses Are Wreaking Havoc**

This situation was underscored in a March 2022 cyber insurance event, sponsored by cybersecurity vendor Sophos, called "Optimizing Your Cyber Insurance Position," where Marsh McLennan Agency (MMA) risk management consultant Marc Schein, national co-chair of the Cyber Center of Excellence, laid out why cyber insurers are revising their requirements for applicants and why their models needed to change.

Schein said the global average associated with ransomware recovery for 2021 was expected to reach roughly $20 billion. The frequency and severity of attacks are increasing, he said, and "insurers' rating models did not accurately predict some of the loss severity that they've actually been seeing \[with\] evolving privacy regulation."

Additionally, increasing regulatory fines and penalties "really have started to wreak havoc on the cyber insurance marketplace," Schein said.

The industry is seeing "increasing conservative limit deployment from certain carriers in response to an increase in volatility from large losses and deteriorating financial performance," he added. "They're not only raising prices, but they're also now starting to change the way that the coverage is structured."

Scott Godes, a partner with law firm Barnes & Thornburg, is a cyber insurance specialist. He agrees that major changes are occurring, noting that some carriers are implementing new exclusions and limitations on the types of coverage policyholders need the most. Nearly all carriers are raising their rates across the board.

"Carriers are getting significantly more aggressive on their claim positions," Godes says. "They are using outside counsel much more frequently to investigate, handle, and adjust claims. It seems very unlikely that carriers hire lawyers to adjust claims to give the most coverage possible to their insureds."

Insurers are finding that assumptions they made about potential losses, based on their experience with other insurance policies such as personal and property liability, are not accurate. Losses have been much higher on some cyber insurance policies over the past several years than insurers anticipated five years ago.

An August 2021 article in Canadian Underwriter highlighted the financial effect some of these assumptions are having on insurance companies' bottom line. "In cyber liability, total net premiums earned for the second half of 2021 were $94.15 million – $12.15 million from Canadian insurers and $82 million from foreign insurers," it reported. "But total net claims incurred (not including reinsurers' share but including adjustment expenses) were $106.26 million ($97.4 million from foreign insurers and $8.86 million from Canadian insurers), for a loss ratio of nearly 113%."

**Setting Baseline Security Controls**

Insurance brokers and carriers are responding to the higher losses from ransomware and unexpected costs by modifying how and to whom they write policies.

Insurers are beginning to require certain security controls be in place prior to sitting down with a prospect to discuss cyber insurance.

"What cyber insurance brokers and carriers want to see from policyholders is a real effort and investment made to reduce the likelihood of a ransomware attack and to be prepared to respond to one should it happen," Forrester's Burn says.

To that end, she recommends that organizations put the following controls in place immediately:

*   Securing Remote Desktop Protocol (RDP) and other remote access configurations.
*   Restricting macros from executing when downloaded from the Internet.
*   Establishing an incident response plan — companies must have playbooks for common attack scenarios like ransomware and business email compromises, and they must test those plans and playbooks regularly with tabletop exercises and crisis simulations.
*   Implementing multifactor authentication.
*   Implementing an offsite backup solution.

MMA's list of controls includes the above, plus the following:

*   Employee cybersecurity training.
*   Third-party risk management (TPRM).
*   Patch management.
*   Vulnerability management.
*   Endpoint detection and response (EDR) and managed detection and response (MDR).
*   Logging and monitoring.
*   End-of-life plan.
*   Email filtering.
*   Privileged access management (PAM).

TPRM is often poorly understood, since organizations have a difficult time determining the risks associated with their supply chains. It is even more difficult to determine the risk of a supply chain's supply chain.

Burn says she expects to see a new, focused breed of cyber insurance policies in the next 12 months to 18 months to cover the weakest link in the supply chain. What those policies will cover is still unwritten.

Turbulent Cyber Insurance Market Sees Rising Prices and Sinking Coverage

Uncontrolled resource consumption in Mattermost version 6.6.0 and earlier allows an authenticated attacker to crash the server via a crafted SVG attachment on a post.

CVE-2022-1982: Security Updates

SQL injection in Logon Page of IDCE MV's application, version 1.0, allows an attacker to inject SQL payloads in the user field, connecting to a database to access enterprise's private and sensitive information.

Olá!

Neste artigo eu comprovo a falha de SQL Injection no software de gestão de saúde IDCE da empresa MV Informática para a base do CVE-2022-30496.

Embora o software seja de uma versão antiga, lançada há alguns anos atrás, algumas empresas brasileiras de saúde ainda o utilizam em larga escala. A maioria das empresas o tem rodando apenas em redes locais ou protegidos por VPN. Porém ainda é possível encontrar este software vulnerável sendo utilizado abertamente através da internet e sem nenhuma proteção extra.

Aproveito para informar que a ação de coletar informações de serviços não é caracterizado crime, uma vez que foi utilizado um ambiente controlado de teste e nenhuma informação privada foi revelada. Esta matéria tem como fins apresentar os métodos utilizados por hackers para encontrar informações de empresas e apresentar aos desenvolvedores as falhas de segurança que suas aplicações web (portais, sites de atendimento, etc) possuem. Corrigir ou não é uma decisão dos desenvolvedores e gestores/clientes destas aplicações.

Por Iran Macedo, especialista em proteção de dados e segurança ofensiva / Pentest.

**A falha de SQLi**

O software testado foi o IDCE - MV Medicina Diagnóstica. Este software é utilizado por hospitais e seus médicos para gerarem laudos de exames médicos de pacientes. Mas não somente isso, pois pode controlar fluxo de pagamentos, gerenciar usuários, suas informações e permissões, dados de parceiros, de fornecedores e de clientes (pacientes) e outros serviços gerenciais relativos aos hospitais e clínicas.

Realizando o teste mais básico de SQL Injection, não conseguimos nada. Por exemplo, ao adicionar uma aspas simples ' no campo usuário, temos a resposta "Usuário e/ou Senha inválidos!", o que parece ser um bom sinal, uma vez que a aplicação parece tratar a entrada enviada pelo usuário antes de envia-la ao banco de dados.

**Time-Based Blind injection**

Para iniciar meus testes, fiz o envio de um usuário e senha inválidos, interceptei pelo Burp, copiei os dados de requisição e salvei num arquivo TXT, que foi utilizado pelo SQLMap como base da requisição através do parâmetro "-r".

Num teste anterior em um outro produto do desenvolvedor MV, vimos que o banco de dados utilizado era um Oracle. Desta forma as chances do desenvolvedor utilizar na epoca o Oracle como a solução de banco de dados para todas as suas aplicações é grande. Partindo deste princípio, configurei o meu SQLMap para testar todas os possíveis ataques (level 5 e risk 3) somente para banco Oracle nesta aplicação. Isso reduz a quantidade e o tempo de execução dos testes.

Como resultado, o campo testado (Usuário) pareceu ser vulnerável a um ataque de SQL Injection em Oracle e Time-Based Blind.

Ao final dos testes o SQLMap trouxe a confirmação da falha de segurança da aplicação, evidenciando o banco de dados encontrado (Oracle), a versão e o sistema operacional do servidor do banco de dados (Windows 2008 R2) e outras informações. Isto já é suficiente para comprovar a falha de segurança na aplicação.

Para ser mais conclusivo, outros dados não sensíveis foram capturados, como por exemplo o usuário utilizado pelo banco de dados e a base atualmente acessada.

E, para evidenciar que seria possível acessar todas as informações dentro desta base, pegamos os nomes das colunas de uma dada tabela utilizada pela aplicação IDCE.

Estas evidências são suficientes para comprovar a falha de segurança da aplicação, que acaba expondo as informações dentro do seu banco de dados.

Por ser um falha baseada em tempo de resposta às cegas (Time-Based Blind), este tipo de ataque pode levar muito tempo para ser executado.

**Correção da falha** _(informação atualizada)_

Conversando por vídeo conferência com o desenvolvedor em maio de 2020 e em junho de 2022, fui informado de que a MV Informática corrigiu as falhas apresentadas nesta versão testada. Desta forma, é recomendado que a solução de medicina diagnóstica IDCE seja utilizada sempre de forma atualizada. Infelizmente algumas empresas ainda utilizam versões desatualizadas e vulneráveis.

**Conclusão**

Mantenha o seu software atualizado e sempre utilize as versões mais atuais e estáveis. Utilizar softwares piratas pode parecer como uma solução viável e barata para quem não quer gastar dinheiro pagando por programas licenciados. Mas lembre-se de que isto não é legal (no termo jurídico da palavra), além de não ter as atualizações necessárias para mantê-lo seguro. O "barato" pode acabar saindo muito, mas muito mais caro do que pagar por softwares licenciados. Visto que uma multa aplicada por processos judiciais de clientes afetados através da LGPD não é nada barato, sem dizer dos riscos de se ter o banco de dados principal invadido.

Mantenha-se seguro e um grande abraço!

Documentação formal do CVE na Mitre: MeuGithub

CVE ID: CVE-2022-30496.

CVE-2022-30496: SQL Injection no IDCE MV

Specific BD Pyxis™ products were installed with default credentials and may presently still operate with these credentials. There may be scenarios where BD Pyxis™ products are installed with the same default local operating system credentials or domain-joined server(s) credentials that may be shared across product types. If exploited, threat actors may be able to gain privileged access to the underlying file system and could potentially exploit or gain access to ePHI or other sensitive information.

*   **Cybersecurity**
*   About us
*   Trust center
*   Bulletins and patches
*   Vulnerability disclosures
*   Helpful resources

*   BD Pyxis™ Products - Default Credentials

This notification provides product security information and recommendations related to the use of default credentials in specific BD Pyxis™ products. BD has voluntarily reported this vulnerability to the U.S. Food and Drug Administration (FDA) and Information Sharing and Analysis Organizations (ISAOs) where BD participates, including the U.S. Department of Homeland Security Cybersecurity and Infrastructure Security Agency (CISA) and the Health Information Sharing and Analysis Center (HISAC).

**Products in Scope**

The product list below identifies existing BD Pyxis™ products that may use default credentials.

*   BD Pyxis™ Anesthesia Station ES
*   BD Pyxis™ CIISafe
*   BD Pyxis™ Logistics
*   BD Pyxis™ MedBank
*   BD Pyxis™ MedStation™ 4000
*   BD Pyxis™ MedStation™ ES
*   BD Pyxis™ MedStation™ ES Server
*   BD Pyxis™ ParAssist

*   BD Pyxis™ Rapid Rx
*   BD Pyxis™ StockStation
*   BD Pyxis™ SupplyCenter
*   BD Pyxis™ SupplyRoller
*   BD Pyxis™ SupplyStation™
*   BD Pyxis™ SupplyStation™ EC
*   BD Pyxis™ SupplyStation™ RF auxiliary
*   BD Rowa™ Pouch Packaging Systems

**Vulnerability Details**

**CVE-2022-22767 -** Specific BD Pyxis™ products were installed with default credentials and may presently still operate with these credentials. There may be scenarios where BD Pyxis™ products are installed with the same default local operating system credentials or domain-joined server(s) credentials that may be shared across product types. If exploited, threat actors may be able to gain privileged access to the underlying file system and could potentially exploit or gain access to ePHI or other sensitive information.

To exploit this vulnerability, threat actors would have to gain access to the default credentials, infiltrate a facility’s network, and gain access to individual devices and/or servers.

The default credentials are primarily managed by BD support personnel. In cases where customers have domain-joined servers, BD support personnel will work with customer representatives to jointly manage credentials.

The use of default credentials in BD Pyxis™ devices is documented in BD Product Security White Papers, which customers can request from the BD Cybersecurity Trust Center. BD Product Security White Papers detail how security and privacy practices have been applied and provide information to help customers safeguard product security throughout each product's life cycle.

**Vulnerability Score**

*   CVSS: 8.8 (High) CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Rationale: Adjacent access is required to exploit this vulnerability, meaning the attack needs to be initiated from the same shared physical or logical network. The attack complexity is low and is based on access to default credentials still in use. The scope is considered unchanged as this vulnerability is specific to only the impacted application. The vulnerability has a high impact on confidentiality, integrity and availability as specific default credentials potentially allow threat actors to gain privileged access to specific devices.

**Mitigations and Compensating Controls**

BD is currently strengthening our credential management capabilities in BD Pyxis™ products. Service personnel are proactively working with customers whose domain-joined server(s) credentials require updates.

BD is currently piloting a credential management solution that is initially targeted for specific BD Pyxis™ product versions and will allow for improved authentication management practices with specific local operating system credentials. Changes needed for installation, upgrade or to applications are being evaluated as part of the overall remediations.

Additionally, BD recommends the following compensating controls for customers using BD Pyxis™ products that utilize default credentials:

*   Limit physical access to only authorized personnel.
*   Tightly control management of system passwords provided to authorized users.
*   Monitor and log network traffic attempting to reach the affected products for suspicious activity.
*   Isolate affected products in a secure VLAN or behind firewalls with restricted access that only permits communication with trusted hosts in other networks when needed.
*   Work with your local BD support team to ensure that patching and virus definitions are up to date. The BD Remote Support Services Solution for automated patching and virus definition management is an available solution for customer accounts.

**Additional Resources**

For product- or site-specific concerns, contact your BD service representative.

**Company**

*   Contact us
*   BD code of conduct
*   Careers
*   Inclusion and diversity
*   Sustainability
*   Suppliers
*   News
*   Investors
*   Video gallery
*   External funding program

**Support**

*   Technical support
*   Product security and privacy
*   Live chat
*   Order status
*   Customer portals
*   Alerts and notices
*   Electronic instructions for use
*   COVID-19

CVE-2022-22767: BD Pyxis<sup>™</sup> Products - Default Credentials

LinkPlay Sound Bar v1.0 allows attackers to escalate privileges via a hardcoded password for the SSL certificate.

From: Lifeng Zhao <lifeng.zhao@linkplay.com> Sent: Sunday, December 12, 2021 5:03 PM To: Hidden Subject: Re: Security Vulnerability \*\*\* The Answer \*\*\* Hi Ohana, Thank you very much for your detailed report on the security vulnerability. It's super helpful and important to us. We'll take the immediate action to fix this. Thank you again for your great support. Best, Lifeng From: Hidden Date: 2021-12-12 21:24 To: security@linkplay.com Subject: Security Vulnerability \*\*\* The vulnerability \*\*\* Bug Type: Hard-coded secret key Impact: RCE, Supply chain attack Platforms: IOS + Android applications Our lab team has reviewed your product from a security perspective and noticed a few security issues that you should be aware of (technical details provided below). It is important to note that CyberArk Labs follow the security industry standard disclosure policy. We allow 90 days for the issues to be fixed/patched/mitigated. CyberArk Labs reserves the right to publicly disclose all information about the issues after this timeframe. We would be happy to share any additional information and to cooperate with you in mitigating the issue in a timely fashion. Summary: We can access an admin user in the Artifactory JFrog system, through which you can manage all the code of the applications and change it. As a result, we can change the application code across multiple tenants, ending with full RCE over every app. It is important to note, however, that both Android and IOS applications suffer from these vulnerabilities In details: We found the API key for admin and the password of the SSL client certificate have been hardcoded and stored on the application SoundBar (com.wifiaudio.Yamaha). To exploit this, you can add the API key to each request sent to the server. 1.Within the SoundBar application, we found the password of certificate\_new\_encrypted.p12 SSL certificate file. Using this certificate, we can communicate with the Soundbar device on port 443. Besides that, we found that the file is encoded with the XOR operator with the number 2. Therefore, it is simple to overcome the encoding. As a result, we can communicate with HTTPS requests with the device. 2. Also, we found that the application sends logs to the URL https://log.linkplay.com:8081/artifactory/Android/logs with the header "X-JFrog-Art-Api, and the API key AKCp5bB…. We discovered this API key is the key of the admin user in the system. This is a major security concern because every malicious user can access the JFrog artifactory with full admin access. In other words, a malicious user can corrupt the repository and cause clients to download malicious applications. 3.Moreover, we noticed that the JFROG version (6.2.0) is not up-to-date. The latest version is (7.10.2). Thus, it is vulnerable to the following CVEs: 1. CVE-2020-7931 2. From the frog website Lastly, we found the vulnerability (the admin API key) in many applications. Below are some links to several apps: ·https://play.google.com/store/apps/details?id=com.medion.speaker ·https://play.google.com/store/apps/details?id=com.wifiaudio.Yamaha ·https://play.google.com/store/apps/details?id=com.wifiaudio.triangle ·https://play.google.com/store/apps/details?id=com.wifiaudio.cavalier ·https://play.google.com/store/apps/details?id=com.wifiaudio.jam ·https://play.google.com/store/apps/details?id=com.wifiaudio.FABRIQ ·https://play.google.com/store/apps/details?id=com.zoundindustries.marshallvoice ·https://play.google.com/store/apps/details?id=com.dpiinc.ISBWV418B ·https://play.google.com/store/apps/details?id=com.ihome.ama ·https://play.google.com/store/apps/details?id=com.wifiaudio.iHome ·https://play.google.com/store/apps/details?id=com.wifiaudio.Creative

CVE-2022-28605: hardcoded on LinkPlay app

Flower, a web UI for the Celery Python RPC framework, all versions as of 05-02-2022 is vulnerable to an OAuth authentication bypass. An attacker could then access the Flower API to discover and invoke arbitrary Celery RPC calls or deny service by shutting down Celery task nodes.

This post discloses two vulnerabilities in Flower, a popular open-source web application deployed along with Celery (a task queue for Python):

*   Lack of CSRF or SSRF protections in Flower, allowing remote API invocations on internally-hosted instances
*   An OAuth authentication bypass allowing anyone to login and access all Flower functionality

These issues are tracked under CVE-2022-30034.

I created a PR which fixes the OAuth bypass and disables the API unless authentication is configured. The maintainer did not respond to attempts at contact so it is unclear if this will be merged: https://github.com/mher/flower/pull/1216.

The vulnerabilities themselves are moderately interesting, but a more interesting question to ask is “what could an attacker _do_ with Flower?”:

*   Invoke arbitrary tasks registered with Celery (basically, RPC; but the tasks would be highly dependent on application context)
*   Apache Airflow is probably the most popular software which uses Celery, and registers a Celery task in a default configuration. Through Flower, an attacker could invoke airflow tasks run with arbitrary parameters, which could (dependent on configuration or other vulnerabilities) be used to achieve RCE

**Background**

Flower is a web app which allows monitoring and managing Celery, which is a task queue for Python.

*   Flower has more than 5000 stars on Github and is included in the default deployments of other extremely popular software such as Apache Airflow.
*   Flower is (or was) included but not enabled by default in some managed Airflow deployments such as Google Cloud Composer.
*   Shodan shows more than 2000 publicly-exposed instances, although most instances appear to require authentication with basic authentication, and thus would not be vulnerable.
*   There are likely many more instances which are only accessible on internal/corporate networks.

**Lack of CSRF and SSRF Protections**

Flower lacks CSRF protection, meaning that if a user with access to a Flower instance visits a malicious website, that site could run JavaScript which calls Flower’s APIs. This would primarily be used to exploit other vulnerabilities, such as through the arbitrary task invocation issue. The lack of CSRF protections apply to all web routes, APIs, and the api/task/events websocket endpoint. In particular, websocket connections can be used to solidly confirm the presence of the vulnerable listener on internal networks and also leak some minor information.

Lack of authentication by default also means that SSRF attacks would be straightforward on any instance not configured for authentication.

Flower also has a strange (i.e. broken) CORS policy, but it doesn’t appear to lead to any additional impact. _Note:_ a recent PR opened the CORS headers up with a wildcard, which would increase the exploitability of CSRF.

Overall, I think the likelihood of CSRF exploitation through Flower is relatively low, so my PR didn’t attempt to add CSRF protections, because doing so would likely require breaking all existing Flower API clients (e.g. requiring a custom HTTP header). Rather, the PR disables the API if authentication is disabled.

**OAuth Bypass Vulnerability**

Flower supports OAuth login via Google, Github, Okta, and Gitlab. When configuring OAuth according to the documentation, Flower requires the user to provide a regular expression which is checked against the user email that Flower receives after the user logs in:

    flower --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@example.com
    

The above command line is intended to configure Flower to use Gitlab OAuth and only allow users whose emails are registered with example.com. However, the regular expression check _lacks regex anchors_, thus allowing anyone to authenticate as long as they can sign up to the OAuth identity provider with a user-controlled email.

Example scenarios:

*   For .*@example.com, a valid user might be alice@example.com, but attacker@example.com.attacker.com can also login.
*   Specifying me@gmail.com would only be intended to allow one user to login, but me@gmail.com.attacker.com also works.
*   Because the regular expression is provided on the command line, the period may not be correctly escaped. For a literal period provided in a shell command, a double backslash is generally needed to get a literal backslash in the argument. The documentation examples use either zero or one backslashes. As a result, .*@corp.example.com or .*@corp\.example\.com could be bypassed with attacker@corpZexample.com even if anchors were applied.

**Reproduction**

I demonstrated the vulnerability in a local deployment of Flower with the following configuration:

1.  Create a public Gitlab user user1@tannerprynn.com (the intended user of the application)
    *   Configure an application under this user to login to Flower
2.  Create a second public Gitlab user user1@tannerprynn.com.pry.nz
3.  Flower configuration:
    *   Command-line options --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@tannerprynn.com
    *   Environment variables FLOWER_OAUTH2_KEY, FLOWER_OAUTH2_SECRET, FLOWER_OAUTH2_REDIRECT_URI

**Recommendations for Flower**

1.  Disable the API unless authentication is configured for Flower
2.  Implement CSRF protections (primarily relevant to the API); the most straightforward would be to require a custom non-CORS-exempt header for all API requests
3.  Fixing the OAuth bypass will likely require either a breaking change for users, or using custom logic to match the user-provided string without interpreting a single period as a wildcard character

**Post-Exploitation**

With the ability to send requests to Flower, an attacker would primarily use its APIs - in particular, POST /api/task/apply/{taskname} which allows invoking any Celery task. Assuming the attacker is not operating through blind CSRF, they can use GET /api/task/types and other APIs to list which tasks can be called and the parameters, and attempt to exploit those specific tasks. Given the expectation that these calls would only come from internal, trusted systems, it is likely that any custom-developed tasks have vulnerabilities or cause some dangerous actions. However, those vulns would be highly application/context-specific.

I was interested in one specific deployment of Flower, which is with Airflow, a very popular open-source app. Flower is deployed without authentication in the default Airflow configuration (when deployed with the recommended docker-compose configuration and Helm chart). Airflow registers a single task airflow.executors.celery_executor.execute_command which allows invoking an Airflow task via the equivalent of a command-line invocation of airflow tasks run.

    POST /api/task/apply/airflow.executors.celery_executor.execute_command HTTP/1.1
    Host: flower:5555
    Content-Type: text/plain
    Content-Length: 84
    
    {"args":[["airflow", "tasks", "run", "example_bash_operator", "runme_1", "1234"]]}
    

Initially, I was relatively confident that this would lead directly to RCE, but it doesn’t appear straightforward:

*   Although the arguments appear to specify a command-line invocation, they don’t actually pass through a shell at any point. Celery passes these arguments through a message queue (e.g. Redis) and they invoke the execute_command Python method after being picked up by an Airflow worker, which then parses the arguments using its own command-line parser.
*   The first three arguments ("airflow", "tasks", "run") are validated and cannot be changed to invoke other airflow CLI commands.
*   The last argument is execution_date_or_run_id which is used unsafely in Airflow’s example_bash_operator, but this argument appears to be validated.

That’s not to say that this is safe. An attacker can still specify arbitrary arguments after airflow tasks run, which would include parameters such as --cfg-path and --subdir. If combined with the ability to write a file somewhere on the filesystem, either of these configuration options allows picking up and running arbitrary python code. Without that ability, the impact would be limited to calling the DAGs/tasks that are already set up on the system.

**Recommendations for Airflow**

1.  If possible, strip all parameters from the arguments provided to this invocation path so that an attacker does not have the ability to change the configuration in a way which might allow unexpected code execution
2.  Although run_id seems to be validated, preventing injection in example_bash_operator, that doesn’t seem to be a documented expectation in general, so you should handle it safely in your example code
3.  If Flower isn’t a necessary component of Airflow, consider removing it from the default docker-compose/Helm setup
4.  Alternatively, set up docker-compose and Helm to use basic auth with randomly-generated passwords for Flower (even a weak static password would actually help limit CSRF/SSRF attacks)

From discussions with the Airflow maintainer, Flower is seen as a development-only tool that should not be used in any production deployment. However, given that Flower itself does not appear to be actively maintained, the Airflow maintainer decided that they would disable Flower by default in their docker-compose and Helm chart (starting in version 2.3.1).

**Disclosure Timeline**

*   05 April 2022: Initial contacts to Apache Security team
*   06 April 2022: Partial disclosure to Airflow maintainer of impact and recommendations for Airflow
*   06 April 2022: Initial attempt to contact the Flower maintainer (mher)
*   06-21 April 2022: Follow up emails to the Airflow maintainer
*   12-25 April 2022: Discussion with Airflow maintainer
*   23-26 April 2022: Attempts to reach a maintainer for Flower via the associated Celery project’s team members, but no team member was able to give me a working contact
*   26 April 2022: Opened an issue on the public Flower repo asking for a security contact
*   03 May 2022: Followed up on the public issue to state that disclosure would occur in 14 days (17 May) due to lack of response
*   16 May 2022: Airflow maintainer requested a short delay to allow a new release of Airflow which disables Flower by default
*   25 May 2022: Airflow updated to 2.3.1
*   26 May 2022: Public disclosure

CVE-2022-30034: Multiple Vulnerabilities in Flower and Downstream Attacks on Airflow

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in WinAPRS 2.9.0. A buffer overflow in DIGI address processing for VHF KISS packets allows a remote attacker to cause a denial of service (daemon crash) via a malicious AX.25 packet over the air. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Hackers have been breaching computer system defenses for more than half a century, and the networks they use to exploit those weaknesses have been around for far longer than that. With the internet replacing most wirelines and wavelengths, and with the rise of cybercrime sophistication from petty thieves to organized nation-states, the threat landscape has exploded over the last 20 years. Yet one of the oldest network protocols – amateur or “ham” radio – is still used to this day in emergency communications during times of war and disaster, and to this day can still be used in binary exploitation.

Ham radio evokes an image of old guys turning knobs on vintage, tube radios and talking to other hobbyists about their configurations. Nowadays, radios are getting much more complicated, and with the built-in ability to perform digital communications, the possibilities are almost limitless. You can hook them up to computers to do anything from text messaging and email to sharing images and tracking weather balloons. There’s still something magical about connecting to a device or contacting someone across the planet without being hooked up to the internet or a phone line.

I recently passed the Offensive Security Exploit Developer (OSED) exam and wanted to apply what I’d learned to real-world security problems. I’m always looking for ways to improve my threat modeling, attack simulation, and penetration testing skills, and thought that ham radio would be a fun environment to explore. Amateur radio equipment and frequency spectrums are accessible all over the world and are instructive for a blog series that shows how the vulnerabilities of older technologies can be leveraged with today’s hacking fundamentals. With ham radio as our testing and proving ground, we’ll look at reverse engineering, the creation of custom exploits, and developing skills to bypass security mitigations. We’ll also take a look at writing handmade Windows shellcode and adopting older techniques to more modern versions of Windows.

**Packet Radio**

I've been messing around with packet radio and various digital modes on and off for years and have wondered if any vulnerabilities exist that could allow an attacker to obtain remote code execution through the airwaves. I always thought it was a fun idea to be able to hack a computer that isn't even hooked up to the internet. Many ham programs are written by enthusiasts and are quite old, so it seemed likely that there would be exploitable vulnerabilities. In my research I decided to focus mainly on vulnerabilities that could lead to remote code or command execution, though if I found other vulnerabilities, I didn't ignore them. I also decided to start by focusing on Windows software, since the OSED exam focused on Windows user-mode exploitation and it's where I have the most experience. I started this project with a specific goal in mind: get a remote shell over ham radio.

As a hacker, I am most interested in the various digital modes that ham radio has to offer. There are many, and for my research I decided to focus on software that uses the AX.25 protocol.

"Packet radio" generally refers to a very specific digital mode of operation that uses the AX.25 protocol. AX.25 is a data-link layer protocol (layer 2 of the OSI model). In this mode, data is split into packets and transmitted over the air. AX.25 has support for different packet types and includes modes that are similar to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on Ethernet. In some cases, the protocol can do some error correcting, like TCP. Another mode will just send packets out into the air without waiting for any kind of acknowledgement, like UDP. Windows does not have any built-in way to handle AX.25 traffic, so end-user software would have to do this on its own or it must be abstracted away. The Linux kernel has built-in support for AX.25, so you can potentially set up AX.25 network interfaces that have callsigns for addresses instead of IP addresses.

AX.25 is commonly used today for Automatic Packet Reporting System (APRS), Winlink email over ham radio, Bulletin Board Systems (BBS) operations, and more. It seems it is more generally used for a ham to make a contact with a computer, as opposed to making live contacts with other hams. More information about the AX.25 protocol can be found here: http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf

**Automatic Packet Reporting System (APRS)**

The most common use of AX.25 is with the Automatic Packet Reporting System (APRS). Therefore, I decided to focus first on APRS software for this research project. APRS allows hams to transmit telemetry data such as GPS coordinates, weather data, small generic messages, and more. An APRS station can send out a broadcast message, or it can send a message addressed to another specific station. Since the range on the 2m band isn’t that great, APRS stations can “digipeat” the packets out again. This means that if one station receives a packet, it will retransmit it to send it further away. There are also “IGate” systems which are bridged to the internet via the APRS Internet Service (APRS-IS) backbone (http://www.aprs-is.net). This adds extra usability to the APRS system and means you can transmit data globally using the internet if desired. In fact, you can view APRS traffic anywhere in the world at https://aprs.fi and you don’t even need a license to check it out.

How do APRS stations find each other? How does one station find an IGate to bridge to the internet? You can transmit APRS on basically any amateur frequency for which you are licensed, but around the globe each region generally has an allotted frequency where this traffic is used. In the US, that frequency is 144.390 MHz. Just about anywhere in the country you can tune a radio to this frequency and hear data being transmitted at least every minute or so.

APRS is a protocol that runs on top of AX.25, like how HTTP runs on top of TCP. APRS packets make use of the AX.25 unnumbered information (UI) frames. Since I was going to be reverse engineering APRS software, it made sense to examine APRS data frames to understand their structure. AX.25 UI frames look like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

In an AX.25 UI frame, all addresses will be ham radio callsigns with an optional SSID appended to them. If your callsign was K7HAX, your address could be something like K7HAX-14. The digipeater addresses field can contain up to eight digipeater addresses to specify the path the packet should take. A digipeater is a radio station that listens for packets and then retransmits those packets to extend the range. The information field contains user-specified data. APRS makes heavy use of this field and it’s likely to be the most interesting field to play with.

The APRS specification allows for various data types, formats, and encodings. Most of this information is stored in the information field of the AX.25 packet. A generic APRS information field structure looks like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

The data type specifies what kind of APRS data follows. Options include GPS position, direction finding, weather information, messages, and more. Here’s a real APRS message I pulled from https://aprs.fi:

:Are you working tonight?

The colon denotes that the APRS data contains a message. The rest of the data is just the plaintext message. In this case the APRS data extension and comment fields are unused. Here’s another example:

\=3319.44S/06012.46W# 144.930MHz. SNDigi

The equal sign denotes that the data contains position data without a timestamp. Immediately following that is the actual position data. Between the two coordinates is a forward slash and immediately following the data is a hash symbol. Combined, these symbols would make “/#”. This data tells the receiving station what type of station sent the message and what symbol or icon to use to display the station on a map.

APRS has two tables full of different symbols (car, truck, bicycle, balloon, etc.). The forward slash specifies which table to use. The hash tells which symbol to use in that table. After the hash symbol is some additional message data which appears to list the transmitting frequency and probably the software or device used to transmit (SNDigi). There’s so much more to APRS than just this but it gives a rough idea of how the packets look and what we can expect APRS software to be doing when decoding messages. More information about the APRS protocol can be found here: http://www.aprs.org/doc/APRS101.PDF

Since APRS is probably the most common packet protocol in use today, and there is no shortage of APRS software to choose from, I decided to start my research here. I focused on Windows-based APRS software that was written in C or C++ so I could continue honing my IDA and WinDbg reversing skills.

**Hardware for Packet Radio**

There is a huge number of combinations of hardware to get on the air with packet, but in general you’ll need three main components: a transceiver, a terminal node controller (TNC), and a computer. You use the computer to interact with the various packet radio software you want to use. The transceiver sends and receives the communications over the radio. The TNC is basically a packet radio modem that sits between the two, converting the data into sound. It works similarly to a dial-up modem, but for radio instead of telephone lines. A TNC is typically a little box that’s hooked up to the computer and the radio. A TNC will often have a built-in microcomputer with its own operating system so you can open a terminal and send and receive messages right from the TNC. My TNC has a built-in mailbox where other hams can leave messages. It can decode APRS messages with its own software and display them in a human-readable format via serial console. Here’s a photo of the hardware I’m using for my receiving station:

****

**Keep It Simple, Stupid! (KISS)**

Each TNC make and model has its own set of commands you must use to send packets, and they may display packets differently to the user. The computer software must therefore understand how to interface with each make and model, which is cumbersome. To remedy this, most TNCs support a mode called KISS (Keep It Simple, Stupid). This mode disables all the “smart” features of the TNC and turns it into a dumb modem. The TNC will simply demodulate the signals from the radio and transmit the raw data back to your PC and vice versa. To simplify things, I’ll be placing my TNC into KISS mode for testing and using it wherever possible.

The important bit to know about the KISS protocol is that the TNC will add a 0xC0 control character to the beginning and end of each packet, and it will expect those characters to be there for any outgoing transmissions. There are also a few other special control characters the TNC will watch for, which is important to be aware of when writing shellcode later. These characters would be considered “bad characters” when writing shellcode and must be avoided. A full description of the KISS protocol can be found here: http://www.ax25.net/kiss.aspx

**Choosing an APRS Program**

The aprs-is.net website has a list of some known APRS client software.

Looking over the list, I figured an older client would be the most likely to contain exploitable memory corruption vulnerabilities. Looking at the various options, I found that the WinAPRS download page said it hadn't been updated since January 14, 2013. I figured that was a good sign that the software was likely not maintained and would therefore contain vulnerabilities. I downloaded the latest version (2.9.0) and got to work.

**Next Steps**

The next post in this series will discuss the reverse engineering process using WinDbg. We’ll dive into the nitty gritty technical details of an exploitable memory corruption vulnerability in WinAPRS including how it was found and why it’s exploitable.

CVE-2022-24700: Hacking Ham Radio: WinAPRS – Part 1

An analysis of leaked chats from the notorious Conti ransomware group earlier this year has revealed that the syndicate has been working on a set of firmware attack techniques that could offer a path to accessing privileged code on compromised devices.
"Control over firmware gives attackers virtually unmatched powers both to directly cause damage and to enable other long-term strategic goals,"

An analysis of leaked chats from the notorious Conti ransomware group earlier this year has revealed that the syndicate has been working on a set of firmware attack techniques that could offer a path to accessing privileged code on compromised devices.

"Control over firmware gives attackers virtually unmatched powers both to directly cause damage and to enable other long-term strategic goals," firmware and hardware security firm Eclypsium said in a report shared with The Hacker News.

"Such level of access would allow an adversary to cause irreparable damage to a system or to establish ongoing persistence that is virtually invisible to the operating system."

Specifically, this includes attacks aimed at embedded microcontrollers such as the Intel Management Engine (ME), a privileged component that's part of the company's processor chipsets and which can completely bypass the operating system.

The conversations among the Conti members, which leaked after the group pledged its support to Russia in the latter's invasion of Ukraine, have shed light on the syndicate's attempts to mine for vulnerabilities related to ME firmware and BIOS write protection.

This entailed finding undocumented commands and vulnerabilities in the ME interface, achieving code execution in the ME to access and rewrite the SPI flash memory, and dropping System Management Mode (SMM)-level implants, which could be leveraged to even modify the kernel.

The research ultimately manifested in the form of a proof-of-concept (PoC) code in June 2021 that can gain SMM code execution by gaining control over the ME after obtaining initial access to the host by means of traditional vectors like phishing, malware, or a supply chain compromise, the leaked chats show.

"By shifting focus to Intel ME as well as targeting devices in which the BIOS is write protected, attackers could easily find far more available target devices," the researchers said.

That's not all. Control over the firmware could also be exploited to gain long-term persistence, evade security solutions, and cause irreparable system damage, enabling the threat actor to mount destructive attacks as witnessed during the Russo-Ukrainian war.

"The Conti leaks exposed a strategic shift that moves firmware attacks even further away from the prying eyes of traditional security tools," the researchers said.

"The shift to ME firmware gives attackers a far larger pool of potential victims to attack, and a new avenue to reaching the most privileged code and execution modes available on modern systems."

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

Conti Leaks Reveal Ransomware Gang's Interest in Firmware-based Attacks

Technique skirts web security controls

A security researcher has discovered a neat, albeit partially developed, technique to bypass CSP (Content Security Policy) controls using WordPress.

The hack, discovered by security researcher Paulos Yibelo, relies on abusing same origin method execution.

This technique uses JSON padding to call a function. That’s the sort of thing that might allow the compromise of a WordPress account but only with the addition of a cross-site scripting (XSS) exploit, which the researcher doesn’t have as yet.

Catch up with the latest WordPress related security news

Yibelo told The Daily Swig that they have not gone as far as attempting the trick on live sites, restricting exploits to a test research site they themselves owned.

“I haven’t really attempted to because it requires a logged in WordPress user or admin to visit my website, so I install the plugin and have a HTML injection – which is illegal to do,” Yibelo explained, adding they hadn’t attempted to exploit the bug in the wild on bug bounty sites either.

The researcher added that they reported it to WordPress three months ago via HackerOne. After failing to get a reply, Yibelo went public with the findings through a technical blog post.

**Endpoint endgame**

Attacks are potentially possible in two scenarios: 1) websites that don’t use WordPress directly but have an endpoint of WordPress on the same-domain or subdomain, and 2) a website hosted on WordPress with a CSP header.

The potential impact is severe, as Yibelo’s blog post explains:

If an attacker finds an HTML injection vulnerability within the main domain (ex: website1.com – not WordPress,) using this vulnerability, they can use a WordPress endpoint to upgrade a useless HTML Injection to a full blown XSS that can be escalated to perform \[remote code execution\] RCE. This means having WordPress anywhere on the site defeats the purpose of having a secure CSP.

The Daily Swig invited WordPress’s core development team to comment on the research. No word back, as yet, but we’ll update this story as and when we hear more.

Yibelo concluded: “I hope Wordpress fixes it so CSP stays relevant on sites that host a WordPress endpoint.”

Content Security Policy is a technology set by websites and used by browsers that can block external resources and prevent XSS attacks.

YOU MAY ALSO LIKE WordPress theme Jupiter patches critical security hole

Tag

#ios