2 puan yazan GN⁺ 2025-09-28 | 1 yorum | WhatsApp'ta paylaş
  • Kaliforniya’da depozitonun 21 gün içinde iade edilmesi ve ön inceleme bildirimi yükümlülüğüne uyulmaması nedeniyle bir uyuşmazlık çıktı; kira sözleşmesinde ev sahibine ait bilgi bulunmadığı için önce aracı kurumla (International Executive Rentals) iletişim kurulan bir durum gelişti
  • Aracı kurum depozitoyu kendilerinin tutmadığını savunarak sözleşme kopyasını gönderdi; ancak bu belgede “depozito IER trust hesabında tutulur” ifadesiyle ek madde (Addendum) birbiriyle çeliştiği için şüphe doğdu
  • İmza platformu RightSignature tarafından eklenen doğrulama sayfasındaki checksum aynıydı; ancak PDF metadata analizinde değişiklik zamanı·ID etiketleri (ID0/ID1) farkı ve saat dilimi uyumsuzluğu tespit edilerek sonradan düzenleme izleri ortaya çıktı
  • PDF’in iç yapısı ayrıştırılıp karşılaştırıldığında, 3. sayfadaki touchUp_TextEdit etiketi ve font adlandırma kuralı değişikliği ile imza eklenirken kullanılan Courier fontunun adının değişmesi bulundu; böylece imzadan sonra düzenleme yapıldığını gösteren ipuçları elde edildi
  • Geliştirici araçlarıyla orijinal base.pdf ile “Original checksum” eşleşmesi doğrulandığında ek maddenin bulunmadığı görüldü; ekran paylaşımı sırasında da yükleme tarihi ile Draft/Completed olarak iki ayrı kayıt ortaya çıkarak manipülasyon olasılığına güçlü işaretler sundu

Olayın arka planı ve hukuki bağlam

  • Kısa süreli kiralama olmasına rağmen Kaliforniya’daki kiracı koruma mevzuatı gereği depozitonun iade süresi 21 gün ve taşınma öncesi inceleme bildirimi yükümlülüğü bulunuyor
    • Depozitonun saklanması ve iadesinden sorumlu taraf ev sahibi; aracı kurumun hukuki sorumluluğu yok
    • Sözleşmede ev sahibinin adı ve adresi eksik olduğu için tebligatın aracı kurum üzerinden yapılabildiği bir durum oluştu
  • Aracı kurum temsilcisi “depozitoyu biz tutmuyoruz” diyen bir e-posta gönderdi; ancak ekli sözleşmede IER’nin tuttuğunu belirten ifade ile Addendum’daki ‘ev sahibi tutar’ ifadesi birlikte yer alarak çelişti

Sorunlu belge ve çelişen hükümler

  • Ana metindeki hüküm: “Güvence (depozito)… IER Trust Account’ta tutulur” şeklinde kurum tarafından saklama ifadesi yer alıyor
  • Sayfa altındaki onay kutusu alanı: Addendum 1 içinde “depozito ev sahibi tarafından tutulur” ifadesi işaretlenmiş durumda
    • Yazarın elindeki kopyada Addendum 1 boş, aracı kurumun kopyasında ise işaretlenmiş ve doldurulmuş durumda

Adli inceleme 1: PDF metadata karşılaştırması

  • Araç: pdftk dump_data ile CreationDate/ModDate ve ID0/ID1 çıkarıldı
    • Yazarın kopyası: oluşturma ve değişiklik zamanı aynı, UTC, ID0=ID1
    • Aracı kurum kopyası: oluşturma zamanı aynı, ancak değişiklik zamanı son pazartesi, PDT gösterimi var, ID0 aynı·ID1 farklı
  • Yorum: ID0 ilk oluşturma sırasında verilir ve değişmez; ID1 ise düzenleme olduğunda değişme eğilimindedir. Bu da aynı orijinal dosya üzerinde sonradan değişiklik yapıldığı ihtimalini destekliyor

Adli inceleme 2: Sayfa bazında yapı karşılaştırması

  • Araç: pdfalyzer ile nesne ayrıştırma ve diff karşılaştırması yapıldı
    • Farklar yalnızca 3. sayfada yoğunlaşıyor, diğer sayfaların yapısı aynı
      1. sayfada touchUp_TextEdit etiketi bulunması, Acrobat ile düzenleme izi olarak değerlendirildi
  • Olası karşı argüman: Bunun ev sahibi adını eklemek gibi imza öncesi bir düzenleme olması da mümkün; bu nedenle ek ve daha belirleyici kanıt gerekti

Adli inceleme 3: Font adlandırma kuralları ve imza zamanının izlenmesi

  • Çoğu sayfadaki fontlar tutarlı bir adlandırma kuralını izlerken, sorunlu 3. sayfa Acrobat tarzında yeniden adlandırılmış görünüyor
  • RightSignature’ın imza tamamlandığında eklediği Courier fontu belgenin genelinde aynı adla yer alıyor; ancak yalnızca 3. sayfada farklı kuralla yazılmış
    • Courier sadece imzadan sonra var olduğundan, 3. sayfadaki bu yeniden adlandırma imzadan sonra düzenleme anlamına geliyor

Adli inceleme 4: İmza öncesi orijinal dosyanın elde edilmesi

  • RightSignature viewer network sekmesinde (F12) base.pdf dosyası bulunup indirildi
    • sha256sum, doğrulama sayfasındaki Original checksum ile tam olarak eşleşti; bu orijinal dosyada Addendum yoktu
  • Sonuç niteliğinde kanıt: Doğrulama sayfasının tasarımı bağımsız doğrulamaya uygun olmasa da, platform içindeki orijinal dosya ile checksum eşleştirmesi sayesinde ek maddenin orijinal belgede yer almadığı kanıtlandı

Aracı kurumun iddiası ve ek bulgular

  • Aracı kurum: “RightSignature her indirmede yeniden mühürlediği için düzenlenmiş gibi görünüyor” iddiasını öne sürdü
    • Ancak metadata’daki saat dilimi·ID1 değişimi, yalnızca 3. sayfaya özgü yapısal farklar ve imza sonrası font adlandırma değişikliği bu iddiayla uyumlu değil
  • Ekran paylaşımı sırasında görülenler: “Uploaded: 09/22/25”, Send for signature düğmesi, Draft/Completed olarak iki ayrı kayıt
    • Completed belgesinde Addendum yok, Draft belgede ise Addendum var izlenimi doğrulandı

Tahmini motivasyon ve risk

  • Tahmin: Aracı kurumun “IER tutar” ifadesi nedeniyle depozito iadesi sorumluluğu doğabileceğini fark ettikten sonra, sonradan Addendum eklemeye çalışmış olabileceği düşünülüyor
    • Sonuçta sivil hukukta küçük ölçekli potansiyel sorumluluktan kaçmaya çalışırken belge sahteciliği şüphesi yaratma riski ortaya çıkmış olabilir
    • Nihai hukuki sorumluluk ev sahibinde olsa bile, belgeyi manipüle etme eylemi ayrı bir hukuki risk doğurabilir

Pratik çıkarımlar ve müdahale ipuçları

  • Elektronik imza platformu kullanılırken, imzadan hemen sonra orijinal base.pdf dosyasını ve checksum’ı çevrimdışı saklama ihtiyacı artıyor
  • PDF adli inceleme noktaları
    • Creation/Modification zaman damgalarının saat dilimi ve senkron durumunu kontrol edin
    • ID0/ID1 karşılaştırmasıyla değişiklik geçmişi tahmini yapın
    • Sayfa bazlı nesne diff’i, düzenleme etiketleri (touchUp_TextEdit) ve font adlandırma kuralı değişikliklerini tespit edin
  • “Platform yeniden mühürlüyor” iddiasına karşı platform orijinali ile doğrulama checksum’ını çapraz doğrulamak mümkün
    • Geliştirici araçlarındaki network sekmesi üzerinden imza öncesi orijinal dosyayı elde etmek belirleyici olabilir

1 yorum

 
GN⁺ 2025-09-28
Hacker News görüşleri
  • California'daki High Technology Theft Apprehension and Prosecution Program, FBI'ın Internet Crime Complaint Center'ı ve San Francisco'nun Financial Crimes Unit'i gibi kurumlara başvurulması öneriliyor; RightSignature Citrix tarafından satın alındığı için Citrix'e de bildirmeyi düşünmek mantıklı olabilir. Olayın maddi unsurları açık biçimde lehinize göründüğünden, avukatlık masrafı olmadan da başarılı olma ihtimali yüksek ve ayrıca tazminat talep etmek de mümkün olabilir (High Technology Theft Apprehension and Prosecution Program, Internet Crime Complaint Center, Financial Crimes Unit, Citrix satın alımıyla ilgili haber, Citrix GC bilgisi)

    • Bunun ceza davası olma ihtimali yüksek; cezalandırma sürecini doğrudan devlet yürütecektir ve ayrıca hukuk davası da açılabilir. Bir avukat tutarsanız biraz zaman alabilir ama ek bir maliyet olmadan da gayet makul bir tazminat alma şansınız vardır; cezalandırma açısından da anlamlı olur.

    • Böyle bir şey bir kişinin başına geldiyse muhtemelen daha birçok kişiye de olmuştur; yeterince araştırılırsa toplu dava da mümkün olabilir diye düşünüyorum.

  • Bu yüzden önemli belgeler üç nüsha hazırlanmalı — her taraf için birer tane ve noter de üçüncü kopyayı saklamalı. Belge imzalama hizmetleri bu rolü üstlenir; çok nadiren de olsa kimin gerçek kopyaya sahip olduğuna dair tanıklık etmek gerekebilir. Ben benzer bir şirkette çalışırken yalnızca 1 imza ihtilafı vakası duydum, içerik ihtilafı ise hiç olmadı. Hash'in nasıl çalıştığı bana açık olsa da bir hâkim teknik detayları anlamayabilir; sonuçta şirketin resmî bir pozisyon açıklaması yapması gerekir.

    • Üç nüsha geleneği en az 14. yüzyıldaki indenture sözleşmelerine kadar uzanıyor. “Indenture” sözcüğü, diş gibi zikzaklı kesimden geliyor; belge elde üç kez yazılır, hepsi birlikte imzalanır ve sonra kesilirdi. Bu hem çoğaltmayı zorlaştırır hem de ortada büyük Latin harfleri kullanılarak sahteciliği güçleştirirdi. İki kopya uyuşmuyorsa birisi yalan söylüyor demektir; üçüncü kopya da noterde saklanarak kimin doğru söylediği belirlenirdi. Indentured servant sözleşmeleri de bu yöntemle yapılırdı.

    • RightSignature'ın ucuz, self-host edilen bir hizmet değil de pahalı bir SaaS hizmeti olmasının nedeni tam da bu: kimin hangi sürümü imzaladığına dair tanıklık edebilecek üçüncü tarafı sağlamak.

    • Üç nüsha uygulamasına dair açıklamayı ancak şimdi duyuyorum; uzun süredir bunun ne olduğunu merak ediyordum ama bakmaya fırsat bulamamıştım.

  • Daha önce Gwern'in insanların bunu neden daha sık denemediğini sorguladığı yazıyı hatırladım (Gwern blogu: PDF sahteciliği üzerine düşünceler)

    • Bence OP'nin bu vakası o sorunun cevabı niteliğinde. Bir doğrulama hizmeti üzerinden sahtecilik yapılmış olması sarsıcı ve bu durumu düzgün biçimde inceleyip kanıtlamak için yazılım ve adli bilişim konusunda çok yetkin birinin sayısız doğrulama adımından geçmesi gerekiyor. Üstelik hâlâ bir uzlaşma ya da mahkûmiyet de yok. Craig Wright vakasında olduğu gibi basit düzenleme ve geriye tarih atma işlemleri bile çok ciddi uzman adli incelemesi gerektiriyor; buna karşılık orijinal PDF'i değiştirmek bir aceminin 5 dakikada yapabileceği bir şey.

    • Gwern'in odaklandığı şey muhtemelen akademik makale PDF'leri gibi herkese açık belgelerin sahteciliğiydi. Bu durumda büsbütün yeni bir PDF üretip orijinalle karşılaştırma imkânını ortadan kaldırmak daha iyi olabilir; ama hukukî delil niteliğindeki resmî belgelerde fark edilmemek için mümkün olduğunca orijinalin aynısını üretmek gerekir. Yine de böyle belgeler genelde internette açık olmaz.

    • “Neden PDF için Photoshop yok?” sorusunun yanıtlarından biri Xournal++.

  • Ben de yakın zamanda benzer bir şey yaşadım. Portekiz'de 1 yıl kaldım ve emlakçı elektrik-su faturalarını değiştirip bana sahte PDF verdi. PDF metadata'sından sahteciliği fark ettim ama daha ileri gitmedim, sadece paramı geri aldım. Metadata'nın da kolayca üzerine yazılabildiğini öğrenmiş oldum. Böyle durumlarda güvenli biçimde nasıl korunulabileceğini merak ediyorum.

    • Dijital imzalı elektronik faturalar bir çözüm olabilir. Örneğin Fransa'daki Factur-X (Almanya'daki adıyla ZUGFeRD), imzalı XML verisini PDF içine gömüyor. Böylece faturayı gerçekten ilgili düzenleyicinin oluşturup oluşturmadığını kolayca doğrulamak mümkün oluyor. Avrupa'da birçok ülke KDV işlemleri için bu sistemi uygulamaya alıyor ve makine tarafından okunabilen imza verisi, kâğıt belgelere göre çok daha güvenilir. Bir başka önlem de bu tür vakaları bildirip ilgili kişilerin dolandırıcılıktan cezalandırılmasını sağlamak.

    • Avukatlar bunun cevabını yüzyıllardır biliyordu: tüm belgeler birden fazla nüsha halinde hazırlanmalı ve imza anında taraflarca ayrı ayrı saklanmalı. Ben de sözleşmeleri iki nüsha alıyorum; iki taraf da ikisini imzalıyor ve herkes kendi nüshasını saklıyor. Değişiklik olduğunda da aynı şey geçerli. Herkes kendi kopyasını özenle muhafaza ediyor. Bunun dijital süreçte de uygulanması gerekiyor.

  • Böyle bir durumda, sahte belge kullanarak dolandırıcılık yapıldığı için dava açılması gerekiyormuş gibi geliyor. Sizde işe yaramamış olsa bile aynı yöntemle birçok başka mağdur ortaya çıkmış olabilir.

    • Diğer kiracılar için savaşmak istemiyorsanız, dava açmakla sadece “tehdit” etmeniz bile yeterli olabilir. Bu, emlakçıyı ev sahibinin bilgilerini vermeye ya da depozitoyu iade etmeye itebilir.

    • Nihai hedef, iade edilmesi gereken depozito ya da wire-fraud (ceza hukuku kapsamında dolandırıcılık) nedeniyle hukukî tazminat olmalı.

  • RightSignature sitesinde açık kanıtlar duruyor gibi görünüyor ama site ortadan kalksa bile belgenin gerçekliğini doğrulamanın bir yolu olmalı. Şu anda sunulan doğrulama sayfası, site olmazsa işe yaramaz hale geliyor.

    • Bunun zor görünmesinin nedeni, doğrulama sayfası PDF'in içinde yer alsa da kendi hash'ini ya da imzasını içine koyamaması. Yalnızca hash kullanmak da yetmez; dosya değiştirilirken hash de değiştirilebilir. Açık biçimde imzalanmış payload'ın çıkarılabilmesi gerekiyor ama RightSignature kriptografik temelli bir tasarım değil, baştan aşağı yeniden tasarlanması gerekir.

    • PDF'in kendisi imza doğrulama özelliğini destekliyor ve Adobe Reader da bunu tanıyor. DocuSign bu yöntemi kullanıyor ve imzalı sürüm doğrudan Reader içinde görülebiliyor (Adobe imza belge kılavuzu, imza önizleme örneği: Adobe Reader örneği)

  • Emlak aracılık şirketiyle ilgili nasıl sonuçlandığını gerçekten çok merak ediyorum.

    • Henüz hiçbir şey olmadı. Emlakla ilgili resmî kuruma resmî şikâyette bulunma sürecindeyim ve aracılık şirketinden ek bir yanıt da almadım.
  • sha256 çarpışmasını kasıtlı olarak üretmenin pratikte imkânsız olduğunu düşünüyorum. SHAttered bile SHA-1 için 110 yıllık GPU gücü gerektirmişti. Acaba RightSignature tarafında yanlış belge yanlışlıkla yüklenmiş olabilir mi; örneğin yanlış dosya seçilmiş ya da yanlışlıkla farklı sürüm yüklenip sonra karıştırılmış olabilir gibi geliyor.

    • OP yazıda açıkça belirtiyor ki söz konusu taslak çok daha sonra yüklenmiş, dolayısıyla bunun basit bir karışıklık olması mümkün değil. Eğer bilerek yeni sürüm yükledilerse, zaten imzalanmış kira sözleşmesi tamamlandıktan sonra değiştirilmiş sürümü yeniden yüklemekte nasıl bir mantıklı amaç olabilir, anlamıyorum.

    • Gerçekte imza için kullanılan hash, orijinal belgeyle eşleşiyor (kiracı imzası ve dolandırıcılık amaçlı ek madde içermeyen sürümle). Bunun dışındaki başka hiçbir sürümle hash tutmuyor.

  • Bu aşamada aracılık şirketinin önünde iki seçenek var: (A) depozitoyu derhal kendisi iade eder ve eğer aracı sadece iletici konumundaysa bunu sonra ev sahibinden tahsil etmeye çalışır; (B) ev sahibinin tüm bilgilerini verir ve yasal iadenin açık biçimde talep edilmesini sağlar. PDF sahteciliği meselesi ve şirketle yaşanan çekişme ilginç olabilir ama asıl amaç depozitonun geri alınması.

  • Girmeye çalıştım ama 403 hatası alıyorum (web archive bağlantısı)

    • Bende olmadı