← Tüm Sorulara Dön

Ransomware e-defter XML'lerini şifrelediğinde, berat dosyalarından hash doğrulaması yaparak kurtarma şansımız var mı?

Muhasebe sunucumuzdaki e-defter klasörümüz şifrelendi; elimizde hem mükellef mali mührü hem de GİB zaman damgasıyla imzalanmış olan orijinal berat dosyaları (...-Y-000000.xml ve ...-K-000000.xml) sağlam olarak duruyor. Veritabanımızdan ilgili dönemin yevmiye ve kebir muhasebe kayıtlarını SQL dump olarak çekip yeniden e-defter XML'i oluşturabiliyoruz. Ancak yeniden oluşturulan bu XML dosyalarının GİB'deki berat ile eşleşip eşleşmediğini nasıl doğrularız? Berat içerisindeki hash değerinden yola çıkarak şifrelenen XML'i doğrudan çözmek (reverse/decrypt) kriptografik olarak mümkün müdür; değilse yeniden oluşturulan XML'in berat hash'i ile birebir tutması için adli bilişim ve yazılım mimarisi açısından hangi adımlar atılmalıdır?

Durum: Çözüldü Kategori: Soru-Cevap

2 Cevap

✓

Muhasebe sunucusu ransomware ile şifrelendiğinde, mükelleflerin en sık başvurduğu varsayım berat dosyasından yola çıkarak şifrelenmiş XML'i kurtarmak veya veritabanından tekrar XML üreterek eski beratla birleştirmektir. Ancak bu süreçte hem kriptografik sınırların hem de XML dijital imza standartlarının çok iyi anlaşılması gerekir.

1. Berat Dosyasından Şifreli XML Geri Döndürülebilir mi? (Kriptografik İmkansızlık):

Berat dosyasında tutulan veri, şifrelenmiş bir metin değil; tek yönlü kriptografik özet fonksiyonu olan SHA-256 (Secure Hash Algorithm 256-bit) çıktısıdır. Kriptografinin temel prensibi gereği, tek yönlü özet fonksiyonları (one-way hash) matematiksel olarak geri döndürülemez (pre-image resistance). Berat içerisindeki 64 karakterlik onaltılık (hex) veya Base64 kodlanmış DigestValue verisinden hareketle şifrelenmiş orijinal e-defter XML dosyasını tersine mühendislikle (reverse engineering / decrypt) elde etmek kesinlikle imkansızdır.

2. Berat İçerisindeki Hash Alanı ve XMLDSig Mimarisi:

GİB e-defter beratları, W3C XML Signature (XMLDSig) ve ETSI XAdES standartlarına uygun olarak üretilir. Berat dosyasını bir metin düzenleyici ile açtığınızda şu imza bloğunu görürsünüz:

<ds:Reference URI="1234567890-202601-Y-000000.xml">
  <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
  <ds:DigestValue>dGhpcyBpcyBhIHZhbGlkIHNoYTI1NiBoYXNo...</ds:DigestValue>
</ds:Reference>

Buradaki <ds:DigestValue>, ana defter dosyasının kanonikleştirilmiş (C14N) veya ham halinin SHA-256 özetidir. Beratın kendisi de TÜBİTAK KamuSM Kamu Sertifikasyon Merkezi zaman damgası ve GİB mali mührü ile imzalanmıştır.

3. Veritabanından Yeniden Üretimde 'Hash Uyuşmazlığı' Çıkmazı:

Muhasebe veritabanından (SQL) aynı yevmiye kayıtları çekilerek e-defter XML'i yeniden üretildiğinde, hash değerinin eski berattaki değerle tutma ihtimali pratikte son derece düşüktür. Kriptografideki çığ etkisi (avalanche effect) sebebiyle girdi verisindeki tek bir bitlik fark bile SHA-256 özetini tamamen değiştirir:

XML Biçimlendirme ve Boşluklar: XML etiketleri arasındaki boşluklar, satır sonu karakterleri (Windows CRLF vs Unix LF), UTF-8 BOM varlığı veya yokluğu hash'i bozar.
Kanonikleştirme (C14N - Canonical XML): İmzalamada kullanılan Canonicalization algoritması (http://www.w3.org/TR/2001/REC-xml-c14n-20010315) attribute sıralamasını ve namespace bildirimlerini normalize eder. Yazılımın kullandığı kütüphane versiyonu değişmişse C14N çıktısı farklılaşır.
Oluşturulma Zaman Damgası: XML başlığında yer alan CreationDate veya muhasebe yazılımının eklediği metadata saat/dakika bilgisi farklı olacağından özet tutmayacaktır.

4. Hash Doğrulama Prosedürü ve Yasal Aksiyon:

Yeniden üretilen XML dosyasının hash'ini doğrulamak için komut satırından:

certutil -hashfile yeni_defter.xml SHA256 veya Linux ortamında sha256sum yeni_defter.xml komutları çalıştırılır ve çıktı Base64 formatına çevrilerek berattaki DigestValue ile kıyaslanır. Eğer değerler uyuşuyorsa mükemmel bir kurtarma sağlanmıştır. Ancak uyuşmuyorsa, defter gayriyasal hale gelir; bu durumda hiçbir şekilde sahte eşleştirme yapılmamalı, GİB e-Defter Şube Müdürlüğü'ne 'Berat İptal ve Yeniden Berat Gönderim Talebi' ile resmi başvuru yapılmalıdır.

Yanıtlayan

SOC Analisti Berke K.

Adli bilişim ve yazılım mühendisliği ekiplerinin hash uyuşmazlığını aşmak için uygulayabileceği teknik inceleme adımları:

Orijinal Muhasebe Yazılımı ve XSD Sürümünün Tespiti: Defteri ilk üreten muhasebe yazılımının majör ve minör versiyonu (build number), kullanılan XML şeması (XSD) ve TÜBİTAK KamuSM MA3 API kütüphanesi birebir aynı ortamda (aynı Java Runtime Environment sürümünde) çalıştırılmalıdır.
Kayıt İçi Tarih ve Sıralama Analizi: SQL tablosundan kayıtlar çekilirken ORDER BY YevmiyeNo, KayitTarihi sıralamasının orijinal e-defterdeki sıralama ile birebir aynı olması sağlanmalıdır. Kuruş hanelerindeki yuvarlama (rounding) formatı orijinal defter kurallarına göre normalize edilmelidir.

Yanıtlayan

Kıdemli Güvenlik Mimarı T.