Ray Ozzie ha oramai abbandonato il suo ruolo di Chief Software Architet presso Microsoft, ma a quanto pare lo sviluppatore di Lotus Notes ha ancora qualcosa da dire riguardo il lavoro sin qui svolto in quel di Redmond. E soprattutto su quello non svolto, gli obiettivi raggiunti parzialmente o comunque non al livello di integrazione che il manager sperava.
Dov’è finita la svolta epocale di cui parlava Bill Gates cinque anni fa anticipando l’entrata in gioco di Ozzie in uno dei ruoli operativi più prestigiosi in quel di Redmond? Ozzie concede a Microsoft il merito di aver fatto notevoli progressi in merito all’integrazione tra i suoi modelli di business tradizionali e il cloud computing, ma dal memo Dawn of a New Day traspare anche il malcontento per quello che si sarebbe potuto fare e non si è fatto.
Nel futuro “inevitabile” descritto da Ozzie, le esperienze di computing sono necessariamente “transmediali e intra-dispositivo”, incentrate sui network sociali o aziendali dell’utente e con la possibilità di sincronizzare ogni genere di dispositivo con la “nuvola” di dati disponibile sui server remoti dell’organizzazione/servizio di riferimento.
Dove si colloca Microsoft in tutto ciò? “Nonostante il nostro enorme progresso”, dice Ozzie, “alcune delle opportunità che indicai nel mio memo cinque anni fa restano ancora da realizzare”. Ozzie aveva una visione “chiara” di come andava eseguito il balzo evolutivo del modello di business di Redmond, eppure i concorrenti hanno superato Microsoft “nelle proprie esperienze mobile, nell’integrazione senza soluzione di continuità tra hardware e software e i servizi, e nel social networking e in una miriade di nuove forme di interazioni sociali Internet-centirche”.
Ufficialmente Ozzie continua a supervisionare i business Microsoft – Xbox e Windows Phone 7 in particolare – ma a giudicare da quel che traspare dal suo nuovo memoriale pare evidente che il manager si sia messo in rotta di collisione con una visione manageriale avversa , che gli ha lasciato meno libertà di quanta lui avrebbe voluta per operare al meglio.
Alfonso Maruccia
-
No, un momento...
Questo exploit funziona solo su una rete wifi non protetta... o sbaglio?Su una LAN cablata concettualmente potrebbe anche funzionare, ma non così facilmente, richiederebbe altre tecniche "malevole" come ARP spoofing e compagnia briscola...FridayChildRe: No, un momento...
Da quello che leggo, basta essere sulla stessa LAN...- Scritto da: FridayChild> Questo exploit funziona solo su una rete wifi non> protetta... o> sbaglio?> Su una LAN cablata concettualmente potrebbe anche> funzionare, ma non così facilmente, richiederebbe> altre tecniche "malevole" come ARP spoofing e> compagnia> briscola...Homo ArtisticusRe: No, un momento...
Insomma sto stizio che si è inventato un semplice wireshark su firefox?PippoRe: No, un momento...
- Scritto da: Pippo> Insomma sto stizio che si è inventato un semplice> wireshark su> firefox?sto tizio ha inventato un tool x scimmie ritardate che fa tanto hype (appunto per quello) ,ma le tecniche sono poi sempre le stesse : sniffing su reti wifi aperte (o -fatto in separata sede- ARP poisoning su wired lan) , collecting dei cookie e spararli verso il sito "target", per 'rubarne' l'identita.Naturalmente essendo il collecting & co dei cookie molto specifico per il singolo sito bersaglio (ci sono i digest, md5, ecc.. deve replicare nel giusto modo) e' chiaro che funzionera' bene nei primi tempi, e poi i "target" in lista, cambieranno qualcosa, e se nessuno aggiorna il tool, non fungera' piu'. ANCHE se la tecnica in se continuera' ad andare sinche' tutto non sara' criptato end-to-end, o il sistema usera' qualcosa di molto clever [es: pgp/aes/smime in javascript] ... (ma comunque riduplicabile ,visto che si puo sniffare).bubbaRe: No, un momento...
- Scritto da: bubba> sto tizio ha inventato un tool x scimmie> ritardate che fa tanto hype (appunto per quello)> ,ma le tecniche sono poi sempre le stesse :> sniffing su reti wifi aperte (o -fatto in> separata sede- ARP poisoning su wired lan) ,> collecting dei cookie e spararli verso il sito> "target", per 'rubarne'> l'identita.> > Naturalmente essendo il collecting & co dei> cookie molto specifico per il singolo sito> bersaglio (ci sono i digest, md5, ecc.. deve> replicare nel giusto modo) e' chiaro che> funzionera' bene nei primi tempi, e poi i> "target" in lista, cambieranno qualcosa, e se> nessuno aggiorna il tool, non fungera' piu'.> ANCHE se la tecnica in se continuera' ad andare> sinche' tutto non sara' criptato end-to-end, o il> sistema usera' qualcosa di molto clever [es:> pgp/aes/smime in javascript] ... (ma comunque> riduplicabile ,visto che si puo> sniffare).Non credo.L'unico modo per evitare lo sniffing è usare SSL (https).E' un difetto by design .Il cookie-stealing non necessita di particolari accorgimenti: in pratica adotta la stessa tecnica del salvataggio delle sessioni dei vari browser.Solo che le sessioni non sono le tue :)Il tutto è gestito da un handler (uno per ogni dominio previsto) presenti in "handlers" tramite back-end che è un vero e proprio "spoofer" (un eseguibile in Windows e Mac OSX): firesheep-backend.L'uovo di colombo.H5N1Vabé... non si può avere tutto dalla vit
Vabé... non si può avere tutto dalla vita...http://arewefastyet.com/ 8) 8) 8) 8) 8) 8)UbuntoRe: Vabé... non si può avere tutto dalla vit
Scusa... ma che c'entra il tuo commento?Dave veeRe: Vabé... non si può avere tutto dalla vit
- Scritto da: Dave vee> Scusa... ma che c'entra il tuo commento?A volte sono benaltrista. Questa è una di quelle.Spero tu capisca il motivo guardando quel grafico.UbuntoRe: Vabé... non si può avere tutto dalla vit
Mi associo al "non capisco".Velocità nei benchmark vs thread sul rubare i cookies ( ai bambini? :) ), proprio non riesco a metterli insieme.ValerenLeggete bene
... c'è bisogno, in background, del tool "Winpcap" per l'effettivo sniffing dei pacchetti in transito.Dal sito: "Note: Windows users need to install Winpcap first!"e grazie al c4zz0...eee rrrIo non ci sono mai cascato
Quando ho scritto software finora ho SEMPRE vincolato il cookie all'indirizzo IP della macchina. L'ideale compromesso tra sicurezza e necessità di riloggarsi sarebbe alla sottorete /24, se ognuno si fida della propria LAN, ma se i siti web più popolari sono realizzati da sprovveduti, beh, non ci possiamo fare niente.Inoltre se siamo nattati siamo doppiamente fregati, il trucco di Firesheep funziona alla stragrande...Una volta ebbi un cookie amministrativo di dooyoo.it su un mio pannello web, non vi dico..... :) (anni e anni e anni fa)-----------------------------------------------------------Modificato dall' autore il 26 ottobre 2010 21.33-----------------------------------------------------------djechelonRe: Io non ci sono mai cascato
- Scritto da: djechelon> Quando ho scritto software finora ho SEMPRE> vincolato il cookie all'indirizzo IP della> macchina. L'ideale compromesso tra sicurezza e> necessità di riloggarsi sarebbe alla sottorete> /24, se ognuno si fida della propria LAN, ma se i> siti web più popolari sono realizzati da> sprovveduti, beh, non ci possiamo fare> niente.> Inoltre se siamo nattati siamo doppiamente> fregati, il trucco di Firesheep funziona alla> stragrande...ci spiegi come fai, da un'appliXXXXXone web, a gestire i'ip interno alla lan (192.168.x.x)? o ricorri a java che legge e manda poi al web server o ti attacchi.L'unica è utilizzare https per tutta la sessione, non solo al login.eee rrrRe: Io non ci sono mai cascato
- Scritto da: djechelon> Quando ho scritto software finora ho SEMPRE> vincolato il cookie all'indirizzo IP della> macchina. L'ideale compromesso tra sicurezza ebeh in una azienda molto probabilmente tutti i pc escono con lo stesso identico IP, per cui non ha molto senso vincolare l'IP alla macchina, non ci vedo alcun valore aggiunto...bboGMAIL usa sempre SSL
se non sbaglio da qualche tempo GMAIL usa forzatamente http.forse non lo usa al momento del login, dovrei controllareBoboMilanoRe: GMAIL usa sempre SSL
gmail.com: Thawte SGC CA [128 bit]Dourangoveramente...
Io la uso come una "feature"...No non è una battuta!Hai da vedere come si incrokkiano i siti di advertising quando in due o tre si scambiano qualche cookie.L'importante è non fidarsi delle password in "chiaro"...Del resto di cosa stiamo parlando?Da quando non è possibile sniffare le connessioni in chiaro (e quindi anche lo scambio dei cookies)?Avete presente wireshark e il suo predeXXXXXre ethereal?Non c'è difesa da questo!Salvo criptare tutto!Mah... mi pare che il tutto lascia il tempo che trova!ullalaFiresheep
Se firesheep ruba le credenziali all'interno di una rete significa che l'utente "malandrino" sia già connesso con quella rete e che possa essere già a conoscenza di username e password. Di sicuro se andassi in giro con il notebook non potrò comunque accedere alle reti wifi protette. Certo, se poi voglio rubare le credenziali della rete di un amico o conoscente che mi lascia connettere alla sua wireless be'...Se il mio ragionamento non è errato, credo quindi che firesheep non sia così malvagio. O posso accedere alle credenziali di altre reti alle quali non sono connesso? In questo caso, il problema non è marginale.Grazie.Alberto CordedduRe: Firesheep
Ma infatti credo che il problema sia prettamente estero (grazie al decreto pisanu che vieta il wifi libero in italia) quando ti connetti a reti condivise da "tutti" od open negli aeroporti, certi alberghi ecc. se uno fa entrare nella sua rete privata una persona dovrebbe perlomeno fidarsi o conoscerla o cambiare le credenziali subito dopo (non si sa mai nemmeno tra gli amici ) sulle lan cablate credo sia più facile (ma potrei sbagliarmi non sono molto ferrato) adottare contromisure.Scusate ma sono utonto volevo domandare a solo titolo informativo e di difesa come funzionano i cookie, ma i cokkie di per se con controllo hashmd5 e scadenza, non si rinnovano continuamente? nel senso un eventuale malintenzionato non potrebbe entrare nell'account xy solo per poco tempo? (a meno che non cambi la password una volta loggato al sito ovvio) se il ladro di biscotti ruba il cookie mentre l'utente è collegato e lo usa subito i siti non si accorgono di doppio login da due sistemi diversi o fanno caso solo all'ip di rete? e se l'utente si disconnette prima del malintenzionato non invalida il cookie?Magari ho fatto domande sceme ma è per capire.utontopassa nteAlcune note a riguardo
In realtà alcuni "ovvi" dettagli sono stati omessi, sia nell'articolo di PI che nella pagina di FireSheep (ma ben discussi nei commenti sottostanti).Intanto, il funzionamento di FireSheep si basa sull'utilizzo di reti WiFi non crittografate (o di alcune particolari reti Ethernet cablate). Da notare che il termine "Non crittografate" non necessariamente corrisponde a "Non pubbliche".Il problema, quindi, non si pone affatto sulle reti WiFi private (protette da WPA/WPA2) ma neanche sulla maggior parte delle reti WiFi pubbliche (in cui tipicamente si adopera WPA/TKIP con chiave fornita automaticamente dall'Access Point).In secondo luogo, il plug-in può funzionare solo ammettendo di disporre di una scheda WiFi capace di funzionare in "Monitor Mode" (ovvero capace di catturare il traffico WiFi delle altre stazioni over-the-air). Non tutte le schede (e non tutti i driver) supportano tale modalità. (http://en.wikipedia.org/wiki/Monitor_mode)In ogni caso, si tratta di problemi assolutamente noti ed affrontati da decenni, per i quali sono sempre esistiti tool a riguardo (Cain per Windows, o Ettercap per Linux sono solo alcune delle soluzioni disponibili da diversi lustri).Tuttavia, mi sembra di capire che fomentare di tanto in tanto isterismi collettivi rappresenti, al giorno d'oggi, il metodo migliore per ricevere l'attenzione.Primiano Tucci,http://www.primianotucci.comPrimiano TucciGrazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoGrazie per esserti iscritto alla nostra newsletterOops, la registrazione alla newsletter non è andata a buon fine. Riprova.Leggi gli altri commentiPubblicato il 26 ott 2010Ti potrebbe interessare