Först publicerad på Hans Husman om Media: PDF: Säkerhetsrisk att angripare systematiskt analyserande stora mängder dokument.

En av de funktioner jag i särsklass haft störst nytta av från funktioner Google adderat genom åren till sökresultaten är quick view för PDF (och önskvärt vore det samma för PS: givet mängden bildformat webbläsarna klarar och nästan sedan starten divergensen från html-konceptets idé om att ej ha absoluta avstånd o.s.v. och att det är det basala skrivar-språket d.v.s. jag betvivlar licens-problem eller svårighet tolka - förstår jag inte problemet).

För mig nyligen försvann funktionen. Även om jag inte ska utesluta att det är inställnings-relaterat (inte heller har jag kontrollerat om det fortfarande är funktionellt ex. via Google Docs d.v.s. access Google cache av PDF-filen snarare än originalet) var den första associationen jag nu håller som mindre trolig att det var relaterat att funktionen ofta är funktionell för att nå filer man ej direkt har access till. Förklaringen vad jag kommer ihåg utan undantag (surfande dock regelmässigt journal-artiklar när det handlar om PDF) är:

• Åtminstone för flera journal-hus att de vill ha bättre indexering av PDF-filerna och gör Google full access.
• De stänger ej av cache av dessa eller generellt. Anmärkningsvärt möjligen indikerande ett pedagogiskt eller tekniskt problem med någon plattform hos publicist eller Google är att åtminstone ett större journal-hus har cache avstängt html men ej på PDF (ev. på annan subdomän mer för html inkluderande där särskilt sammanfattningar med väldigt långt historiskt kontext bakåt), och samma ger ej access via cache på flera domäner men åtminstone för de mer arkiv-liknande subdomänerna inkl. pdf finns den.
  
  
• D.v.s. oavsett betallösning journal-huset tänker sig kan vi för fallet när PDF-filen existerar i cache åtminstone i meningen att den går att nå där via quick-view (om detta avviker i övrigt för cache vet jag inte).

Regelmässigt när vi når login-ruta hos journal är det ju vettigt att söka Google på titeln. Inte ovanligt har ex. universitet rätt att publicera artikeln i dess helhet och vi kan läsa den. Görande detta får vi också normalt upp sökträff journalen och kan där notera möjligheten, och beroende på moralisk-tolkning (jag tolkar detta som att de vanligen gjort detta helt medvetet för att relativt annat on-site ganska taffligt försök att få mer trafik och därmed accepterar läsare via denna kanal varande färre än vad de tror ska generera försäljningsaffärer via mer allmän söktrafik).

Emellertid såvida inte något varit direkt fel hos Google betvivlar jag nu förklaringen. För Google att direkt engagera sig i sådana fel-beslut (när det ev. är det) är ju små-dumt. Det gör det otydligt var deras ansvar börjar och slutar samtidigt som givet tämligen konservativt föränderliga idéer och lösningar med sällan något radikalt nytt (jfr de sista större för många år sedan med sitemap's via XML, och API-leverans, resp. Google:s administrationstjänst hos dom för det och andra enklare inställningar).

Så vad är förklaringen? Jag har också nyligen uppmärksammat att andra aktörer också skurit återpublicering PDF. Vi kan se relationer till dom samarbetsgrupper för informationssäkerhet inkluderande särskilt större företag med behov och bredare påverkan, myndigheter och inte sällan leverantörer som normalt inte bidragit särskilt konstruktivt alls i problemlösning (d.v.s. jag avser antivirusföretagen) som etablerades för ett antal år sedan under Bush II period vid makten.

Vilket problem kan vi ha i PDF som skulle föranleda detta? Säkerhetsdefekter öppnande upp läsarens dator betvivlar jag lätt här eftersom det normalt bör vara en uppdateringsfråga snarare än publicist-fråga.

Däremot om PDF på skapande sidan - antingen som troligast den som ursprungligen skapat dokument men ev. också den som återpublicerar - adderar information som inte förväntas eller förstås ska finnas där kan det innebära problem krävande sådant här. Ex. om filerna kan innehålla "pdf-lokala" lösenord möjliga att extrahera direkt eller indirekt (ex. indirekt svaga-hash för bruteforce-angrepp) inkluderas inser vi att om användarna återanvänder dem kan problemet vara enormt. Många aktörer här är ju ex. myndigheter m.m. Mycket annat liknande är också tänkbart och då jag inte kan något om formatet mer än att jag noterat att dess iso-ofta feltolkas regelmässigt vid kopiering ex. från Google quickview till dokument i Google Docs kan jag ingenting om det.

Inte heller har jag kontrollerat vad som kan ha publicerats. Mitt perspektiv på sådant här är att problematiken ej är associerat ett dokument-format eller tjänst utan allt publicerat sker denna mining på regelmässigt av olika aktörer. För återpublicerande aktörer att ta bort filerna kan vara mer relaterad att de inte ska riskeraa publicera vägar in att angripa ursprungligt publicerande trots att de kanske själva korrigerat problemet.

Först publicerad i Hans Husman om Media: Pan-amerikanska Intrusion detection: Har företag i internet-infrastruktur börjat kopplas in?.

Det upplevde jag för några år sedan tittande ytligt på förslagen och vad publicerat en hel del risker med idén om en stor pan-amerikanskt IDS-lösning för myndigheter m.m. I rapporterings-mening är det excellent men fodrar också att man tänker redundans i annan mening än flera lager av säkerhet i definierade lösning hanterande risken att samtliga är osäkra samtidigt eller i sig självt introducerande säkerhetsproblem påverkande samtidigt "allt".

Projektet fördröjdes i driftsättning och även om vi inte ska utesluta att mina och troligt en hel del andras indikation kring dom riskerna spelar in ska vi också förstå stora IT-projekt oavsett i myndighet eller företag som vad som välkomnar frågetecken av typen nya övergripande risk att hantera, politiska frågor som behöver säkerställas o.s.v. Stora projekt är har alltid mer kvar att göra när det ska driftsättas (då får i värsta fall den stackars configuration mananger resa iväg och göra driftsättning i tjänstetecken som "råkar gå fel": kan det vara hårdvaran i er testmiljö? Vi får pröva igen i morgon).

Antar vi nu att projektet nått längre idag - jag har ej följt upp - kommer logiskt en punkt givet den utgångspunkt och idé-system för nationell säkerhet man tidigt indikerade som vision att se kritisk infrastruktur som kritisk oavsett om formellt statligt, i statligt kontrollerat bolag eller överhuvudtaget inte statligt.

D.v.s. vi kan tänka oss att man hänger på IDS-systemet utanför befintliga infrastruktur-nära eller stora internet-strukturer (ex. sökmotorer, sociala media m.m.).

Om så är fallet är frågan hur bra gjord IDS-lösningen är. Är den helt tyst är det excellent därför om den inte är tyst såvida inte whitening är infört välgjort (och det är den föga troligt om IDS-lösningen redan på trivial nivå inte är tyst) berättar den saker för mig. Den läcker information.

Mer uppenbart kan det handla om problem med den själv relaterat vilken mjukvara den har installerad. Inte lika problematiskt men väl så mycket lättare att angripa är om IDS-lösningen gör information sharing som kan användas för att politisk angripa entiteter som stött lösningen, konceptet i sig själv eller som den av en egentligen icke-relaterad länge pågående kampanj (där det inte behöver ha särskilt stor betydelse vem, vad eller ens hela USA som koncept den riktar sig mot så länge entiteten som är målet kan associeras till lösningen).

Antag nu att information relaterat "hostile spidering" d.v.s. strunta i dom små konfigurations-filerna och hämta ut den statistik vi är intresserade av säg ex. av några myndigheters sökmotorer (där även om jag inte nödvändigtvis själv skulle göra det vet att taket sitter ganska högt generellt på amerikanska myndigheters sajter: de klarar en hel del och vill dela information) propageras som risk indication till sökmotorer och internet-tjänster där du är inloggad.

Om så kan åtminstone jag se med din statistik över väldigt många koncept associerade politiska kampanjer såväl som några år en ganska flitig leverantör av press-releaser, nyhetshändelser (ex. företag A får en nyhet att leverera branschtidning B så att dom syns för att visa kompetens och slå-ner konkurrent inför upphandling relaterat säkerhetsproblem, driftinstabilitet eller liknande) o.s.v. att ett politiskt säkerhetshål har introducerats.

Vad mera är kommer nu frågan om information sharing konceptet i sig läcker information om användar-profilerna. Ingenting indikerar nu det och jag ser inte att jag korrekt kan pröva det liksom ej heller att jag skulle det med mindre än att man hade betalat mig per timme för det från nät- och produkt-ägare eller lösningen i sig indikerat hotar struktur jag har ett direkt ansvar för där finansiering hanteras i det och genomfört juridiskt korrekt (ej fallet). Men att sådana över-uttryckta information-sharing kan läcka information är en risk vi ska värdera jämförande med historiken vi har för generella kommunikationsprotokoll, krypteringslösningar i protokoll (jfr SSL, SPKM, GSS-api med associerade kompisar, Kerberos o.s.v.). Och när tester och quality assurance planeras tänka: På vilken nivå ungefär ligger vårt säkerhetstänk jämfört med generella kommunikations- och säkerhetsprotokoll? Och under det vilket eller vilka sådana är vår lösning beroende av? Där den stora frågan är om det hela rent av läcker direkt till klient i data och timing sequences den humpar tillbaka ner till.

Men här är vi ute i det mycket spekulativa därför jag har inte följt upp ens om lösningen fortsattes som projekt, om så driftsatts seriöst eller hur man ser den specifikt ska passas in. Jag noterade endast att man nät-dumper flaggade samtidigt som min webbläsare flaggade interferens rörande ett ej exakt motsvarande exempel men som möjligen föreslår något åt det hållet.

Det blir lätt komiskt när åtminstone en tämligen kreativ tolkning av vår ordlek med Microsoft produktnamn relaterat up diskuterades som ett ex. (lika bra som något annat man antagligen kan hitta) rörande en del potentiella möjliga problem tycks uppvisa "nuhet" eller "horoskop-kvalitet":

• Är Microsofts DataUp bättre eller sämre än verklighetens DataDown? (2013-02-22)
• Ridiculous: Microsoft's Azure Fails Over Unrenewed Security Certificate | Forbes

Jag kände dock inte ens till tjänsten och även om jag tycker konceptet molntjänster generellt verkar lovande är min allmänna princip kring nytt inom IT att när det blivit tråkigt och är en 8 - 12 år inkört börjar det bli lagom att pröva på (Ubuntu var jag i brott mot mina principer cirka 1 år tidig på - endast sju år gammalt - men då bygger det ju ändå till 98% på allt i övrigt runt Linux förutom lite extra-stöd runt installationen och configuration management: Första release "20 October 2004; 8 years ago" enligt Wikipedia).

Egentligen hade jag inte tänkt skriva något om det därför att jag inte vill utesluta att läsare felaktigt kunde tolka Är Microsofts DataUp bättre eller sämre än verklighetens DataDown? (2013-02-22) lite personlig, och i så fall denna p.s.s. Nu har jag emellertid senaste väldigt många år ett särskilt intresse av SSL liksom liknande lösningar som SPKM (och lite längre ut Kerberos), och vill allmänt gärna följa "security events" relaterat SSL som tycks beröra större infrastruktur. I kontext av att spara sådana händelser är den lösning som fungerar enklast och mest kostnadseffektivt att blogga det. Korrekt här ser man det som jag egentligen inte bryr mig om det är Microsoft eller något annat IT-företag. En korrekt förtroendeingivande lista av ett mindre urval i form av vad publicerat just Hans Husman om Information Warfare finns sist i Relaterat: SSL, och ger också en del konkretiserade exempel för vad som berörs i slutet ytterst kortfattat (nu när Microsoft säkert redan är ganska nedstämda och ledsna över det här problemet vill jag inte att dom ska känna att jag mobbar dem).

Predikterbarheten om den alls finns som utomstående har vi dock i diverse tidigare problem att hantera certifikaten både Microsoft och andra haft, och rent av för samma tjänst:

• Summary of Windows Azure Service Disruption on Feb 29th, 2012 | MSDN Blogs > Windows Azure > Summary of Windows Azure Service Disruption on Feb 29th
[Red. Tycks vara officiell information från Microsoft.]

Om Microsoft haft större problem än andra generellt inom t.ex. molntjänster vet jag inte men om så verkar det kanske inte orimligt genom att jag har för mig att de har egen katalog-hantering som är tämligen varierad i plattformarna den är implementerad på. Alla X.500-standarderna liksom X.509 (att för den tidsrika- och över-ambitiösa läsaren laborera med via OpenSSL) är inte helt triviala i representation (ASN.1) vilket egentligen just för certifikat idag inte ska behöva vara ett problem men kanske lättare blir det ju mer av lösningen man själv tagit ansvar för och därmed kanske lättare anpassar av och till när det upplevs nödvändigt eller praktiskt för att möjliggöra något vilket ju inte sällan åtminstone när jag programmerar tenderar att ge underliga fel.

Uppgifter från användarna tycks i alla fall indikera att det är just server-certifikaten som gått ut även om jag inte klarade att hitta någon information från Microsoft:

• Storage certificate expired? | social.msdn.microsoft.com/Forums/

Oavsett problemet med tillgänglighet när en molntjänst (för vilka den poäng jag kan se är att man ska slippa bry sig i allt som annars av och till orsakar problem - inte minst att saker går ner p.g.a. slarv - genom standardiserat arbete och quality assurance som når en längre genom att väldigt många användare delar utvecklingskostnaden för plattformen samtidigt som nersidan för leverantören blir så mycket större när en mängd kunder drabbas samtidigt istället för ett fåtal) ska säkerhetsproblemet heller inte underskattas enligt t.ex. nedan:

"According to Microsoft, the outage that affected Azure was due to something as minor as an expired SSL certificate."

[Red. Referensen till Microsoft tror jag inte stämmer utan är nog snarare användarnas diskussion.]

Från: Expired SSL certificate causes Microsoft Azure outages | Slashgear.com

Om vi börjar utanför den specifika instansen av problem indikerar det att man inte har kontroll över sina server-certifikat där andra problem inte lika uppenbara möjligt också kan vara fallet. Att dom nya certifikaten endast tycks vara giltigt ett fåtal månader indikerar kanske att man insett detta problem utan att åtminstone rörande alla kompetenser varit medvetna om det. De kortare certifikaten kanske just nu får kort giltighet för att ge tid att verifiera att de i övrigt är sunda (rörande hashfunktioner-använda, asymmetriskt lösning och associerat generering av nonsen resp. symmetriska nycklar för resp. session). Alternativt att man inte vill utesluta att CA-server i den egna infrastrukturen en bit upp vidrörts av något som inte borde ha varit i närheten av dom.

För det specifika fallet gäller det ju verkligen för att någon säkerhet över en större population klienter ska bibehållas att tjänsten korrekt gick ner direkt när certifikaten gick ut. Om inte generellt finns ju alltid risken - genom att dom här lösningen när så inte är fallet låter klienten göra ett avgörande - risken och problemet att klienten just kan välja att acceptera ett certifikat som gått ut. Kan de verifiera att en mängd andra användare har problem samtidigt är det ett ganska enkelt beslut att fatta potentiellt felaktigt om man har behov av att komma åt något. Någon god möjlighet att verifiera certifikatet man accepterar finns inte på det sätt som de flesta kommer göra det och därmed kan sessionen vara öppen för vad helst som befann sig framför en viss tjänst.

Även om så ev. kanske inte var möjligt om tjänsten stängde ner korrekt ska man inte utesluta att sådant här kan ske prospekterande mot givna användare. Det kan tyckas lite underligt särskilt om vi går så långt att vi inte utesluter att själva hanteringen av certifikaten server-side tagits ner som del av ett riktigt angrepp. Emellertid om säkerhetsarkitekturen för molntjänsten är något så när vettigt gjord ska den vara avgränsad och utan att access till en viss del av lösningen öppnar upp allt över alla användare. Just här behöver det ju inte vara mer än att underordnad katalogserver klarats att kanske isolerats i nätet. En känsla jag har är att ganska mycket skett riktat prospekterande över en mängd företag och tjänster sista 10 - 11 veckorna (om inte mer). Det här tycks väl kanske inte lika troligt vara en del av det men det återstår att se om nu Microsoft kommer ge mer information när deras utredning är klar av orsakerna.

Lämnar vi Microsoft och ser mer allmänt på detta problem och liknande är känslan att det i mycket har att göra med att SSL ofta egentligen inte ses som del av säkerhetsarkitektur med förståelse och hantering av aktuella grupper av problem på det sätt som krävs för att man ska få säkerhet i nivå med det förtroende man vill att SSL ska kommunicera till användarna. Både hur SSL-sessioner parametriseras, server-stöd aldrig uppdateras avseende protokoll, underliga fallback till "mindre" säkra konfigurationer, ständiga problem med server-certifikat lite överallt o.s.v. är det om inte så vad vi åtminstone behöver förklara med att för mycket ansvar för säkerhetslösningen ligger där den idag för ofta inte hanterats bra. Tråkigt räcker det knappast helt även om det började skötas exemplariskt på server-sidan. Lösningen för boot-strapping av betrodda certifikat hos klienten är inte direkt helt optimala inte sällan byggande på principen att man laddar ner en webbläsare eller helt operativsystem utan SSL eller får på ej betrott medium i vilken server-certifikaten vi litar kommer med.

SSL-branschen har dock alltid varit mycket förtroende i vad som går att göra och kan visas upp. Ex. väldigt säker hosting för några enstaka centrala certifikat-server väldigt högt upp i nätverken medan det mesta under mycket verkligare för säkerheten oftare sköts lite hur som helst. Och det är överhuvudtaget på många sätt både en väldigt framgångsrik och värdefull säkerhetsprimitiv såväl som en lösning på alla sätt mindre bra än vad som egentligen är önskvärt. Praktiskt igång och vad folk använder kontra något som skulle vara ett större djävulskap likt föga annat att få ut och nå acceptans för hos både användare och "servrar". Ungefär som väldigt mycket annat i vår vardag (ex. cigarett-filter: fortfarande massor av lungcancer, hjärt- och kärlsjukdomar o.s.v. men påminner i alla fall rökarna dagligen om att röken är farlig nog att "kräva" filtrering).

Relaterat: SSL

• SSL i Chrome och på Google.com + Verifiera din webbplats (1/15/2009) | Hans Husman om Information Warfare
• Google: OpenSSL + NSS och SSL i Chrome + Native Client + Ratproxy (1/13/2009) | Hans Husman om Information Warfare
• Att tunnla SSL resistent mot trafikanalys (3/25/2010) | Hans Husman om Information Warfare
• Svenska myndigheter: SSL-problem och bortglömda domäner (2/16/2012) | Hans Husman om Information Warfare
• MD2 ger säkerhetshål i SSL (8/09/2009) | Hans Husman om Information Warfare
• Secure Sockets Layer (SSL) (3/13/2010) | Hans Husman om Information Warfare
• En kul detalj runt SSLeay som ju blev OpenSSL resp. RSA (2/16/2010) | Hans Husman om Information Warfare
• Appropå C och säkerhet (1/12/2009) | Hans Husman om Information Warfare
• OpenSSL godkänd av DHS (?) (7/26/2012) | Hans Husman om Information Warfare