171 entry daha
  • yeni bir şey değil.
    ilgili data'ya 2010 yılında sahip olan kişi/kişiler olduğunu düşünmekteyim. bununla ilgili sağlama yakın delillerim de mevcuttur. ve entry'min en altında anlatacağım.

    bir bilgi güvenliği uzmanı olarak başlık görür görmez ilgimi çekti. dosyaları amazon üzerinde basitçe kurduğum bir windows server'a 20 mb/sec gibi bir download hızı ile dakikalar içerisinde indirdim. içeriğini incelediğimde; *.myd, *.frm gibi mysql'e ait olduğu aşikar ve tecrübeyle sabit olan bir data-folder olduğunu farkettim. bir mysql-server kurup gerekli ayarları yaptıktan sonra programı çalıştırdım ve diğer yazar arkadaşların da söylediği gibi ailemi, yedi ceddimi sorgulayabildim. yani ele geçirilen data her nerenin datası olursa olsun, kıymetli bir data. hem de executable bir programla sunulmakta. program yiğit dalkıran isminde, hakkında pek bilgi bulamadığım bir yazılımcı arkadaş tarafından kodlanmış.

    altyapı şu şekilde
    programlama dili: delphi 7
    db component: zeoslib
    veritabanı: mysql

    veritabanını direkt olarak görüntülemek istediğinizde sadece encrypt edilmiş datalar bulunmaktadır.
    "rndgg4fl3,rnd70uwqp,rndpov6bq,rndy5ym2w,rndu0xfy2" gibi kolon adları mevcut örneğin.

    bu da demek oluyor ki, direkt veritabanına erişmek, datalara erişmek anlamını taşımıyor. yani bu sorgu.exe adındaki programcık olmadan, dataları decrypt etmek çok çok uzun zaman alacaktır ve imkansıza yakındır. e bu program dataları okuyabiliyorsa, encrypt/decrypt edilirken kullanılan salt/hash içinde store edilmek zorunda. bu yüzden "dede" ismindeki delphi debugger'ı indirip, biraz reverse engineering işlerine giriştim.

    aslında programda bir login promt da var; ya ele geçiren saldırgan ya da programı yazan arkadaş bunu disable etmiş. yani direkt access sağlamış ve app'i geri compile etmiş, executable halde sunmuş.

    kodlardan two-way-encryption için gereken hash/salt'ı (anahtar kod) bulabilmek için birazcık gezindim; sonra gitgide daha ilginç şeyler görmeye başladım.

    ilgili veritabanı normal şartlarda lokal'de çalışmıyormuş. yani bu programcık egm, mernis vs her nerede kullanılıyorsa; her bir bilgisayara mysql server kurup üstünde 18 gb'a yakın bir veritabanı koşturmanın hiçbir mantığı da olmadığı aşikar. veritabanı'nın remote'da koşması da son derece normal ama; anormal olan kısım veritabanının koştuğu sunucunun devletin kendi ıp adresleri üzerinde değil, çizgi telekom'a (bilinen adı ile natro) ait 89.19.19.xxx ip adresli sunucuda koşmakta. burada akla önemli bir soru geliyor. bu programı ve ilgili altyapıyı kullanan kurum, nasıl olur da 70 milyon vatandaşının bilgilerini üçüncü parti bir ticari hosting firmasının sunucularında barındırır? zaten çok büyük olasılıkla bu datalar, şu anda ping almayan, down durumda olan ilgili ip'deki sunucudan çalınmıştır. (bu arada konunun çizgi telekom ile zerre alakası yoktur, onlara karşı herhangi bir suçlamam veya imam bulunmamaktadır.)

    yazacaklarımın ayyıldız tim isimli oluşumun 16 şubat 2016 ayyıldız tim'in anonymous'a cevabı başlığında verdiği cevapla kesişen noktaları olsa da, açıklamanın bazı noktalarına katılmamaktayım.

    kesişen noktam şu; bu mevzu bugünün işi değil. öyle ki 21.01.2016 tarihinde şurası üzerinden bir virus scan talebinde bulunulmuş. lakin hala olayın bu kadar yeni olmadığını düşündüğümden biraz daha araştırdım; ne göreyim. vaktinde, bir yazılımcı arkadaş bu datalara bi şekilde erişmiş ve nasıl decrypt edeceğine dair bir foruma soru sormuş: şifrelenmiş sql içeriğini çözmek.

    arkadaşımız dosyalara ulaşmış, lokaline kurduğu sql sunucuda her query'i loglayarak, kendisi için arattığı "sertçelik" soyadının encrypt edilmiş halini dahi paylaşmış sorusunda. üstelik diğer bir ayrıntı ise datanın 18 gb büyüklüğünde olduğu, mevcut data da 18 gb büyüklüğünde. ayrıca ilgili linkte verilen query örneğinde "and (1=1)" cümlesi de bulunmakta. mevcut yazılımda da query bu şekilde gönderilmektedir yani her şey örtüşüyor.

    bu durumda 15 temmuz 2010 tarihinde bazı kişi veya kişilerin bu dosyalara erişimi varmış.

    buraya kadar gelmişken "and (1=1)" gibi "always true" dönen bir statement'ın her sorguda kullanılması karşısındaki düştüğüm çaresizliği anlatamam. bunları gördükçe insan reverse engineering'den soğuyor.

    bu tarz konuların hukuki ve vicdani sorumluluğunun yüksek olduğunu düşündüğümden, araştırmama burada son verdim ve reverse engineering yapmayı siktirettim. veritabanını sildim. sunucuyu yaktım.

    üç beş yıl önce, ankara'da coğrafi bilgi sistemleri, e-devlet projesi ile ilgili bir forumda konuşmacı olarak yer almıştım. konuşmam gereken konu bu tarz hassas çalışmalar yapılırken ne tarz güvenlik önlemleri alınması gerektiği üzerineydi... derince bir giriş yaptım konuya man-in-the middle'lar falan; sonra aklıma geldi sordum: "bilgisayarlarınıza herhangi bir üçüncü parti donanım bağlayabiliyor musunuz (flash disk vs)?". cevabı evet idi. ondan sonra güvenlik ile ilgili bir konuşma yapmak anlamsız olacaktı; hep beraber tse adına katılan bayanın sertifikasyon başarı hikayelerini dinledik...

    herhangi bir ifşa veya veri açığa çıkarma olmadığı için, anlattıklarımın kanıtı anlamında aşağıdaki ekran görüntülerini bilginize sunarım.

    encrypted halde veritabanı
    decompile edilmiş halde sorgu.exe

    dip not: hemen herkes olaya çok basit yaklaşmış. aslında böyle olmamalı... örneğin şu an maksimum bir saat ayırarak bir web sitesi hazırlayabilirim veya hazırlayabilecek bir sürü insan tanıyorum. ve herkes istediği sorgulamayı hazırlanacak olan bu web arayüzü üzerinden yapabilir. tüm ülkenin tüm bilgileri açığa çıkar. saçmalık. kişisel bilgilerimiz bu kadar aleni olmamalı. bu verilerin çalınmasından sorumlu olan her kimse, umarım en yakın zamanda yakalanır ve cezasını çeker. gerçi internet dünyası, biliyorsunuz "abur cubur" her şey yükleniyor. yok etmesi de mümkün değil. bu işin içinden nasıl çıkılacak bilmiyorum. kişisel olarak bu durumdan gerçekten çok üzgünüm.
30 entry daha
hesabın var mı? giriş yap