Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
říjen 21
Doplňkové poznámky ke večerjší konferenci #HackerFest

Jak zamezit spouštění PowerShell skriptů

Včera jste viděli množství PowerShell útoků. To v člověku automaticky vyvolává otázku - není tedy lepší ten PowerShell nějak zakázat?

Zaprvé není. Je to úplně jedno. Cokoliv uděláte v jazyce PowerShell, uděláte klidně přímo v C#. Zkompilujete a spustíte normálně ve formě exe. Ani tak vám to žádný antivirus nebude blokovat. Kdyby to chtěl blokovat, dělal by to i v případě PowerShellu. Důvod, proč to neblokoval, byl jedině ten, že to prostě blokovat nechtěl. Antiviry detekují jen a pouze známé binární signatury.

Například můj keylogger, co jsem napsal v PowerShellu, vlastně vůbec není v PowerShellu. Když se do něho podíváte, zjistíte, že je to celé v podstatě hlavně C# kód vložený dovnitř pomocí here-string. Pokud se tento kód spouští z jazyka PowerShell, stejně se musí zkompilovat.

PowerShell normálně ten text jen vyextrahuje a spustí na tom C# kompilátor (program csc.exe máte normálně jako součást instalace .NET frameworku). Vznikne DLL někde v tempu, tu si PowerShell zase načte zpět a takhle ji používá. Možno v klidu sledovat například pomocí process monitoru (procmon), který stáhnete ze SysInternals.

Všimli jste si během mé přednášky, že by to vadilo některému antiviru? Ten vznik DLL? Binární knihovny, která keylogeruje? Ne. Ani pod úplně obyčejným uživatelem.

Všimli jste si, že by antiviru vadilo, že jsem si ze sítě stáhl EXE soubor. Nebyl podepsán firmou Microsoft a přitom jeho popisek byl úplně přesně stejný, jako popisek všech Windows exe? Není to podezřelé?

Tak tolik asi k tzv. heuristice, kterou ty antiviry údajně dělají.

Zadruhé, pokud byste ho zakázat chtěli, musíte mít na paměti, že to moc nevynutíte. Rozhodně nestačí použít Set-ExecutionPolicy. Tohle nastavení se dá obejít přímo parametrem -ExecutionPolicy programu powershell.exe. Stačí tedy spouštět vaše skripty nepřímo z příkazové řádky, nebo z BAT.

Pokud se chcete zbavit i parametru -ExecutionPolicy, musíte ten zákaz udělat přes group policy z domény. Tam je to potom silnější. Nastavení najdete v počítačové části GPO objektu zde:

Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Turn on Script Execution = Disabled

Nesmíte povolit podepsané skripty (allow only signed scripts). I obyčejný uživatel si může nainstalovat svoji vlastní důvěryhodnou autoritu a svůj vlastní podpisový (code signing) certifikát a jupí. Takže byste to museli úplně zakázat.

A to je stejně na nic. PowerShell příkazovou řádku si zločinec může spustit vždycky bez ohledu na politiku. Skript do ní prostě jenom překopíruje ze schránky a nikdo mu v tom bránit nebude. To byste museli zakázat úplně powershell.exe. Na to máte například Software Restriction Policies (SRP) už od Windows XP. Nebo na Enterprise edicích Windows je v podstatě stejný AppLocker (Application Control Policies).

Nakonec si uvědomte, jak jednoduché je stát se lokálním administratorem a prostě tahle nastavení z registrů vymazat. Při nejhorším offline.

Takže není cesta. Prostě zapomeňte. A začněte se chovat bezpečně. To byla taky ta zpráva, kterou moje přednáška měla udělovat.

Skrytá registrová hodnota a další poznámky

Zmiňoval jsem se také krátce o ukládání PowerShell skriptů v registrových hodnotách. Tak k tomu jen doplnění.

Ano, do řetězcové hodnoty v registrech od Windows Vista se vleze neomezeně :-) Omezeně jen hláškou "insufficient system resources", asi kvůli málo paměti? Na mé testovací virtuálce jsem do jedné registrové hodnoty vecpal 290 MB.

Nebo může ten skript nacpat rovnou do jména té registrové hodnoty. Jméno může mít až 16383 znaků. Jenom to musí založit až z PowerShell 3.0, protože dvojka uměla jenom 255 znaků na jméno hodnoty. Má to navíc pro útočníka pěknou vlastnost. Regedit hodnoty, jejichž jméno je delší než 255 znaků, prostě nezobrazuje. Stačí to udělat delší a nebude to vůbec přes regedit vidět.

Samozřejmě vzniká otázka, jak to tam hacker vloží, aby se v tom neobjevovaly speciální znaky. Případně, aby to nebylo možno na první pohled považovat za PowerShell. Ne že bych očekával od nějakého antiviru, že by se na to soustředil. Oni se většinou soustředí hlavně na BSOD, zátuhy, točení procesoru a mazání kdoví čeho.

Tak jak? Útočník to zkonvertuje na Base64 a má to. Bez mezer a většiny speciálních znaků, jenom US-ASCII znaky zapsatelné z klávesnice. Bleskovka zde:

[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('text, co nepujde jenom tak precist'))
# result: dGV4dCwgY28gbmVwdWpkZSBqZW5vbSB0YWsgcHJlY2lzdA==

Závěr

Ano, pochopili jste to dobře. Žádný antivirus vás neochrání před cíleným, ručně provedeným útokem člověka, který sedí u vás v síti a ví co dělá. Nevěřte řečem o heuristice. To je totální nesmysl.

A dávejte si prostě jenom pozor!

říjen 20
Prezentace z konference #HackerFest2014

Moje prezentace z naší konference GOPAS HackerFest 2014 je k dispozici ke stažení tady: GOPAS HackerFest 2014

říjen 15
Mají distribuční skupiny SID?

Včera jsem dostal podnět k napsání tohoto článečku na základě tohoto, kde někdo píše, že distribution group se dá v SharePoint údajně použít pro přidělení přístupu. Je to tam tak jednoduše mimochodem zmíněno, takže se stalo, že autorské emvípí (MVP) zmátlo jiné emvípí a tak to třetí emvípí musí napravit.

Nedá. Oficiální článek o verzi SharePoint 2013 je zde. Ano, Microsoft poskytuje návod, jak údajně "expand a distribution group and add the individual members to a SharePoint group" - například tady.

Když si ten support přečtete, tak pochopíte, že se jedná o ruční vybrání seznamu emailových adres z té skupiny a natvrdo naplnění do SharePointu. Já se nehádám, to samozřejmě jde udělat pomocí PowerShell skriptíku na 2 řádky.

Ale fakt je, že distribution group se pro zabezpečení použít nedá. Podívejme se proč.

A současně zničme populární fámu, že distribuční skupina nemá SID.

Distribution group má SID

Ano. Distribuční skupina je v podstatě úplně stejná skupina v Active Directory LDAP databázi, jako jakákoliv jiná bezpečnostní skupina. Je to typ objektu (class) group. Má objectSID atribut a ten se taky naplní unikátním SIDem hned při vytváření. SID se generuje běžným unikátním způsobem za použití RID FSMO master role.

Poznámka - o RID managerovi si můžete přečíst v několika mých starších poustech jako je tady, zde, tuten, tenhleten nebo tudlenc.

Jeden rozdíl mezi security group a distribution group je hodnota atributu groupType. V případě distribution group ne-obsahuje zapnutý bit 0x80000000, který tam je jen pro security group (viz. ADS_GROUP_TYPE_ENUM). Druhý rozdíl je v atributu sAMAccountType, kde je pro distribution group hodnota 268435457 (NON_SECURITY_GROUP_OBJECT), zatímco security group tam má hodnotu 268435456 (GROUP_OBJECT).

Jinak je to z pohledu LDAP úplně stejné.

Distribution group se nevyhodnocuje při ověřování a nepřidává se do access token

Proč by se tedy distribution group nedala použít k zabezpečení? No ona by se i dala. SID má, takže použít se v podstatě dá. Jenom je vám to na nic. Protože v této skupině v podstatě "nejste".

Při příhlašování si DC vytváří seznam vašich skupin. Tento seznam potom putuje přes NTLM, nebo Kerberos tiket do uživatelova access token. O téhle skupině jsem tu psal už ohledně omezení na počty položek, nebo když jde o aktualizaci členství ve skupinách.

V každém případě se do něho nedostane nic jiného, než bezpečnostní skupiny. Domain controller při ověřování uživatele členství v distribučních skupinách vůbec nevyhodnocuje. Prostě je v databázi nehledá a ignoruje.

SID distribuční skupiny se tedy může objevit na NTFS, nebo v SharePointu. Nebude mít ale efekt, protože stejný SID se v access tokenu uživatele nikdy neobjeví.

Zřetězené členství

Jen pro úplnost dodejme, že byste mohli mít v ADčku dokonce skupiny zřetězené do mixu. Jakože distribuční skupina by byla členem bezpečnostní a to by zase mohlo být členem jiné distribuční apod. Asi to nenaklikáte, ale principiálně by to šlo.

V každém případě to ale poruší řetěz skupin, takže členství při ověřování se vyhodnocuje pouze v souvislé security group oblasti.

říjen 13
Jak rychle se projeví zákaz účtu nebo zneplatnění certifikátu

V pátek jsem se zákazníkem řešil, jak zrychlit zneplatnění certifikátu (certificate revocation). Oni mají přihlašování čipovými kartami (smart card logon - PKINIT). A zdálo se jim, že mít CRL s celodenní platností není moc vhodné. To je pravda. K tomu ale něco až v druhé části.

Nejprve jsem chtěl, abyste si uvědomili něco jiného. Pokud se přihlašujete pomocí Kerberos (což je výchozí), tak dostáváte tickety, které platí 10 hodin (opět výchozí nastavení). I přihlašování čipovou kartou je ve skutečnosti Kerberos, který na základě karty generuje ty stejné tickety. Z toho vyplývají určité otázky ohledně zákazu účtu.

Zajímají nás pouze síťové přístupy

Nejprve si ujasněme, že nás zajímají hlavně síťové přístupy. To, že uživatel po přihlášení na stanici, na ní může pracovat až do smrti, nám nevadí. Tomu stejně nejste schopni zabránit, protože přihlášení z cache (cached logon) nikdy nevyprší (moje starší věci zde a zde).

Ale do sítě se už nemusí dostat. Pro přístupy do sítě musíte mít vždy nějaké online přihlašovací údaje. Tam keš nefunguje.

Budeme se tedy zabývat v podstatě třemi síťovými ověřovacími metodami - Kerberos, NTLM (obecně všechny tři verze LM, NTLM, NTLMv2) a Schannel. V případě Kerberos se můžete ověřit heslem, nebo privátním klíčem certifikátu na čipové kartě (PKINIT). V případě NTLM se ověřujete pouze heslem. V případě Schannel se ověřujete pomocí TLS client certificate authentication - tohle umí HTTP.SYS (a tedy IIS, AD FS, nebo WinRM, nebo SQL reporting services apod.). O TLS client certificate authentication jsem psal už například tady.

Takže máme tři metody. Všechny tři metody budou do sítě muset ověřit každé nově vznikající TCP spojení, nebo i častěji. V případě HTTP a Kerberos se například ověřuje i každý požadavek. Prostě aby řeč nestála.

K tomu "TCP spojení" bych ještě upozornil, že například sdílené soubory (SMB), nebo prohlížeče (HTTP) si nechávají svoje spojení otevřené i potom, co už nic nestahují, nebo i když pozavíráte všechna okna (případ u SMB). Čistě z toho důvodu, aby to nemuseli znovu nákladně otevírat, kdyby si uživatel v dohledné době vzpomněl, že chce pokračovat. Timeout u těch spojení je ale obvykle v oblasti několika sekund (SMB 20 sec), nebo minut (IEčko má 1 minutu).

Zákaz účtu při NTLM a Schannel

Tyto dva protokoly vyžadují pass-through ověření každého spojení přímo online na DC. Pokud zakážete uživatelský účet, projeví se to tedy hned při nejbližším pokusu uživatele dostat se někam do sítě. Stejně jako změny členství ve skupinách, jak jsem tu již jednou psal.

Zákaz účtu při Kerberos ověření

Je jedno, jestli se ověřujete pomocí hesla, nebo čipové karty (smart card logon). V obou případech vám domain controller vytvoří TGT ticket. Tento platí 10 hodin. Po tuto dobu se už znovu nevytváří.

Pokud jdete později na nějakou síťovou službu, musíte k tomu mít TGS ticket (service ticket). Ten vám opět musí vydat DC. Vydá vám ho na základě předchozího TGT. TGS ticket platí od okamžiku vydání maximálně po dobu platnosti původního TGT. Takže zase něco méně, než 10 hodin.

Jak se tedy projevuje zákaz účtu? Jestliže už máte TGT, zákaz účtu se už znovu nekontroluje. Od toho to taky má delší platnost, aby se ušetřila zátěž na DC. To znamená, že s platným TGT se můžete dostat v pohodě ještě dalších 10 hodin do sítě. Tečka.

Poznámka ke členství ve skupinách. TGT obsahuje jen global a universal skupiny. Zatímco TGS obsahuje navíc i domain local skupiny. Změna členství ve skupinách se tedy projeví také nejhůře až za 10 hodin.

Kdybyste to chtěli zrychlit, můžete zkrátit životnosti TGT a TGS tiketů v politice. Nemám moc zkušeností s takovou změnou. Jediné co můžu říct je, že u jednoho zákazníka jsem kdysi nastavoval 2 hodiny, u jiného jsme to dali dokonce na 35 minut pro TGS a (1 hodina pro TGT) a zdá se, že všechno žije. Ale byl bych opatrný. To může záviset hodně na prostředí a službách.

Ještě poznamenejme, že připojení, která se ověřují pomocí RADIUS (jako jsou VPN, nebo WiFi), se také ověřují jen při ustavení toho spojení a je čistě na implementaci, jestli to má nějaké opětovné ověření v průběhu připojení, nebo ne.

Tohle jsou důvody, proč i ISO/IEC 27002 doporučuje zvážit podle bodu 9.2.6 Removal or adjustment of access rights, jestli není vhodné člověka, kterého vyhazujete, fyzicky odstřihnout od možnosti vůbec pracovat - například ho pryč doprovodí bezpečák. Měli byste mít také seznam připojení, která by bylo vhodné mu explicitně utnout ručně (VPN, terminál apod.).

Odbočka - vtipná příhoda ke slovíčku "bezpečák". Kdysi jsme byli s kamarádem na akci. Byl hrozně pyšný, že má tričko s nápisem RSA Security. Potom vychladl, když se ho nějaké holky ptaly, jestli má obušek, nebo nosí i pistoli :-)

Smart card logon a zneplatnění přihlašovacího certifikátu

Pokud používáte přihlašování čipovými kartami, bojujete ještě s jedním problémem. Když člověk někde ztratí, nebo jen zapomene kartu (smart card), měli byste mu její certifikát zneplatnit (revoke). Tohle jde udělat i dočasně (certificate hold - ano, v tomto případě to není nic proti filosofii, protože se tím jen přihlašujete a neděláte non-repudiation).

Zneplatněné certifikáty se musí objevit na CRL (certificate revocation list), který se vydává jen občas. Výchozí nastavení je myslím jednou denně.

Je jedno jestli máte delta CRL, nebo používáte i OCSP. Jde vždycky o interval platnosti tohoto delta CRL seznamu, se kterým musíte počítat.

Ano, CRL můžete vydat ručně rovnou v okamžiku, kdy certifikát zneplatňujete. To ano, to samozřejmě uděláte. Jenže klienti a řadiče domény (DC) mohou mít předchozí CRL/OCSP nakešované na celou dobu jeho platnosti.

Zabývejme se tedy otázkou, jak tohle co nejvíce zrychlit. Prostě nastavit jeho platnost na co nejkratší dobu. Něco jako 1 hodina například?

Proti této touze nás budou ale brzdit požadavky na dostupnost certifikační autority (CA) a CRL/OCSP distribučních bodů. Případně LDAP replikační prodlevy na ADčku (AD replication delay), pokud tedy publikujete do LDAPu.

CRL publikační interval, požadavky na dostupnost CA a jak to vylepšit

OCSP odpovědi se generují z CRL, takže s tímto se tu není potřeba zabývat. Nehledě na to, že OCSP je nejspíš docela zbytečné vůbec pro interní autiritu mít.

AD CS publikuje CRL podle registrové hodnoty CrlPeriodUnits.- nastavitelné i přes GUI ve vlastnostech položky Revoked Certificates. Podle toho se uvnitř CRL objeví hodnoty Effective date a Next update. Tedy to určuje platnost CRL. Jsou tam ještě přesahy o pár minutek kvůli rozhození hodin, ale to není podstatné.

Blbé je toto. Přestavte si, že autorita, nebo CRL distribuce, selže těsně okolo okamžiku další publikace CRL. Všechno přestane fungovat a nebudete mít dostatek času to opravit. Na vylepšení tohoto problému se používá buď registrová hodnota CrlOverlapPeriodUnits, nebo prostě jenom naplánovaná úloha na publikaci CRL častěji (certutil -crl a certutil -crl delta).

Detaily jsou mimo tento článek. Prostě to znemaná, že platnost CRL je potom dána CrlPeriodUnits plus CrlOverlapPeriodUnits. Viz. můj obrázek:

Pokud tedy publikujete CRL častěji, než je jeho skutečná platnost pro klienty - certutil -crl, nebo právě CrlOverlapPeriodUnits - požadavky na jeho dostupnost jsou dány právě tímto jeho časem.

Jenže to je možná pořád moc krátko. A přitom bych rád měl co nejrychlejší CRL. Potom si můžete pomoci ještě dalším nastavením, které funguje pro Windows Vista a Windows 2008 a novější. Podle následujícího obrázku. Prodlouží to platnost CRL, pokud nelze stáhnout novější (certificate path validation settings - allow CRL and OSCP responses to be valid longer than their lifetime).

Zde je obvykle diskuze. Když mám krátké CRL a přitom ho tady znovu prodloužím, není to nebezpečné? Trošičku, ale jen opravdu maličko :-) To by musel nějaký MITM být schopen zablokovat uživateli schopnost stáhnout aktuální CRL. Já tvrdím, že pokud by už byl schopen zablokovat stahování CRL, nebo OCSP, tak to už může udělat takovou škálu mnohem lepších útoků, než aby blokoval CRL. Navíc se nám jedná o přihlašování čipovou kartou.

To by vektor útoku musel být následující. Fyzicky ukradnu kartu a potom ještě počítači, ale i všem DCčkům, zablokuju CRL, abych se mohl přihlásit. No nesmysl. Jestli ten MITM umí zablokovat CRL pro všechna DCčka, proč by kradl někomu čipovku? To už zaútočí někde jinde a přitom pohodlněji.

Takže můžete mít CRL platnost opravdu kraťoučkou, například hodinu a přitom mít požadavek na jeho dostupnost v oblasti několika hodin.

říjen 10
Nějaké nové obrázky z Windows Server 10 technical preview

Udělal jsem ještě nějaké další screenshoty z Windows Server 10 technical preview, tak tady jsou, pouze s minimálními komentáři.

IEčko je tam pořád pouze verze 11.

Tohle dělá už i Windows 2012 R2, ale rád jsem si to típnul, protože už konečně zase jde třídit seznam ACE (access control entries) ve vlasnostech NTFS souborů a adresářů. Ve Windows 2012 to nešlo, což mě dost obtěžovalo. Ale pánové vás varují, že to možná až tak dobře nechápete, jak to zabezpečení (permissions) vlastně funguje!

Následují obrázky z GUI Hyper-V. Bylo přidáno jakési podivné rozšíření pro Azure. Velikost výchozí RAM paměti se zvětšila na 1GB, protože Windows 8 a Windows 2012 už dlouho vyžadují tohle minimum pro instalaci. Nová nastavení pro checkpoint (dříve snapshot). Popisky jsou totálně chaotické, zřejmě se autor vyhulil, nebo to byl ind. Rozhodně se tu objevují jakési novinky - standard checkpoint a production checkpoint. Hned příští týden si to znovu nainstaluju a zjistím co to opravdu znamená.

GUI trošku jinak zobrazuje IP adresu virtuálky, zvláště když máte více síťovek. Dělá to jedna z integration services (IS) nazvaná Data Exchange, pořád stejně jako ve Windows 2012. Prostě jenom předělali GUI.

Pro zájemce, dá se zjistit i verze operačního systému. Viz můj skriptík - musíte jen změnit jméno virtuálky na začátku příkazu:

'client7' | % { Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem -Filter "ElementName='$_'" } | % { $_.GetRelated("Msvm_KvpExchangeComponent").GuestIntrinsicExchangeItems | Select @{ n = 'What' ; e = { ([xml] $_).SelectSingleNode("/INSTANCE/PROPERTY[@NAME='Name']/VALUE").'#text' } }, @{ n = 'Value' ; e = { ([xml] $_).SelectSingleNode("/INSTANCE/PROPERTY[@NAME='Data']/VALUE").'#text' } } }

Při instalaci Active Directory (AD DS) nelze vybrat a ani později nelze povýšit na vyšší forest functional level (FFL) ani domain functional level (DFL), než je starší Windows 2012 R2.

A na konec jakýsi Soft restart. Zdá se, že to umí otočit, aniž by museli projíždět BIOS. Pěkné. Použije se to například pomocí příkazu shutdown a parametru /soft. Ale nevím jak to funguje. Ve virtuálce se to otáčí komplet, dokonce mi to dává vybrat bootovat z DVD. Možná to vyžaduje nějakou hardware podporu.

shutdown /r /soft /t 0 /f

říjen 10
Skutečná ověřovací aktivita jednotlivých DC

Včera jsem tu psal o parametru /logon_query programu netlogon. Říkal jsem, že je to v podstatě nesmyslný parametr, protože to měří jen NTLM ověřování. Navíc ve Windows 2012 je buď chyba, nebo to záměrně úplně zrušili.

Abych jenom nereptal, mám tu lepší řešení. Zjistit sumu hodnot atributů logonCount pro každé DC. To je nereplikovaný atribut (podobně jako je lastLogon, o kterém jsem se zmiňoval tady), který u každého účtu zachycuje historicky počet ověření jeho přihlašovacích údajů - tedy hesla, nebo certifikátu v případě Schannel, nebo PKINIT (smart card logon). Tohle samozřejmě bere i Kerberos.

Na každém DC bude mít u každého účtu tento atribut hodnotu takovou, kolikrát ho to dané DC za svůj život ověřilo. Hodnota se nenuluje ani při restartu. Takže je to historicky od instalace daného DC. A pokud jste instalovali to DC z IFM (install from media), tak tam bude hodnota plus to z té zálohy.

Takže hodnota je přesnější, ale má to špatnou vlastnost v tom, že to je od instalace toho DC. Ale pokud to budete měřit rozdílově, tedy změna hodnoty od včerejška, nebo za poslední týden, uvidíte v tom mnohem přesnější informace o tom, jak je ověřování rozloženo mezi jednotlivé řadiče domény (domain controller).

Tento skript na ukázku vypíše sumu hodnot logonCount pro každé DC ve forestu.

dsquery server | % { $_.Trim('"') } | % { ([ADSI] "LDAP://$_").serverReference } | % { ([ADSI] "LDAP://$_").dNSHostName } | select @{ n = 'dc' ; e = { $_ } }, @{ n = 'logonCountSum' ; e = { dsquery * domainRoot -filter '(logonCount>=1)' -attr logonCount -server $_ -limit 0 | ? { $_ -match '\s+\d+\s+' } | Measure-Object -Sum | Select-Object -Expand Sum } }

Pokud bych měl jen zmínit nějaké zajímavosti k jeho PowerShell implementaci, tak si všimněte, že to používá ADSI a ne ten podivný AD module for PowerShell, takže to poběží úplně kdekoliv. Je to taky napsáno na jeden řádek, což by mohlo ukazovat krásu (nebo prasárnu) PowerShellu. A nakonec si všimněte operátoru -match, který krásně vybírá čísla pomocí regulárního výrazu (regex).

říjen 09
Co (ne)zobrazuje nltest /logon_query

V pondělí mi přišel dotaz ohledně parametru /logon_query programu nltest. Jak se zdá, na Windows 2012 už nefunguje, tedy vrací hodnotu 0. Parametr jsem neznal, tak jsem to trošku prozkoumal a závěr je ten, že mě ani nikdy zajímat neměl. Protože je úplně na nic. Proto taky asi přestal na Windows 2012 řadičích domény (DC) fungovat. Nebo spíš jenom chybka?

Co to zobrazuje za hodnotu?

V tomhle článku na technetu píšou, že se jedná o Queries the cumulative number of NTLM logon attempts at a console or over a network. Což je dost nesmyslná nebo alespoň matoucí informace. Tak jsem to pozjišťoval.

Pomocí Network Monitoru jsem zjistil, že se to připojuje přes SMB named pipes  do Netlogon interface na DC, kde to pomocí funkce NetrLogonControl2Ex a I_NetLogonControl2 zjišťuje hodnotu struktury NETLOGON_INFO_3, ve které je netlog3_logon_attempts. To má ovšem stejně na prd vypovídací hodnotu, jako předchozí popisek :-)

Takže jsem to musel vyzkoušet

Hodnota se nuluje po restartu operačního systému DC. Restartovat službu Netlogon ani NTDS nestačí. Na každém DC to má jinou hodnotu.

Hodnota se zvyšuje při každém NTLM pass-through ověření o jedničku (všechny verze LM, NTLM i NTLMv2). Tzn. pokud uživatel přistupuje na nějakou síťovou službu přes NTLM po síti. S konzolí (console) to nemá nic společného. To potom ten cílový server použije svoje blízké DC k ověření uživatele (nltest /sc_query) - použije svůj Netlogon secure channel vůči tomuto blízkému DC.

Hodnota se nemění, pokud se uživatel ověřuje pomocí Kerberos. Hodnota se nemění, ani když se používá Schannel ověření uživatele pomocí TLS client certificate (SSL). Hodnota se nemění ani když probíhá PAC validation (privilege attribute certificate) při Kerberos ověření do služby, která běží pod obyčejným uživatelem.

Obě tyto věci - Schannel a PAC validation jdou také pass-through přes ten cílový server, takže by se mohlo čekat, že to zvýší čítač. Nezvýší.

Na co to tedy je?

Prakticky na nic. Vědět absolutní počet NTLM ověření nedává smysl, protože tohle ověření v prvé řadě vůbec nechcete. Ani NTLMv2 neposkytuje plně vzájemné ověření klienta a serveru (mutual authentication) a to kompletně ani při NTLMv2 session security. Používá to starší HMAC-MD5. Zatímco Kerberos dělá vždycky mutual authentication a navíc může být AES.

Jediné, co vám to může indikovat je fakt, že máte těch NTLM ověření nějak moc.

Hodnota na každém DC bude jiná. Za prvé to závisí na době běhu daného DC stroje. Při jeho restartu se to nuluje.

Zadruhé NTLM ověřování je spíše anomálie. Budou ho dělat jen některé služby, které jsou špatně nastaveny, takže jim nejede Kerberos. Každý počítač má svůj Netlogon secure channel trvale jen s jedním blízkým DC. Jestli máte například jen jeden server, který z nějakého důvodu dělá NTLM ověřování (typicky ne-nastavený SQL server) - bude se ten čítač zvyšovat jen na jednom DC.

Jeho hodnota bude pak obvykle záviset na počtu TCP spojení do takové špatně nastavené služby. Samozřejmě ve velkém prostředí to může být poměrně rovnoměrné na všech DC, ale taky nemusí.

Prostě informace na nic. Krom faktu, že to ukazuje, že nějaké NTLM ověřování vůbec máte.

říjen 02
První zážitky s Windows 10 preview

Windows 10 Preview for Enterprise jsou tady. Podívejte se na nějaké úplně první obrázky a zkušenosti. A ještě jedna zajímavost ohledně čísla 10. Cca před týdnem byl naplánován online meeting a představení Windows 9 pro MVP, kterého jsem se včera účastnil. Všimněte si, že se to ještě před týdnem jmenovalo Windows 9.

Typuju, že Windows Nein asi nebyl úplně dobrý název pro německý trh :-)

Instaluju do Hyper-V takže je jistě zajímavé, že instalačka už rovnou obsahuje ovladače pro synthetic zařízení (integration services), jako je SCSI sběrnice. To je případ už od Windows 8.1 a Windows 2012 R2. Takže na Windows 2012 R2 Hyper-V se to dá nainstalovat do VM Generation 2, což má UEFI "BIOS" a neobsahuje to vůbec emulated zařízení.

Jak se zdá, verze operačního systému Windows 10 preview z dne 1.10.2014 je 6.4 build 9841, tedy 6.4.9841.

Instalace v stejná jako kdykoliv předtím.

Aaa, jak se dívám, můžu být rád, že jsem vybral Customize namísto Use express settings:

A konečně jsme tu

Jo tak tohle jsou ty napjatě očekávané desktopy. Přesněji nejvíce očekávaná enterprise fíčura roku.

Vokna bez rámečku! Vypadá to hezky, to nemůžu říct. PowerShell pětka (PowerShell 5.0). Celkem příkazů 1229. Na Windows 8.1 je jich 2087.

Menu WinX stále neobsahuje PowerShell.

A nová skupina s mongolsko-čínským popiskem - System Managed Accounts Group_ploc :-) Pěkné. To budou asi ty žádané enterprizové fíčury!

Žeby něco jako multifaktorová autentizace do různých služeb? No uvidíme...

Taky nemalá partička dalších kámošů, jejichž popisky se nepodařilo dodat. I když ty VMIC jsou Hyper-V integration services, jak to tak pozoruju. Ovšem změna, už to běží rovnou v SVCHOST procesu. Kůl.

Prostě blbosti. Hlavně že se to jmenuje Windows 10 a zase na tom nepojede půlka programů :-) Další obrázky zase příště.

říjen 01
Pozvánka na konference a prezentace z konference minulé!

Tak už se nám to povážlivě blíží! GOPAS pořádá konference, kde budu přednášet i já.​

Nejbližší je lahůdková konference HackerFest, bude už tento měsíc v Praze, nezapomeňte se přihlásit. Na HackerFestu budu mít přednášku na téma:

Útoky, které žádný antivirus nezachytí

Druhou je již (doufám) tradiční ShowIT v Bratislavě, bude v únoru (februári). Jak se dívám, marketing ještě nebyl schopen aktualizovat web, tak to berte jako první vlaštovku a začněte se těšit!

Také jsem chtěl využít příležitosti a zveřejnit zde prezentaci z pondělní "minikonference" Duel HyperV a VMWare pořádanou v GOPASu v Bratislavě. Moji prezentaci najdete zde.

září 26
Zapnutí Kerberos delegace pro Hyper-V live migration

Když zapínáte Hyper-V live migration na Windows 2012, tak už nepotřebujete cluster (jak jsem tu psal zrovna před pár dny). K tomu, abyste live migration zapnuli mezi několika hyper-v hosty, musíte jim povolit Kerberos constrained delegation na hodnotu Trust this computer for delegation to specified services only - use Kerberos only. K tomu, aby Kerberos delegace fungovala, musí být počítačové účty nodeů vaší farmy členem skupiny Windows Authorization Access Group (WAAG) - viz článek o Kerberos delegaci.

Jenže to musíte povolit všem nodeům vzájemě a ještě navíc musíte povolit delegaci i do SMB storage. Což je drbačka i v případě dvou členů farmy, natož když jich máte více.

Tak jsem si na to napsal skript v PowerShell. Je to napsáno obecně pro Windows 2003 a novější, takže nepoužívám ActiveDirectory module, který nemám rád už z principu, že to nepoužívá LDAP, ale nějakou podivnou web servisu. Navíc ten ActiveDirectory mobule blbne na Windows 8.1, hanba :-)

Myslím, že je jasné, že změnit musíte akorát první tři proměnné.

$domain = 'gopas.virtual'
$nodes = @('noda', 'nodb', 'nodc')
$storages = @('stor', 'stor2')



$domainDN = ($domain.Split('.') | % { "DC=$_" }) -join ','

$WAAG = dsquery * $domainDN -filter "(&(sAMAccountName=Windows Authorization Access Group)(objectClass=group))" | % { $_.Trim('"') } | % { [ADSI] "LDAP://$_" }

$nodes | % {

  dsquery * $domainDN -filter "(&(sAMAccountName=$_`$)(objectClass=computer))" 

} | % { $_.Trim('"') } | % {

  $oneNode = [ADSI] "LDAP://$_"
    
  $spns = $nodes -ne $oneNode.name | % { 
    
    'Microsoft Virtual System Migration Service/{0}' -f $_
    'Microsoft Virtual System Migration Service/{0}.{1}' -f $_, $domain
  }

  $spns += $storages | % { 

    'cifs/{0}' -f $_
    'cifs/{0}.{1}' -f $_, $domain
  }
    
  Write-Host '-----------------------'
  Write-Host ('One host: {0} | {1}' -f $oneNode.name.Value, $oneNode.dNSHostName.Value)
  Write-Host ('SPNs: {0}' -f ($spns | Out-String))
 
  $oneNode.PutEx(3, 'msDS-AllowedToDelegateTo', $spns)
  $oneNode.SetInfo()


  $WAAG.Add($oneNode.Path)
}

Tak užívejte :-)

září 25
Proč nevěřím Hyper-V GenerationID a neodvažoval bych se používat snapshot (checkpoint) pro obnovu DC

Už jsem tu psal několikrát (tady a tady) o obnově řadičů domény a s tím souvisejícím GenerationId, pokud domain controller běží ve virtuálním počítači. Od Windows 2012 Hyper-V a pokud váš konkrétní virtuální DC je také alespoň Windows 2012, údajně ho "můžete bezpečně obnovit" z virtualizačního snapshotu (neboli dnes checkpointu).

Jak za jízdy (já si to nazývám live-snapshot), tak i z vypnutého snapshotu (offline-snapshot).

Podívejme se, jak to celé funguje a sami zvažte, jestli je dobrý nápad na to spoléhat.

GenerationId a jeho infrastruktura

Je to jednoduché. Ve virtuálkách, které mají nainstalovanou a vůbec správnou verzi integračních komponent (Hyper-V integration services) existuje ovladač jádra gencounter.sys (název v device manageru je Microsoft Hyper-V Generation Counter).

Tento driver se zavádí v režimu Manual. To znamená, že ho spouští něco jiného, nejspíš během svého vlastního startu.

Active Directory domain controller (ADDS DC) ve verzi Windows 2012 a novější se prostě tohoto driveru zeptá pokaždé, když chce dělat nějakou replikaci, nebo možná i někdy častěji, když je k tomu nějaký důvod. Zeptá se na aktuální GenerationId a zapíše si ho do nereplikovaného atributu msDS-GenerationID, který má ve své LDAP databázi na svém computer objektu (přímo na účtu počítače, obvykle v OU=Domain Controllers).

Pokud se GenerationId od posledně změnilo, rovnou provede opravu InvocationId a stane se novou instací LDAP databáze.

Smutná fakta

Pokud ten ovladač gencounter.sys z nějakého důvodu nenaběhne, prostě se vůbec nic nestane! DC vám vůbec nic nezaloguje, normálně naběhne, ale když potom obnovíte snapshot, tak se to prostě jenom nedozví, a normálně replikuje, jako by se nechumelilo. Žádný error v žádném logu. Ani v System logu, nikde.

Můžete to jednoduše vyzkoušet tak, že v registrech v HKLM\SYSTEM\CurrentControlSet\Services\gencounter změníte hodnotu Start = 4, tedy na Disabled a restartujete.

Ano, tohle byste normálně neudělali. Ale jakou máte tedy jistotu, že ten ovladač skutečně běží? Co když prostě jenom nenaběhne kvůli málo paměti? Kvůli nějakému timeoutu při restartu, nebo to prostě spadlo kvůli kdovíjaké chybě?

Spoléhat se na to podle mě nejde. Takže jako jsem říkal už předtím, obnovovat snapshot DC je nebezpečná hra s ohněm.

září 25
Extended protection for authentication - lepší zabezpečení intranetových HTTPS proti MITM

Právě včera jsem tu uveřnil článek o MITM útocích na HTTP web servery. Ty jsou obvykle chráněny pomocí TLS (ano, cca 15 let se už SSL používá jen jako úplně záložní metoda) a tedy HTTPS. K tomu je zapotřebí certifikát na web serveru, který poskytuje ale jen jednostranné ověření identity serveru. Neposkytuje vzájemné ověření i identity klienta.

Vzájemné ověření klienta a serveru se pro intranetové web servery dosahuje obvykle pomocí windows authentication za pomocí protokolu Kerberos. NTLM vzájemné ověření identity nepostkyje, NTLM ověřuje pouze identitu uživatele. Vzájemné ověření identity uživatele i serveru by se dalo dosáhnout také použitím TLS client certificate authentication, ale o tom tenhle článek není.

Z absence vzájemné autentizace TLS tunelu/kanálu pak vyplývá možnost různých útoků. Například:

  • TLS strip attack, jak jsem popisoval zrovna včera
  • HTTPS MITM (někdy to dělají i firewally jako HTTPS inspection). Tady se jedná o případ, kdy prostřední útočník (man in the middle) aktivně vstupuje do komunikace, vygeneruje si sám podvržený certifikát serveru a nabídne ho klientovi. Takový "útok" dělají například i testovací a troubleshootovací nástroje, jako je fiddler, nebo nejnovější Microsoft Message Analyser (který používá sám vnitřně fiddler).

U toho MITM útoku se zastavme. Proti podvodníkovi se brání už sám Internet Explorer na straně klienta tím, že obvykle zobrazí červené hlášení, že certifikát útočníka je neplatný. To samozřejmě za předpokladu, že ho nemáte na počítači z nějakého důvodu zdůvěryhodněny, že :-) Takže uživatel by se měl normálně dozvědět, že něco s tím TLS kanálem není v pořádku.

Jenže uživatelé tahle varování odkliknou. Proti tomu, aby vám uživatelé odklikávali taková hlášení, se server sám bránit nemůže. Vy prostě ze strany serveru uživatelův "odklik" neovlivníte. A to je škoda.

I kdyby to uživatel neodkliknul, stejně je pořád ohrožován HTTPS strip útokem, nebo třeba tím, že podvržený certifikát serveru je na jeho počítači důvěryhodný.

Od toho je právě tahle fíčura nazvaná extended protection for authentication. Je to relativně stará novinka, ale neznámá, proto o tom taky píšu. Je to k dispozici jako vylepšení protokolů Kerberos a NTLMv2 na straně klienta (od Windows XP SP3 a Windows 2003 SP2) podle KB968389. Na těchto systémech si to musíte ještě i povolit v registrech hodnotou SuppressExtendedProtection = DWORD = 0.

Ve Windows 7 a Windows 2008 R2 je to už od samého základu.

Jedná se o vylepšení Kerberos a NTLM o to, že se do ověřovacího paketu započítává thumbprint certifikátu, který vidí klient. Pojem "ověřovací paket" znamená v případě NTLM response (pouze NTLMv2) přihešování (HMAC-MD5) do NTLM challenge spolu s heší hesla (MD4). V případě Kerberosu se to hmakne pomocí session key klient-webServer z TGS.

Znamená to, že klient vypočítá ověřovací paket pomocí toho, co sám vidí za serverův certifikát ze svého pohledu. A server na druhé straně si naopak zpočítá co očekává od klienta na základě svého vlastního certifikátu, který si myslí, že by měl klient asi dostat. Pokud to sedí, server klienta přijme.

Výhody?

V případě Kerberos ověření, které je samo o sobě vzdájmené (mutual authentication) to zajistí vazbu vnitřního ověření uživatelského účtu na TLS kanál. Tím se zabrání libovolným MITM útokům.

V případě NTLMv2, které je jen jednostranným ověřením klienta to má navíc efekt vzájemného ověření klienta i serveru - naváže se klientovo ověření na  ověření serveru - a máte v podstatě mutual authenticated NTLM :-)

Zapnutí?

Raději bych vynutil rovnou TLS klientské certifikáty, což je méně kompatibilně závislé, totálně standardní a navíc třeba pro SharePoint je to možné udělat pomocí NETSH HTTP tak, že to vůbec neovlivňuje parametry IIS, které SharePoint rád znásilňuje.

Ale pokud máte vnitřní prostředí na Windows 7 a novějších, hurá do toho!

září 24
Proč je alza.cz špatně udělaný web z pohledu HTTPS bezpečnosti - aneb HTTPS strip attack a downgrade

Dneska se podívejme na jeden antihekovací problém s HTTPS webovými servery. Není to problém jen alza.cz, na které se to pěkně předvede. Je to problém obecně, můj odhad od oka 99% všech web serverů :-) Alzu jsem si vybral jen proto, že mě přišla dneska rovnou do rány :-)

Jinak mě samozřejmě nejde o hekování webu. Mě se jedná o zabezpečení intranetových web serverů, jako je SharePoint a OWA a jiné business portály.

O co jde? To že web server má HTTPS není ještě žádná paráda. Aspoň něco. Ale může se z toho lehce stát nic.

Takže se podívejte na libovolný webový server, který implementuje HTTPS. Můžete zkusit taky gmail, facebook, nebo azure a MS download, msdn, Office365 apod. Nebo třeba váš vlastní SharePoint nebo OWA. Jak říkám, je to 99%. Všichni umožňují připojovat se přes nezašifrované HTTP a až později přejít na HTTPS. A nevyžadují klientské TLS certifikáty (TLS client certificate authentication).

Jak z toho dostat uživatelovo heslo? Nechceme, nebo nemůžeme dělat HTTPS MITM s podvrhnutým serverovým certifikátem (neboli HTTPS inspection). Nemůžeme, protože by mu klient nevěřil. Ne že by ta červená varování mnoha lidem vadila :-) ale jde to obvykle mnohem nenápadněji. Pomocí HTTPS strip (SSL strip, TLS strip) útoku, což je vlastně downgrade útok (ale v podstatě ne kryptografický, jen protokolový) za pomoci MITM.

HTTPS web servery obvykle umožňují přesměrování

Normální lidé zadávají do prohlížeče obvykle jen jméno serveru, bez předpony HTTPS://. Znamená to, že prohlížeč zkusí primárně jít na nezašifrované HTTP. Je jedno, jestli to jde, nebo to máte na svém web serveru zablokované, nebo tam máte redirect, nebo váš server vrací všechny linky a jiné odkazy jako HTTPS.

Pokud to klient zkusí sám dobrovolně od začátku jen přes HTTP, je proklet. Proč?

Normálně máte na svém TLS/SSL web serveru něco jako 302 redirect na HTTPS. Nebo také uvnitř webových stránek uvádíte odkazy explicitně na HTTPS. Prostě člověk jde na HTTP a ono ho to v odpovědi přesměruje na šifrované HTTPS. Viz. tyto dva obrázky z mého kurzu o PKI a TLS:

Jenže jak říkám, je už od začátku špatně, že jste do adresy zadali místo HTTPS jen nezašifrované HTTP.

HTTPS strip útok pomocí MITM (man in the middle)

Mrkněte se na obrázek:

Vy dobrovolně začnete s nechráněným HTTP. Útočník si stoupne mezi vás a HTTPS server. Všechno co vy pošlete na server přes HTTP, on přehodí na HTTPS. Všechny odpovědi od serveru, které explicitně obsahují zmínky o zabezpečeném HTTPS útočník změní zpět na čísté HTTP.

Pokud se vás web server snaží přesměrovat 302 na šifrované HTTPS, útočník vás prostě něchá na HTTP. Pokud vám server vloží do stránky absolutní odkazy, které vedou na šifrované HTTPS, útočník je prostě jen změní.

A je to.

Jak se proti tomu bránit

Existují alespoň tři metody

  • musíte explicitně začít s HTTPS:// prefixem. A potom se musíte ujistit, že ten HTTPS prefix stále vidíte v panelu s adresou. A navíc musí být v Internet Exploreru vidět zámeček (lock icon) vpravo. Ta ikonka je zásadní. Viz. problém s alza.cz.
  • webový server vyžaduje ověření uživatele pomocí klientského TLS/SSL certifikátu (tedy TLS client certificate authentication), o čemž jsem tu psal už několikrát - například tady a nedávno tady. Jde o to, že spojení je v takovém případě vzájemně autentizovaná (mutual authentication), útočník v prostředku (MITM) nemá klientský certifikát a může si tedy trhnout nohou.
  • pro vnitřní web servery, které ověřují uživatele pomocí Kerberos (nebo i NTLM, když už by to muselo být) by se použila tzv. extended protection for authentication. O tom co nejdříve udělám další článeček, je to velice zajímavá věc. V podstatě se jedná o to, že navážete kerberosové tikety na TLS certifikát web serveru.

Jak jistě poznáte, první metoda vyžaduje uživatelovu dobrou vůli, porozumnění a zodpovědnost. Druhé dvě metody se hodí výborně do vnitřních prostředí, mě se velmi líbí ta druhá, s klientským TLS certifikátem, protože je kompatibilní i se SharePoint. On totiž SharePoint oficiálně extended protection nepodporuje, což je škoda. Zapnout to můžete, ale na vlastní riziko.

Zato klientský certifikát je parádička, která vám i z internetu přinese dokonce single-sign-on (SSO), to je potom krása!

Problém s alza.cz

Proč je tedy problém s alzou? Pokud se tam podíváte, jedete normálně na HTTP. To by tak nevadilo. To je normálka. Tudíž chcete přejít na TLS. Napíšete do adresy https://www.alza.cz a zjistíte, že v panelu ikonka certifikátu (a dokonce zeleného) jen problikne. Skončí to na tom, že v adrese vidíte sice HTTPS prefix, ale už nevidíte vpravo certifikátovou ikonečku.

Co to znamená? Adresa s HTTPS bez ikonky certifikátu? Odpověď vám dá například Developer Toolbar F12 v Internet Exploreru, přesněji jeho Network záložka. Když si nachytáte komunikaci mezi sebou a web serverem, zjistíte, že plno elementů stránky, jako jsou obrázky nebo skripty, se stahují buď úplně bez šifrování přes čisté HTTP, nebo z jiného HTTPS serveru.

Prohlížeč nemůže garantovat, že certifikátem je všechno zabezpečeno a prostě ho nezobrazí. Prefix HTTPS:// tam zůstane, protože základní HTML je opravdu na této adrese.

Takže nemáte žádnou informaci o tom, co vlastně je přes HTTPS a co není. Jste si jistí, že přihlašovací javascript, který vám zobrazí přihlašovací okénko dorazil přes šifrované spojení? Nemají to dokonce ani možno otevřít jako samostatnou stránku, takže víte v celku prd. To byste sice nevěděli, ani kdyby to samostatná stránka byla, ale přecejenom by to mohlo být zřetelnější.

Takže zde ani vlastní sebeochrana uživatele proti SSL strip útoku nefunguje.

Závěrem

Snažte se vždycky kontrolovat ikonku certifikátu a HTTPS:// prefix. Pokud to jde, použijte klientské certifikáty, nebo si přečtete zítra o Extended Protection v IIS za přispění Kerberos.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
17.10.2014 18:19
CHFI: Computer Hacking Forensic Investigator!!!
17.10.2014 12:59
zdá se, že na jakémkoliv telefonu jde zjistit IMEI zavoláním na *#06# to je zajímavé.
17.10.2014 12:56
dnešní fyzikální okénko: http://palkovsky.blog.idnes.cz/c/196273/Rychlosti-se-nescitaji.html
14.10.2014 22:01
tak soft restart na Windows 10 server asi nefunguje - nebo to chce nejakou hw podporu?
13.10.2014 18:58
Prave jsem dostal na googlu kapcu "debil".
12.10.2014 14:04
Napeti pred konferencemi #hackerfest a msfest vrcholi! Uz za tyden!
10.10.2014 19:44
http://status.modern.ie
9.10.2014 13:36
na RDP terminal se da jit bez licence, kdyz nejede licencni server, nebo nechcete konzumovat licenci – staci do MSTSC klienta zadat do adresy /admin
9.10.2014 13:33
Windows 2012 based Remote Desktop Session Host (RDP session host) error: The remote session has been disconnected because there are no Remote Desktop License Servers available to provide a license. Hotfix download: http://support2.microsoft.com/kb/2916846
9.10.2014 13:03
Dva ucty se stejnym heslem - bacha. Kdyz zjistim jedno heslo, rovnou ho zkusit na vsechny ostatni ucty je hracka. Bez zamknuti!

7.10.2014 13:33
a máme tu program mých 4 přednášek na konferenci http://www.ms-fest.cz, která proběhne 19.10 v Brně!
2.10.2014 23:37
Na serverech 10 je něco, co se jmenuje "Windows Volume Replication". Jestli to je synchronní replikace, tak paráááda!
2.10.2014 22:45
aha, takže ovladač na disketu ve Windows 10 není ani po instalaci. Tak ne že bych to potřeboval na železe, ale potřebuju to pro Hyper-V virtuálky a autounattend.xml.
2.10.2014 21:29
windows 10 nemají v instalačce ovladač na disketu? ach bože.
2.10.2014 19:37
konference HackerFest už v pondělí 20.10. http://www.hackerfest.cz
2.10.2014 19:34
... a když to je kratší než 140 znaků, tak k tomu není link na twitteru. Jsem dobrej!
2.10.2014 19:23
Mám nový automatický re-tweeter pro SharePoint. To je božíííííííí. Cokoliv hodím do SharePointu se mi automaticky přepošle na twitter. Konečně jsem to dodělal.
1.10.2014 18:43
Uz se stahuje Windows 10 Enterprise Preview!
1.10.2014 7:54
Jo taaak Windows 10? Kam to cislovani asi povede?
30.9.2014 18:25
Zitra vecer se tesim na predstaveni Windows 9 pro MVPiky! Snad budu moct neco uverejnit i tady!
26.9.2014 11:46
dneska jsem vymyslel optimální český překlad pro failover cluster - přepadový chuchvalec.
4.9.2014 19:14
Euforie z Office365 podporu! Nemuzu si pomoct, ale musim vyjadrit obrovske nadseni z borcu z podpory na Office365. Ne ze by me pomohli :-) ale snazi se a jsou velmi ochotni. Diky do Svedska!
4.9.2014 8:29

vsechny Windows Live ucty zamknuty? Ze by mel MS nervy z celebrit?

1.9.2014 18:09

Ubytování v Ostravě za 1400,- na 4 noci s kabelovým internetem 6 MB, vlastní pokoj velmi nově opravený a zařízený, s kuchyňkou a sociálkou. Panebože!!! To je skoro lepší se sem úplně přestěhovat!

 

22.8.2014 4:40
Dekuji vsem za prizpevky a komentare!