Keynote by Fyodor Yarochkin : How evolution shapes the infosec
Fyodor Y. presentation covers his past experience and mainly focus on computer crime research. Actually, Fyodor Y. experience covers : Snort/IDS ,Honeypot and Intrusion detection.
Fyodor Y. starts by underlining that malicious activities are linked to financial gain on Internet (China and Russia), that joins Raul Chieasa's Keynote on HES 2011.
Fyodor Y. pointed various observations:
The fact is most security researchers focus on finding vulnerability and computers crime focus on how to gain money by exploting human vulnerabilities (SE) than deep and complex vulnerability
double-click mailing --> companies discussing malicious behaviour on the Net.
An example was given by F. of a malicious company that fakes a real advertisement company, making a flash file ad.
The crime engineer are developing attacks depending on the location of the victim kind a of customization.
Glottalization of the crime scene (localisation does not matter)
Volumes of micro-transactions --> Stealing a 1 $USD from 1,000,000 still makes a $1, 000, 000
There are other means of taking control over wealth than cash
F. points the new payment technologies as those based on phone to pay duties. Mobile payments are not supervised by the government in consequence a parallel market is growing up (Android mobile are more and more targeted by attacks that makes mobile payment). Indeed an Android application seems to be clean at the first verification, bypassing the control of google market. But once the application is installed it triggers an update that get the malicious payload.
To conclude Fyodor stress the fact Human vulnerability could not be fixed
Fyodor Y. end his keynote by presenting his "Honeypot project"
Motivation: What is the risk of Taiwan networks being owned now"
- Identify regional threats
- Cooperation with CERT
- Real-time exposure .... .
Hacking the NFC credit card for fun and debit . by Renaud Lifchitz
Firstly, I want to thank Renaud L. for the quality of its presentation because he was able to demonstrate a serious
vulnerabilities regarding NFC systems basing on simple techniques and tools.
Renaud L. starts his presentation by introducing the following terms:
Contactless payment : daily payment with no need for card insertion and pin. Two main systems are present in the market: Visa Paywave and MatserCard Paypass
NFC card could be recognized by a specific logo printed on them.
These card are developed using EMV standards (specification for data storage and security protocol .ISO 7816 standards)
The card memory is a real filesystem with a root directory (MF)and folders (DF). BER TLV (very near to ASN.1) is used for
data encoding (emvlab.org/tlvutils for decoding tools).
Card Commands requests are structured as : Class (targeted application), Instruction (read/write...), parameter, data length, data and the length of expected response.
The response contains mainly data and SWA/SW errors.
After this refresher, Renaud L. introduce the goal of his research. Indeed, his idea is to compare the security of NFC card with other security models as those of Passports or NAVIGO cards(used in France for public transportation).
Actually, Navigo card presents a good security level as no personal data are stored in them, use of good encryption and authentication mechanisms.
Regarding NFC cards, the first observation pointed out by Renaud L. is the lack of authentication and encryption
As a proof of concept, Renaud L. presented the necessary information and ingredients:
NFC frequencies: HF (13,56 Mhz) and LF (125-134 Khz) usages )
NFC readers: USB readers SCM SCLL3711 (40 euros) ACS ACR120U/ACR
Tools : scriptor (ISO 7816), Libnfc ,pn53x-tamashell
The POC allows Renaud L. to demonstrate that is possible to get remotely the following data :
Confirmed : Cardholder (gender, first name and last name), PAN, Expiration data ,Magnetic strip data (for cloning card), transaction history
Probably :no CVV (just one time-CVV possibly can be used for online payment
To conclude Renaud L. listed some possible attacks :
- Read victm data and us it in commerce web site CVV is not alwas asked
- Remote DOS attack
- Create a magnetic strip dump
- User tracking
For his demo Renaud L. follows these steps:
- Wake up the card : list passive target
- select banking application (AID) --> look at receipt
- Read specific EMV record
However Renaud L. notices the the distance still a limitation to the attack. That could be mitigated using an USRP and telescoping antenna.
Secure Password Managers" and "Military-Grade Encryption" on Smartphones: Oh Really by Andrey Belenko & Dmitry Sklyarov
This presentation aims to give an overview on security mechanisms used (or not) by password managers on Smartphones.
For that, the speakers firstly tried to underline the difference between
the capabilities (TPM, biometrics...) offered by a PC password manager and those (passwords and passcode) that exists on smartphones
Moreover, on smartphones password managers have various handicap:
Pasword typing : it is hard to type long and complex password
Relatively slow CPU : Complex password-token transforms will impact the usability so handling passwords is more complex than PC
Before going deeper into the study results, speakers made as threat model based on the following assumptions:
The Attacker has physical access to the device, backup of the device and to the paswords manager database file. the attacker tries then to recover the master passwords.
Generally, the physical access is quite easy (think of fake charging station)
The device backup on :
Apple IOS
- Needs device passwode or iTunes pairing (optional encryption PBKDF-2 SHA 1 with 10 0000 iterations).
Balckberry
- Needs device password (Optional encryption -not enforced-).
The database files could be retreieved
Appple iOS
- via afc (need passcode)
- via ssh (jailbroken device)
- via (physical imaging)
Blackberry
- Needs device password
The analysis presented by the speakers was based on a top 10 of Apple and blackberry applications (free and paid applications)
(Sorry but I wont give the analysis of all applications but you can refer to speakers's slides ).
As examples :
BlackBerry Wallet 1.0
- Stores sha-256 password
- Password verification requires 2x sha256
- No salt --> rainbow tables
iOS password managers
Free Tools :
- Store passwords is Doucments/Password_keeper.sqlite
- Master password is always 4 digits
- No data encryption
- Master password is stored in clear : SELECT ZPASSWORD from ....
Paid tools
- Master key is encrypted with master password
- Use of iOS keychain
To conclude, speakers stated that Paid apps are not necessarily more secure than free ones.
All Your Calls Are Still Belong to Us - How We Compromised the Cisco VoIP Crypto Ecosystem by Daniel Mende and Enno Rey
The speaker starts his presentation , before detailing the technical side, by a little refresher of what he calls the "7 sisters".
- Access control
- Isolation
- Restriction
- Encryption
- Entity protection
- Secure management
- Visibility
These 7 principals are the basics for securing infrastructure regardless the technology used. These principals can be broken down to a checklist.
The speaker listed then different case studies to demonstrate that globally the above principal es. for example:
Case study scope: Call center 1500 Voip
Presence of MS08-67 , Weak password , use of the same passwords on different components
No access Layer protection in place (abusing STP/DTP/OSPF/...)
Globally, the speaker feels according to his experience that regarding Voip equipment no body feels responsible to patch this boxes which implies security vulnerabilities .
The second part of the presentation aimed to explain Cisco mechanism for Voip encryption. Hence, a refresher of the use of certificates and their implications has been presented.
Indeed in Cisco World lots of certificate are used in a complex manner:
CUCM : needs a certificate itself of tftp signing firmware
CAPF:(CA) needs a certificate
Phone: use a certificate generated by the CAPF used for the communication between the phone and the call manager
CTL: The Certificate Trust List (CTL) is the root of the whole trust chain used in the crypto system of the CUCM. The CTL contains a server certificate, public key, serial number, signature, issuer name, subject name, server function, DNS name and the IP address for each server in the Unified Communication environment.
The CTL file must be created by an administrator in order to activate the “Mixed Mode” of the CUCM. The CTL file itself is signed by the private key stored on the security token (aladin etoken)
Cisco IP Phones are using two different certificate types :
Manufacture-installed certificate (MIC):
Locally significant certificate (LSC):
Actually, the weak point of the whole CUCM Security Model is the Certificate Trust List, which can potentially be subverted.
To understand how communications are encrypted between and Iphone and a call managern, it is necessary to understand How a phone gets its certificate:
- Phone boots get the context CUCM
- CUCM sends an initial CTL file
- Phone checks if LSC is installed (local)
- If not contact CUCM to get a partial config file
- CUCM sends a partial onfig
- The Phone generate public/private key
- Send the public key to CUCM
- Signed
- get it back
- installed as certificate
The speaker pointed out also some the following behaviour when playing with CTL :
- if validation fails reject CTL but old one get lost and we re back to initial provisioning state
- just accept the new one
In other way, If this process is intercepted, by a Man-in-the-Middle attack, it is possible to replace the original
Certificate Trust List with a modified one.
The attack scenario consists in:
- Traffic redirection between CUMC and phone
- Provide TFTP server
- Phone has to reboot (SYN flood 30-50 sec ), any port can be used
- Use this FTP server to provide CTL file
- Fake CTL main properties
- Replace public key of CTLs own Signing Certificate
- Replace public keys of matching CUCM certificate
Once the phone disposes of modified certs of its main communication partners, the attacker can:
- Access the phone private key associated with LSC
- Read the encrypted config
- MITM SIP-TLS traffic
- Get user credentials
- Replace key materials
- Plus all the nice things that can be done with SIP protocol
The demo is based on a Python script: ctl_proxy.py
This small python script implements an TFTP server to serve modified CTL files and signed files to cisco
VoIP Hard- and Softphones. The tool is transparent from an TFTP view, so if a phone requests a special
file, this file is fetched from the CUCM TFTP server and served to the phone afterwards.
The tool is planned to be released on ERNW blog.
No comments:
Post a Comment