I found following vulnerabilities on the Airtame Device (Before Version 3)

1. Session Fixation (CVE-2017-15304)
2. Updating Firmware via HTTP
3. Using Weak Cryptographic Hash Function For File Integrity
4. Using Weak Cryptographic Hash Function For Storing Passwords
5. Using Hardcoded Credentials

Problem 1, 4, 5 are gone since they removed their Php web panel. It’s not possible for me to retest the problem 2 and 3 since I don’t have the device anymore. Since 2,5 months have passed from initial report submission, I don’t think it’s an ethical issue to share them publicly.

Introduction

In July, I got an Airtame Device and decided to test it. First of all, let me introduce the Airtame:

“Airtame is an enterprise-grade wireless HDMI solution for offices, meeting rooms and classrooms. Users can share content from their laptop or mobile device to one or more screens. Airtame’s digital signage capabilities will also help in utilizing screens by showing relevant information when nobody’s using those screens.” – https://help.airtame.com/general/faqs/what-is-airtame-including-video

After initial setup, I noticed that it has a web panel for device configuration. I did my blackbox test on this panel.

I was also capturing the traffic while I was digging the functionalities on the panel. I noticed that it updates it’s firmware from this URL: http://repos-cdn.airtame.com/firmware/beta/

This URL doesn’t require any authentication and provides the firmware of all versions. I also reported this URL to Airtame team but they said that page is publicly available on purpose, so I can share it with you.

After I downloaded latest.tar.gz file from here, I noticed that it’s an img file. I mounted it to see what is inside (Following screenshot shows firmware version 3 but this article is about version 2.3, don’t get confused)

mount -o loop,offset=159383552 airtame-fw-v3.0.0-b6.img /mnt/disk3

After then, it was possible to check the source code of Php web panel. I found following vulnerabilities during my test.

Session Fixation (CVE-2017-15304)

This vulnerability occurs in login functionality in the Web Panel. It’s possible to set our own cookie by editing “PHPSESSID” header in the POST request of the login action. Following screenshot shows our login request. Note that PHPSESSID value is changed to “a”:

Application accepts this value and sets it as our session id. Following screenshot shows the response to the request above.

To prove that our valid session id is “a”, I changed PHPSESSID value to something else and navigated to /bin/get_config.php which requires login. Application denied our request since the PHPSESSID wasn’t valid.

Now, I changed back it to “a” again to prove that this is the valid session id. Application accepts that value.

The important point is, this session id is not invalidated via logout functionality. So if attacker knows the correct admin password, he can set a custom session id for the admin user. After then, even if the admin user changes his password, since the session id will be still valid, attacker can login the application.

Updating Firmware via HTTP

By listening the traffic of the application, I noticed that it downloads firmware file via HTTP. Which means that firmware files can be altered during transmission.

Since I don’t have the Airtame device anymore, I could only retest the vulnerabilities via latest firmware file. Update is triggered via “airtame-device-update” binary file. Since I can’t reverse engineer shit, best option for me to grep an URL

It’s still HTTP. But doesn’t mean that it will download the firmware file via HTTP. That “checkfw.php” checks the given version and -probably- returns true or false. In my case, it was always false since there is no new update. As a result, I don’t know if this is fixed but earlier Airtame team said they will carry the update channel to HTTPS.

Using Weak Cryptographic Hash Function For File Integrity

By listening the traffic of the application, I noticed that integrity check is done with MD5 hashing algorithm.

http://repos-cdn.airtame.com/firmware/beta/latest.rootfs.md5

To be honest, if you are using HTTP to download updates, hash comparison doesn’t mean anything. Attacker can change the update file and it’s hash on air. Even if you use HTTPS for update and put the file and it’s hash to the same server, it’s still doesn’t provide anything. If an attacker can compromise the server, he can change both file and it’s hash. For me the best practise should be getting update file and it’s hash from different servers.

I’m not sure if this vulnerability is fixed.

Using Weak Cryptographic Hash Function For Storing Passwords

In source code analysis,  I noticed that application stores user passwords with MD5 hashes.

Using Hardcoded Credentials

I observed that application uses hardcoded credentials for communicating with server.

Result

Airtame team was very kind and they commented every vulnerability seriously. They sent me a t-shirt, some stickers and this beatiful note with a team picture.

Disclosure Timeline

-Report submitted to Airtame (3 August 2017)

-Airtame team confirmed the vulnerabilities and said they will be gone in next update (7 August 2017)

-New Airtame update available (9 October 2017)

As you all know, I published Hidden Tear’s code in August 2015, and EDA2’s code in October 2015. I explained the reasons behind these publications several times. To summarise them again:

1. Changing programming language trend to a high level language, so that decompile process will be possible&faster.
2.  Destroying the business of ransomware code&service sellers.
3. Using implemented backdoors to decrypt infected files.
4. Providing a ransomware source code for educational purposes

I don’t want to talk about them over and over again. Let’s just check the outcomes:

1. Yes, trend is slightly changed to a high level language (C#) but it doesn’t matter since you can’t find a solution for decryption anymore.
2. Their business was slightly broken in 2016, but now it’s growing again.
3. Yes we were able to decrypt some cases but the backdoors are fixed by time.
4. That’s the only good outcome

Now, we are seeing new Hidden Tear/EDA2 variants appears every day which doesn’t have any backdoor. I’ve already seen this long time ago, and I moved to different things. I want to say that I’m sorry for Hidden Tear/EDA2 experiments, they were total failures. Caused more chaos even my intentation was good.

Note: Some may think that I’m scared after Marcus’s case, that’s not the thing. I’ve published Hidden Tear in August 2015, went to Las Vegas in 2016 and 2017. I have no legal problem since I didn’t sell this code or used it in criminal activities.

Note 2: I’m seeing some people programmed a variant named EDA3, there is no EDA1 or EDA3 from my side. 2 is not a version number.

-Not: Burada yer alan tavsiyeler güvenlik alanında iyi derecede bilgiye sahip olan, İngilizce bilen ve yeni bir tool üretmek isteyen insanlara hitap ediyor. Ayrıca aşağıda yer alacak her tavsiye aşırı derecede özneldir.-

Yeni Bir Tool Üretmenin Felsefesi

Yeni bir tool üretmek iyi derecede bilgi ister, fakat bu bilgi seviyesi gerekli olan tek şey değil. Örneğin, siz çok iyi bir programcı olabilirsiniz ve network güvenliği hakkında uzmanlığa yakın bir bilginiz olabilir. Fakat bu, network güvenliği alanında orijinal bir tool üretebileceğiniz anlamına gelmez. Aynı şekilde sizden daha alt seviye biri bütün dünyanın kullanacağı bir tool üretebilir.

Bu konuda müzik dünyasından bir örnek verebilirim: Lars Ulrich 

Müzik ve güvenlik tool’u geliştirmek ilk başta alakasız gelebilir. Ancak ben yeni bir tool yazıp paylaşmayı, bir müzik albümü çıkarmaya benzetiyorum. İkisinde de sıfırdan, farklı ve orijinal bir şey yaratmanız gerekiyor. Daha sonra, yarattığınız bu yapıtı halka açıyorsunuz ve geri dönüşleri beklemeye başlıyorsunuz. İnsanlar ortaya koyduğunuz yapıtı çok da beğenebilir, nefret de edebilir.

Her neyse, Lars Ulrich örneğine geri dönebiliriz. Bilmeyenler için Lars Ulrich Metallica’nın bateristidir.

Metal müzik kültürüne aşina olmayanlar için biraz daha ek bilgi vereyim: Lars Ulrich kötü bir bateristtir! Çoğu zaman kendi yazdığı ritimleri bile çalamaz, çalarken her zaman basite kaçar. Hatta Youtube’da görüyoruz ki 20 yaşındaki bateristler, Lars’ın yazdığı ritimleri Lars’ın kendisinden daha iyi çalıyor. Peki durum böyleyken Lars nasıl oluyor da Metallica’ya yön verip onu 30 yıldır dünyanın zirvesinde tutabiliyor? Evet, Lars enstürmanı iyi çalamıyor olabilir, fakat kendisi müthiş bir bestekar. Şarkıların yazılma sürecinde doğrudan büyük payı var. Aynı zamanda müziğe ilk başladığı 20’li yaşlarından itibaren kimseyi taklit etmeyerek, her zaman kendi tarzını sürdürmeye devam etti. Yani sürekli yeni bir şeyler üretti. Bunları yaptığı için enstürman çalmada kötü olsa bile hep dünyanın zirvesinde olmayı başardı.

Şimdi bunu neden anlattın bize diyecek olursanız, şunun için anlattım. Enstürman çalmayı programlama bilgisi olarak düşünebilirsiniz. Bir enstürmanı çok iyi çalmanız, hit bir şarkı besteleyebileceğiniz anlamına gelmiyor. Başka bestekarların şarkılarını onlardan daha iyi çalabilirsiniz, fakat bestekar olmak farklı bir konu. Tool geliştirmeye de bu açıdan bakmanızı öneririm. Orta seviyeli bir programcı olabilirsiniz. Ancak bu sizi hiç bir zaman yıldırmasın. Başkalarını taklit etmeyip, kendi tarzınızı oluşturduğunuz sürece ortaya kaliteli bir iş çıkarmanız gayet mümkün.

Tool’u Kodlamadan Önce

Sektörde örnek aldığınız kişileri iyi seçin. Dünya çapında kabul görmüş, alanında usta güvenlik uzmanlarını araştırın, yazdıklarını okuyun, toollarını ve tarzlarını inceleyin. Bunu yapmak bir gün Defcon’da demo yapmanızı garanti etmez. Fakat dünyaya yeni bir katkıda bulunamayan lokal uzmanları kendinize örnek alırsanız asla Defcon’da demo yapamayacağınızı garanti edebilirim.

Bunun yanında Blackhat ve Defcon’da demosu yapılabilecek bir tool’un, sektöre yeni bir şey katması gerekli. Yeni bir şeyden kastım, daha önce asla değinilmemiş bir konu olmak zorunda değil. Başka çok iyi bir tool’un eksik kaldığı bir noktayı da tamamlayabilirsiniz. Örneğin bir port scanner yazdığımızı düşünelim.

–Bu port scannerın Nmap’e kıyasla bir avantajı var mı?

Hayır yok: Bu tool Defcon’a uygun değil.

Evet, Nmap’den çok daha hızlı çalışıyor: Güzel bir başlangıç, fakat yeni bir soru var.

–Hızlı port scanning konusunda iddialı olan masscan, zmap gibi toollara kıyasla bir avantajı var mı?

Hayır yok: Bu tool Defcon’a uygun değil.

Evet, masscan ve zmap portları tararken x metodunu kullanıyor, bu x metodunu firewall’lar tespit ediyor fakat ben y metodunu kullandığım için firewall’lar tarafından bloklanmıyorum: Bu tool Defcon’a uygun olabilir.

Bizim yazdığımız Leviathan Framework aslında bir bakıma Metasploit’in bir kaç açığını kapatıyordu ve üstüne yeni özellikler ekliyordu. Şöyle ki, elinizde bir SMB Remote Code Execution exploiti olsun. Metasploit kullanarak belirlediğiniz bir ya da bir kaç hedefi exploit etmeniz mümkün. Ancak aynı anda 60,000 hedefi aynı anda exploit edemezsiniz. Leviathan’da hem bu çoklu exploitation özelliğini aktif ettik, hem de discovery kısmını çok daha pratik hale getirdik diye özetleyebilirim.

O yüzden kodlayacağınız tool’un kalite, orijinallik ve sektöre katkı konusunda yeterli olduğuna emin olmanız lazım.

Bunun yanında genç kesime verebileceğim diğer bir tavsiye de tool fikrinizi -çok gerekmedikçe- insanlara anlatmayın, yorumlarını almayın. Eğer ticari bir ürün yapıyorsanız, tabi ki marketing gibi gereksinimler için bu işin uzmanlarına akıl danışmanız gerekebilir. Ancak Blackhat/Defcon gibi deneysel ortamlarda tool’un marketing değerinin bir önemi yoktur. Bu tip ortamlarda işin teknik/bilim kısmı önemlidir. Tool fikrinizi anlattığınız kişi bir güvenlik uzmanı olabilir. Ancak yine de bu kişinin vizyonu, tool’unuzu anlamak için yeterli olmayabilir. Yazının başında belirttiğim gibi güvenlik alanında uzman olmak ile tool geliştirmek farklı sanatlardır. Siz fikrinizi anlattığınızda, karşınızdaki kişiden “x tool’u varken buna ne gerek var, bu tool tutmaz, güzel ama Defcon’luk bir şey değil” gibi heves kırıcı cümleler duyabilirsiniz. Böyle bir diyalogda gerçekten kazanabileceğiniz hiç bir şey yok. Siz eğer fikrinize güveniyorsanız, bunu çok dillendirmeden yapın ve yayınlayın.

Tool’u Kodladıktan Sonra

Yazdığınız tool ne kadar iyi, ne kadar orijinal bir iş olursa olsun düzgün dokümante edilmediyse muhtemelen pek fazla kişi tarafından kullanılmayacaktır. Bunun yanında Blackhat ve Defcon jürisi tarafından hemencecik üstü çizilecektir. O yüzden tool’un her ayrıntısını, düzgün bir dille açıklamanız lazım. Örnek olarak Leviathan’ın Github sayfasına bakabilirsiniz. README.md‘de genel özelliklere yer verirken detaylara Wiki sayfasında yer verdim.

Bu adım da bittikten sonra tool’u artık halka açıp geri dönüşleri beklemeye başlayabilirsiniz. Peki tool’u nasıl halka açacaksınız? Ben bugüne kadar Reddit Netsec ve Twitter dışında başka bir kaynağa ihtiyaç duymadım. Eğer tool iyiyse zaten Reddit/Twitter üzerinden bütün sektöre yayılacaktır. İlk feedback’leri aldıktan sonra tool’unuzu daha iyi hale getirebilirsiniz.

Daha sonra Blackhat ve Defcon’a başvuru süreci başlıyor. Blackhat Arsenal’e yapılan başvurular Toolswatch ekibi tarafından değerlendiriliyor. “Call For Tools” zamanı yıldan yıla değişiklik gösteriyor. Bu yıl Mayıs ayının başında göndermek gerekiyordu. Blackhat websitesinden bir başvuru formu açıyor, tool hakkındaki detayları oraya girmeniz gerekiyor. Defcon’un başvurusu biraz daha geç bitiyor. Başvuru’yu e-mail yoluyla yapıyorsunuz. Başvuruyu bitirdikten sonra beklemeye başlıyorsunuz.

Kabul Sonrası

Şimdi artık yapacağınız demoya hazırlanmanız lazım. Burada birkaç seçeneğiniz var. Mesela, tool’un canlı demosunu yapabilirsiniz. Ancak bu biraz sancılı olacaktır. Canlı demolarda genelde bir şeyler ters gider. Uzun bir sunumda bir demonun ters gitmesi pek bir sorun teşkil etmeyebilir ancak sadece demodan oluşan bir sunumda demonun ters gitmesi her şeyin ters gitmesi demek. Biz daha çok video ve slaytlar üzerinden anlatım yaptık. Ancak canlı demolar her zaman daha heyecan vericidir. Karar sizin.

Demo Günü

Demo’yu hangi saate ve güne verdikleri oldukça önemli. Sizinle aynı saatte çok meşhur biri demo yapıyorsa, kalabalığın önemli bir kısmı orada olacaktır. Örneğin, biz Blackhat’te, Powershell Empire’ı yazan ekiple aynı saatteydik, kalabalığın önemli bir kısmı onlara kaymıştı. Diğer tarafımızda, alanında yine meşhur olan Paula Januszkiewicz vardı, o da epey bir kalabalık toplamıştı. Ancak bunlara rağmen yine biz de kendimize bir kalabalık toplayabildik.

Defcon’da ise günün çok önemi var. Örneğin birinci ve ikinci gün Demo Labs salonu kalabalıktan çıldırırken, bizim demo yapacağımız üçüncü günde ortalık tenhaydı. Çünkü Defcon’un son günü yarım gün, ve Amerikan katılımcıların çoğu Pazartesi mesaisine yetişmek için o gün sabah yola çıkıyor. Ya da demo’nuz ikinci gündeyse ama saat 12:00’ye verildiyse önemli bir kalabalık yemeğe gitmiş olacak. Bunlar biraz şans işi.

Sonuç

Yazının başında değindiğim gibi ben Türkiye’de pek çok insanın Blackhat/Defcon’da yer alabileceğine yürekten inanıyorum. Çoğu kişinin daha önce hiç buralara gelmeyi hiç denemediğini düşünüyorum. Denediğiniz takdirde başarabileceğinizden eminim. Boş şans.

Bildiğiniz üzere bundan yaklaşık 2 ay önce Özge Barbaros ile Leviathan Framework isimli tool’u yayınlamıştık. Bu tool ile dünyanın en prestijli offensive security konferansları olan Blackhat USA ve Defcon konferanslarının Arsenal ve Demo Labs kısımlarında demo yapmaya hak kazandık. Lise hayallerimi gerçekleştirmeyi başardığım için çok mutluyum. Konferans dönüşünde edindiğim tecrübeleri ve sunum yapmak isteyenler için tavsiyelerimi paylaşacağım. 24-31 Temmuzda Las Vegas’ta görüşmek üzere.

Linkler:

https://www.blackhat.com/us-17/arsenal.html#leviathan-framework

https://www.defcon.org/html/defcon-25/dc-25-demolabs.html

It’s really easy to implement Python exploits to Leviathan by following our manual. I implemented both SMB and RDP codes. So let’s see how Leviathan helps you to detect Doublepulsar implants in wide range. This is a great example which shows Leviathan’s custom exploit flexibility.

Discovery Phase

Firstly, you need to discover IP addresses which are running RDP or SMB. You have 3 different options:

1)Discover them with Shodan (Auto-query, Manual-query)

1)Discover them with Censys (Auto-query, Manual-query)

1)Discover them with Masscan

For this example, I used Shodan’s auto-query feature for detecting RDP services in Turkey (Discovery –> Shodan –> Automatic Query)

Also, you can use masscan option to discover services in given IP range. This IP range can be the whole Internet :)

Detection

Detection is also easy. Find your discovery id first (Assets –> Show discovered machines –> everything) Copy your discovery id and return back to the main menu.

Go to Custom Exploits section (Attack –> Custom Exploits)

Enter your discovery id, enter the exploit name (detect_doublepulsar_rdp)

Leviathan will run the exploit against the discovered targets.

Proof of Concept

I created a Basic-Authentication protected folder on my website and put an image file on it.

I included this image with<img> tag inside the e-mail and sent that to Outlook for Mac client.

<p><img src=3D"http://utkusen.com/mstest/test.jpg" alt=3D""></p>

Result on Outlook for Mac’s side:

A login prompt pops up. It says “Your login information will be sent securely” on the prompt but I can see the username/password values on my website’s log.

Reference: Microsoft Outlook for Mac CVE-2017-0207 Spoofing Vulnerability

Fix Timeline

-Vulnerability is reported / 19 December 2016

-Microsoft said they got the report / 22 December 2016

-Microsoft said they reproduced the issue / 4 January 2017

-Microsoft said they will fix the vulnerability on March 14 / 22 February 2017

-Microsoft said I entered into March’s acknowledgement list / 7 March 2017

-Microsoft published acknowledgement for this: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0207

-Microsoft published March’s acknowledgement list (my name wasn’t there) / Second week of April

-I told Microsoft that my name is missing / 17 April 2017

-I told Microsoft that my name is missing / 19 April 2017

-I told Microsoft that my name is missing / 21 April 2017

-I told Microsoft that my name is missing / 23 April 2017

Bu tip botların dünyada yarattığı en büyük endişe maalesef gizlilik ihlali. Çünkü bu yazılımlar konuşmalarınızı internet üzerinden bir yere gönderip cevabını size geri gönderiyor. Yani konuşmalarınız aslında bir yerlerde kayıt altında tutuluyor. Özellikle sizi sürekli dinleyen yazılımların verdiği endişe çok büyük. Örneğin Siri sadece “Hey Siri” derseniz ya da Google “Ok Google” derseniz komutlarınızı işliyor fakat bu cümleleri yakalayabilmesi için sizi her zaman dinlemeli. Bu yaptığı dinlemeleri nasıl değerlendiriyorlar bu bir soru işareti. Sürekli dinlemeyi deaktif etseniz bile bunun gerçekten deaktif olduğundan emin olmak güç.

Bu tip endişeler yüzünden bazı geliştiriciler açık kaynak kodlu yazılımlar geliştirdi. Bunların en popüleri Jasper projesi. Kodlarını görebildiğiniz için konuşmanızın siz istemedikçe bir yerlere gönderilmediğinden emin olabiliyorsunuz. Fakat ne yazık ki Türkçe desteği bulunmamakta. Hobi olarak bunun Türkçe halini yapmak istedim. Açık kaynak kodlu Türkçe konuşan bir Jarvis’in pek çok kullanım alanı olabilir diye düşündüm. Konuşmalarımızın üçüncü partilere yollanmayacak olması da bu kullanım alanını genişletebilirdi.

Fakat Türkçe konusunda yaşadığım ve henüz aşamadığım bazı zorluklar mevcut. Bir botun sizin sesinizden emir alıp, bu emri yerine getirip sonra konuşarak bilgi vermesi için basitçe şu adımları gerçekleştirmesi gerekiyor.

1. Kullanıcıdan aldığı sesi işleyip yazıya dönüştürmeli (Speech-to-text)
2. Yazıdaki denilen şeyi algılayıp ona göre gerekli işlemleri yapmalı
3. Sonuç olarak ürettiği yazıyı tekrar ses olarak geri dönmeli (text-to-speech)

Türkçe dilinde yazıda denilen şeyi algılama üzerine bir sürü yapılmış çalışma mevcut. Benim ROMTU projem de aşağı yukarı benzer bir şey yapıyordu. Bir yere veri göndermeden offline yapılması teoride mümkün. Ancak pratikte yine uzak bir servise gönderip işlenmesi daha makul olmakta.

Türkçe bir yazıyı sesli bir şekilde okuma işi de kolay. Bunun için gTTs kütüphanesinden faydalandım. Bir yere veri göndermeden yapmak yine mümkün oluyor.

Fakat Türkçe speech-to-text şu an için büyük problem. Açık kaynak kodlu bir çalışma bulamadım bununla ilgili. Google’ın bu işi gerçekleştiren bir API‘ı mevcut. Onu kullanmak zorunda kaldım. Bu API oldukça başarılı çalışsa da ses dosyasını Google serverlarına gönderip, yazı karşılığını alıyoruz. Yani sesimiz yine üçüncü parti bir yere ulaşıyor.

Buna henüz bir çözüm bulabilmiş değilim. O yüzden kodları henüz yayınlamayacağım. Ancak bu projeyle uğraşırken Twitch’de seebotschat isimli bir kanala denk geldim. Bu kanalda birisi iki Google Home cihazını yan yana koyarak sohbet ettiriyordu. Türkçe olarak böyle bir çalışma yapıldı mı diye araştırdım ve bir şey bulamadım. En azından şimdilik böyle bir şey yapıp video çekeyim diye düşündüm.

Şu an var olan gizlilik problemini çözer çözmez projeyi açık kaynak kodlu olarak yayınlayacağım. O zamana kadar aşağıdaki videoyla eğlenebilirsiniz.

In september, I was testing spam filters of various e-mail services such as Gmail, Outlook 365 and Yandex. I used my university e-mail address which uses Office 365 Web Service and personal e-mail addresses from Gmail and Yandex. I installed sees tool on an Amazon server to send phishing e-mails. The test wasn’t so successful. A sample setting for targeting my Yandex e-mail:

It landed on spam folder. Tried with Gmail and Outlook 365, still no luck. Maybe this tool was not so efficient maybe I was doing a mistake, I wasn’t sure.

Suddenly, a weird thing happened. I saw an e-mail on my Yandex inbox which has “Verify Test 2” on it’s subject field and has a green valid sign.

At first few seconds, I was thinking that I accidently sent another test e-mail to my Yandex e-mail and it worked. But then I realized I was using “Verify Test 1” subject for Yandex, and “Verify Test 2” for Outlook. There should be something else.

After few minutes of inspection, I remembered that I set up an e-mail forwarding rule for my Outlook 365 e-mail to Yandex. So, Outlook forwarded this e-mail to Yandex. But why that valid sign appeared now?

I checked it in Yandex’s website it says: (By the way this feature is not supported anymore.)

“With a DKIM signature, the email recipient can verify that the message really came from the supposed sender.”

It was a simple DKIM(DomainKeys Identified Mail) validator. So basically if an e-mail signed by a valid certificate regarding to the domain name of the sender, we see that cool icon. So, sender domain is microsoft.com, it should have been signed by Microsoft’s certificate??

In order to understand whats going on, I checked the headers of these spam and valid e-mails. The header below is belongs to the e-mail which is marked as spam by Yandex:

Received: from mxfront15h.mail.yandex.net ([127.0.0.1])
	by mxfront15h.mail.yandex.net with LMTP id HG70cJmK
	for <utku.sen@yandex.com>; Sat, 3 Sep 2016 22:02:37 +0300
Received: from ec2-52-51-33-8.eu-west-1.compute.amazonaws.com (ec2-52-51-33-8.eu-west-1.compute.amazonaws.com [52.51.33.8])
	by mxfront15h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id K8106KgL1a-2aGmWbm2;
	Sat, 03 Sep 2016 22:02:36 +0300
Return-Path: qhDwA.reWXEDN@example.com
X-Yandex-Front: mxfront15h.mail.yandex.net
X-Yandex-TimeMark: 1472929356
Authentication-Results: mxfront15h.mail.yandex.net; spf=fail (mxfront15h.mail.yandex.net: domain of example.com does not designate 52.51.33.8 as permitted sender) smtp.mail=qhDwA.reWXEDN@example.com
X-Yandex-Spam: 1
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by ip-10-0-0-12.eu-west-1.compute.internal (Postfix) with ESMTP id 2749C42DA5
	for <utku.sen@yandex.com>; Sat,  3 Sep 2016 19:02:36 +0000 (UTC)
Content-Type: multipart/alternative;
    boundary="127.0.0.1.0.4022.1472929356.122.1"
From: Johannes Brahms <secure@microsoft.com>
Subject: Verify Test 1
MIME-Version: 1.0
To: utku.sen@yandex.com

It’s received by Amazon server, there is no valid signature, no surprise it was landed on spam folder. Let’s check the header of valid e-mail:

Received: from mxfront9h.mail.yandex.net ([127.0.0.1])
	by mxfront9h.mail.yandex.net with LMTP id anm2f8eB
	for <utku.sen@yandex.com>; Sat, 3 Sep 2016 22:05:49 +0300
Received: from mail-he1eur01lp0215.outbound.protection.outlook.com (mail-he1eur01lp0215.outbound.protection.outlook.com [213.199.154.215])
	by mxfront9h.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id **REMOVED**;
	Sat, 03 Sep 2016 22:05:48 +0300
	(using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
	(Client certificate not present)
Return-Path: utku.sen@bilgiedu.net
X-Yandex-Front: mxfront9h.mail.yandex.net
X-Yandex-TimeMark: 1472929548
Authentication-Results: mxfront9h.mail.yandex.net; dkim=pass header.i=@bilgiedu.onmicrosoft.com
X-Yandex-Spam: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bilgiedu.onmicrosoft.com; s=selector1-bilgiedu-net;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=**REMOVED**
 b=**REMOVED**
Resent-From: <utku.sen@bilgiedu.net>
Received: from HE1PR0401CA0023.eurprd04.prod.outlook.com (10.166.116.161) by
 AM5PR0401MB2563.eurprd04.prod.outlook.com (10.169.245.14) with Microsoft SMTP
 Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id
 15.1.609.3; Sat, 3 Sep 2016 19:05:44 +0000
Received: from AM5EUR02FT060.eop-EUR02.prod.protection.outlook.com
 (2a01:111:f400:7e1e::203) by HE1PR0401CA0023.outlook.office365.com
 (2a01:111:e400:c512::33) with Microsoft SMTP Server (version=TLS1_0,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend
 Transport; Sat, 3 Sep 2016 19:05:44 +0000
Received-SPF: Fail (protection.outlook.com: domain of example.com does not
 designate 52.51.33.8 as permitted sender) receiver=protection.outlook.com;
 client-ip=52.51.33.8; helo=ip-10-0-0-12.eu-west-1.compute.internal;
Received: from ip-10-0-0-12.eu-west-1.compute.internal (52.51.33.8) by
 AM5EUR02FT060.mail.protection.outlook.com (10.152.9.179) with Microsoft SMTP
 Server id 15.1.587.6 via Frontend Transport; Sat, 3 Sep 2016 19:05:43 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by ip-10-0-0-12.eu-west-1.compute.internal (Postfix) with ESMTP id E7BF642DA5
	for <utku.sen@bilgiedu.net>; Sat,  3 Sep 2016 19:05:42 +0000 (UTC)
Content-Type: multipart/alternative;
	boundary="127.0.0.1.0.4033.1472929542.917.1"
From: Johannes Brahms <secure@microsoft.com>
Subject: Verify Test 2
MIME-Version: 1.0
To: <utku.sen@bilgiedu.net>

To be honest, I didn’t fully understand whats going on since I’m no expert on e-mail authentication topic. E-mail received by outlook.com domain and has a DKIM signature info in it. Let’s check that (I removed bh and b fields):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bilgiedu.onmicrosoft.com; s=selector1-bilgiedu-net;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
 bh=**REMOVED**
 b=**REMOVED**

a= the signing algorithm

c= the canonicalization algorithm

d= signing domain

h=the list of signed header fields

bh= body hash

b= digital signature of the contents

So my e-mail address is utku.sen@bilgiedu.net but the signing domain is bilgiedu.onmicrosoft.com. I’m not sure if it’s like that on all Outlook 365 clients, probably it is.

But in the e-mail, sender is secure@microsoft.com. This part was a confusion for me. Is onmicrosoft.com’s signature is same with microsoft.com? If so that’s an issue on Microsoft’s side. Or, it’s not like that and Yandex has an issue on identifying valid DKIM signatures. Or, I totally don’t know shit about this DKIM stuff.

Update (20 November 2016): Reddit user ptmb wrote a good explanation about whats going on:

“To further develop on /u/indrora ‘s explanation of DKIM, the problem here, and why it was related to DKIM, was that when Outlook was redirecting the messages it was signing them with it’s own DKIM key instead of keeping whatever signature was originally in the email (or lack of it).
That means that instead of having an email with a proof of identity from the original sender, you received an email with a proof of identity from the “redirector”.
And because Outlook was blindly signing these messages it was redirecting, if the message had a fake from field saying something@microsoft.com, then after Outlook blindly redirected it, it’d have a genuine DKIM signature from microsoft by coincidence, even though the original email wasn’t from Microsoft at all.”

I decided to do some additional tests. I changed my forwarding address to my Gmail address and sent another spam e-mail with microsoft.com domain to my Outlook address. It landed on spam folder in Outlook and inbox in Gmail.

I changed forwarding address to Yandex again. This time I changed the spam e-mail’s domain with an other domain name than microsoft.com. It landed on spam box in both Outlook and Yandex. Also there was no “green valid sign” on it (obviously)

Even if I didn’t fully understand whats going on, I could send valid e-mails from microsoft.com to anyone.

Anyway, I decided to notify both Yandex and Microsoft. I said to Yandex you may have a problem with that “green valid sign”, it may cause a security illusion for users. Also I sent a vulnerability report to Microsoft.

I couldn’t hear back from Yandex but later on Microsoft security team said they reproduced the vulnerability. After some time, vulnerability is fixed. The weird thing is, Yandex disabled that “green sign” feature after some time (I don’t know exact date). I’m not sure if it’s related with this anomaly. Anyway, you can find remediation timeline below.

Timeline:

-September 3, 2016: Issue reported to Microsoft

-September 3, 2016: Microsoft forwarded the report to analysts

-September 29, 2016: Microsoft said they reproduced the issue

-October 27, 2016: Microsoft said the vulnerability is fixed

-November 2016: Microsoft gives credit to me: https://technet.microsoft.com/en-us/security/cc308575

Profesyonel olarak bilgi güvenliğiyle ilgilenen biri olarak gizlilik (privacy) ve operasyon güvenliği (OPSEC) alanları hakkında da araştırmalar yapmaktayım. Dünyada OPSEC, bir alt bilim dalı gibi ele alındığından hakkında makaleler yazılması olağan karşılanır. Umarım bu yazı ülkemizde suçluya yol göstermekten ziyade teknik bir bakış açısı olarak görülür.

OPSEC (Operasyon Güvenliği) Nedir

OPSEC, Amerikan ordusu tarafından 2. Dünya savaşından beri kullanılan bir terimdir. Genel anlamda kritik bilgilerin düşman istihbaratı tarafından ele geçirilmemesini amaç edinir. Daha dar anlamda ise kabaca, küçük ayrıntıların korunarak büyük resmin görülmesini engellemek diyebiliriz.

OPSEC’in Önemli İki İlkesi

Konu OPSEC olduğu zaman dikkat edilecek pek çok ilke mevcut. Fakat burada sadece konuyla ilintili olan iki ilkeden bahsetmek istiyorum.

1) Kalabalıkta Gizlenme İlkesi:

Bu ilkeye göre kişi eylemini gerçekleştirirken toplumun geri kalan fertlerinden kolayca ayırt edilememelidir. Yani nasıl ki IŞİD teröristleri eylem yaparken sakallarını kesip yerel halktan biriymiş gibi giyiniyorsa, bilgisayar dünyasında da bunun paraleli yöntemler izlenmelidir. Büyük veriler incelenirken seni diğer insanlardan ayırt edecek bir detaya sahip olmaman gerekir.

2) Deniability (inkar edilebilirlik) İlkesi:

Bu ilkeye göre eğer bir şüphe sonucu yakalanırsan, eylemi yaptığını inkar edebilecek ve aksi ispat edilemeyecek şekilde kanıt bırakmaman gerekir. Örneğin hırsızlık yaparken kameralardan uzak durup parmak izi bırakmazsan biri seni görse bile inkar ettiğin takdirde suçlu bulunmayabilirsin. Bilgisayar dünyasında da bunun paraleli yöntemler izlenmelidir. Cihazlarınızda ve internet aktivitelerinizde sizi suçlu çıkaracak loglar bırakmamalısınız.

Fetö’nün Yaptığı Kritik Yanlışlar:

1)Kendi mesajlaşma uygulamasını yazmak -Kalabalıkta gizlenme ilkesi ihlali

2)Bu uygulamanın örgüt üyeleri dışında kimse tarafından kullanılamaması – Deniability (inkar edilebilirlik) ihlali

Ev Yapımı Mesajlaşma Uygulamasının Yol Açacağı Problemler

İlk olarak, end-to-end encryption (uçtan uca şifreleme) kullanan bir program yazmak kolay bir iş değildir. Eğer bu alanda uzman değilseniz bir yerlerde hata yapmanız çok olası. Uzman olsanız bile, kodunuzun güvenilirliğinden emin olmanız için başka uzmanlar tarafından da incelenmesi gerekebilir.

Tamam, diyelim ki Bylock alanında uzman kişiler tarafından programlandı. Ölümcül operasyon güvenliği problemi burada bitmiyor.

Yağmurlu bir havada polisten kaçtığınızı düşünün. Sizce akıllıca olan herkes gibi bir şemsiye edinip kalabalığa karışıp normal davranmak mı, yoksa şort-tişört-kar maskesi giyerek dolaşmak mı? Bir suç örgütü için ev yapımı mesajlaşma programı kullanmak ikincisi gibidir diyebiliriz.

Biraz daha teknik detaylarla açıklayayım. Türkiye’de hangi mesajlaşma uygulaması kaç kişi tarafından kullanılıyor? Aşağıda tamamen tahmini sayılar vereceğim:

Whatsapp: 20.000.000

Facebook Messenger: 10.000.000

Telegram: 900.000

Signal: 500.000

Bylock: 100.000

Bylock sadece örgüt üyeleri tarafından kullanılabildiği için polisin 100.000 kullanıcıyı tespit etmesi için sadece bir kişinin telefonunu el geçirmesi yeterli olacaktır. Şöyle ki:

1)Bylock yüklü bir telefon ele geçir

2)Bylock’un bağlantı kurduğu sunucuların IP adreslerini tespit et

Bonus) Eğer sunucuların bulunduğu ülkenin kanunları ve siyasi otoritesi izin veriyorsa sunuculara baskın yap, tersine mühendislik yapıp bütün mesajlaşmaları ele geçirmeye çalış

3)Türkiye’deki bütün servis sağlayıcılarla iletişime geç

4)Bylock’un sunucu IP’lerine hangi cihazlar tarafından veri yollandığını tespit et

5)Bütün cihaz sahiplerini tutukla, paylaşımlı bir ağ ise kameraları kontrol et. Kamera da yoksa en şüphe çeken ismi tutukla

Durum bu şekildeyken kişi, telefonundan Bylock uygulamasını silse bile Bylock sunucularıyla veri transferinde bulunduğu tespit edildiği için inkar hakkı kalmıyor.

Üyeler Bylock’u VPN üzerinden kullansaydı bu sonuçlar yaşanmayabilirdi. Ancak Bylock kullanıcılarının genelde 40 yaş üstü teknolojiyle pek arası olmayan insanlar olduğunu düşünürsek, hata yapma risklerinin çok fazla olduğunu görürüz. Bylock’a 1 sene içinde sadece bir kere bile VPN’siz bağlanmaları açığa çıkmaları için yeterli olacaktır.

Peki örgüt üyeleri güvenilirliği farklı otoritelerce teyit edilmiş bir mesajlaşma uygulaması (örneğin Signal) kullansaydı ne olurdu?

1)Polis ilk etapta pek çok örgüt üyesinin telefonunda Signal uygulamasının yüklü olduğu -bir şekilde- tespit ederdi

2)Signal’in bağlantı kurduğu sunucuların IP adresleri tespit edilirdi

Bonus) Sunuculara baskın yap.. hayır.. kanuni olarak gücün buna yetmeyebilir. Yetse bile elde edebileceğin bir şey yok çünkü bütün konuşmalar şifreli. Elde edilebilecek tek şey kim tarafından kime hangi tarihte mesaj yollandığı (metadata).

3)Türkiye’deki bütün servis sağlayıcılarla iletişime geç

4)Signal’in sunucu IP’lerine hangi cihazlar tarafından data yollandığını tespit et (500.000 kişi)

Şimdi burada bir yol ayrımına gidilmesi lazım:

4.1) 500.000 kişiyi de tutukla?!?!?!

Bu, pratikte çok mümkün olmayacaktır. Çünkü Signal, halka açık bir yazılım olduğu için bunu kullanan konuyla alakasız yüzbinlerce kişi var. Bunun avantajını kullanarak örgüt üyeleri de inkar haklarını kullanabilir. Google Play ya da App Store’dan indirilen bir uygulamanın ciddi bir kanuni yaptırımı olacağını düşünmüyorum. Kısa ya da uzun bir süre sonra delil yetersizliğinden serbest kalabilirler.

4.2)Signal kullanımını yasakla

Bu çözüm de çok ilkelce fakat bir önceki çözüme göre daha makul. Yasak geldikten sonra örgüt üyeleri peki diyerek telefonlarından Signal’i silerler, başka bir uygulamaya geçerler.

Sonuç

İkinci seneryoda gördüğümüz gibi güvenlik güçlerinin, tek atışta bütün örgütü tutuklayacak bir imkanı olmayacaktır. Whatsapp kullanmak bile Bylock kullanmaktan daha güvenli olacakken neden böyle özel bir program yazıldı merak ediyorum. Fetö üyeleri çok mu aptaldı yoksa birileri Fetö’nün tek seferde deşifre edilmesini mi istedi?

Pwnie Awards Adaylığım

Pwnie Awards, her sene Las Vegas’ta güvenlik dünyasının en başarılı ve en kötü işlerine verilen bir ödüldür. Güvenlik dünyasının Oscar’ı, Ballon dor’u olarak düşünebilirsiniz. Jüri, dünyanın seçkin güvenlik araştırmacılarından oluşur. Bu ödülü her sene takip ederdim. Geçen aylarda aday gösterme sürecinin başladığını okudum. Fakat aday olabilmek hiç aklıma bile gelmeyen bir şeydi. Bir gün Twitter’da anonim bir kullanıcıdan DM aldım. Beni “Best Backdoor” kategorisinde aday göstereceğini, bunu fazlasıyla hakettiğimi söyledi. Teşekkür ettim, fakat olabileceğine çok ihtimal vermiyordum. Çünkü adaylar yine jüri tarafından belirlenecekti.

Konferansın başlamasına yaklaşık 10 gün kala aday listesi açıklandı. Heyecanla sayfada ismimi arattım. Yoktum. Yaklaşık 30 saniyelik bir burukluk yaşasam da Best Backdoor kategorisi adaylarının henüz açıklanmadığını farkettim. Siteyi her gün kontrol ediyordum. En son Amerika’ya uçarken Londra havaalanında kontrol ettim. Aday gösterilmiştim :)

Bu benim için oldukça büyük bir başarıydı. Hem Türkiye’den aday gösterilen ilk kişi olmak, hem de jürideki üstadların yaptığım işi başarılı bulması beni mutlu etmişti. Çünkü Türk güvenlik topluluğunun saygın isimleri beni aralıklı zamanlarla yerden yere vurdu. Aramızdaki büyük yaş farkından ve kariyerlerine olan saygımdan söylenen her şeyi sineye çektim. Ama umarım bu adaylık olaya daha farklı açılardan bakabilmelerine yardımcı olur.

Black Hat konferansı bitiminde ödül töreni yapıldı. Jüri her sene seremoniyi ciddiyetsiz bir şekilde sürdürürdü fakat bu sene bu durum üst düzeydeydi :) Jürinin bir kısmı sarhoştu, masada şampanya içiliyordu. Normal koşullarda epey eleştirebileceğim bir durum fakat bu insanlar alanlarında en iyiler olduğu için “çılgın bilim adamı” yakıştırması yapıp saygı duyuyorum.

Açıkçası son ana kadar kazanma ümidim yoktu. Çünkü “Best Backdoor” kategorisindeki rakibim Çin Devletiydi :) Juniper Firewall’unda buldukları bir backdoor ile aday gösterilmişlerdi. Çok önemli bir işti. Herneyse sıra bizim kategoriye geldi.

Tabi o an kalbim yerinden fırlayacak gibiydi. Fakat çok uzun sürmedi. Çünkü beklediğim gibi ödülü hakeden Çin Devleti kazandı. Kendilerini tebrik ediyorum. Kazanamasam bile güzel bir deneyimdi.

Black Hat USA 2016

Black Hat bu sene konferanslar açısından bana göre hayal kırıklığıydı. Belki ben çok talihsiz konuşmalara denk geldim, emin değilim. Girdiğim konuşmalar ya çok alt seviyeye hitap ediyordu ya da konuşmacının sunum yetenekleri çok kötüydü.

Ancak Business Hall kısmı Avrupa’da yapılan konferansa göre çok daha büyük ve çok daha iyiydi. Güvenlik fuarı gibi dizayn edilmişti.

Bir sürü ücretsiz tişört ve Pwnie Awards dışında Black Hat benim açımdan çok verimli değildi.

Defcon

Hayatımda ilk defa bir Defcon etkinliğine gittim, bulunmaktan en mutlu olduğum ortamlardan biriydi diyebilirim.

İlk olarak belirtmem gereken şey: Defcon Black Hat’e kıyasla aşırı kalabalıktı. Black Hat fiyatlarının Defcon’dan neredeyse 10 kat daha pahalı olduğunu düşününce bu netice çok şaşırtmadı beni.

Kalabalığa rağmen oldukça güzel bir ortam vardı. Köşe başında laptoplarıyla bir şey yapan insanlar, geek kızlar, çeşitli village’larda yarışan insanlar.. Ayrıca konuşmaların kalitesi de Black Hat’e göre daha yukarıdaydı ve daha üst düzey insanlara hitap ediyordu.

Beni en çok mutlu eden şeylerden biri de dünya gözüyle dünyanın ilk hackerlarından Captain Crunch lakaplı John Draper’ı görmek oldu. Kendisi epey yaşlanmış, tekerlekli sandalye ile dolaşıyordu.

Kendisiyle fotoğraf çekilmek için $100’lık Tor Router’larından satın almak gerekiyordu. İlk başta biraz yadırgamış olsam da daha sonra hak verdim. Yaşlı bir adam evine ekmek götürmeye çalışıyor. Bundan normal bir şey yok :)

Bu arada Defcon 24’ün badge’inden biraz bahsedeyim. Kuru kafa şeklinde elektronik bir devre. Üzerinde 4 sağda 4 solda olmak üzere 8 adet tuş ve çeşitli ledler vardı. Her sene olduğu gibi bu sene de badge’ın içinde bir challenge saklıydı tabi. İlk -basit- challenge Konami Code denen, çoğu Konami oyununda çalışan hileyle ışıkların harekete geçirilmesiydi. İlk gün bununla ilgili bir videoyu da paylaştım.

#defcon #badge trick pic.twitter.com/Wtu9idpVd7

— Utku Sen (@utku1337) August 5, 2016

Esas büyük oyunu gören arkadaş çözümü şurada uzunca anlatmış.