SSRF em parisneo/lollms-webui

A exploração bem-sucedida da SSRF em lollms-webui permite que um atacante utilize o servidor vulnerável como um proxy para acessar recursos internos ou externos que normalmente não seriam acessíveis. Ao enviar requisições maliciosas através da API /api/proxy com URLs como {"url":"http://steal.target"}, o atacante pode contornar controles de acesso e obter informações confidenciais. Isso pode incluir acesso a bancos de dados internos, serviços de nuvem ou outros sistemas protegidos por firewalls. A vulnerabilidade é agravada pelo fato de que as medidas de segurança existentes, como forbidremoteaccess e check_access, não são suficientes para mitigar o risco de SSRF.

Organizations deploying lollms-webui, particularly those exposing it to untrusted networks or using it to proxy requests to internal services, are at risk. Shared hosting environments where multiple users share the same server instance are also vulnerable, as an attacker could potentially exploit the vulnerability through another user's account.

• python / server:

import requests
import json

url = 'http://your_lollms_webui_ip/api/proxy'
headers = {'Content-Type': 'application/json'}
data = json.dumps({'url': 'http://127.0.0.1:8080'}) # Test URL

response = requests.post(url, headers=headers, data=data)

if response.status_code == 200:
    print("Potential SSRF detected.  Review response content.")
    print(response.text)
else:
    print("Request failed.")

• generic web:

curl -v -X POST 'http://your_lollms_webui_ip/api/proxy' -H 'Content-Type: application/json' -d '{"url":"http://127.0.0.1:8080"}'

• linux / server:

journalctl -u lollms-webui -f | grep "proxy request" # Look for suspicious URLs in logs

1. 2025-03-20Disclosure

   disclosure

1. Reservado2024-12-18
2. Publicada2025-03-20
3. EPSS atualizado2026-04-02

Enquanto a correção oficial está em desenvolvimento, algumas medidas paliativas podem ser implementadas para reduzir o risco de exploração. A primeira é desabilitar temporariamente a API /api/proxy se não for essencial para a funcionalidade do sistema. Em segundo lugar, implementar regras de firewall ou WAF (Web Application Firewall) para bloquear requisições com URLs suspeitas ou que apontem para recursos internos. É crucial monitorar os logs do servidor em busca de atividades incomuns, como requisições para URLs inesperadas. Após a aplicação da correção, verifique se a vulnerabilidade foi efetivamente eliminada tentando acessar um recurso interno através da API /api/proxy e confirmando que a requisição é bloqueada ou falha.