Ostatnio na virtualstudy.pl była prezentacja Pauli Januszkiewicz o Technikach hakerskich dla adminów IT,  gdzie przedstawiono rozwiązanie którego szukałem od jakiegoś czasu.

Chodzi dokładnie o wyciąganie haseł do kont uruchamiających serwisy.

Za pomocą narzędzia napisanego przez Michała Grzegorzewskiego jest to dziecinnie proste.

Po szczegóły techniczne odsyłam do bloga Michała (http://zine.net.pl/blogs/mgrzeg/) gdzie również znajdziecie tool SAPD.

A poniżej krótki pokaz:

Najpierw odpalamy konsole z konta systemowego:

Psexec -i -s cmd.exe

Następnie uruchamiamy tool sapd z nazwą serwisu który jest uruchamiany z konta innego niż systemowe.

Sapd.exe nazwa_uslugi

I dostajemy hasełko. Łatwo, szybko i przyjemnie :-)

Czasami się zdarza w vmware server 2.0, że po przeniesieniu wirtualnej maszyny z jednego komputera na inny, wyskakuje taki błąd przy próbie dodania jej do inventory:

Unknown (Invalid)

Przyczyną tego błędu jest to, że VM’ka została utworzona w systemie z ustawionymi lokalami na np. polski, i przeniesiona na system gdzie są ustawione inne lokale, np. angielskie

Wystarczy wtedy zmienić w plikach vmx (oraz vmsd) linijkę:

.encoding = “<tutaj kodowanie>”

Czyli np. .encoding = “windows-1252″ na .encoding = “windows-1250″

Potem wystarczy tylko dodać ponownie VM’ke do inventory i powinno wszystko działać.

Ostatnio przyjechał do nas projektor Dell 4610X - małe czarne pudełko z antenką wifi.

Działa to w ten sposób, że użytkownik łączy się za pomocą przeglądarki z urządzeniem, ściąga aplikacje, uruchamia … i już można prowadzić prezentacje wyświetlając jednocześnie obraz z 4 komputerów - fajnie….. fajnie by było… gdyby  nie to, że wpadliśmy z kumplem na pomysł  aby przetestować czy ta aplikacja będzie działać z maszyn w oddziale z innego miasta (oddziały połączone dedykowanym łączem, na brzegach ISA 2006) i czy nie trzeba będzie rzeźbić czegoś na firewallach.

Tak więc, za wiele nie myśląc, otworzyliśmy pierwszą lepszą aktywną sesję RDP z maszyną z innego miasta, uruchomiliśmy przeglądarkę, ściągnęliśmy soft, odpaliliśmy i …. świat zwolnił - praca po RDP przypominała pracę na modemie 56K z włączonymi wszystkimi wodotryskami.  Ekran odświeżany co kilkanaście sekund, reakcja myszki nie wiele szybsza. Mówiąc krótko - nie da się pracować.

Eeee - pomyśleliśmy - pewnie trafiliśmy akurat na jakiś pik, albo chłopaki po drugiej stronie akurat coś robią na serwerze. Spróbujmy na innym… a więc szybkie logowanie, przeglądarka, uruchomienie softu …. I kurde znowu to samo - wszystko zwalnia niemiłosiernie …  :/

Podsumowując: rozwalone dwa serwery produkcyjne w niewiele ponad 2 minuty - myślę, że to całkiem niezły wynik ;-)

No ale koniec śmiechów - trzeba to przecież jakoś naprawić.

Oczywiście próba odinstalowania aplikacji nic nie pomogła, wyczekiwane okienko czasowe  na  restart serwerów również. Fiaskiem skończyły się też telefony do supportu Dell’a i zaklinanie laleczki voodoo.

Dwa dni później, po postawieniu testowej wirtualki i prześledzeniu zmian jakie wprowadziła ta aplikacja do systemu doszedłem co jest grane. Przyczyną okazało się zmienienie poziomu akceleracji dla RDP Display Driver (RDPDD.DLL)  przez aplikacje z projektora Della, a dokładniej nie przywracanie jej wcześniejszego stanu po odinstalowaniu aplikacji .

Wartość tą ustawia się w rejestrze, w gałęzi:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RDPDD\Device0

Wystarczy zmienić wartość Acceleration.Level (DWORD) na 0

0 - Pełna akceleracja

5 - Brak akceleracji

To tyle, jedna mała aplikacja wycięła mi dwa dni życia.

Swoją drogą, to nie udało nam się podłączyć projektora między miastami, ale to wbrew pozorom temat na zupełnie inną opowieść.

Mały quiz na koniec: która z sytuacji, z opisanych w tej historyjce, nie powinna się nigdy wydarzyć i świadczy o niekompetencji adminów? ;-)