Category Archives: computer

I foreløbig tre datacentre, som hver bruger op mod én megawatt, sidder et foreløbig ti mand stort firma på 5,6 procent af regnekraften til udvinding af kryptovalutaen Bitcoin. Målet er at udvide til at nå op på mellem 7 og 10 procent. Det skriver Ars Technica.

De tidlige pionerdage, hvor et par almindelige pc’er var i stand til at blande sig i udvindingen af Bitcoins, er for længst forbi. I dag er end ikke grafikprocessorer tilstrækkeligt.

Hos firmaet MegaBigPower arbejder foreløbig 90.000 specialudviklede processorer på de algoritmer, som bruges til at udregne den næste Bitcoin. Processorerne er samlet på printkort med hver 16 styk, og 16 af disse printkort er så samlet i én beregningsenhed, som styres ved hjælp af en Raspberry Pi-computer.

MegaBigPowers næste version samler dog endnu flere Bitcoin-processorer pr. enhed, så hver enhed vil have en kapacitet på 1,5 terahash, som er den enhed, Bitcoin-mineudstyret måles efter. Samlet har MegaBigPower 2,2 petahash.

Forretningsmodellen er at have så stor specialiseret kapacitet, at den kan sælges til investorer, som ønsker at deltage i udvindingen af Bitcoins, men ikke har mulighed for at investere i det specialiserede udstyr.

Udfordringen er især strømforbruget til beregningerne, og derfor er MegaBigPowers datacentre også placeret i blandt andet den amerikanske delstat Washington, hvor der er adgang til billig elektricitet fra vandkraftværker.

Har du tilmeldt dig Version2s daglige nyhedsbrev? Gør det her.

Uge 3: I mit sidste blogindlæg så vi hvordan man nemt orkestrerer sin private sky og bliver en helt i skysovs i sin egen organisationen, og så var det at det utænkelige skete… lige pludseligt selvantændte vores orkestrerings software, FiFo, ok – selvantændelse er måske så meget sagt, men det holdt bare op med at virke. Når man klikker på fanebladene i FiFo så bliver der simpelthen ikke vist noget indhold, og i sin browsers JavaScript konsol kan man se følgende fejl:

Nårh men heldigvis var nedbrudet kun begrænset til FiFo, så SmartOS og alle de virtuelle kundemaskiner fortsatte med at køre ufortrødent videre. Men nu er vores kommandolinie udfordrede kunder meget utilfredse med at de ikke selv kan administrere deres virtuelle maskiner via et grafisk bruger interface.

På ovenstående billede er jeg i gang med at trøste en af vores højt profilerede kendis kunder, nemlig selveste præsidenten for SQLUG.

Vi startede med at søge hjælp i FiFo google groups, og drengene der er rigtig hurtige til at svare og tilbyde forskellige løsninger. Vi startede med at debugge efter den fremgangsmåde som de foreslog og efter denne checkliste, men vi fandt hurtig ud af at det var en lettere uoverkommelig opgave. Mest på grund af FiFos kompleksitet, ikke engang log filerne afslørede nogen spor af hvad der kunne være årsagen til sammenbruddet.

Det endte med at vi opgav alle forsøg på at få den havarerede FiFo installationen op at køre igen. Vi besluttede os derfor til at lave en ny installation. Men ak…. hvis man laver en ny installation, så bliver den oprindelige database overskrevet, og det er helt uaceptabelt for os da vi allerede på nuværende tidspunkt har en del bruger information i databasen.

I et sidste genoplivningsforsøg så fulgte vi opgraderingsguiden fra a-z, og Juhuuu! opgraderingen var en succes – men FiFo nægtede bare fuldstændigt at genstarte efter opgraderingen, succes min bare r..! hvad skal vi dog gøre? Vores kunder er stadig ulykkelige og forlanger en løsning her og nu!

Det er åbenlyst at FiFo ikke er det rigtige valg for os på nuværende tidspunkt, vi bliver nødt til at se på alternativerne.

Så hvad er alternativerne egentlig? Tja, hvis vi kigger i det kommercielle marked så er der OpenNebula, OpenStack, CloudStack og selvfølgelig SmartDataCenter. SmartDataCenter er jo ikke rigtig en option for os, fordi det koster en masse penge som vi ikke har på udviklings budgettet. Hvad angår de tre førstnævnte alternativer så har de ingen understøttelse af SmartOS hypervisoren, og der er ingen nuværerende planer om at understøtte det hellere.

Vi kunne bidrage til Hendrik Volkmer anstrengelser med at portere openStack til SmartOS, men der er ingen færdiggørelse i sigte, da han som så mange andre mennesker har et almindeligt lønmodtager job der skal betale for mad, husleje og andre livsnødvendigheder. Og for det andet så er arbejdet omkring sådanne et projekt enormt, bare tænk på alt den administration der ligger i det udover selve kodningen, der er f.eks. versionsstyring, dokumentation, bugfixes, markedsføring etc. etc.

En anden ide kunne være at siden OpenNebula, OpenStack, CloudStack alle understøtter AWS EC2 API’et, så kunne vi jo kode vores egen web service der kører på SmartOS og som er EC2 kompatibel. Denne ide lider af nogenlunde de samme, skal vi sige, omstændigheder som plager Hendrik Volkmer’s ide. Det er en enorm process der aldrig vil se nogen ende og det kræver både tid og penge for at kunne give det den opmærksomhed som det kræver.

Men Hey! Vi kunne da også bare bidrage til FiFo projektet – meeen, FiFo har jo vist sig at være for kompleks, hvilket nok skyldes at FiFo prøver at være omnipotent ligesom de fire andre alternativer, men FiFo har bare ikke den samme financielle rygstøtte som de andre alternativer har. Og derudover kan der være ganske langt fra version 0.4 til ver 1.0. Og hvad mere er, vi har ikke tid til at vente på en stabil produktions release, når vores kunder står og forlanger en løsning nu! og ikke i morgen!

Stay tuned…. for næste ophidsende del i denne serie, for at se hvordan vi valgte at løse problemet.

I denne uge byder vi en ny blogger velkommen på Version2. Jakob Heidelberg har været it-konsulent siden 2001. Han er senior sikkerhedskonsulent i Enterprise Risk Services hos Deloitte og arbejder med cybersikkerhed på relativt teknisk plan, med primært fokus på Microsoft-platformen og aktuelle hackermetoder.

I sit første blogindlæg skriver han blandt andet:

’Jeg vil i dette indlæg give inspiration til, hvordan man kan forbedre sikkerheden omkring virksomhedens implementering af Active Directory (AD).

Vi skal se på, hvordan man i praksis, med lidt teknisk indsigt og kreativ tankegang, kan opnå administrator rettigheder på et domæne – uden at få ens egen brugerkonto smidt ind i en privilegeret gruppe.

Det er tanken, at påpege nogle typiske “huller”, der ofte opstår omkring AD, og som potentielt kan udnyttes af en ondsindet person – hvad enten hun er intern eller ekstern. Forhåbentlig kan bevidstheden om disse hullers karakter og eksistens hjælpe til at højne sikkerhedsniveauet i din virksomhed.’

Du kan læse Jakobs blog om, hvad man som it-chef bør være opmærksom på angående administrationsrettigheder her.

Jakobs med denne blog er at dele viden og skabe opmærksomhed om observationer, han mener kan have andres interesse, samt at indgå i dialog om disse emner og dermed lære af læsernes erfaringer.

Jeg vil i dette indlæg give inspiration til, hvordan man kan forbedre sikkerheden omkring virksomhedens implementering af Active Directory (AD).

Vi skal se på, hvordan man i praksis, med lidt teknisk indsigt og kreativ tankegang, kan opnå administrator rettigheder på et domæne – uden at få ens egen brugerkonto smidt ind i en privilegeret gruppe.

Det er tanken, at påpege nogle typiske “huller”, der ofte opstår omkring AD, og som potentielt kan udnyttes af en ondsindet person – hvad enten hun er intern eller ekstern. Forhåbentlig kan bevidstheden om disse hullers karakter og eksistens hjælpe til at højne sikkerhedsniveauet i din virksomhed.

Det er ikke nok at tjekke sine grupper

Engang var det tæt på almindelig praksis at have de indbyggede privilegerede grupper i AD spækket med et utal af kendte og ukendte brugerkonti – typisk nogen som ingen i IT-afdelingen kunne redegøre for, men som ingen turde fjerne. I dag har de fleste af os heldigvis lært, at den type administrativ praksis er decideret skødesløs. Det bør høre fortiden til.

Det er dog langt fra tilstrækkeligt alene at overvåge medlemskabet af “Domain Admins”, “Enterprise Admins” og lignende indbyggede privilegerede grupper, som tildeler medlemmerne meget omfattende rettigheder. Der er mange andre ting, som man bør gøre sig bevidst.

Hvornår er man Domain Admin?

Lad os lige se på hvem der egentlig er administratorer i et givent domæne. Det kan under denne øvelse være ganske gavnligt at betragte en “Domain Admin” som »en person, der kender koden til en brugerkonto, som er tildelt rettigheder svarende til dem, der gives via medlemskab af “Domain Admins” gruppen«. Det skal lige bemærkes, at denne “kode” kan være enten et klartekst kodeord eller en tilsvarende LM/NT-hash-værdi.

Det er helt bevidst, at jeg ikke bare antager, at der kun er et enkelt individ bag hver enkelt brugerkonto. Det er forhåbentlig tilfældet i overvejende grad, men det er bestemt ikke en naturlov. Der kan være flere personer, som kender den aktuelle kode – enten med vilje (f.eks. de “forbudte”, men desværre meget populære, »shared accounts«) eller som følge af en kompromittering.

Det er også helt bevidst, at jeg siger “svarende til“. Man kan nemlig have masser af essentielle rettigheder uden at være medlem af nogen indbygget privilegeret gruppe. Med »Delegate Control« funktionalitet i AD kan man eksempelvis komme rigtig langt, og hvis virksomhedens overvågningsværktøjer kun koncentrerer sig om ændringer af gruppemedlemskabet i de almindelige velkendte grupper, så kan en ondsindet person, som én gang måtte have opnået administratorrettighed på domænet, bevæge sig frit under radaren derefter.

Det er en sund øvelse også lige at kigge på, hvad der helt præcist skal beskyttes i AD sammenhæng.

Hvad består kronjuvelerne af?

De vigtigste computere i et AD er dets Domain Controllere. På disse servere foregår al magien omkring autentificering af brugere og tildelingen af rettigheder ift. gruppemedlemskab og lignende. Det er altså disse computere, som vi bør sikre bedre end alle andre. Hvis en eller flere af disse først er kompromitteret, så falder hele korthuset ofte sammen.

Det absolut vigtigste objekt på enhver Domain Controller er dens Extensible Storage Engine (ESE) database fil, »Ntds.dit«, der som standard placeret under biblioteket »C:\Windows\NTDS\«. Denne fil indeholder al information om ADs topologi og indhold, herunder selve nøglerne til slottet: alle brugernavne og tilhørende koder (kræver også en kopi af SYSTEM hive filen). Adgangskoderne optræder godt nok i (envejs)krypteret form (desværre u-saltede hashværdier), men det kan man efterhånden cracke relativt hurtigt, hvis ikke brugerne er særdeles dygtige til at finde på – og huske – lange og komplekse adgangskoder.

I denne fil ligger der altså en enorm værdi for en angriber. Med brugernavne og adgangskoder vil man i teorien kunne tilgå ethvert system (og tilhørende data), som er afhængig af AD autentificering – som den bruger man nu engang lyster.

Hvad gør man med hashen?

En angriber kan gøre to ting med de hashværdier, der kan trækkes ud af »Ntds.dit«. Enten kan de (1) benyttes som de er, nemlig til såkaldte »Pass-the-Hash« angreb, der i bund og grund svarer til velkendt Single Sign-On (SSO) funktionalitet, eller (2) de kan udsættes for forskellige typer crypto-angreb, f.eks. vha. bruteforce-, wordlist- eller rainbowtableangreb (eller hybrider heraf). Der findes masser af gratis og effektive værktøjer til den slags operationer. Der findes oven i købet online tjenester, hvis man ikke selv vil gøre arbejdet.

Hvis man ønsker det, kan man sågar kigge efter brugernes tidligere anvendte adgangskoder. Disse gemmes nemlig for at AD kan holde styr på om brugerne kan genanvende gamle koder, hvilket som standard er sat til 24 værdier. Hvis det lykkes at “dekryptere” to eller flere adgangskoder for en given bruger, så er der en god sandsynlighed for, at man kan finde mønstre, som vedkommende vil anvende til at danne fremtidige adgangskoder (og tilhørende hash-værdier) også. Sådan kan man på uautoriseret vis bevæge sig gennem netværket – under “falsk identitet” – længe.

Det er altså værd lige at se på hvem, der egentlig har adgang til dine Domain Controllere og dine uvurderlige »Ntds.dit« filer.

Hvem har adgang kronjuvelerne?

Jeg vil i dette indlæg se helt bort fra traditionel fysisk sikkerhed omkring virksomhedens Domain Controllere. Det er min påstand, at mange stadig har alvorlige udfordringer på dette område, hvilket jeg da også har tænkt mig at uddybe ved en kommende lejlighed. Vi skal her se på nogle andre almindelige “smuthuller”.

Bliver dine Domain Controllere overvåget?

Normalt er det jo positivt, hvis serverparken bliver overvåget effektivt. Mange virksomheder har management- og overvågningssystemer, såsom Microsoft System Center Operations Manager (SCOM) og System Center Configuration Manager (SCCM), eller tilsvarende systemer.

Disse systemers agenter eller bagvedliggende services er desværre ofte sat op til at køre i en brugerkontekst, som giver en “almindelig” server administrator langt flere rettigheder, end godt er.

Det kan eksempelvis være muligt, at eksekvere scripts med administrative rettigheder, altså “på vegne af” en mere privilegeret bruger, og måske oven i købet i SYSTEM kontekst.

Selvom der ikke er rettigheder til at logge direkte på Domain Controllere med f.eks. RDP, så kan der med lidt kreativ tankegang fifle med AD. Det er eksempelvis forholdsvis nemt at tvinge »Ntds.dit« ud af en Domain Controller vha. et lille PowerShell script, eller på anden vis at manipulere med AD.

I den forbindelse bør der stilles nogle afgørende spørgsmål, såsom: Skal disse systemer overhovedet køre på mine Domain Controllere, således at almindelige server administratorer effektivt bliver “Domain Admins”? Kan det begrænses, så det kun er de rette (og få) personer, der får mulighed for at udføre kritiske opgaver i AD? Bør Domain Controllere holdes i et selvstændigt management miljø sammen med f.eks. PKI og IdM serverne?

Er dine Domain Controllere virtualiserede?

Virtualiseringen af Domain Controllere har tilført endnu flere sikkerhedsudfordringer, hvis alvor den gennemsnitlige IT-ansvarlige synes at underkende. Ud over fysiske udfordringer, så har man nu også virtuelle udfordringer, og problemet er, som i så mange andre tilfælde, at man ikke har fået tænkt sikkerhed med fra starten. Det er jo så dejlig nemt bare lige at virtualisere alt, men nu har vi pludselig også administratorer af det virtuelle miljø at tage højde for.

Disse begunstigede individer kan eksempelvis nemt tage »snapshots« af kørende Domain Controllere og/eller eksportere disse til eksterne medier. Så har de god tid til at rode med dem offline derhjemme efter fyraften. Det kan jo også tage lidt tid at bruteforce en større brugerdatabase.

Er dine VM-administratorer også lige lovlig privilegerede i denne sammenhæng?

Hvem har ellers adgang til Ntds.dit filen eller kopier af denne?

Lad os også lige kigge på storage. Hvis der anvendes SAN, NAS eller cloud storage, hvad enten det er til iSCSI eller NFS diske, eller om det er til backup, så er der her en anden angrebsvinkel.

En storage administrator har oftest fri adgang til »Ntds.dit« filer, enten som rå filer eller inde i containere, så som VMDK eller VHD(x) filer. Måske kan disse filer hentes fra skyen, mens man sidder på netcaféen nede på hjørnet? Dejlig nemt og bekvemt.

Vi har også vores kære »Backup Operators«. Det lyder jo umiddelbart harmløst, men de kan altså også få fat i kronjuvelerne relativt problemfrit. »Volume Shadow Copy« teknologien har oven i købet gjort det ekstremt nemt at hive »Ntds.dit« ud af en kørende maskine, som ellers har låst den pågældende fil (alternativt kan »ntdsutil« anvendes til formålet).

Har du et komplet overblik over hvor din virksomheds AD-kronjuveler er, og hvem der har adgang til dem?

En “Domain Admin” logger kun på Domain Controllere, ikke?

Det sidste sikkerhedsproblem jeg her vil nævne, er desværre ret almindeligt i dagens Danmark – og resten af verden for den sags skyld.

Det er således, at enhver lokal administrator på en given Windows maskine (klient eller server), hvor en bruger forinden har været logget på som “Domain Admin”, har adgang til sidstnævnte administrators adgangskode, igen i form af en hashværdi. En lokal administrator kan tiltvinge sig adgang til maskinen hukommelse, hvor login-sessioner gemmes.

Det vil med andre ord sige, at databaseadministratoren, som ellers kun er lokal administrator på f.eks. “SQLSERVER1″, kan opsnappe og genanvende adgangskoder for de administratorer på domænet, som måtte være – eller har været – logget på “SQLSERVER1″, indtil denne genstartes.

Der er ganske vist lidt ændringer i dette scenarie med Windows 8.1 og Windows Server 2012 R2, men det kommer jeg tilbage til i et kommende indlæg dedikeret til »Pass-the-Hash« angreb og »Credential Hygiene« konceptet.

Igen kan det være sundt at stille sig selv nogle spørgsmål: Er det muligt at få en “Domain Admin” til at logge på applikations- eller databaseservere i dit miljø – eller en klient for den sags skyld (typisk IT-support/Helpdesk) – eller har man allerede garderet sig imod dette scenarie? Kører der »services« eller »scheduled tasks« i “Domain Admin” kontekst på den slags servere? Hvis en “Domain Admin” har været logget på andet end en Domain Controller, bliver den pågældende computer så genstartet umiddelbart efter sessionens ophør?

Afrunding

I dette indlæg har jeg gjort rede for, at det ikke er helt så enkelt at afgøre, hvem der er administrator i et givet AD domæne, på grund af typiske uhensigtsmæssigheder i implementeringen af AD og tilhørende administrative praksis.

Så hvis du sidder som IT-ansvarlig i en virksomhed, hvor AD er central container for alle medarbejderes identitet, og du ikke har helt styr på alle ovenstående problemstillinger, så lad mig lige spørge dig igen: hvor mange administratorer findes der egentlig på dit domæne?

I kommende indlæg på denne blog vil jeg komme ind på detaljerne i flere af de ovenfor berørte sårbarheder og angrebstyper. Der kommer vi lidt dybere ned i teknikken. Stay tuned!

Links til relaterede artikler og baggrundsinformation

• Artikel: Enforce password history
• Artikel: Obtaining NTDS.dit Using In-Built Windows Commands
• Artikel: Password Audit of a Domain Controller
• Whitepaper: Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques
• Whitepaper: Best Practices for Securing Active Directory

Norske myndigheder advarer nu om, at biler med intelligente transportsystemer (ITS) kan være pivåbne for hackere, skriver Teknisk Ukeblad.

Krypteringen i systemerne er ofte alt for svag, og hackere kan vælge og vrage mellem indgange i systemerne, lyder det. Samtidig er kildekoden til systemerne lukket land for alle andre end bilproducenterne selv. Det vækker bekymring hos senioringeniør Marie Moe fra det norske Nasjonal Sikkerhetsmyndighet (NSM).

»Det gør det vanskeligt for uafhængige sikkerhedsforskere at få indblik og føre kontrol med kvaliteten på løsningerne,« siger Marie Moe til Teknisk Ukeblad.

En lang række funktioner i nutidens biler bliver styret af elektroniske kontrolenheder (ECU). De kommunikerer over bilens interne netværk, som kaldes CAN-bus (controlled area network).

»Her er en række porte, som åbner for at tage kontrol over systemet, som usb-porte, cd-afspilleren og ikke mindst OBD II-porten, som bruges af mekanikere til at læse information fra bilens elektronik,« siger Marie Moe til Teknisk Ukeblad.

Interesseret i bilsikkerhed – følg med i din indbakke med Ingeniørens nyhedsbrev

»Det er også muligt, at man kan koble sig ind ved hjælp af den trådløse kommunikation til bilnøglen,« fortsætter hun.

Når først hackere er inde i systemet, er der på grund af den ringe kryptering ikke meget, der holder dem tilbage.

Dertil kommer det, at mange af bilerne ikke bliver opdateret. Det er særligt problematisk, fordi biler har en længere levetid end det meste forbrugerelektronik, og softwareopdateringer er derfor nødvendige for sikkerheden.

Hackere demonstrerer, hvordan de kan overtage styringen af en bil.

Oracle har nu officielt frigivet den nyeste udgave af Java-platformen, som ifølge selskabet selv er den største i form af nye funktioner i mange år, efter Java 7 især blev brugt til at rydde op i platformen.

Det betyder, at Oracle blandt andet har knækket koden til at få gjort de såkaldte lambda-udtryk til en del af selve Java 8-platformen.

Lambda-udtryk er et koncept med rødder helt tilbage til før de første elektroniske computere, men de har de seneste år fået en renæssance, fordi de både kan give objektorienterede sprog som Java en let måde at skrive små funktioner på og en måde at lave programmering til parallel databehandling.

»Vi har integreret lambda-udtryk, så det fungerer glat sammen med Javas objektorienterede rødder. Det har ikke været nogen lille udfordring«, siger Georges Saab, underdirektør med ansvar for Java-platformen hos Oracle, til Version2.

Lambda-udtryk er en anden måde at lave funktionskald på, end den objektorienterede model, som Java hidtil har benyttet og som fortsat vil være den primære måde at programmere i Java. Lambda-udtryk findes i en række andre programmeringssprog, eksempelvis Microsofts .Net og C#, og det var oprindeligt planlagt, at lambda-udtryk og de beslægtede closures skulle have været med allerede i Java 7.

Det blev imidlertid droppet, men nu er både lambda-udtryk og closures altså med i Java 8.

»Vi ønsker at gå forsigtigt frem og så tilføje mere funktionalitet senere, så vi kommer til at se en løbende udvikling. Det her er heller ikke vores første forsøg på lambda-udtryk«, siger Georges Saab.

Lambda-udtryk kan blandt andet bruges til at lave applikationer, som kan arbejde parallelt, og her har det været vigtigt, at lambda-udtryk i Java ikke på samme måde som programmering med tråde lagde det meste af byrden på udvikleren, men i stedet lod Javas virtuelle maskine gøre det grove arbejde.

»I den første version var ydelsen udmærket, men det skalerede ikke, som vi gerne ville have det. Nu synes vi, det er rigtig godt, men der er stadig plads til forbedring«, siger Georges Saab.

Da lambda-udtryk er en tilføjelse til Java, har det også været vigtigt at gøre det på en måde, så det kunne bruges til at udvide allerede skrevne Java-applikationer uden at skulle skrive sin kode helt om.

Ud over understøttelsen af lambda-udtryk, så har Java 8 også fået den nye Javascript-motor Nashorn og et helt nyt API til tid og dato.

Desuden er der nu rettet ind mellem de to udgaver Java SE 8 og Java ME 8, så ME-versionen blot er en delmængde af SE-udgaven.

ME er beregnet til helt små apparater som eksempelvis intelligente termostater, mens den nye Java SE 8 Embedded er beregnet til lidt større enheder som eksempelvis en Raspberry Pi.

Den russiske regering har besluttet sig for at udskifte alle sine iPads til tablets fra Samsung i stedet.

Hidtil har regeringen benyttet sig af iPads til sessioner i det russiske kabinet, men det er altså ikke tilfældet længere.

Selv om det kunne ses som et signal til Vesten midt i krisen i Ukraine, hvor Rusland møder sanktioner, er det ikke tilfældet forlyder det fra det russiske nyhedsbureau ITAR-TASS.

Det er derimod et spørgsmål om sikkerhed, understeger den russiske minister for kommunikation, Nikolai Nikiforov.

»De er specielt beskyttede enheder, som kan blive brugt til at behandle fortrolig data. Dele af informationerne ved kabinetsessioner er fortrolige, og disse Samsung-devices tilfredsstiller til fulde disse behov og har været underlagt den strengeste certificering,« siger han til det russiske nyhedsbureau.

Hvor det altså kunne ses som et russisk signal til Vesten om, at man er villig til at boykotte deres produkter, på samme måde som Vesten lægger Rusland på is oven på annekteringen af halvøen Krim, slår den russiske regering altså fast, at skiftet fra amerikanske Apple til Samsung intet politisk budskab har.

Ifølge den russiske kommunikationsminister Nikiforov tog man dog beslutningen om udskiftningen for ikke så længe siden.