atak etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
atak etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

14 Ekim 2019 Pazartesi

SQL Server'da "SQL Injection" Saldırı Vakası

Birkaç aydır kendi ürünüm olan Microsoft SQL Server ortamları için veritabanı izleme uygulamam Kangal'ın yeni major versiyonuna son halini vermek konusunda ve bir yandan da müşteri ortamlarının ihtiyaçları ve yeni projeler konusunda çalışıyorum. Son gelişmelerden sonra bir tecrübeyi paylaşmak istedim.

Kangal'ın yeni versiyonuna SQL Injection saldırılarını yakalayacak yeni bir özellik ekledim. Pilot ortamlarda başarılı sonuç elde ettikten sonra ilgili güncellemelerin tüm müşteri ortamlarına da akmasını sağladım.

Yeni versiyonun pilot süreci devam ederken bu özellik bazı müşterilerde zaman zaman alarm üretiyordu, alarm geldiğinde ilgili IT yöneticisine bu alarm için gelen e-postaya cevaben "planlı bir pentest çalışması mı yapılıyor?" diye soruyordum ve "evet" cevabını alınca hayatımıza devam ediyorduk. Bu ortamlardan birinde, bir müşteriden gene alarm geldi. Her zamanki gibi IT yöneticisine yine bir pentest çalışması olup olmadığını sordum ve "hayır" cevabını aldım. Tabii o anda hemen yangın zilleri çalmaya başladı; IT yöneticisi, Yazılım Müdürü ve hatta Genel Müdür, bu saldırıdan haberdar olması gereken herkese ulaştım. Sorunun üstünde hepbirlikte çalıştık, yazılım tarafındaki açıklar tespit edildi ve en kısa sürede soruna müdahale edilip bertaraf edilmiş oldu.


Saldırı esnasında Kangal'ın ürettiği alarmlardan bir örnek


SQL Injection saldırısı nedir? 
Özellikle dinamik SQL kullanılan uygulamalarda, arayüzlerde gerekli korunma önlemleri de alınmadıysa, uygulamaların ürettiği SQL cümleciklerinin arasına veya sonuna "enjekte edilen"/eklenen SQL cümlecikleriyle veritabanlarınıza ve hatta veritabanı sunucunuza saldırganların müdahale edebilmesidir çok özetle. Bunun nasıl yapılabileceğine dair internette oldukça fazla kaynak mevcut.

Bu sorunu fark edemeseydik neler olabilirdi?
Saldırganlar veritabanımızda birçok şey yapabilirlerdi. Örneğin görmelerini istemediğimiz verileri görebilirlerdi, kayıtlarda değişiklikler yapabilirlerdi, tablolarımızı ve hatta veritabanlarımızı silebilirlerdi, hatta disklerimizi formatlayabilir, sunucumuzu kapatabilirlerdi, ki saldırgan arkadaş bunu da denedi.

Neler yapabilecekleri, bizim proaktif olarak ne kadar önlem aldığımıza, uygulamamızı ve yetkilendirme politikamızı ne kadar sıkı tuttuğumuza, en iyi pratikleri ne kadar yakından izlediğimize ve ne kadar disiplinli olduğumuza göre değişir. Eğer tüm uygulama kullanıcılarına "sysadmin" veya "db_owner" yetkisi verilen, SQL Server servis hesabı için en iyi pratiklerin uygulanmadığı, Instance seviyesindeki ayarlara önüne gelenin güvenliği düşünmeden müdahale ettiği bir ortam olsaydı, yaşadığımız bu saldırı felaketle sonuçlanabilirdi.

Özellikle küçük ve orta ölçekli şirketlerin böyle saldırıları fark edecekleri mekanizmaları (uygulama ve kalifiye personel) olmuyor. Eğer bu konuda yetenekli bir uygulamanız yoksa bu tür saldırıları fark ettiğinizde oldukça geç kalmış olabilirsiniz. Çünkü bu saldırıda saldırganın çalıştırdığı komutları uygulamanın çalıştırdığı onca komuttan göz kontrolüyle ayıramazsınız. Ancak uygulama hatalarını yakalayan bir mekanizmanız varsa ve mekanizmanın yakaladığı anormallikler konusunda sizi uyaran alarmlar varsa bu saldırıyı böyle yakalarsınız ya da saldırıyı vakitlice fark edemezsiniz ve ancak saldırının sonuçları sayesinde saldırıdan haberdar olursunuz, ki bu da hiç hoş bir deneyim olmaz. 

Kangal uygulamalarınızın veritabanına karşı çalıştırdığı SQL kodlarına dair tüm hataları takip eder. Bir hata oluştuğunda bu hataya dair ayrıntıları kayıt altına alır. Yeni eklenen SQL Injection koruma özelliği sayesinde de bu üretilen hataları analiz eder ve olası SQL Injection saldırılarına karşı tüm ekibinizi uyarır. Olası saldırılar veya uygulama hatalarınız hakkında en kısa sürede, ayrıntılı bir şekilde haberdar olmuş olursunuz.

Kangal'a eklenen yeni özelliklerden bir diğeri de veritabanı yedeklemesi ile yapılan veri hırsızlığına karşı izleme yapması ve alarm üretmesi. Bu konuya da bir dahaki yazımda değineceğim.

Meraklıları için İpucu:
Eğer benzer bir uygulamayı kendi olanaklarınızla kendi ortamlarınızda yapmak isterseniz bunu Extended Event'lerle yapabilirsiniz. Extended Event'in "error_reported" adında bir Event'i var. Bu Event ile SQL hatalarını kayıt altına alabilir, bu kayıtları taratıp anormallikleri raporlatabilirsiniz.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com


29 Eylül 2017 Cuma

Veritabanınızdaki veriler ne kadar güvende sizce?

Güvenlik gündemden düşmeyen ve düşmeyecek bir konu, sonuçta İhtiyaçlar Hiyerarşisinin de 2. basamağında. Hatta malumunuz son günlerde her yerde Gartner'ın Güvenlik Danışmanlığı dalında ve ciro bakımından 5 yıl art arda 1. sıraya koyduğu Deloitte'ta yaşanan güvenlik açığı konuşuluyor. Peki sizin sistemlerinizin güvenliği ne alemde? Bunu yeterince sorguluyor musunuz?

Bu yazımda size son günlerde yaşadığım bir güvenlik sorunundan ve bir Microsoft SQL Server veritabanı yöneticisinin gözünden güvenlik ile ilgili alınması gereken tedbirlerden bahsedeceğim.

Kısa bir süre önce yönetimini yaptığım sunucuların birinden güvenlik alarmları geldiğini gördüm, durumu analiz edip hemen ilgili IT yöneticisine bildirdim. O da ilgili diğer arkadaşlara bildirdi ve sisteme bir saldırı olduğu netleşti. İlgili ekip tarafından gerekli önlemler alındı ve atak engellenmiş oldu. 

Peki saldırının türü neydi ve saldırıyı nasıl fark ettim? Microsoft SQL Server ürününün varsayılan olarak böyle bir alarmı veya mekanizması yok. Fakat bunun temel altyapısı var. Eğer biraz tecrübeniz varsa, biraz bu konulara kafa yoruyorsanız ve üşengeç biri de değilseniz o zaman eminim sizin de aklınıza gelmiştir bu mekanizma ve bazılarınız zaten uygulamıştır. 

Bakım ve destek anlaşması kapsamında ilgili sunuculara kurduğum izleme sistemindeki onlarca kontrolden biri şöyle:
- Her X dakikada bir Error Log dosyası içerisindeki (ki Error Log dosyasına yazılan her şey Windows Application Event Log'a da yazılır, yani alternatif bir yöntem) tüm "Login Failed" kelimeleri geçen hatalar taranır, 
- Eğer bulunan kayıt sayısı beklenilen/normal sayılan değerden yüksekse, ilgili yöneticilere e-posta ile (aşağıdaki resimdeki gibi bir liste) bildirilir.

Çok basit bir oto-denetim, ama çok etkili. Bahsettiğim saldırıyı güvenlik, ağ ve sistem yönetiminden önce benim fark etmemi sağlayan yöntem bu idi.

Bu saldırıya "Brute Force" mu desek, DDoS mu? Sonuç itibariyle farklı farklı IP adreslerinden, farklı farklı kullanıcı adı ve şifre kombinasyonuyla veritabanına girilmeye çalışıldı.


Saldırı sırasında oluşan hatalar

Çok iyi hatırlıyorum, 2 sene önce bir başka ortamda da aynen yukarıdaki hata mesajlarına benzer hatalar oluşmuştu. Müşteriyle daha yeni bakım ve destek anlaşması yapmıştık. Bana sunucularının çok kritik olduğundan bahsetmişti. Sunucuya daha ilk bağlandığımda hata kayıt dosyalarının böyle mesajlarla dolu olduğunu görmüştüm. Kim bilir ne süredir saldırı altındaydı ve bundan hiç haberi yoktu. Bunu müşteriyle ilettiğimde tüyleri diken diken olmuştu.

Microsoft SQL Server, yıllardır güvenlik açıkları kapsamında rakiplerine göre katbekat güvenli bir ilişkisel veritabanı ürünüdür. Bununla birlikte, nasıl güvenli olduğundan emin olduğunuz herhangi bir aracı, gereci kullanırken tüm güvenlik önlemlerini almanız gerekiyorsa, SQL Server'ı da kullanırken en azından temel güvenlik önlemlerini almalısınız.


Kaynak: Microsoft'un bir sunumundan...

Uzun yıllardır gerek projeler kapsamında, gerekse tam zamanlı olarak verilerin çok hassas olduğu sağlık ve finans sektörlerlerinden birçok kurumda çalışmalar yaptım. Kontrolümde olan sunucular yüzlerce kez dahili ve harici denetimlere tabi tutuldu. Aşağıda sizlerle bu tecrübelerimden aklıma gelen başlıca maddeleri paylaşmak istiyorum. Eğer birçoğu klasikleşmiş bu maddeleri ortamınıza uygulayabilirseniz, SQL Server kapsamında alınabilecek başlıca güvenlik tedbirlerini almış olursunuz. Hem kendi güvenliğinizi sağlamış olursunuz, hem de olası denetimlerde başınız ağrımaz.

- SQL Server'ın varsayılan (daha fazla bilgi için) portu 1433'tür, bunu dünyadaki tüm saldırganlar bilir. Farklı bir port kullanın.

- SQL Server kurulumuyla birlikte "sa" hesabı varsayılan olarak gelir. Bunu da aynı şekilde tüm saldırganlar bilir. Bu nedenle yukarıdaki loglarda da görebileceğiniz üzere "sa" hesabı da saldırılan hesaplardan biriydi. "sa" hesabının yerine başka kullanabileceğiniz "sysadmin" rolü üyesi hesaplar olduğundan emin olduktan sonra "sa" hesabını "Disable" duruma getirin veya "sa" hesabının adını değiştirin.

- Guest hesabını kullanmayın. Public kullanıcısına yetki vermeyin.

- Kullanıcılarınızın Login'ler için basit veya boş şifreler belirleyebilmesini engelleyin. 

- Mümkün olduğunca SQL Authentication yerine Windows Authentication'ı tercih edin.

- Yazılımcılarınız "SQL Injection" konusunda bilinçlendirilmeli. Uygulama arayüzlerinde kullanılan metin kutuları sadece almaları gerektiği türden ve uzunlukta değerler almalı. Örneğin sayısal bir değer kutusuna metin girilememeli veya TC Kimlik No alanına 11'den fazla karakter girilememeli.

- Uygulamalarınız sadece ihtiyacı olan uygulama kullanıcılarıyla erişsin veritabanına. Böylece uygulamanızdaki bir açık vasıtasıyla veritabanına ulaşılırsa, sadece uygulamanın ulaşabileceği veriye ulaşılabilir olsun, daha fazlası yapılamasın.

- Kod yazarken güvenlik (ve performans) açısından mümkün olduğunca dinamik SQL kullanmayın. Kullanacağınız zaman da dinamik SQL metinlerini güvenlik denetimine tabi tutmadan çalıştırmayın.  Örneğin "Doğum Yılı" veya benzer bir veri giriş kutusuna kesme işareti, "DROP, ALTER, GRANT, EXECUTE" gibi komutlar girilememeli.

- Uygulama yazarken kesinlikle ve hiçbir zaman son kullanıcının gireceği veriye güvenmeyin. Sadece güvenlik açısından değil, performans ve işlevsellik açısından da.

- Uygulama yazılırken sadece işlev değil, güvenlik (ve performans) odaklı yazılmalı. Yazılımcılar bu konuda net olarak bilinçli ve eğitimli olmalı. Projeler sadece işlevsellik ihtiyaçlarının giderileceği kadar sürelendirilmemeli. Yazılımcılar ve iş analistleri üstünde zaman baskısı olursa herkes sadece işlevselliğe odaklanır. Güvenlik ve performans testleri için de projelere süreler eklenmeli. Gerçekçi süreler! Zaman baskısı nedeniyle birçok şirkette hala doğru düzgün işlevsellik testi bile yapılmadan canlıya kod taşıması yapıldığını biliyorum maalesef.

- Her seviyedeki tüm kullanıcılara, sadece gerektiği kadar yetki verilmeli. Birçok ortamda gördüğümüz gibi tüm kullanıcılar "sysadmin" olmasın veya tek bir kullanıcıyla (genellikle "sa") tüm sistemi yönetmeye kalkmayın.

- Veritabanı yöneticisinin işlemleri dahil tüm kritik işlemleri 3. parti araçlarla veya SQL Server'ın sağladığı imkanlarla kayıt altına alın. Fakat birçok ortamda olduğu gibi sadece işlemleri kaydetmekle kalmayın, bu kayıtları otomatik olarak inceleyin ve anlam çıkartın ve sonuçlar için alarmlar ve raporlar ürettirin. 

- Görevler ayrılığı ilkesini işletin. Domain veya Windows yöneticileri için "sysadmin" rolüyle kullanıcılar olmadığından emin olun. Mümkünse herkes kendi işini yapsın. Örneğin bir önceki maddede bahsettiğim kayıt mekanizmasını hem kuran, hem yöneten aynı kişi olmamalı. Kayıt altına alınan işlemler değiştirilememeli.

- Sisteminizde her zaman neyin normal, neyin anormal olduğunu bilmelisiniz. Nasıl performans için bir referans hattınız varsa (var, değil mi?), güvenlik için de bir referans hattınız olmalı. Örneğin özellikle çok kritik tablolardan toplu sorgulamalar yapılmasını istemeyebilirsiniz ve böyle bir şey olduğunda haberdar olmak isteyebilirsiniz. Böyle tabloları belirleyin ve gerekli alarm mekanizmalarını kurun.

- Yazılımcılar, iş analistleri ve diğer personel uygulama kullanıcılarının şifrelerini bilmemeli. Bu bilgiler (Connection String) şifreli saklanmalıdır.

- Yazılımcılar, iş analistleri ve diğerlerinin doğrudan canlı sunuculara uygulama kullanıcılarının bilgileri ile bağlanamamasını sağlayın. Canlı sunuculara uygulama kullanıcıları kullanılarak ancak uygulama sunucularından veya ilgili sunuculardan ve uygulamalar aracılığıyla gelinebilmeli.

- Mümkünse canlı ortamınız için ağ bölümü ile koordineli çalışarak IP kısıtlaması koydurtun. Canlı ortamınıza mümkünse sadece belli IP adreslerinden/bloklarından (uygulama sunucuları) gelinebilsin.

- Gerek canlı ortamınız, gerekse geliştirme ve test ortamınızdaki hassas verilerinizi maskeleyin. Sadece yetkili kişiler, görmeleri gereken verilerin, görmeleri gereken kısımlarını görebilsinler. Hem bir veri sızıntısı durumunda ilgili, ilgisiz herkes zan altında kalmamış olur, hem saldırganların işi zorlaşmış olur, hem de olası sızıntının nereden kaynaklanabileceği hakkında inceleme yapacağınız daha dar bir alan olur.

- Veritabanı yedeklerinizi de canlı ortamınızı koruduğunuz gibi koruyun. Mümkünse yedeklerinizi şifreleyin (Backup Encryption SQL Server 2014 ile geldi). Yedeklere kimlerin erişebildiği net ve sınırlı olmalı. Ayrıca mümkünse kimlerin eriştiğinin kaydı tutulmalı ve raporlanmalı.

- SQL Server servis hesaplarınız olarak Local System gibi geniş yetkilere sahip hesapları kullanmayın. Eğer bir Domain hesabı kullanacaksanız bu normal bir "Domain User" hesabı olsun mesela.

- CLR veya xp_cmdshell gibi aktif olarak kullanılmayacak hiçbir özelliği etkinleştirmeyin. Kullanmayacağınız hiçbir SQL Server servisini veya uygulamayı veritabanı sunucunuza kurmayın.

- Daha ileri seviye güvenlik tedbirleri için örneğin diskteki veriyi ve yedekleri korumak için Transparent Data Encryption özelliğini kullanmayı düşünün. (İleri seviye. Enterprise Edition gerektirir.)

- Veriyi hareket halindeyken (uygulama ve veritabanı arasında gidip geliyorken) ve veri veritabanında dururken şifreli olsun istiyorsanız SQL Server 2016 ile birlikte gelen Always Encrypted özelliğini kullanmayı düşünün. (İleri seviye, her senaryo için uygulanabilir değil. Enterprise Edition gerektirir.)

- Kullandığınız SQL Server versiyonunun güncel sürümlerini kullandığınızdan emin olun.

- Güvenlik haberlerini yakından takip edin, sadece yazılımlarınızı değil, kendinizi de güncel tutun.

Unutmayın, güvenlik sadece ağ katmanı veya daha çok bütçeniz varsa güvenlik bölümlerinde kullanılan pahalı araç gereçlerle sınırlı değildir. Diğer katmanlardan bağımsız olarak sadece veritabanında alacağınız önlemler de yeterli değildir. Geliştirdiğiniz ve kullandığınız uygulamalarınız da kesinlikle bir istisna değildir, olamaz. Güvenlik baştan sona bir bütündür, şirket sekreterinden girişteki güvenliğe, finans müdüründen yazılım mimarına kadar bir takım işidir. Bu katmanlar zincirindeki en zayıf halkanız kadar güçlüdür güvenliğiniz.


Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com