recentpopularlog in

jabley : infosec   183

« earlier  
Lest We Remember: Cold Boot Attacks on Encryption Keys | Center for Information Technology Policy
Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them.
security  paper  dram  memory  attack  encryption  infosec 
17 days ago by jabley
Stack Overflow Considered Harmful? The Impact of Copy&Paste on Android Application Security
Online programming discussion platforms such as
Stack Overflow serve as a rich source of information for software
developers. Available information include vibrant discussions
and oftentimes ready-to-use code snippets. Previous research
identified Stack Overflow as one of the most important information sources developers rely on. Anecdotes report that
software developers copy and paste code snippets from those
information sources for convenience reasons. Such behavior
results in a constant flow of community-provided code snippets
into production software. To date, the impact of this behaviour
on code security is unknown.
We answer this highly important question by quantifying
the proliferation of security-related code snippets from Stack
Overflow in Android applications available on Google Play.
Access to the rich source of information available on Stack
Overflow including ready-to-use code snippets provides huge
benefits for software developers. However, when it comes to
code security there are some caveats to bear in mind: Due
to the complex nature of code security, it is very difficult to
provide ready-to-use and secure solutions for every problem.
Hence, integrating a security-related code snippet from Stack
Overflow into production software requires caution and expertise.
Unsurprisingly, we observed insecure code snippets being copied
into Android applications millions of users install from Google
Play every day.
To quantitatively evaluate the extent of this observation, we
scanned Stack Overflow for code snippets and evaluated their
security score using a stochastic gradient descent classifier. In
order to identify code reuse in Android applications, we applied
state-of-the-art static analysis. Our results are alarming: 15.4%
of the 1.3 million Android applications we analyzed, contained
security-related code snippets from Stack Overflow. Out of these
97.9% contain at least one insecure code snippet.
filetype:pdf  paper  security  research  infosec  code  reuse 
october 2019 by jabley
[no title]
how information operations have been carried out in the past to exploit divisions
filetype:pdf  cybersecurity  security  infosec 
july 2019 by jabley
Programming Satan’s Computer
Cryptographic protocols are used in distributed systems to
identify users and authenticate transactions. They may involve the exchange of about 2–5 messages, and one might think that a program of
this size would be fairly easy to get right. However, this is absolutely not
the case: bugs are routinely found in well known protocols, and years
after they were first published. The problem is the presence of a hostile
opponent, who can alter messages at will. In effect, our task is to program a computer which gives answers which are subtly and maliciously
wrong at the most inconvenient possible moment. This is a fascinating
problem; and we hope that the lessons learned from programming Satan’s computer may be helpful in tackling the more common problem of
programming Murphy’s.
paper  security  infosec  comp-sci  crypto  protocol  design 
june 2019 by jabley
ExSpectre: Hiding Malware in Speculative Execution
Recently, the Spectre and Meltdown attacks revealed serious vulnerabilities in modern CPU designs, allowing
an attacker to exfiltrate data from sensitive programs. These
vulnerabilities take advantage of speculative execution to coerce
a processor to perform computation that would otherwise not
occur, leaking the resulting information via side channels to an
attacker.
In this paper, we extend these ideas in a different direction,
and leverage speculative execution in order to hide malware from
both static and dynamic analysis. Using this technique, critical
portions of a malicious program’s computation can be shielded
from view, such that even a debugger following an instructionlevel trace of the program cannot tell how its results were
computed.
We introduce ExSpectre, which compiles arbitrary malicious
code into a seemingly-benign payload binary. When a separate
trigger program runs on the same machine, it mistrains the CPU’s
branch predictor, causing the payload program to speculatively
execute its malicious payload, which communicates speculative
results back to the rest of the payload program to change its
real-world behavior.
We study the extent and types of execution that can be
performed speculatively, and demonstrate several computations
that can be performed covertly. In particular, within speculative execution we are able to decrypt memory using AES-NI
instructions at over 11 kbps. Building on this, we decrypt and
interpret a custom virtual machine language to perform arbitrary
computation and system calls in the real world. We demonstrate
this with a proof-of-concept dial back shell, which takes only
a few milliseconds to execute after the trigger is issued. We
also show how our corresponding trigger program can be a preexisting benign application already running on the system, and
demonstrate this concept with OpenSSL driven remotely by the
attacker as a trigger program.
ExSpectre demonstrates a new kind of malware that evades
existing reverse engineering and binary analysis techniques. Because its true functionality is contained in seemingly unreachable
dead code, and its control flow driven externally by potentially
any other program running at the same time, ExSpectre poses a
novel threat to state-of-the-art malware analysis techniques.
malware  cpu  papers  security  filetype:pdf  infosec  spectre  vulnerability 
march 2019 by jabley
ACLs don't
The ACL model is unable to make correct access decisions for interactions involving more than
two principals, since required information is not retained across message sends. Though this
deficiency has long been documented in the published literature, it is not widely understood. This
logic error in the ACL model is exploited by both the clickjacking and Cross-Site Request
Forgery attacks that affect many Web applications.
filetype:pdf  paper  web  infosec  vulnerability  security 
january 2019 by jabley
Erays: Reverse Engineering Ethereum’s Opaque Smart Contracts
Interacting with Ethereum smart contracts can have potentially
devastating financial consequences. In light of
this, several regulatory bodies have called for a need to
audit smart contracts for security and correctness guarantees.
Unfortunately, auditing smart contracts that do
not have readily available source code can be challenging,
and there are currently few tools available that aid in
this process. Such contracts remain opaque to auditors.
To address this, we present Erays, a reverse engineering
tool for smart contracts. Erays takes in smart contract
from the Ethereum blockchain, and produces high-level
pseudocode suitable for manual analysis. We show how
Erays can be used to provide insight into several contract
properties, such as code complexity and code reuse in
the ecosystem. We then leverage Erays to link contracts
with no previously available source code to public source
code, thus reducing the overall opacity in the ecosystem.
Finally, we demonstrate how Erays can be used for
reverse-engineering in four case studies: high-value multisignature
wallets, arbitrage bots, exchange accounts, and
finally, a popular smart-contract game, Cryptokitties. We
conclude with a discussion regarding the value of reverse
engineering in the smart contract ecosystem, and how
Erays can be leveraged to address the challenges that lie
ahead
infosec  security  filetype:pdf  paper  toread  contracts  ethereum  cryptocurrency  vm  reverse-engineering 
august 2018 by jabley
So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users
It is often suggested that users are hopelessly lazy and
unmotivated on security questions. They chose weak
passwords, ignore security warnings, and are oblivious
to certificates errors. We argue that users’ rejection
of the security advice they receive is entirely rational
from an economic perspective. The advice offers to
shield them from the direct costs of attacks, but burdens
them with far greater indirect costs in the form of effort.
Looking at various examples of security advice we find
that the advice is complex and growing, but the benefit
is largely speculative or moot. For example, much of the
advice concerning passwords is outdated and does little
to address actual treats, and fully 100% of certificate
error warnings appear to be false positives. Further, if
users spent even a minute a day reading URLs to avoid
phishing, the cost (in terms of user time) would be two
orders of magnitude greater than all phishing losses.
Thus we find that most security advice simply offers a
poor cost-benefit tradeoff to users and is rejected. Security
advice is a daily burden, applied to the whole
population, while an upper bound on the benefit is the
harm suffered by the fraction that become victims annually.
When that fraction is small, designing security
advice that is beneficial is very hard. For example, it
makes little sense to burden all users with a daily task
to spare 0.01% of them a modest annual pain.
security  infosec  usability  paper  filetype:pdf  economics  time  risk 
august 2018 by jabley
Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer
Operating systems provide various inter-process communication
(IPC) mechanisms. Software applications typically
use IPC for communication between frontend and
backend components, which run in different processes
on the same computer. This paper studies the security
of how the IPC mechanisms are used in PC, Mac and
Linux software. We describe attacks where a nonprivileged
process impersonates the IPC communication endpoints.
The attacks are closely related to impersonation
and man-in-the-middle attacks on computer networks but
take place inside one computer. The vulnerable IPC
methods are ones where a server process binds to a name
or address and waits for client communication. Our results
show that application developers are often unaware
of the risks and secure practices in using IPC. We find attacks
against several security-critical applications including
password managers and hardware tokens, in which
another user’s process is able to steal and misuse sensitive
data such as the victim’s credentials. The vulnerabilities
can be exploited in enterprise environments with
centralized access control that gives multiple users remote
or local login access to the same host. Computers
with guest accounts and shared computers at home are
similarly vulnerable.
paper  filetype:pdf  infosec  password-manager  vulnerability  security 
august 2018 by jabley
« earlier      
per page:    204080120160

Copy this bookmark:





to read