Tag Archives: security

A Security Issue in Android That Remains Unfixed – Pull-down Menu On Lock Screen

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

Having your phone lying around when your kids are playing with everything they find is a great security test. They immediately discover new features and ways to go beyond the usual flow.

This is the way I recently discovered a security issue with Android. Apparently, even if the phone is locked, the pull-down menu with quick settings works. Also, volume control works. Not every functionality inside the quick settings menu works fully while unlocked, but you can disable mobile data and Wi-Fi, you can turn on your hotspot, you can switch to Airplane mode.

While this has been pointed out on Google Pixel forums, on reddit and Stack Exchange, it has not been fixed in stock Android. Different manufacturers seem to have acknowledged the issue in their custom ROMs, but that’s not a reliable long-term solution.

Let me explain why this is an issue. First, it breaks the assumption that when the phone is locked nothing works. Breaking user assumptions is bad by itself.

Second, it allows criminals to steal your phone and put in in Airplane mode, thus disabling any ability to track the phone – either through “find my phone” services, or by the police through mobile carriers. They can silence the phone, so that it’s not found with “ring my phone” functionality. It’s true that an attacker can just take out the SIM card, but having the Wi-Fi on still allows tracking using wifi networks through which the phone passes.

Third, the hotspot (similar issues go with Bluetooth). Allowing a connection can be used to attack the device. It’s not trivial, but it’s not impossible either. It can also be used to do all sorts of network attacks on other devices connected to the hotspot (e.g. you enable the hotspot, a laptop connects automatically, and you execute an APR poisoning attack). The hotspot also allows attackers to use a device to commit online crimes and frame the owner. Especially if they do not steal the phone, but leave it lying where it originally was, just with the hotspot turned on. Of course, they would need to get the password for the hotspot, but this can be obtained through social engineering.

The interesting thing is that when you use Google’s Family Link to lock a device that’s given to a child, the pull-down menu doesn’t work. So the basic idea that “once locked, nothing should be accessible” is there, it’s just not implemented in the default use-case.

While the things described above are indeed edge-cases and may be far fetched, I think they should be fixed. The more functionality is available on a locked phone, the more attack surface it has (including for the exploitation of 0days).

The post A Security Issue in Android That Remains Unfixed – Pull-down Menu On Lock Screen appeared first on Bozho's tech blog.

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. Къш бе!