Passato l'uragano, gli Americani iniziano a temere le truffe collegate a Katrina. Si ipotizzano furti di denaro o di dati riservati carpiti con l'esca delle finte donazioni.
« luglio 2005 | Principale | settembre 2005 »
Passato l'uragano, gli Americani iniziano a temere le truffe collegate a Katrina. Si ipotizzano furti di denaro o di dati riservati carpiti con l'esca delle finte donazioni.
Scritto il 31 agosto 2005 alle 22:43 nella Phishing e truffe | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Nuova vulnerabilità per Adobe Acrobat e Adobe Reader, che potrebbe permettere a un hacker ostile di creare file PDF appositamente studiati per mandare in crash il programma ed eseguire codice arbitrario.
Adobe ha rilasciato un advisory e un upgrade.
Scritto il 20 agosto 2005 alle 13:16 nella Nuove vulnerabilità | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Qui potete trovare un'ottima cronistoria dei vari worm che hanno tenuto impegnati gli esperti di IT security questa settimana di agosto, dalla pubblicazione delle patch da parte di Microsoft alla release degli exploit e quindi dei relativi worm (fra cui Zotob, a cui ho già accennato l'altro giorno, e i vari "-bot").
Scritto il 19 agosto 2005 alle 12:47 nella Malware | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
La Federal Deposit Insurance Corporation, un'agenzia governativa statunitense per la supervisione delle attività bancarie, ha pubblicato un vademecum indirizzato alle banche su come limitare i rischi derivanti dallo spyware.
Scritto il 18 agosto 2005 alle 21:18 nella Phishing e truffe, Privacy e spam | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Il worm Zotob ha iniziato a far parlare di sè, infettando massicciamente i computer che girano col sistema operativo Windows 2000. Così almeno riporta una "breaking news" di CNN.
Il worm sfrutta una vulnerabilità del servizio Plug and Play attraverso la porta TCP/445.
Per una descrizione dettagliata consiglio la pagina informativa di Nod32.it.
Forse a qualcuno potrà interessare la proof of concept su cui è basato il worm, che si può trovare qui.
Scritto il 17 agosto 2005 alle 08:29 nella Malware | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Anche le piccole banche iniziano a essere preda del phishing. Questa è arrivata proprio ora, e prende di mira i clienti della Cassa di Risparmio di Rimini (CARIM):
Date: Sat, 13 Aug 2005 05:04:30 -0700
From: Sicurezza (sicurezza@cassarinini.com)
X-Mailer: The Bat! (v2.00.5) Personal
Subject: CARIM Online: avviso urgente
Caro Cliente,
Ci interessiamo molto per la sicurezza dei nostri clienti, perche costantemente elaboriamo nuovi dati e protezioni.
Di recente le prove non autorizzate per prelevare i soldi dal conto bancario diventano regolari.
Studiamo ogni operazione con scrupolosita ed elaboriamo criteri utili per trovare operazione sospette.
In questo momento sviluppiamo un sistema di sicurezza per l'accesso elettronico del conto bancario, pronto per l'adempimento.
Il sistema Segue il a.m. criterio e in certi condizioni chiede la domanda segreta in oltre il conto corrente e l'operazione
corrente si bloccano finchÈ non si accertano i particolari di pagamento.
La invitiamo a riempire la forma supplementare di autorizzazione, necessario per l'attivazione del sistema.
http://cassarinini.com
Attendiamo la vostra comprensione.
Speriamo, che valuterete il nostro sistema della protezione dei dati di nuovo livello.
Ringraziamenti per la collaborazione
In questo caso i phisher sperano di ingannare gli utenti con un dominio simile a quello della banca (cassarinini.com al posto di cassarimini.com).
Da notare anche in questo caso (come in molti altri) l'italiano sgrammaticato, frutto probabilmente di un software di traduzione automatica.
I dati di registrazione del dominio sono evidentemente falsi. Il sito di phishing attualmente pare irraggiungibile, ma il server sembrerebbe trovarsi a Taiwan.
Il messaggio e-mail proviene da un utente dial-up indiano.
Aggiornamento (14.26): è arrivato un secondo phishing, del tutto simile al primo, ma che come indirizzo mostra http://online-cassarimini.net/
Il sito in questo caso è raggiungibile, e come prevedibile chiede agli utenti di inserire username e password. Il server è lo stesso.
Scritto il 13 agosto 2005 alle 13:57 nella Phishing e truffe | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Che i collegamenti Bluetooth non fossero completamente sicuri lo si era capito già da tempo. Ora iniziano a comparire i primi walkthorugh su come forzare il pairing fra due dispositivi bluetooth e procedere così al furto delle relative chiavi.
Ecco un esempio recentemente apparso su bugtraq.
Scritto il 13 agosto 2005 alle 12:55 nella Cellulari e PDA, Hacking, Wireless | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Icann ha recentemente pubblicato un rapporto sul pericolo di Domain Hijacking (lo spostamento fraudolento di un dominio Internet).
Del rapporto e dei rischi derivati dal domain hijacking ne parla anche questo articolo di eWeek.
Da notare che il domain hijacking potrebbe anche essere usato come trappola a scopo di phishing (in gergo questa tecnica viene chiamata "pharming", ma spesso viene eseguita mediante un DNS poisoning contro cui l'utente può fare ben poco).
Al punto 5.1 del documento vi è un interessante vademecum per i titolari di un dominio. Tenete presente che le procedure di registrazione e spostamento dei un dominio .it sono diverse da quelle di un dominio .com, .net, .org, .info o .biz, e che il documento di Icann si concentra su questi ultimi. Tuttavia credo sia importante riprendere questi consigli.
Mi sono preso la libertà di evidenziare col neretto i suggerimenti più importanti e meno banali, che quando non seguiti sono spesso fonte di problemi:
5.1 Steps Registrants Can Take to Protect Domain Names
A registrant can reduce the risk of losing a domain name by taking measures to protect his registration information and name holder status. The following measures are available to registrants today. Awareness campaigns will increase registrant understanding of these opportunities and services.
To protect against unintended loss or hijacking of a domain name, a registrant should
1) Keep domain name registration records accurate and current.
2) Keep registrant account information (user identity, password, or other credentials) private, secure, and recoverable.
3) Only grant registration account access and change control to parties in the registrant’s organization whose role(s) involve domain name administration.
4) Choose a registrar with hours of operation that match the needs of the registrant.
5) Keep current and accurate registrar business and emergency contact information.
6) Be familiar with and incorporate urgent restoration of domain name and DNS configuration procedures as part of business continuity policy and planning.
7) Investigate whether business interruption and losses related to a registration or DNS configuration incident are covered by insurance policies.
8) Request that domain names be placed on Registrar-Lock.
9) If a registrant’s sponsoring registrar uses EPP, the registrant should use a unique EPP authInfo code for each domain name registered.
10) Request that the losing registrar contact the registrant when a transfer request is received using a contact point separate from that used by the gaining registrar.
11) Routinely check the Whois service to check if a domain name is under Registrar-Lock. Note however that this information can be as much as 24 hours out-of-date, compared to the Registrar-Lock status in the registry.
12) Routinely check domain name information to ensure that no unauthorized changes have been made to the contact information. This check can be automated using scripting tools and commercially available software. More frequent queries increase timeliness of detection and thus reduce the level of risk that a change will go unnoticed.
13) Consult with the sponsoring registrar to establish appropriate (and possibly preferred) authentication processes for removing a transfer lock or changing a domain name configuration. (We note that such added safeguards may delay or increase the
SSAC Report: Domain Name Hijacking 34
difficulty of transferring names, but this is exactly the relationship some registrants may want with a registrar.)
14) Choose a registrar who issues a transfer pending notification as its standard practice.
Registrants seeking to further reduce risk should:
15) Choose a registrar who will notify the registrant using contact methods in addition to (and in parallel with) standard email notices.
16) Specify the contact methods that must be used (e.g., any or all contacts in the registration record, including, email, telephone, messaging and paging services, fax, etc.).
Some of these services are likely to be offered by registrars as part of a basic service. Registrants that place a high value on their domain names may be willing to pay a premium for enhanced protection
Scritto il 11 agosto 2005 alle 12:20 nella Phishing e truffe | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
Un altro messaggio di phishing, in italiano incerto, si sta facendo strada in queste ore.
Caro (indirizzo e-mail)
,
Recentemente abbiamo notato uno o più tentativi di entrare al vostro conto di BancoPostaonline da un IP indirizzo differente.
Se recentemente accedeste al vostro conto mentre viaggiavate,
i tentativi insoliti di accedere a vostro Conto BancoPosta possono essere iniziati da voi.
Tuttavia, visiti prego appena possibile BancoPostaonline per controllare le vostre informazioni di conto:
https://bancopostaonline.poste.it/bpol/bancoposta/formslogin.asp
Ringraziamenti per vostra pazienza.
BancoPostaon.
Scritto il 07 agosto 2005 alle 22:45 nella Phishing e truffe | Permalink | Commenti (0) | TrackBack (0)
Reblog
(0)
| |
|
