{"id":83,"date":"2012-02-14T01:03:39","date_gmt":"2012-02-14T06:03:39","guid":{"rendered":"http:\/\/jlg.name\/blog\/?p=83"},"modified":"2012-11-06T16:37:33","modified_gmt":"2012-11-06T21:37:33","slug":"ndss-2012","status":"publish","type":"post","link":"http:\/\/jlg.name\/blog\/2012\/02\/ndss-2012\/","title":{"rendered":"NDSS 2012"},"content":{"rendered":"

Last week I attended the Network and Distributed System Security (NDSS) Symposium<\/a> in San Diego, California.\u00a0 NDSS is generally considered one of the top-tier academic security conferences.\u00a0 This was my second year in a row attending the symposium.<\/p>\n

Things I learned or especially enjoyed are in boldface<\/strong> text below (you may safely skip the non-boldfaced text in the list):<\/p>\n

    \n
  1. What you publicly \u201cLike\u201d on Facebook makes it easy for someone to profile probable values for attributes you didn\u2019t make public, including gender, relationship status, and age.<\/strong>\u00a0 For example, as described by Chaabane et al.<\/a>, \u201csingle users share more interests than married ones.\u00a0 In particular, a single user has an average of 9 music interests whereas a married user has only 5.79.\u201d<\/li>\n
  2. Femtocells could represent a major vector for attacking or disrupting cellular infrastrcture.<\/strong>\u00a0 I\u2019ve used femtocells; they are great for having strong conversations in weak coverage areas, but to quote the conclusion of Golde et al.<\/a>: \u201cDeployed 3G femtocells already outnumber traditional 3G base stations globally, and their deployment is increasing rapidly. However, the security of these low-cost devices and the overall architecture seems poorly implemented in practice. They are inherently trusted, able to monitor and modify all communication passing through them, and with an ability to contact other femtocells through the VPN network…[However, it is well known that it is possible to get root level access to these devices.\u00a0 We] evaluated and demonstrated attacks originating from a rogue femtocell and their impact on endusers and mobile operators. It is not only possible to intercept and modify mobile communication but also completely impersonate subscribers. Additionally, using the provided access to the operator network, we could leverage these attacks to a global scale, affect the network availability, and take control of a part of the femtocell infrastructure…We believe that attacks specifically targeting end-users are a major problem and almost impossible to mitigate by operators due to the nature of the current femtocell architecture. The only solution towards attacks against end-users would be to not treat the femtocell as a trusted device and rely on end-to-end encryption between the phone and the operator network. However, due to the nature of the 3G architecture and protocols and the large amount of required changes, it is probably not a practical solution.\u201d<\/li>\n
  3. Appending padding bytes onto data, before encrypting the data, can be dangerous.<\/strong>\u00a0 \u201cPadding\u201d is non-useful data appended to a message simply to ensure a minimum length message or to ensure the message ends on a byte-multiple boundary.\u00a0 (Some encryption functions require such precisely sized input.)\u00a0 As described by AlFardan and Paterson<\/a>: \u201cthe padding oracle attack…exploits the MAC-then-Pad-then-Encrypt construction used by TLS and makes use of subtle timing differences that may arise in the cryptographic processing carried out during decryption, in order to glean information about the correctness or otherwise of the plaintext format underlying a target ciphertext.\u00a0 Specifically, Canvel et al. used timing of encrypted TLS error messages in order to distinguish whether the padding occurring at the end of the plaintext was correctly formatted according to the TLS standard or not.\u00a0 Using Vaudenay\u2019s ideas, this padding oracle<\/em> information can be leveraged to build a full plaintext recovery attack.\u201d\u00a0 AlFardan and Paterson\u2019s paper described a padding oracle attack against two implementations of the DTLS (datagram transport layer security) protocol, resulting in full or partial plaintext recovery.<\/li>\n
  4. If you want people to click on your malicious link, keep it short and simple.<\/strong>\u00a0 Onarlioglu et al.<\/a> presented the results of their user-behavior study that showed, among other results: \u201cWhen the participants did not have the technical knowledge to make an informed decision for a test and had to rely on their intuition, a very common trend was to make a guess based on the \u2018size\u2019, the \u2018length\u2019, or the \u2018complexity\u2019 of the artifacts involved. For example, a benign Amazon link was labeled as malicious by non-technical participants on the basis that the URL contained a crowded parameter string. Some of the comments included: \u2018Too long and complicated.<\/em>\u2019, \u2018It consists of many numbers.<\/em>\u2019, \u2018It has lots of funny letters.<\/em>\u2019 and \u2018It has a very long name and also has some unknown code in it.<\/em>\u2019. Many of these participants later said they would instead follow a malicious PayPal phishing URL because \u2018It is simple.<\/em>\u2019, \u2018Easy to read.<\/em>\u2019, \u2018Clear obvious link.<\/em>\u2019 and it has a \u2018Short address<\/em>\u2019. One participant made a direct comparison between the two links: \u2018This is not dangerous, address is clear. [Amazon link] was dangerous because it was not like this.<\/em>\u2019. Interestingly, in some cases, the non-technical participants managed to avert attacks thanks to this strategy. For example, a number of participants concluded that a Facebook post containing a code injection attack was dangerous solely on the grounds that the link was \u2018long\u2019 and \u2018confusing\u2019…the majority of the non-techie group was not aware of the fact that a shortened URL could link to any destination on the web. Rather, they thought that TinyURL was the website that actually hosted the content.\u201d<\/li>\n
  5. There needs to be more transparency into how lawful telephone interception systems are constructed and deployed.<\/strong>\u00a0 At CCS two years ago a paper by Sherr et al.<\/a> was presented that described a control-plane-DoS attack on CALEA systems; here Bates et al.<\/a> propose a cryptography-based forensics engine for audit and accounting of CALEA systems.\u00a0 As described by Bates et al.: \u201cThe inability to properly study deployed wiretap systems gives an advantage to those who wish to circumvent them; those who intend to illegally subvert a surveillance system are not usually constrained by the laws governing access to the wiretaps. Indeed, the limited amount of research that has looked at wiretap systems and standards has shown that existing wiretaps are vulnerable to unilateral countermeasures by the target of the wiretap, resulting in incorrect call records and\/or omissions in audio recordings.\u201d\u00a0 Given the amount of light that people are shining on other infrastructure-critical systems such as smart meters and SCADA control systems, perhaps the time is ripe for giving lawful-intercept and monitoring systems the same treatment.<\/li>\n
  6. There are still cute ideas in hardware virtualization.<\/strong>\u00a0 Sun et al.<\/a> presented work (that followed the nifty Lockdown work by Vasudevan et al.<\/a> at Carnegie Mellon, of which I was previously unaware) on using the ACPI S3 sleep mode as a BIOS-assisted method for switching between \u201crunning\u201d OSes.\u00a0 The idea is that when you want to switch from your \u201cgeneral web surfing\u201d OS to your \u201cbank access\u201d OS, you simply suspend the first VM (to the S3 state) and then wake the second VM (from its sleep state).\u00a0 Lockdown did the switch in 20 seconds using the S4 sleep mode; Sun et al.\u2019s work on SecureSwitch does the switch in 6 seconds using the S3 sleep mode but requires some hardware modifications.\u00a0 Given my interest in hardware virtualization, I particularly enjoyed learning about these two projects.\u00a0 I also liked the three other systems-security papers presented in the same session: Lin et al. presented forensics work on discovering data structures in unmapped memory; El Defrawy et al.<\/a> presented work on modifying low-end microcontrollers to provide inexpensive roots of trust for embedded systems; and Tian et al.<\/a> presented a scheme for one virtual machine to continuously monitor another VM\u2019s heap for evidence of buffer overflow.<\/li>\n
  7. Defensive systems that take active responses, such as the OSPF \u201cfight-back\u201d mechanism, can introduce new vulnerabilities as a result of these responses.<\/strong>\u00a0 In some of my favorite work from the conference, Nakibly et al. described a new \u201cDisguised LSA\u201d attack against the Open Shortest Path First (OSPF) interior gateway protocol.\u00a0 The authors first describe the OSPF \u201cfight-back\u201d mechanism: \u201cOnce a router receives an instance of its own LSA [link state advertisement] which is newer than the last instance it originated, it immediately advertises a newer instance of the LSA which cancels out the false one.\u201d\u00a0 However, \u201c[The] OSPF spec states that two instances of an LSA [link state advertisement] are considered identical if they have the same values in the following three fields: Sequence Number, Checksum, and Age…all three relevant fields [are] predictable.\u201d\u00a0 In the Disguised LSA attack the authors first send a forged LSA (purportedly from a victim router) with sequence number N (call this \u201cLSA-A\u201d), then one second later send another forged LSA with sequence number N+1 (LSA-B).\u00a0 When the victim router receives LSA-A it will fight back by sending a new LSA with sequence number N+1 (LSA-C).\u00a0 But when the victim receives LSA-B it will ignore it as being a duplicate of LSA-C.\u00a0 Meanwhile, any router that receives LSA-B before LSA-C will install (the attacker\u2019s) LSA-B and discard (the victim\u2019s) LSA-C as a duplicate.\u00a0 Not all routers in an area will be poisoned by LSA-B, but the authors\u2019 simulation suggests that 90% or more routers in an AS could be poisoned.\u00a0 In other disrupting-networks work, Schuchard et al.<\/a> presented a short paper on how an adversary can send legitimate but oddly-formed BGP messages to cause routers in an arbitrary network location to fall into one of a \u201cvariety of failure modes, ranging from severe performance degradation to the unrecoverable failure of all active routing sessions”; and Jiang et al.<\/a> demonstrated that \u201ca vulnerability affecting the large majority of popular DNS implementations which allows a malicious domain name [such as those used in] malicious activities such as phishing, malware propagation, and botnet command and control [to] stay resolvable long after it has been removed from the upper level servers\u201d, even after the TTL for the domain name expires in DNS caches.<\/li>\n
  8. Hot topic 1:\u00a0 Three papers discussed negative aspects of location privacy in cellular networks.<\/strong>\u00a0 Kune et al.<\/a> describe both an attack to determine the TMSI (temporary mobile subscriber identity) assigned to a telephone number in a GSM network, and a technique for monitoring PCCH (paging channel) traffic from a particular cell tower to determine if the subscriber is in the vicinity of (within a few kilometers of) that tower.\u00a0 Bindschaedler et al.<\/a> show empirically that recent research on \u201cmix zones\u201d — geographic areas in which users can mix or change their device identifiers such as IP and MAC addresses to hide their movement and ongoing communications — is not yet effective as a privacy preservation mechanism for cellular users.\u00a0 Finally, in the words of Qian et al.<\/a>: \u201cAn important class of attacks against cellular network infrastructures, i.e.<\/em>, signaling DoS attack, paging channel overload, and channel exhaustion attack, operates by sending low rate data traffic to a large number of mobile devices at a particular location<\/em> to exhaust bottleneck resources…[We demonstrate] how to create a hit-list of reachable mobile IP addresses associated with the target location to facilitate such targeted DoS attacks.\u201d\u00a0 Of particular interest: \u201cWe show that 80% of the devices keep their device IPs for more than 4 hours, leaving ample time for attack reconnaissance\u201d and that often on UMTS networks in large U.S. cities an attacker could \u201clocate enough IPs to impose 2.5 to 3.5 times the normal load on the network.\u201d<\/li>\n
  9. Hot topic 2:\u00a0 Three papers discussed privacy preservation in cloud-based searching.<\/strong>\u00a0 Chen et al. presented an interesting architecture where a private cloud and public cloud work are used together to perform a search over sensitive DNA information: \u201cInspired by the famous \u201cseed-and-extend\u201d method, our approach strategically splits a mapping task: the public cloud seeks exact matches between the keyed hash values of short read substrings (called seeds) and those of reference sequences to roughly position reads on the genome; the private cloud extends the seeds from these positions to find right alignments. Our novel seed-combination technique further moves most workload of this task to the public cloud. The new approach is found to work effectively against known inference attacks, and also easily scale to millions of reads.\u201d\u00a0 Lu, in addition to having the best opening to a Related Work section that I\u2019ve ever read — “This section overviews related work; it can be skipped with no lack of continuity<\/em>” — demonstrates \u201chow to build a system that supports logarithmic search over encrypted data.\u201d\u00a0 This system \u201cwould allow a database owner to outsource its encrypted database to a cloud server. The owner would retain control over what records can be queried and by whom, by granting each authorized user a search token and a decryption key. A user would then present this token to cloud server who would use it to find encrypted matching records, while learning nothing else. A user could then use its owner-issued decryption key to learn the actual matching records.\u201d\u00a0 Finally, Stefanov et al.<\/a> presented sort-of-cloud-related work on optimizing \u201cOblivious RAM\u201d: \u201cThe goal of O-RAM is to completely hide the data access pattern (which blocks were read\/written) from the server. In other words, each data read or write request will generate a completely random sequence of data accesses from the server\u2019s perspective.\u201d<\/li>\n
  10. Hot topic 3: Five papers discussed smartphone and\/or app insecurity.<\/strong>\u00a0 In work that had my jaw hitting the floor regarding the security design of production apps, Schrittwieser et al.<\/a> \u201canalyze nine popular mobile messaging and VoIP applications and evaluate their security models with a focus on authentication mechanisms. We find that a majority of the examined applications use the user\u2019s phone number as a unique token to identify accounts, which further encumbers the implementation of security barriers. Finally, experimental results show that major security flaws exist in most of the tested applications, allowing attackers to hijack accounts, spoof sender-IDs or enumerate subscribers.\u201d\u00a0 Davi et al.<\/a> described a control-flow integrity checker for smartphones with ARM processors: asserting \u201cthe basic safety property that the control-flow of a program follows only the legitimate paths determined in advance. If an adversary hijacks the control-flow, CFI enforcement can detect this divagation and prevent the attack.\u201d\u00a0 Zhou et al.<\/a> analyzed the prevalence of malware in five Android app markets, including the official market and four popular alternative markets.\u00a0 Two papers (Bugiel et al. and Grace et al.) address privilege-escalation problems in Android, where malicious applications are able to gain unapproved privileges either (Bugiel et al.<\/a>) by colluding with other differently-privileged applications or (Grace et al.<\/a>) by invoking APIs unexpectedly exported by the Android framework.\u00a0 The presenter for the latter paper showed a video of a malicious application sending an SMS message and rebooting(!) the phone, both without holding any user-granted permissions<\/em>.<\/li>\n<\/ol>\n

    There were three keynote speakers, whose messages were: (1) you\u2019re a security professional so you need to be involved in publicly advocating one way or the other on security-related social issues; (2) the future [30 years ahead] will be a strange and interesting place and, since you\u2019re a security researcher, you\u2019ll help us get there; and (3) passwords are pass\u00e9; if you\u2019re not using two- (or more-)factor authentication then you\u2019re not a good security practitioner.<\/p>\n

    I like NDSS because of the practical nature of the (mostly academic) work presented:\u00a0 Much of the work feels innovative enough to advance the science of security, yet relevant and practical enough to immediately be integrated as useful extensions to existing commercial products.\u00a0 Only 17% of submitted manuscripts were accepted for publication, so the quality of work presented was good.\u00a0 Unfortunately, attendance is low — someone told me there were 210 people there, but I never heard the official count — so it is not as good a see-old-friends-and-make-new-ones event as, say, CCS.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Last week I attended the Network and Distributed System Security (NDSS) Symposium in San Diego, California.\u00a0 NDSS is generally considered one of the top-tier academic security conferences.\u00a0 This was my second year in a row attending the symposium. Things I learned or especially enjoyed are in boldface text below (you may safely skip the non-boldfaced […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[],"_links":{"self":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/83"}],"collection":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/comments?post=83"}],"version-history":[{"count":10,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/83\/revisions"}],"predecessor-version":[{"id":653,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/posts\/83\/revisions\/653"}],"wp:attachment":[{"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/media?parent=83"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/categories?post=83"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/jlg.name\/blog\/wp-json\/wp\/v2\/tags?post=83"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}