Joomla 3.7.0'da SQL Injection Fix

Joomla 3.7.0'da SQL injection Fix

Son zamanlarda joomla topluluğu bir güvenlik zafiyeti buldu bu statik bir güvenlik açığı olduğunu biliyoruz. Bende bu açığı biraz inceleme fırsatı buldum ve zafiyeti nasıl fixlememiz gerektiğini elimden geldiğince göstermek istiyorum.

http://example.com/joomla/index.php?option=com_fields&view=fields&layout=modal& list[fullordering]=exploitation_code





Detect the SQL Injection Vulnerability with a DAST Tool

Açıkta yetkisiz olarak erişile bilen alanların varlığını daha önce bir çok defa keşfedilmiştir. Ayrıca Xss zafiyetinin de olduğunu daha önceden bildiğinizi varsayıyorum.

Genel olarak tarama yaptığınız zaman sıkıntısı çok fazla sürecektir bu yaklaşık olarak 12 saati aştığını bilmenizde fayda var fakat sorgu sayısını azalta biliyorsunuz ve zamanı kısalta bilirsiniz.

Ben sizin için bir araç söylemek istiyorum Qualys WAS aracı ile tarama sonuçlarını görebiliyorsunuz.

POST: http://example.com/Joomla_3_7_0/administrator/index.php?option=com_content&view=articles
Content-Type: application/x-www-form-urlencoded
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn
Data: filter[search]=test&list[fullordering]=%20%2B%20(SELECT
%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20&list[limit]=
20&filter[published]=&filter[category_id]=&filt
er[access]=&filter[author_id]=&filter[language]=&
filter[tag]=&filter[level]=&batch[language_id]=&
batch[assetgroup_id]=&batch[category_id]=&batch[mov
e_copy]=m&batch[tag]=&limitstart=0&task=&
boxchecked=0&b3f17395d768016d233d9e467ae2edb0=1

fullordering görüldüğü gibi Sql injection saldırısına açık olduğunu görmekteyiz.

 [fullordering]=%20%2B%20

 %20%2B%20(SELECT%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20

 uyku moduna geçiyor 28 saniye boyunca sistem uyumaya başlıyor. Sadece Bu kadarda değil aslında daha fazlası olduğu göreceksiniz bunun için biraz daha zaman harcıyorsunuz ama yorulmayın ben sizin için iki önemli açığı daha belirtmek istiyorum joomla için.

 Bazı isteklerde CSRF belirteci çalışmıyor Joomla !

Birincisi, CSRF belirtecinin bu işlev için gerekli olmamasıdır. WAS motoru tarafından keşfedilen PoC isteğinde, b3f17395d768016d233d9e467ae2edb0 parametresi CSRF belirteci gibi davranıyor. Bir CSRF belirteci, oturum başına üretilen ve değiştirilen rasgele bir dizeden oluşur; bu, CSRF saldırılarını azaltmak için sağlam bir yöntemdir . Bununla birlikte, PoC talebinde CSRF belirteci gerekli değildir. Başka bir deyişle, istek aşağıda belirtildiği gibi b3f17395d768016d233d9e467ae2edb0 parametresinin yokluğunda sunucu tarafından gönderilip işlenebilir :

POST: http://example.com/Joomla_3_7_0/administrator/index.php?option=com_content&view=articles
Content-Type: application/x-www-form-urlencoded
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn
Data: filter[search]=test&list[fullordering]=%20%2B%20(SELECT
%200%20FROM%20(SELECT%20SLEEP(28))qsql)%20&list[limit]=
20&filter[published]=&filter[category_id]=&filt
er[access]=&filter[author_id]=&filter[language]=
&filter[tag]=&filter[level]=&batch[language_id]
=&batch[assetgroup_id]=&batch[category_id]=&
batch[move_copy]=m&batch[tag]=&limitstart=0&
task=&boxchecked=0

CSRF belirteci gerektirmemek Joomla tarafından bilinçli olarak yapılmış gibi görünüyor. Sanırım bu yapıldı çünkü arama genellikle hassas bir eylem değildir. SQL injection zayıflığı yokluğunda CSRF korumasına ihtiyaç duyulmaz. Öte yandan, SQL injection ancak bu eylem için CSRF koruması uygulanmadığından mümkündür. Bu durumda bu güvenlik açığı ve uygulamanın sömürülebilir.

Yöntem Değişimi 

İkinci güvenlik sorunu, yöntem değişimi nedeniyle oluşur ve bu güvenlik açığından bir saldırganın yararlanmasına daha kolay hale getirir..

Yöntem Değişimi güvenlik açığı birçok web yöneticisi tarafından unutulmuş veya yok sayılmıştır . Yöntem değişikliği, bazı açıkları kullanmak için imkansız olsa da, başarılı bir saldırı için diğer açıklarla birleştirilebilir..

Sorun, Joomla sunucusunun arama eylemini GET isteği veya POST isteği olarak işleyeceğidir.  POST parametresinde XSS'nin kullanılması, bir üçüncü taraf sunucusunda GET'ten POST'a bir komut dosyası gerektirir ve bir kullanıcının yararlanacağı şüpheli bir bağlantıyla sonuçlanır." Bir GET isteği 3'ü gerektirmediğinden Rd parti sunucusunda, saldırıyı hedefleyen kullanıcıyı ihbar etmek için şüpheli bir bağlantı yok. Bir saldırganın yalnızca güvenlik açığının bulunduğu bağlantıyı oturum açmış olan yönetim kullanıcısına göndermesi ve kullanıcıyı şu bağlantıyı tıklatması için kandırması gerekir:

GET: http://example.com/Joomla_3_7_0/administrator/index.php?
option=com_content&view=articles&filter[search]=
test&list[fullordering]=%20%2B%20(SELECT%200%20FROM%20
(SELECT%20SLEEP(28))qsql)%20&list[limit]=20&filter
[published]=&filter[category_id]=&filter[access]=
&filter[author_id]=&filter[language]=&filter
[tag]=&filter[level]=&batch[language_id]=&batch
[assetgroup_id]=&batch[category_id]=&batch[move_cop
y]=m&batch[tag]=&limitstart=0&task=&boxchecked=0
Cookie: 43cebfbc4cfd7f8b22410edf3e395a17=73kk9nqs40poi0c6ctec25rvn

Joomla Güvenlik Acığı Sonuç

Sonuç olarak sunucuya kadar zarar verile bildiğini görmekteyiz fakat her bulguyu yazamıyoruz bunun için yanlış anlamayın bazı olayları resmedilmesi sorunlar doğurmaktadır. Bunun için yukarıda olan kodları deneyebilirsiniz. Qualys WAS araçlarından destek alarak kontrol ederek açıkları fixleye biliyorsunuz. unutmadan zararsız görülen güvenlik açıkları büyük ve yıkıcı sorunları ortaya çıkarmaktadır. Buna benzer açıkların devlet sitelerinde olduğunu görmekteyim ve bunun için gerçekten üzülmekteyim ufak dorklar ile birlikte bir çok site zarar verilebiliyor bunun için lütfen güncellemeleri ihmal etmeyin dork yazıldığı an bir çok devlet kurumunun zafiyet barındırdığı görülmektedir.

Teşekkürler : qualys ;)