25 Eyl, 2021

[:tr]Microsoft Exchange Hatası 100.000 Kullanıcının Windows Kimlik Bilgilerini Ortaya Çıkarıyor[:en]VMware Warns of Ransomware Friendly Error on vCenter Server[:]

[:tr]

Microsoft Exchange’in autodiscover protokolü uygulanmasında yamasız bir tasarım hatası, dünya çapında Windows etki alanları için yaklaşık 100.000 oturum açma adı ve parolasının sızmasına neden oldu.

Guardicore’dan Amit Serper teknik raporunda; Autodiscover ciddi bir güvenlik sorunudur, çünkü bir saldırgan bu tür etki alanlarını kontrol edebiliyorsa veya aynı ağdaki trafiği ‘koklama’ yeteneğine sahipse, HTTP temel kimlik doğrulaması alan kimlik bilgilerini yakalayabilir.

Ayrıca saldırgan kişinin büyük ölçekte DNS zehirleme yetenekleri varsa, bu Otomatik Keşfet TLD’lerine [üst düzey etki alanları] dayalı büyük ölçekli bir DNS zehirlenmesi kampanyası oluştururken sızdırılan parolalar ve kullanıcı bilgileri sayesinde sistematik olarak DNS saldırılarında kullanabilir.

Autodiscover Nedir?

Autodiscover, kullanıcıların e-posta istemcilerini kurmak ve önceden tanımlanmış diğer ayarları almak için, yalnızca bir e-posta adresi ve parola kombinasyonunun kullanılmasına izin vererek, kullanıcıların Microsoft Outlook gibi uygulamaları minimum kullanıcı girişiyle yapılandırmasına olanak tanır.

Zayıflık Tam Olarak Nereden Kaynaklı?

Guardicore tarafından keşfedilen zayıflık, Autodiscover etki alanlarına yönelik web isteklerinin kullanıcının etki alanının dışına çıkması ve aynı üst düzey etki alanında sızdırılmasına neden olan POX (“düz eski XML”) XML protokolüne dayalı belirli Autodiscover uygulamasında bulunan zayıflıktan olduğunu belirtti.

Bir kullanıcının, e-posta adresi “kullanici@example.com” olduğu varsayalım.

Bu örnekte e-posta istemcisi, aşağıdaki e-posta etki alanı, bir alt etki alanı ve yol dizesi, başarısız olan bir ” back-off” algoritmasını başlatır.

“back-off’ mekanizması, bu sızıntının ana özelliğidir. Çünkü, her zaman etki alanının Autodiscover bölümünü çözmeye çalışıyor ve her zaman başarısız sonuçlanıyor. Yani, bir sonraki Autodiscover URL’si oluşturma girişiminin sonucu şöyle olacaktır;

‘https://Autodiscover.com/Autodiscover/Autodiscover.xml.‘ Bu, Autodiscover.com’un sahibi olan kişinin orijinal alana ulaşamayan tüm istekleri alacağı anlamına gelir.

Bunun sonucunda daha kötü oluşan senaryo ise, araştırmacılar istemciye OAuth veya NTLM gibi güvenli yöntemler yerine daha zayıf bir kimlik doğrulama şemasına (yani, HTTP Temel kimlik doğrulama) bir request’i içeren ve e-postayı isteyen bir “ol switcheroo” saldırısı geliştirdiler.

Bu saldırı türünün etki alanı, kimlik bilgilerini açık metin olarak gönderip, kimlik bilgilerini almaya dayanır.

Sonuç

Autodiscover’den kaynaklı sızıntıları azaltmak için, Exchange kullanıcılarının temel kimlik doğrulama desteğini devre dışı bırakmaları ve olası tüm Autodiscover.TLD etki alanlarının bir listesini yerel bir ana bilgisayar dosyasına veya güvenlik duvarı yapılandırmasına eklemeleri önerilir.

Saldırganlar çoğu zaman ister teknik ister sosyal mühendislik yoluyla olsun, çeşitli teknikler uygulayarak kullanıcıların kimlik bilgilerini kendilerine göndermelerini sağlamaya çalışacaklardır. Ancak bu olay bize, BT departmanının e-posta istemcisi yapılandırması ile ilgili operasyonlarını düzene sokmayı hedefleyen bir protokolle;

Parolaların, BT veya güvenlik departmanından hiç kimsenin haberi olmadan, kuruluşun dışına sızdırılabileceğini gösteriyor. Doğru segmentasyonun ve Sıfır Güvenin önemini bu olayda anlamış oluyoruz.

Bu yazı bilgi amaçlı olup, Exchange saldırılarına karşı farkındalığı arttırabilmek ve bu doğrultuda tedbirler alınabilmesi için hazırlanmıştır.

KVKK, ISO 27001, Bilgi ve İletişim Güvenliği Rehberi, ISO 27701, Bilgi Güvenliği, Siber Güvenlik ve Bilgi Teknolojileri konularında destek ve teklif almak için lütfen

[:en]On September 21, 2021, VMware firm issued a new bulletin alert for 19 vulnerabilities in vCenter Server and Cloud Foundation devices that an attacker could exploit to gain control of an affected system.

The most pressing of these is a random file upload vulnerability in the Analytics service (CVE-2021-22005) that affects vCenter Server 6.7 and 7.0 deployments.

It was reminded that malicious actor with access to vCenter Server port 443 network can run malicious code on vCenter Server by uploading a specially prepared file.

While VMware has released workarounds for the flaw, the company cautions that these are temporary fixes until updates are deployed.

CyberArts cyber security team informed many local companies via e-mail on August 26, about the vulnerabilities related to VCenter in VMware’s bulletin published on September 21, 2021.

Although many companies we have contacted have responded with courtesy regarding the notification, we have observed that they did not take the necessary precautions adequately, considering the criticality of the situation.

After the bulletin published by VMware, we actually saw how right we were.

So How Did CyberArts Gain Intelligence About These Vulnerabilities?

On 27 July 2021, one of the Turkish telecommunication companies applied to our company for consultancy services for Pentest and KVKK processes after a data breach. Afterwards, we agreed and started the Pentest processes immediately. As a result of our tests, it was determined that the application exposed to the breach did not contain critical vulnerabilities that could experience a data breach.

Then, like some companies, we did our test, instead of saying we’re done, we started our cyber intelligence studies to shed light on the event. We continued these processes anonymously.

Subsequently, the threat actor, who posted the data breach of the institution in one of the dark web forums where the databases were sold, began to publish the data of other institutions with the same nickname and similar screenshots. We took this threat actor under the spotlight and came to a certain point by analyzing his posts and screenshots.

Afterwards, negotiations were made with the threat actor. As a result of negotiations, the situation was dominated, and we got information on which system the data breach occurred and how it happened. It has been determined that the institution we serve originates from the service provider, and its data has been removed from the market without paying a single crypto currency to the threat actor other than the service fee.

Immediately after, we contacted companies that we could identify using this service via e-mail.

The full list of flaws patched by the virtualization services provider is as follows:

  • CVE-2021-22005 (CVSS score: 9.8) – vCenter Server file upload vulnerability
  • CVE-2021-21991 (CVSS score: 8.8) – vCenter Server local privilege escalation vulnerability
  • CVE-2021-22006 (CVSS score: 8.3) – vCenter Server reverse proxy bypass vulnerability
  • CVE-2021-22011 (CVSS score: 8.1) – vCenter server unauthenticated API endpoint vulnerability
  • CVE-2021-22015 (CVSS score: 7.8) – vCenter Server improper permission local privilege escalation vulnerabilities
  • CVE-2021-22012 (CVSS score: 7.5) – vCenter Server unauthenticated API information disclosure vulnerability
  • CVE-2021-22013 (CVSS score: 7.5) – vCenter Server file path traversal vulnerability
  • CVE-2021-22016 (CVSS score: 7.5) – vCenter Server reflected XSS vulnerability
  • CVE-2021-22017 (CVSS score: 7.3) – vCenter Server rhttpproxy bypass vulnerability
  • CVE-2021-22014 (CVSS score: 7.2) – vCenter Server authenticated code execution vulnerability
  • CVE-2021-22018 (CVSS score: 6.5) – vCenter Server file deletion vulnerability
  • CVE-2021-21992 (CVSS score: 6.5) – vCenter Server XML parsing denial-of-service vulnerability
  • CVE-2021-22007 (CVSS score: 5.5) – vCenter Server local information disclosure vulnerability
  • CVE-2021-22019 (CVSS score: 5.3) – vCenter Server denial of service vulnerability
  • CVE-2021-22009 (CVSS score: 5.3) – vCenter Server VAPI multiple denial of service vulnerabilities
  • CVE-2021-22010 (CVSS score: 5.3) – vCenter Server VPXD denial of service vulnerability
  • CVE-2021-22008 (CVSS score: 5.3) – vCenter Server information disclosure vulnerability
  • CVE-2021-22020 (CVSS score: 5.0) – vCenter Server Analytics service denial-of-service vulnerability
  • CVE-2021-21993 (CVSS score: 4.3) – vCenter Server SSRF vulnerability

Conclusion:

For ransomware groups, areas such as file upload appear to be a friendly place to infect ransomware.

VMware pointed to the growing threat of ransomware attacks, adding that security solutions needed to be addressed, considering the assumption that “the safest stance” threat actors had already taken control of a desktop and a user account through phishing or spear-phishing attacks.

VMware has said that if an account has been compromised, for example, by a phishing attack, it means that the attacker “can already access the vCenter Server from within a corporate firewall, and time is of the essence for action to be taken there.”

Based on the example given by Vmware, our thinking as CyberArts is;

To fully understand whether you are affected by these vulnerabilities, it is recommended to review the vulnerabilities as incident-response before they are released or covering the previous dates that patches were released. Afterwards, it is necessary to continue the Extensive Pentest processes in order to detect current vulnerabilities.

Because these patches are not released as soon as vulnerabilities occur. Therefore, a violation may have occurred until the patching process. We recommend looking at it from a wide-angle perspective.

Our thoughts on how these patches should be made;

It will vary for organizations with different environments, risk tolerance, security controls, and risk mitigation strategies.

“It is up to you to decide how to proceed,” VMware said. However, he said he still strongly recommends that companies take action given the seriousness.[:]

İçerik Hakkında:
Sosyal Medyada Paylaş:
Facebook
Twitter
LinkedIn
Telegram

İlgili Yazılar