Tag Archives: security

The Lack Of Native MFA For Active Directory Is A Big Sin For Microsoft

от Божидар Божанов
лиценз CC BY

Active Directory is dominant in the enterprise world (as well as the public sector). From my observation, the majority of organization rely on Active Directory for their user accounts. While that may be changing in recent years with more advanced and cloud IAM and directory solutions, the landscape in the last two decades is a domination of Microsoft’s Active Directory.

As a result of that dominance, many cyber attacks rely on exploiting some aspects of Active Directory. Whether it would be weaknesses of Kerberos, “pass the ticket”, golden ticket, etc. Standard attacks like password spraying, credential stuffing and other brute forcing also apply, especially if the Exchange web access is enabled. Last, but not least, simply browsing the active directory once authenticated with a compromised account, provides important information for further exploitation (finding other accounts, finding abandoned, but not disabled accounts, finding passwords in description fields, etc).

Basically, having access an authentication endpoint which interfaces the Active Directory allows attackers to gain access and then do lateral movement.

What is the most recommended measures for preventing authentication attacks? Multi-factor authentication. And the sad reality is that Microsoft doesn’t offer native MFA for Active Directory.

Yes, there are things like Microsoft Hello for Business, but that can’t be used in web and email context – it is tied to the Windows machine. And yes, there are third-party options. But they incur additional cost, and are complex to setup and manage. We all know the power of defaults and built-in features in security – it should be readily available and simple in order to have wide adoption.

What Microsoft should have done is introduce standard, TOTP-based MFA and enforce it through native second-factor screens in Windows, Exchange web access, Outlook and others. Yes, that would require Kerberos upgrades, but it is completely feasible. Ideally, it should be enabled by a single click, which would prompt users to enroll their smart phone apps (Google Authenticator, Microsoft Authenticator, Authy or other) on their next successful login. Of course, there may be users without smartphones, and so the option to not enroll for MFA may be available to certain less-privileged AD groups.

By not doing that, Microsoft exposes all on-premise AD deployments to all sorts of authentication attacks mentioned above. And for me that’s a big sin.

Microsoft would say, of course, that their Azure AD supports many MFA options and is great and modern and secure and everything. And that’s true, if you want to chose to migrate to Azure and use Office365. And pay for subscription vs just the Windows Server license. It’s not a secret that Microsoft’s business model is shifting towards cloud, subscription services. And there’s nothing wrong with that. But leaving on-prem users with no good option for proper MFA across services, including email, is irresponsible.

The post The Lack Of Native MFA For Active Directory Is A Big Sin For Microsoft appeared first on Bozho's tech blog.

DreamHost FAIL (another one)

от Ясен Праматаров
лиценз CC BY

DreamHost са пълни смешници! Казвал съм го и преди, но това вече прелива чашата. Единствената причина да не се махам от тях толкова време е, че все нямам време – имам доста неща за местене, не е просто едно блогче на уърдпрес. А, и другата причина е, че не са български хостинг. Не ми се задълбава в тая насока, но накратко аз доверие нямам по принцип на споделените хостинги, та камо ли ако са български. Всички oversell-ват, при това яко, масово нямат даже ssh, по-специализираната поддръжка е под всякаква критика, а и данните са ми в държава, управлявана от луди алчни нарцистични властолюбиви… хора.

Но за Дриймхост – вижте сега, казвате, че правите “Proactive Security Maintenance” чрез “(New Login Keys)”. Похвално, но:

1) нито е “proactive”, защото го пишете постфактум,

2) нито е “security”, защото НЕ Е и си е покана “елате ни направете MITM” и

3) що не вземете да се гръмнете с вашите циркулярни писма, в които пишете оригиналности и тъпотии, а когато има нещо сериозно – правите проактивно действие, което нито е действие, нито е проактивно.

Толкова съм потресен, че чак не ми се обяснява. Нямам думи направо. Който знае за какво става дума или има време да порови, ще разбере… Вижте, дори уеб-страницата, на която е “обявлението”, не е през SSL, а си е по чист HTTP. Даже когато го видях снощи, съобщението си беше с цитиран ключа на съответната система, която за пример са достъпили… После са го заменили с “removed for security reasons”… Всъщност защо не пуснахте ssh id-то? Щото трябва да пуснете тези на всичките ви хостове, не само на този, който сте пробвали в примера, и това ви се е видяло много като текст? В коментарите някой се беше опитвал да трие ред с номер 10278, който също е от примерната система на админа в Дриймхост… (Сега поне знаем, че някой от техните админи има поне 10278 хоста в known_hosts, макар че какво ни интересува.)

Имат ми пощенския адрес. Даже ми имат два. Имат списък за циркулярни писма, с които спамят потребителите си за глупости. Имат административен панел, в който се влиза с парола и който е по https, където можеха да направят някаква автоматика за това… или изобщо ако бяха пуснали съобщението в админ-панела, щеше да е сто пъти по-добре. Защото вече си влязъл, вече си се доверил на панела. А така, в някакво си сайтче?

Чак ми става кофти, че такива смешници се опитват да се набъркат в OpenStack. Къш бе!

Аматьори.