The Conference will be held at the University of Rome "La Sapienza" 
Aula Odeion - Museo dell'Arte Classica, Facoltà di Lettere - Piazzale Aldo Moro, 5 - Roma

9:00h	Registration
9.30h	"Welcome and opening of the works" L.V.Mancini - Master in Information Security - Sapienza Università di Roma.
9.45h	"Introduction to the OWASP Day 2012" Matteo Meucci - OWASP-Italy Chair
10.00h	"My web site has been breached and my customer's data have been published online, what I can do next?" Marco Morana - CISO Citigroup
10.30h	"Attackers, lies and you" Vincenzo Iozzo - Director of vulnerability intelligence at Trail Of Bits Inc
11.00h	“SPARQL Injection - attacking the triple store” Simone Onofri — Consultant, Techub SpA, Luca Napolitano — Freelance
11.30h	“Android and mobile security: client side, server side, privacy (do android malware writers dream of electric sheep?)" Igor Falcomatà — CTO, Enforcer srl
12.00h	"La convergenza tra OWASP ed (ISC)2: connubio tra approccio empirico e sistematico" Paolo Ottolino, Claudio Sasso - Board (ISC)2 Italy Chapter
12.15h	"ISACA Roma: Strumenti per la Governance IT" Prof. C. Cilli - Presidente ISACA Roma
12.30h	CSA Italy: "Portabilità, interoperabilità e sicurezza applicativa nel cloud" Matteo Cavallini - CSA Italy chapter, Vice President
12.45h	IsecLab: "Cutting-edge research in system security" Marco Balduzzi, Ph.D., Sr. Security Researcher
13.00h	Secure Banking Expert Community: "Unire forze e competenze tecniche per arginare il crimine (sempre più) organizzato" Claudio Santacesaria

Marco Morana

Responsible for security risk and architecture governance of global application programs in Citigroup Institutional Clients Group (ICG) EMEA

"My web site has been breached and my customer's data have been published online, what I can do next?". In this talk, Marco Morana, will show an example of data breach and the business impact on a Company. Marco will discuss the importance of adopting the OWASP Guide for CISO that could be useful to mitigate the next impacts by adopting a strategic approach to application security. This approach is focused on risk management, IS governance and software security assurance. Marco Morana with more than 16 years of professional experience in application security (6 years of it in the financial sector) in diverse professional roles such as technology officer, program manager, business partner and company founder, team leader, security architect, security consultant, software contractor and engineer. Marco is SVP of Technology Risks & Controls in Citigroup Institutional Clients Group (ICG) EMEA, with the role of Senior Security Analyst. Previously, Marco was VP of Information Security Citigroup Global Consumer North America, with the role of Information Technology Security Officer (TISO). For previously at Citigroup, Mark has gained more than 10 years of experience in the field of security software in Foundstone consulting company McAfee Inc. In 2002, he founded the consulting firm of application security CerbTech LLC and has contributed to the development of security services and applications for various clients such as VISA and Data Processing Services CompuCredit. In 2001 he assumed the position of European Operations Manager for EWA IIT and carried out activities of project management for information security in the consortium Thyreaus Datamat SpA and EWA IIT. Between 1998 and 2001 he worked as a software engineer for IBM Internet Security Systems and developed several products for the security of the network as SafeSuite Decision and Internet Security Scanner (ISS). Between 1996 and 1998 he worked at the NASA Ames center in California where he developed the first commercial application of secure email based on Technology and Entrust S / MIME protocol. For this application, Marco obtained a patent and an honorary degree for his contribution to the security of infrastructures NASA (1996). Marco has a Masters in Computer Systems Engineering at the Northwestern Politechnic University and a degree in Mechanical Engineering (Dr Eng) at the University of Padova (Italy).

Vincenzo Iozzo

Director of vulnerability intelligence at Trail Of Bits Inc

Abstract: This talk will analyze recent trends in the mobile threats landscape, suggest effective strategies to mitigate these issues and try to gauge what the future looks like for companies and organizations seeking to protect themselves. Specifically the talk will highlight how mobile poses a totally different set of problems that have very little similarities with desktops and why the security community at large has to make a mindset shift to handle them. Finally assisted by data collected in the past few years we will discuss future trends and threats. Bio: Vincenzo Iozzo leads the collection and analysis of vulnerability intelligence at Trail of Bits. Prior to Trail of Bits, Vincenzo founded Tiqad, an information security consulting firm, worked as a penetration tester for Secure Network srl and was a reverse engineer for Zynamics GmbH. Vincenzo serves as a committee member on the Black Hat Review Board and is a co-author of the "iOS Hacker's Handbook" (Wiley, 2012). He is perhaps best known for his participation in Pwn2Own, where he co-wrote the exploits for BlackBerryOS and iOS that won the contest in 2010 and 2011 and where he co-wrote exploits for Firefox, Internet Explorer, and Safari that placed second in 2012.

After Epic Hack, Apple Suspends Over-the-Phone AppleID Password Resets

BY NATHAN OLIVAREZ-GILES AND MAT HONAN

08.07.12

8:12 PM

Apple is considering changes to its AppleID password reset policies. But what those changes would be, if there are any, aren’t yet clear. Photo: Ariel Zambelich/Wired

Apple on Tuesday ordered its support staff to immediately stop processing AppleID password changes requested over the phone, following the identity hacking of Wired reporter Mat Honan over the weekend, according to Apple employees.

An Apple worker with knowledge of the situation, speaking on condition of anonymity, told Wired that the over-the-phone password freeze would last at least 24 hours. The employee speculated that the freeze was put in place to give Apple more time to determine what security policies needed to be changed, if any.

The change follows similar security tightening at Amazon, which on Tuesday closed a hole in its customer service systems that gave people the ability to gain control of a customer’s Amazon account as long as the hacker knew the name, e-mail address and mailing address of the victim.

Our Apple source’s information was corroborated by an Apple customer service representative, who told us Apple was halting all AppleID password resets by phone. The AppleCare representative shared that detail while Wired was attempting to replicate Honan’s hackers’ exploitation of Apple’s system for the second day. The attempt failed, and the representative said that the company was going through system-wide “maintenance updates” that prevented anyone from resetting any passwords over the phone. The rep said we should try calling back after about 24 hours, and directed us toiforgot.apple.com to change AppleID passwords ourselves on the web instead.

“Right now, our system does not allow us to reset passwords,” the Apple rep told Wired. “I don’t know why.”

In an earlier attempt on Tuesday to change an AppleID password (which is the same password used to log into iCloud and iTunes), Apple customer service offered up a different response, saying that passwords could only be changed over the phone if we were able to supply a serial number for a device linked to the AppleID in question — for example, an iPhone, iPad or MacBook computer. The rep also suggested changing our AppleID password online at appleid.apple.com or iforgot.apple.com.

While it’s clear that Apple is reacting to the privacy vulnerability that surfaced with the hacking of Honan’s digital identity, it’s unclear what final policy change will emerge. Apple officials declined to comment on whether permanent changes to the company’s security measures were planned.

On Monday, we were able to call Apple, reset AppleID passwords over the phone, and gain access to iCloud accounts by supplying AppleCare representatives with a name, e-mail address, mailing address and the last four digits of a credit card number linked to an AppleID. This is the exact same information hackers supplied Apple with on Friday to get a temporary password that gave them access to Honan’s iCloud account.

From there, the hackers wiped Honan’s iPhone, iPad and MacBook. They also used their access to get into Honan’s .Me email account, which gave them access to his Google account (they wiped that too), his personal Twitter account and Gizmodo’s Twitter account. Honan previously worked as a reporter at Gizmodo and, under the hackers’ control, both Twitter accounts became a platform to spout racist and homophobic invective.

Names with matching e-mail addresses and mailing addresses are easy enough to find on the web. Credit card numbers tied to a name can be found on many purchase receipts, and everyday millions of Americans give these valuable numbers out over the phone ordering pizzas, among other things.

Yesterday, Apple issued a statement noting that “we found that our own internal policies were not followed completely.” However, Wired’s internal source at Apple said that if the support representative who took the hacker’s call issued a temporary password based on an Apple ID, billing address, and the last four digits of a credit card, he or she would have “absolutely” been in compliance with Apple policy.

Wired reporter Alexandra Chang contributed to this report.

Gli hacker mi hanno rubato la vita

Il reporter e blogger americano Mat Honan, firma di Wired, ha perso tutte le mail, le foto e i documenti: i pirati informatici volevano violare il suo account Twitter, particolarmente pregiato. Né forza né fortuna per recuperare le password: hanno semplicemente chiamato il servizio clienti di Amazon e Apple

di PAOLA ROSA ADRAGNA

Lo leggo dopo

Mat Honan nella foto pubblicata sul suo blog
Photo: Ariel Zambelich/Wired. Illustration: Ross Patton/Wired 

UNA VITA (digitale) completamente cancellata. Spazzata via. Irrecuperabile. Il primo compleanno della figlia, i cari scomparsi da poco e quegli attimi con gli amici del college che con il tempo ha perso di vista. Momenti della vita di Mat Honan, firma di Wired, cancellati dalle memorie fisiche di computer e telefono da una coppia di hacker ventenni che volevano divertirsi con il suo account Twitter.

Un pizzico di astuzia e i numeri di telefono del servizio clienti Amazon e Apple. Questo è servito ai due ragazzi per impadronirsi della vita digitale di Mat e distruggerla. Nel giro di un'ora, come racconta lo stesso Honan sul suo blog ¹, i due sono entrati nel suo account Google e lo hanno rimosso. Hanno poi usato il suo profilo Twitter, postando commenti omofobi e razzisti ("Ed è così che gran parte dei miei amici sono venuti a sapere quel che stava accadendo", racconta). Ma più di ogni altra cosa, hanno violato il suo AppleID e hanno cancellato tutto: foto, mail, documenti - un intero archivio digitale in gran parte conservato sul computer portatile. "Senza un backup", si maledice ora Honan. Non c'è più niente sul suo iPhone, né sull'iPad, tantomeno sul MacBook.

Inizia tutto verso le 17 di venerdì scorso, mentre Mat gioca con la sua bambina. Il telefono si spegne, lui aspetta una telefonata e lo riaccende, inserisce la password di iCloud ma è sbagliata. Va per collegare il telefono al MacBook e scopre che le informazioni del suo account Google sono sbagliate. Serve un codice Pin da quattro cifre, che Mat non ha. L'idea dell'hackeraggio si fa strada nella sua mente e si rivolge al servizio clienti Apple. Una telefonata da 90 minuti che non risolve certo le cose, soprattutto perché per buona parte del tempo l'operatore crede di parlare con un altro cliente. L'equivoco dà a Mat però un'informazione fondamentale: per entrare nell'iCloud di un qualsiasi utente bastano un indirizzo di fatturazione e le ultime 4 cifre di una carta di credito. Due dati facilmente reperibili sul web, come ha scoperto a sue spese. E come gli ha spiegato uno dei due hacker, Phobia, 19 anni, che ha deciso di raccontargli passo dopo passo il percorso seguito, in cambio della promessa di non essere denunciato.

"Non ho indovinato le tue password, né usato la forza". Inizia così il racconto di Phobia, che piano piano, rivela le falle dei sistemi di sicurezza dei due colossi coinvolti nel caso. Ma partiamo dall'inizio. Phobia risale alla mail Google di Mat tramite il suo sito. Va nella pagina di recovery di Google e fa finta di voler recuperare la password smarrita, e scopre l'indirizzo secondario ".Me", associato all'AppleID. Con questa informazione gli basta solo rintracciare l'indirizzo di Mat e le ultime quattro cifre della sua carta di credito per ottenere le credenziali d'accesso di iCloud direttamente dal servizio clienti AppleCare.

Il complice di Phobia recupera l'indirizzo postale tramite il dominio di Mat, ma sarebbe stato possibile anche su un semplicissimo elenco telefonico. Non è altrettanto facile con il codice della carta, ma l'assistenza Apple non è l'unica che si può raggirare facilmente. Una telefonata ad Amazon - anzi due - e il gioco è fatto. Grazie alle informazioni che ha già, con la prima chiede di inserire una nuova carta di credito associata al profilo, mentre con la seconda fa finta di aver perso le credenziali di accesso e ottiene la possibilità di verificare tutte le carte di credito registrate sul proprio profilo. O meglio, solo gli ultimi quattro numeri. I quattro necessari per chiamare AppleCare e ottenere l'accesso ai ricordi di Mat e cancellarli per impedirgli di recuperare il possesso del suo pc o del suo telefono. Non per vendetta o per odio, spiega Phobia a un Mat disperato. Ma per poter usare il suo account Twitter perché a loro piace il suo nome utente: @mat. Un account che Honan si aggiudicò proprio in virtù del suo essere un geek, un maniaco della tecnologia, e in quanto tale tra i primissimi utenti del social network.

La domanda resta perché tutto questo. Mat lo chiede a Phobia, ma la sua risposta non è soddisfacente. Il giovane hacker vuole pubblicizzare i buchi nella sicurezza delle grandi compagnie, così che possano sistemarli. Non è lui che ha materialmente ripulito la sua memoria, bensì il suo complice, ma sembra dispiaciuto. Alla fine, però, Honan ammette di non avercela neanche particolarmente con i due giovani hacker: "Sono un esperto di tecnologia, avrei dovuto saperlo che andava fatto un backup di quello a cui tengo", racconta ora. Così come non gli pare ora una grande idea l'aver utilizzato account di posta "concatenati" e tutti riconducibili all'account Apple, e impostazioni di sicurezza più complesse.

L'intera storia apre un dibattito sull'affidabilità delle password e dei controlli sulla rete, specialmente con il cloud, ora che tutto è connesso. I codici alfanumerici tutelano abbastanza la sicurezza? Alcune informazioni sensibili vengono reperite con troppa facilità? L'unica cosa certa è che Mat non scorderà mai più di fare un backup, sperando che da qualche parte - nella nuvola - gli vengano restituite le foto della sua bimba.

(10 agosto 2012)

Top 10 Secure Coding Practices

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

Skip to end of metadata

• Attachments:1
• Added by Robert Seacord, last edited by Robert Seacord (Manager) on Mar 01, 2011  (view change)
• show comment

Go to start of metadata

Top 10 Secure Coding Practices

1.  Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05].
2.  Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws.
3.  Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set.
4.  Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.
5.  Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75].
6.  Adhere to the principle of least privilege. Every process should execute with the the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75].
7.  Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem.
8.  Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05].
9.  Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05].
10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

Bonus Secure Coding Practices

1.  Define security requirements. Identify and document security requirements early in the development life cycle and make sure that subsequent development artifacts are evaluated for compliance with those requirements. When security requirements are not defined, the security of the resulting system cannot be effectively evaluated.
2.  Model threats. Use threat modeling to anticipate the threats to which the software will be subjected. Threat modeling involves identifying key assets, decomposing the application, identifying and categorizing the threats to each asset or component, rating the threats based on a risk ranking, and then developing threat mitigation strategies that are implemented in designs, code, and test cases [Swiderski 04].

Bonus Photograph

I found the following photograph on the Web, and I'm still trying to figure out who owns the rights to it. If you know, please comment below.

I like this photograph because it illustrates how the easiest way to break system security is often to circumvent it rather than defeat it (as is the case with most software vulnerabilities related to insecure coding practices).

References

[Saltzer 74] Saltzer, J. H. "Protection and the Control of Information Sharing in Multics." Communications of the ACM 17, 7 (July 1974): 388-402.

[Saltzer 75] Saltzer, J. H. & Schroeder, M. D. "The Protection of Information in Computer Systems." Proceedings of the IEEE 63, 9 (September 1975), 1278-1308.

[Seacord 05] Seacord, R. Secure Coding in C and C++. Upper Saddle River, NJ: Addison-Wesley, 2006 (ISBN 0321335724).

[Swiderski 04] Swiderski, F. & Snyder, W. Threat Modeling. Redmond, WA: Microsoft Press, 2004.

Fastweb Myfastpage: vulnerabilità XSS bypass del controllo

http://disse.cting.org/codes/fastweb.pdf

Fastweb Myfastpage authorization control bypass via XSS.
Sfruttando una vulnerabilità XSS presente nel sito che ospita i pannelli di controllo Fastweb
myfastpage, è possibile accedere abusivamente ai pannelli di configurazione di abbonamenti
internet e telefono degli utenti Fastweb, semplicemente invitandoli a visitare un URL
appositamente forgiato.
In maniera simile ad un cookie stealing si sottraggono le credenziali di accesso alle myfastpage
personali. Il token autenticativo non è nel cookie ma nella URL per accedere al pannello, sotto
forma di parametro checksum generato dinamicamente ad ogni richiesta di accesso ai pannelli.
Una volta sottratto l’indirizzo del pannello chiunque può accedervi anche fuori dalla rete
fastweb e senza autenticazione, basta che conosca l’URL. Via XSS forziamo il browser di un
utente a comunicare gli URL dei pannelli di controllo ad un attaccante esterno.
Login standard
Un normale login ai pannelli di controllo consiste in:
1. Visita a http://www.fastweb.it/login , senza autenticazione se da rete Fastweb
2. GET alla pagina http://www.fastweb.it/myfastpage/goto/momi/?id=<nome-pannello> ,
che viene redirezionato su http://fastmomi.fastweb.it/?service=<nome-pannello>&
checksum=<secret-session-token>&account=<account-number>&channel=MYFP
3. GET verso l’URL del pannello.
I primi due passaggi sono fattibili solo da IP interni alla rete, e il secondo GET necessita i cookie
settati nel primo. L’URL al pannello a cui punta il redirect è invece visitabile da tutti, a patto di
conoscerlo.
L’attacco
L’XSS permette di forzare un browser a fare i 3 passaggi, estrarre l’URL finale e mandarlo a un
cookie grabber installato su una macchina remota. L’attacco è più complicato del solito, a causa
delle necessarie richieste su domini diversi pur rispettando la same origin policy dei browser.
Diagramma dell’attacco
1. Il browser vittima punta all’XSS e esegue il javascript dell’attaccante.
2. Un IFRAME carica http://www.fastweb.it/login e genera i cookies iniziali.
- Same origin policy rispettata: la richiesta è su un’altro dominio ma la richiesta è blind
(non ci interessa la risposta)
3. Più IFRAME caricano i diversi pannelli http://www.fastweb.it/myfastpage/goto/momi/?id=
<nome-pannello> , che ridirezionano automaticamente verso l’URL da catturare.
- Same origin policy rispettata? Si, perchè nonostante l’url iniziale sia in un altro dominio,
l’url destinazione del redirect è nel dominio che ospita l’XSS.
4. Gli URL a cui puntano le .location degli IFRAME caricati vengono inviati alla macchina
dell’attaccante che possiede il corretto URL per accedere dall’esterno al pannello dicontrollo.
Mitigazione del problema
1. Fix degli XSS presenti nel sito
2. Restrizione degli accessi ai pannelli a seconda di cookie, e provenienza dell’IP oltre che
al token già utilizzato.
3. Richiedere nome utente e password per accedere alla Myfastpage anche da IP interni
alla rete Fastweb.
Disclosure
7 Maggio 2010: segnalazione dei problemi al reparto IT security di Fastweb
3 Giugno 2010: pubblicazione dell’advisory


http://www.lucagarufi.com/2011/12/08/212/

Questa volta si parla di Fastweb e della sua pagina di autenticazione al pannello di controllo. Infatti grazie ad una falla scoperta da Emilio Pinna, è possibile entrare in tale pannello senza averne le autorizzazioni. Fastweb prevede, infatti, l’accesso diretto se si è interni alla rete mentre lo nega se si è esterni alla rete. Grazie a questa falla però, sarà possibile accedere al pannello anche se non si fa parte della stessa rete. Emilio Pinna spiega inoltre “Sono certo che altri service provider italiani abbiano problemi simili vista la cattiva abitudine adottata da molti provider di far accedere l’utente ai pannelli di controllo di abbonamento e modem automaticamente, senza autenticazione con user e password, a patto che la richiesta provenga dalla rete casalinga del proprietario dell’abbonamento. Questa sempificazione indebolisce l’infrastruttura, e rende vulnerabilità comuni come XSS, CSRF, DNS rebinding catastrofiche per la privacy e la sicurezza dell’utente finale.” Vediamo in dettaglio come funziona questo attacco.

Come funziona il login normalmente

• Normalmente si visita il sito http://www.fastweb.it/login
• Grazie ad una richiesta GET si passa il valore dell’id del pannello http://www.fastweb.it/myfastpage/goto/momi/?id=<nome-pannello> con conseguente redirect verso http://fastmomi.fastweb.it/?service=<nome-pannello>&
  checksum=<secret-session-token>&account=<account-number>&channel=MYFP
• GET verso l’url del pannello

I primi due URL sono visitabili solo dall’interno ed il secondo GET necessita dei cookies creati nel primo URL. Il terzo URL è possibile raggiungerlo anche dall’esterno, conoscendo però i giusti valori!

Come funziona l’attacco

Attraverso un particolare attacco XSS è possibile accedere anche dall’esterno inviando l’URL finale ad un cookie grabber verso la macchina attaccante. I passaggi sono i seguenti:

1. Il browser della vittima punta all’XSS con il javascript maligno
2. Un IFRAME carica la pagina iniziale http://www.fastweb.it/login e genera i cookie
3. Diversi IFRAME caricano i pannelli all’indirizzo http://www.fastweb.it/myfastpage/goto/momi/?id=
   <nome-pannello>
4. Gli URL a cui puntano le .location degli IFRAME vengono inviati alla macchina attaccante con  l’URL per accedere dall’esterno al pannello di controllo.

Un’immagine che spiega l’attacco.