Potencjalną lukę opisał, jeszcze w maju, James Forshaw, badacz z Google'owskiej grupy Project Zero, specjalizującej się w "polowaniu" na luki w oprogramowaniu innych firm. Żeglując po zawiłej dokumentacji i szeregu implementacyjnych wyjątków, Forshaw odkrył obsługę flag (opisywanych jako FLAG_HAS_ENTERPRISE_CAP) umożliwiających skonteneryzowanym aplikacjom uzyskiwać dostęp do zaawansowanych funkcji.
Jedną z owych funkcji jest dostęp do infrastruktury SSPI, zajmującej się przechowywaniem i stosowaniem poświadczeń tożsamości. Skonteneryzowane aplikacje miały z definicji nie mieć do nich dostępu i zamiast tego korzystać z innych mechanizmów uwierzytelniania, jak zwykle jednak Microsoft musiał wprowadzić "wyjątek dla klientów biznesowych". Weryfikacje wykonywane w ramach udzielania dostępu do wyjątków okazały się na tyle słabe, że pozwalają otrzymać takie pozwolenie w ciemno, a w dodatku ominąć uwierzytelnianie.
Zbyt duże, by łatwo naprawiać
Proces weryfikacji tożsamości w protokole SMB jest tak nieziemsko rozbudowany i podatny na okoliczności, że istnieje mnóstwo ścieżek, na których da się "zmusić" system do zaufania, efektywnie omijając uwierzytelnianie. Ogrom implementacji SMB/RPC/DCOM/WMI/CIM dawno już wykroczył ponad rozmiar, przy którym było możliwe zlikwidowanie niektórych z nich.
Microsoft jest więc zmuszony ustawicznie poprawiać błędy w Windows, bo alternatywą jest usunięcie zgodność, a to zgodność, a nie jakość, sprawia że Windows NT na siebie zarabia. Tak było i tym razem, ale autor zgłoszonej podatności ogłosił, że błąd wcale nie został w pełni załatany. Słabe mechanizmy kontroli "pozwolenia na wyjątki" wciąż umożliwiają podanie takiego SPN (Subject Principal Name), że spełni on wymagania do przepustki, choć nie powinien.
Ponieważ błąd zgłoszono w ramach Project Zero, dotyczy go stosowany tam proces udostępniania informacji na temat odnalezionych luk (disclosure). Niekompletne łatki "nie zatrzymują stopera" i nie zaliczają producentowi dodatkowego czasu na naprawę przed upublicznieniem.
