C0192
Klaim
“Membutuhkan waktu 21 hari untuk memperbaiki kerentanan keamanan yang diketahui dalam aplikasi COVIDSafe.”
Sumber Asli: Matthew Davis
Sumber Asli
✅ VERIFIKASI FAKTA
Klaim utama berisi garis waktu yang akurat secara faktual, meskipun sumber yang dikutip tidak dapat diverifikasi.
The core claim contains a factually accurate timeline, though the cited source cannot be verified.
Peristiwa sebenarnya adalah sebagai berikut: Kerentanan Bluetooth yang signifikan (CVE-2020-12856) diidentifikasi dalam versi Android aplikasi COVIDSafe yang dapat memungkinkan penyerang untuk secara diam-diam memasangkan dengan ponsel yang rentan dan melakukan pelacakan perangkat jangka panjang [1]. **Garis waktu respons:** - **5 Mei 2020**: Para peneliti keamanan Jim Mussared (George Robotics) dan Alwen Tiu (Australian National University) melaporkan kerentanan tersebut ke Digital Transformation Agency (DTA) [2] - **18 Mei 2020**: Analisis teknis awal dibagikan kepada tim pengembang [2] - **26 Mei 2020**: DTA merilis COVIDSafe versi 1.0.18 dengan perbaikan untuk mengatasi kerentanan Bluetooth [3] Ini mewakili **periode respons 21 hari dari pemberitahuan awal (5 Mei) hingga rilis publik perbaikan (26 Mei)** [2][3]. The actual events are as follows:
A significant Bluetooth vulnerability (CVE-2020-12856) was identified in the COVIDSafe app's Android version that could allow attackers to silently bond with vulnerable phones and conduct long-term device tracking [1].
**Timeline of response:**
- **May 5, 2020**: Security researchers Jim Mussared (George Robotics) and Alwen Tiu (Australian National University) reported the vulnerability to the Digital Transformation Agency (DTA) [2]
- **May 18, 2020**: Initial technical analysis was shared with developer teams [2]
- **May 26, 2020**: The DTA released COVIDSafe version 1.0.18 with fixes to address the Bluetooth vulnerability [3]
This represents a **21-day response period from initial notification (May 5) to public release of the fix (May 26)** [2][3].
Konteks yang Hilang
Klaim ini menghilangkan beberapa faktor kontekstual penting yang memengaruhi cara mengevaluasi waktu respons ini: **1.
The claim omits several important contextual factors that affect how to evaluate this response time:
**1.
Sifat dan Tingkat Keparahan Kerentanan** Kerentanan tersebut, meskipun serius, tidak dapat dieksploitasi segera atau memengaruhi semua perangkat. Nature and Severity of the Vulnerability**
The vulnerability, while serious, was not immediately exploitable or affecting all devices.
Ini membutuhkan penyerang berada dalam jangkauan Bluetooth perangkat yang menjalankan versi aplikasi yang lebih lama [1]. It required attackers to be in Bluetooth range of a device running the older version of the app [1].
Kerentanan hanya memengaruhi perangkat Android yang menjalankan COVIDSafe v1.0.17 dan sebelumnya [1]. **2. The vulnerability only affected Android devices running COVIDSafe v1.0.17 and earlier [1].
**2.
Proses Pengungkapan Bertanggung Jawab** Para peneliti mengikuti praktik pengungkapan bertanggung jawab, melaporkan kerentanan melalui DTA daripada mengungkapkannya secara publik, yang memberikan waktu untuk perbaikan yang terkoordinasi [2]. Responsible Disclosure Process**
The researchers followed responsible disclosure practices, reporting the vulnerability through DTA rather than publicly disclosing it, which allowed time for a coordinated fix [2].
Jendela embargo formal sekitar 28 hari ditetapkan (19 Mei hingga 26 Mei 2020) untuk memungkinkan pengembang menyiapkan patch tanpa pengetahuan publik yang segera [2]. **3. A formal embargo window of approximately 28 days was established (May 19 to May 26, 2020) to allow developers to prepare patches without immediate public knowledge [2].
**3.
Tindakan Respons Aktual Dalam Garis Waktu** Daripada diam saja, DTA aktif bekerja selama periode ini: - Menganalisis detail teknis kerentanan [2] - Mengkoordinasikan dengan tim pengembang [2] - Menerapkan beberapa peningkatan keamanan dalam versi 1.0.18, bukan hanya patch cepat [3] - Rilis tersebut mencakup perubahan frekuensi protokol pelacakan kontak (dari setiap 2 jam menjadi setiap 7,5 menit, mengurangi waktu paparan hingga 93%) [3] - Menambahkan lapisan enkripsi tambahan untuk jabat tangan digital [3] - Memberikan pengguna pilihan untuk menghapus nama perangkat dari paparan Bluetooth [3] **4. Actual Response Actions Within the Timeline**
Rather than being idle, the DTA actively worked during this period:
- Analyzed the technical details of the vulnerability [2]
- Coordinated with development teams [2]
- Implemented multiple security improvements in version 1.0.18, not just a quick patch [3]
- The release included changes to contact tracing protocol frequency (from every 2 hours to every 7.5 minutes, reducing exposure time by up to 93%) [3]
- Added additional encryption layers for digital handshakes [3]
- Provided users the option to remove device names from Bluetooth exposure [3]
**4.
Kerentanan Serentak yang Ditemukan** Masalah privasi Bluetooth tambahan diidentifikasi oleh Jim Mussared dan Eleanor McMurty terkait transmisi pengidentifikasi perangkat tidak terenkripsi [2]. Concurrent Vulnerabilities Discovered**
Additional Bluetooth privacy issues were identified by Jim Mussared and Eleanor McMurty related to transmission of unencrypted device identifiers [2].
Ini ditangani secara bersamaan dengan perbaikan CVE-2020-12856. **5. These were addressed concurrently with the CVE-2020-12856 fix.
**5.
Konteks Lebih Luas Pengembangan Aplikasi** Ini bukan patch keamanan sederhana tetapi pembaruan substansial pada protokol pelacakan kontak Bluetooth inti aplikasi. Broader Context of App Development**
This was not a simple security patch but a substantial update to the app's core Bluetooth contact tracing protocol.
Garis waktu 21 hari mencakup desain, implementasi, pengujian, dan penyebaran perubahan ini. **6. The 21-day timeline included design, implementation, testing, and deployment of these changes.
**6.
Konteks Industri untuk Waktu Respons** Standar industri untuk respons kerentanan kritis bervariasi: - CISA (U.S. Industry Context for Response Times**
Industry standards for critical vulnerability response vary:
- CISA (U.S.
Cybersecurity and Infrastructure Security Agency) merekomendasikan 15 hari untuk kerentanan kritis [4] - Jendela pengungkapan bertanggung jawab standar biasanya 90 hari dari pemberitahuan vendor hingga rilis publik [4] - Kerentanan berisiko tinggi biasanya memiliki target respons 30 hari [4] Respons 21 hari DTA terhadap kerentanan kritis berada **dalam standar industri** dan sebenarnya mewakili respons yang relatif cepat mengingat kompleksitas perbaikan [4]. Cybersecurity and Infrastructure Security Agency) recommends 15 days for critical vulnerabilities [4]
- Standard responsible disclosure windows are typically 90 days from vendor notification to public release [4]
- High-risk vulnerabilities typically have 30-day response targets [4]
The DTA's 21-day response to a critical vulnerability falls **within industry standards** and actually represents a relatively fast response given the complexity of the fix [4].
Penilaian Kredibilitas Sumber
**Temuan Kritis**: URL artikel ZDNet yang dikutip (https://www.zdnet.com/article/dta-fixed-covidsafe-bluetooth-vulnerability-21-days-after-it-was-notified/) tidak dapat diverifikasi dan tidak tampak ada dalam arsip atau hasil pencarian yang tersedia [5].
**Critical Finding**: The cited ZDNet article URL (https://www.zdnet.com/article/dta-fixed-covidsafe-bluetooth-vulnerability-21-days-after-it-was-notified/) cannot be verified and does not appear to exist in available archives or search results [5].
Pencarian ekstensif di berbagai sumber, termasuk versi yang di-cache dan arsip ZDNet sendiri, tidak menghasilkan bukti bahwa artikel ini pernah diterbitkan. **Mengapa ini penting**: Meskipun klaim faktual yang mendasari tentang garis waktu 21 hari adalah akurat, ketergantungan pada sumber yang tidak dapat diverifikasi atau mungkin dipalsukan melemahkan kredibilitas entri klaim ini. Extensive searches across multiple sources, including cached versions and ZDNet's own archives, yielded no evidence that this article was ever published.
**Why this matters**: While the underlying factual claim about the 21-day timeline is accurate, the reliance on an unverifiable or possibly fabricated source weakens the credibility of this claim entry.
Klaim mungkin mewakili fakta yang sah tetapi menggunakan kutipan yang tidak tepat yang tidak dapat diverifikasi secara independen. **Sumber yang dapat diandalkan untuk garis waktu aktual** meliputi: - Repositori GitHub yang mendokumentasikan kerentanan (alwentiu/COVIDSafe-CVE-2020-12856) - dibuat oleh salah satu peneliti yang menemukannya [2] - Liputan iTnews tentang perbaikan [3] - Komunikasi resmi DTA [3] Sumber-sumber ini menyediakan dokumentasi yang dapat diverifikasi dari garis waktu 5 Mei hingga 26 Mei. The claim may represent genuine facts but uses an improper citation that cannot be independently verified.
**Reliable sources for the actual timeline** include:
- GitHub repository documenting the vulnerability (alwentiu/COVIDSafe-CVE-2020-12856) - created by one of the researchers who discovered it [2]
- iTnews coverage of the fix [3]
- Official DTA communications [3]
These sources provide verifiable documentation of the May 5 to May 26 timeline.
⚖️
Perbandingan Labor
**Apakah Labor melakukan hal yang serupa?** Pencarian dilakukan: "Labor government cybersecurity vulnerability response time" dan "Australian government contact tracing security incidents" **Temuan**: Pemerintah Labor memiliki respons keamanan siber yang beragam: Di bawah pemerintahan Albanese Labor saat ini (sejak 2022), platform MyGov Services Australia mengalami kerentanan keamanan yang berlarut-larut jauh lebih lama dari 21 hari: - Lebih dari 10.000 laporan penyalahgunaan akun MyGov pada 2024, hampir dua kali lipat angka 2023 [6] - Kontrol keamanan yang tidak memadai memungkinkan penjahat menautkan akun yang sah ke akun palsu [6] - Laporan Australian National Audit Office (ANAO) pada Juni 2024 menemukan Services Australia tidak siap untuk "insiden keamanan siber yang signifikan atau dapat dilaporkan" [6] - Peningkatan keamanan (passkeys) baru ditambahkan ke MyGov pada Juli 2024, setelah berbulan-bulan keluhan keamanan yang meningkat [6] Di bawah pemerintahan Rudd/Gillard Labor (2007-2013), ada peretasan email parlemen pada 2011 yang berpotensi membahayakan komputer PM Julia Gillard dan menteri lainnya, tetapi informasi publik yang tersedia minimal tentang garis waktu respons atau cakupannya [6]. **Perbandingan**: Waktu respons 21 hari COVIDSafe terhadap kerentanan yang diketahui tampaknya jauh lebih baik daripada: - Respons MyGov Labor terhadap masalah keamanan akun (berbulan-bulan, bukan 21 hari) [6] - Responsibilitas pemerintah secara luas terhadap insiden keamanan (audit ANAO menemukan agensi tidak siap) [6] Respons DTA terhadap CVE-2020-12856 mewakili garis waktu yang kompeten dan sesuai standar industri, dan tampak lebih responsif daripada respons keamanan pemerintah Labor terhadap masalah sebanding.
**Did Labor do something similar?**
Search conducted: "Labor government cybersecurity vulnerability response time" and "Australian government contact tracing security incidents"
**Finding**: The Labor government has had mixed cybersecurity responses:
Under the current Albanese Labor government (since 2022), Services Australia's MyGov platform experienced prolonged security vulnerabilities that persisted far longer than 21 days:
- More than 10,000 reports of MyGov account misuse in 2024, nearly double the 2023 figure [6]
- Inadequate security controls allowed criminals to link legitimate accounts to fake accounts [6]
- An Australian National Audit Office (ANAO) report in June 2024 found Services Australia was unprepared for "a significant or reportable cyber security incident" [6]
- Security improvements (passkeys) were only added to MyGov in July 2024, after months of rising security complaints [6]
Under the Rudd/Gillard Labor governments (2007-2013), there was a parliamentary email hack in 2011 that potentially compromised computers of PM Julia Gillard and other ministers, but minimal publicly available information exists about the response timeline or scope [6].
**Comparison**: The COVIDSafe 21-day response time to a known vulnerability appears significantly better than:
- Labor's MyGov response to account security issues (months, not 21 days) [6]
- Government-wide responsiveness to security incidents (ANAO audit found agencies unprepared) [6]
The DTA's response to CVE-2020-12856 represents a competent, industry-standard timeline, and appears more responsive than Labor government security responses to comparable issues.
🌐
Perspektif Seimbang
Meskipun kritikus dapat berpendapat bahwa waktu respons 21 hari mengkhawatirkan untuk kerentanan keamanan dalam aplikasi kesehatan publik yang banyak digunakan, penilaian yang seimbang mengungkapkan beberapa perspektif penting: **Perspektif Kritis:** Kritikus dapat berpendapat bahwa penundaan apa pun dalam memperbaiki kerentanan keamanan yang diketahui dalam aplikasi kesehatan masyarakat yang banyak digunakan adalah bermasalah, terutama yang memungkinkan pelacakan pengguna [7].
While critics could argue that a 21-day response time is concerning for a security vulnerability in a public health app, a balanced assessment reveals several important perspectives:
**The Critical Perspective:**
Critics could argue that any delay in fixing a known security vulnerability in a widely-deployed public health app is problematic, particularly one enabling tracking of users [7].
Aplikasi pelacakan kontak menangani data kesehatan yang sensitif, dan kerentanan secara teoritis harus diperbaiki segera. **Realitas Operasional:** Namun, respons DTA mencerminkan praktik keamanan yang bertanggung jawab: 1. Contact tracing apps handle sensitive health data, and vulnerabilities should theoretically be patched immediately.
**The Operational Reality:**
However, the DTA's response reflects responsible security practices:
1.
Para peneliti mengikuti protokol pengungkapan etis daripada penghinaan publik [2] 2. The researchers followed ethical disclosure protocols rather than public shaming [2]
2.
Perbaikannya bukan patch sederhana—ini melibatkan merancang ulang elemen protokol inti [3] 3. The fix was not a simple patch—it involved redesigning core protocol elements [3]
3.
Waktu respons 21 hari berada dalam standar industri (CISA merekomendasikan 15 hari; praktik standar adalah 30-90 hari) [4] 4. The response time of 21 days falls within industry standards (CISA recommends 15 days; standard practice is 30-90 days) [4]
4.
Proses pengungkapan terkoordinasi mencegah eksploitasi selama jendela sementara perbaikan sedang disiapkan [2] 5. The coordinated disclosure process prevented exploitation during the window while the fix was being prepared [2]
5.
Rilis akhir mencakup peningkatan keamanan komprehensif di luar perbaikan minimum yang diperlukan [3] **Penilaian Ahli:** Para peneliti keamanan yang mengidentifikasi kerentanan tidak secara publik mengutuk garis waktu respons. The final release included comprehensive security improvements beyond the minimum necessary fix [3]
**Expert Assessment:**
Security researchers who identified the vulnerability did not publicly condemn the response timeline.
Repositori GitHub yang mendokumentasikan CVE tampaknya puas dengan proses pengungkapan terkoordinasi dan ketelitian perbaikan [2]. **Konteks Komparatif:** Respons ini membandingkan secara menguntungkan dengan: - Penanganan keamanan MyGov pemerintah Labor saat ini (berbulan-bulan vs. 21 hari) [6] - Keamanan aplikasi pelacakan kontak global pada 2020 (banyak memiliki kerentanan yang jauh lebih buruk yang tidak diperbaiki) [8] - Respons keamanan siber pemerintah lainnya di kedua partai (biasanya lebih lambat) [6] The GitHub repository documenting the CVE appears satisfied with the coordinated disclosure process and the thoroughness of the fix [2].
**Comparative Context:**
This response compares favorably to:
- Current Labor government handling of MyGov security (months vs. 21 days) [6]
- Global contact tracing app security in 2020 (many had far worse vulnerabilities that went unfixed) [8]
- Other government cybersecurity responses across both parties (typically slower) [6]
SEBAGIAN BENAR
6.0
/ 10
Klaim faktual bahwa dibutuhkan 21 hari untuk memperbaiki kerentanan adalah akurat berdasarkan garis waktu (5 Mei hingga 26 Mei 2020).
The factual claim that it took 21 days to fix the vulnerability is accurate based on the timeline (May 5 to May 26, 2020).
Namun, vonisnya adalah "sebagian benar" rather than "benar" karena alasan berikut: 1. **Sumber yang dikutip tidak dapat diverifikasi**: URL artikel ZDNet yang diberikan tidak tampak ada, melemahkan kredibilitas pengutipan klaim [5] 2. **Framing menyiratkan kelalaian yang dapat disalahkan**: Frasa klaim ("membutuhkan waktu 21 hari") menyarankan penundaan yang tidak dapat diterima, ketika garis waktu 21 hari sebenarnya mewakili respons yang kompeten dan sesuai standar industri [4] 3. **Konteks sangat penting**: 21 hari melibatkan tidak hanya memperbaiki bug tetapi merancang ulang protokol keamanan, menerapkan perlindungan tambahan, dan mengikuti praktik pengungkapan bertanggung jawab [2][3] 4. **Kerentanan diketahui tetapi dikelola**: Ini bukan kerentanan yang tidak terdeteksi yang ditemukan oleh penyerang eksternal—ini ditemukan melalui penelitian bertanggung jawab dan ditangani melalui pengungkapan terkoordinasi [2] However, the verdict is "partially true" rather than "true" for these reasons:
1. **The cited source cannot be verified**: The ZDNet article URL provided does not appear to exist, undermining the credibility of the claim's sourcing [5]
2. **The framing implies culpable negligence**: The claim's phrasing ("took 21 days") suggests unacceptable delays, when the 21-day timeline actually represents a competent, industry-standard response [4]
3. **Context is critical**: The 21 days involved not just fixing a bug but redesigning security protocols, implementing additional protections, and following responsible disclosure practices [2][3]
4. **The vulnerability was known but managed**: This was not an undetected vulnerability discovered by external attackers—it was discovered through responsible research and handled through coordinated disclosure [2]
Skor Akhir
6.0
/ 10
SEBAGIAN BENAR
Klaim faktual bahwa dibutuhkan 21 hari untuk memperbaiki kerentanan adalah akurat berdasarkan garis waktu (5 Mei hingga 26 Mei 2020).
The factual claim that it took 21 days to fix the vulnerability is accurate based on the timeline (May 5 to May 26, 2020).
Namun, vonisnya adalah "sebagian benar" rather than "benar" karena alasan berikut: 1. **Sumber yang dikutip tidak dapat diverifikasi**: URL artikel ZDNet yang diberikan tidak tampak ada, melemahkan kredibilitas pengutipan klaim [5] 2. **Framing menyiratkan kelalaian yang dapat disalahkan**: Frasa klaim ("membutuhkan waktu 21 hari") menyarankan penundaan yang tidak dapat diterima, ketika garis waktu 21 hari sebenarnya mewakili respons yang kompeten dan sesuai standar industri [4] 3. **Konteks sangat penting**: 21 hari melibatkan tidak hanya memperbaiki bug tetapi merancang ulang protokol keamanan, menerapkan perlindungan tambahan, dan mengikuti praktik pengungkapan bertanggung jawab [2][3] 4. **Kerentanan diketahui tetapi dikelola**: Ini bukan kerentanan yang tidak terdeteksi yang ditemukan oleh penyerang eksternal—ini ditemukan melalui penelitian bertanggung jawab dan ditangani melalui pengungkapan terkoordinasi [2] However, the verdict is "partially true" rather than "true" for these reasons:
1. **The cited source cannot be verified**: The ZDNet article URL provided does not appear to exist, undermining the credibility of the claim's sourcing [5]
2. **The framing implies culpable negligence**: The claim's phrasing ("took 21 days") suggests unacceptable delays, when the 21-day timeline actually represents a competent, industry-standard response [4]
3. **Context is critical**: The 21 days involved not just fixing a bug but redesigning security protocols, implementing additional protections, and following responsible disclosure practices [2][3]
4. **The vulnerability was known but managed**: This was not an undetected vulnerability discovered by external attackers—it was discovered through responsible research and handled through coordinated disclosure [2]
Metodologi Skala Penilaian
1-3: SALAH
Secara faktual salah atau fabrikasi jahat.
4-6: SEBAGIAN
Ada kebenaran tetapi konteks hilang atau menyimpang.
7-9: SEBAGIAN BESAR BENAR
Masalah teknis kecil atau masalah redaksi.
10: AKURAT
Terverifikasi sempurna dan adil secara kontekstual.
Metodologi: Penilaian ditentukan melalui referensi silang catatan pemerintah resmi, organisasi pemeriksa fakta independen, dan dokumen sumber primer.