recentpopularlog in

jabley : security   764

« earlier  
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 
12 days ago 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
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
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
Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud
Controlled sharing is fundamental to distributed
systems; yet, on the Web, and in the Cloud, sharing is still
based on rudimentary mechanisms. More flexible, decentralized
cryptographic authorization credentials have not been adopted,
largely because their mechanisms have not been incrementally
deployable, simple enough, or efficient enough to implement
across the relevant systems and devices.
This paper introduces macaroons: flexible authorization credentials for Cloud services that support decentralized delegation
between principals. Macaroons are based on a construction that
uses nested, chained MACs (e.g., HMACs [43]) in a manner that
is highly efficient, easy to deploy, and widely applicable.
Although macaroons are bearer credentials, like Web cookies,
macaroons embed caveats that attenuate and contextually confine
when, where, by who, and for what purpose a target service
should authorize requests. This paper describes macaroons and
motivates their design, compares them to other credential systems,
such as cookies and SPKI/SDSI [14], evaluates and measures a
prototype implementation, and discusses practical security and
application considerations. In particular, it is considered how
macaroons can enable more fine-grained authorization in the
Cloud, e.g., by strengthening mechanisms like OAuth2 [17], and
a formalization of macaroons is given in authorization logic.
web  security  paper  filetype:pdf  authentication  authorisation 
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
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