Potential bypass of Runas user restrictions
> When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295.
Interesting combination of circumstances.
50 ways to leak your data: an exploration of apps’ circumvention of the Android permissions system
> This paper is a study of Android apps in the wild that leak permission protected data (identifiers which can be used for tracking, and location information), where those apps should not have been able to see such data due to a lack of granted permissions. By detecting such leakage and analysing the responsible apps, the authors uncover a number of covert and side channels in real-world use.
Chromebook U2F ECDSA vulnerability
> We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.
Experimental feature, with an annoying fix. If it had been for real, quite messy.
Scraping A Public Website Doesn't Violate the CFAA, Ninth Circuit (Mostly) Holds
> This is a major case that will be of interest to a lot of people and a lot of companies. But it’s also pretty complicated and easy to misunderstand. This post will go through it carefully, trying to explain what it says and what it doesn’t say.
Down the Rabbit-Hole...
> I often find it valuable to write simple test cases confirming things work the way I think they do. Sometimes I can’t explain the results, and getting to the bottom of those discrepancies can reveal new research opportunities. This is the story of one of those discrepancies; and the security rabbit-hole it led me down.
> Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie. Secondly, there is nothing stopping you pretending to be a CTF service and getting other applications - even privileged applications - to connect to you.
> Even without bugs, the CTF protocol allows applications to exchange input and read each other’s content. However, there are a lot of protocol bugs that allow taking complete control of almost any other application.
Regarding disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=1859#c10
Username (and password) free login with security keys
> Most readers of this blog will be familiar with the traditional security key user experience: you register a token with a site then, when logging in, you enter a username and password as normal but are also required to press a security key in order for it to sign a challenge from the website. This is an effective defense against phishing, phone number takeover, etc. But modern security keys are capable of serving the roles of username and password too, so the user experience can just involve clicking a login button, pressing the security key, and (perhaps) entering a locally-validated PIN if the security key doesn’t do biometrics. This is possible with the recently released Chromium 76 and also with Edge or Firefox on current versions of Windows.
> That begs the question: what’s the difference between a PIN and a password? On the surface: nothing. A security key PIN is an arbitrary string, not limited to numbers. (I think it was probably considered too embarrassing to call it a password since FIDO’s slogan is “solving the world’s password problem”.)
How (not) to sign a JSON object
This covers a lot of ground. I liked this quote, even though there’s much more to the post.
> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.
How Hacking Works
In which xkcd teaches us about cred stuffing.
KPMG Audit Professionals Manipulated the Scoring of Training Exams
In today’s edition of edit a URL and go to jail...
> KPMG sent participants in training programs a hyperlink that directed them to the applicable exams. Embedded in the hyperlink was an instruction to the server that specified the score necessary to pass the exam. Thus, the characters “MasteryScore=70” meant participants were required to answer at least 70 percent of the answers accurately to pass the exam. By changing the number in the hyperlink, audit professionals could change the score required to pass.
> 58. For a period of time up to November 2015, certain audit professionals, including one partner, altered the URLs for their exams to lower the scores required to pass. Twenty-eight of these auditors did so on four or more occasions. Certain audit professionals lowered the required score to the point of passing exams while answering less than 25 percent of the questions correctly.
Also: 25%??? Come on guys, that’s worse than random chance!
Getting 2FA Right in 2019
> All told, there’s never been a better time to add 2FA to your services. Keep reading to find out how you can do it right.
There’s a lot here and it’s all very good.
The Return of the WIZard: RCE in Exim (CVE-2019-10149)
> In this particular case, RCE means Remote *Command* Execution, not Remote Code Execution: an attacker can execute arbitrary commands with execv(), as root; no memory corruption or ROP (Return-Oriented Programming) is involved.
> This vulnerability is exploitable instantly by a local attacker (and by a remote attacker in certain non-default configurations). To remotely exploit this vulnerability in the default configuration, an attacker must keep a connection to the vulnerable server open for 7 days (by transmitting one byte every few minutes). However, because of the extreme complexity of Exim’s code, we cannot guarantee that this exploitation method is unique; faster methods may exist.
What I Learned Trying To Secure Congressional Campaigns
> I don’t believe I accomplished much, but I made so many friends along the way! And I learned a lot about the idiosyncratic world of Congressional campaigns; knowledge that I want to now hand over to you, the next person willing to take a swing at this piñata of futility.
> The candidate was hardest person to secure. They were too busy to come to the training. They didn’t want to move off their Loudong SB250 phone because it had all their favorite Flash games from the Yahoo store on it. Three different antivirus programs competed for dominion over their Windows 7 laptop.
> Ideally, there would be a billing model where the training is free, but the campaign gets charged thousands of dollars for ignoring it.
Security Issue with Bluetooth Low Energy (BLE) Titan Security Keys
> Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key -- within approximately 30 feet -- to (a) communicate with your security key, or (b) communicate with the device to which your key is paired.
Bluetooth security is... challenging.
Hope is not a NOBUS strategy
> So typically the first thing I do when I get a new implant to look at is see if the authors implemented public key encryption into it, or if they just have some sort of password authentication, and then maybe a symmetric algorithm for protecting their traffic. This was, for a while, a good way to track nation states because people who wanted their implants “easier” to deploy did not put public keys in them, whereas those of us who wanted a NOBUS backdoor generated a new public key per target (like this amazing one, Hydrogen, from 2004).
John the Ripper 1.9.0-jumbo-1
> It’s been 4.5 years and 6000+ jumbo tree commits (not counting JtR core tree commits, nor merge commits) since we released 1.8.0-jumbo-1:
eyeDisk. Hacking the unhackable. Again
> So, a lot of complex SCSI commands were used to understand the controller side of the device, but obtaining the password/iris can be achieved by simply sniffing the USB traffic to get the password/hash in clear text. The software collects the password first, then validates the user-entered password BEFORE sending the unlock password. This is a very poor approach given the unhackable claims and fundamentally undermines the security of the device.
Bad utmp implementations in Glibc and FreeBSD
> I wondered: If the files consist of fixed-sized records, and are readable by regular users, how is consistency maintained? That is – how can a process ensure that, when it updates the database, it doesn’t conflict with another process also attempting to update the database at the same time? Similarly, how can a process reading an entry from the database be sure that it receives a consistent, full record and not a record which has been partially updated? (after all, POSIX allows that a write(2) call can return without having written all the requested bytes, and I’m not aware of Linux or any of the *BSDs documenting that this cannot happen for regular files). Clearly, some kind of locking is needed; a process that wants to write to or read from the database locks it first, performs its operation, and then unlocks the database. Once again, this happens under the hood, in the implementation of the getutent/pututline functions or their equivalents.
Alpine Linux Docker Image root User Hard-Coded Credential Vulnerability
> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the root user. This vulnerability appears to be the result of a regression introduced in December t2015. Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container that utilize Linux PAM, or some other mechanism that uses the system shadow file as an authentication database, may accept a NULL password for the root user.
NULL as in empty. Note the timeline.
> This vulnerability was originally reported and patched in 2015, regression tests were added to prevent this from occurring in the future.
> Unfortunately, later that same year, a commit was pushed to simplify the regression tests. This lead to logic that may have caught this regression being simplified, causing these tests to be incorrectly ‘satisfied’ if the root password was once again removed.
> Eight days after this vulnerability was initially fixed, a commit was pushed which removed this ‘disable root by default’ flag from the ‘edge’ build properties file, reintroducing this issue to subsequent builds.
Ethercombing: Finding Secrets in Popular Places
> In this paper we examine how, even when faced with this statistical improbability, ISE discovered 732 private keys as well as their corresponding public keys that committed 49,060 transactions to the Ethereum blockchain. Additionally, we identified 13,319 Ethereum that was transferred to either invalid destination addresses, or wallets derived from weak keys that at the height of the Ethereum market had a combined total value of $18,899,969. In the process, we discovered that funds from these weak-key addresses are being pilfered and sent to a destination address belonging to an individual or group that is running active campaigns to compromise/gather private keys and obtain these funds. On January 13, 2018, this “blockchainbandit” held a balance of 37,926 ETH valued at $54,343,407.
> In an experiment, we picked a private key of 1, for no reason other than that it is the lower bound of a possible private key for secp256k1 and it also lies within the 1 to 232-1 range of a 32-bit truncated key. We use the private key 0x0000000000000000000000000000000000000000000000000000000000000001 to derive the public Ethereum address 0x7e5f4552091a69125d5dfcb7b8c2659029395bdf.
U2F Technical Overview
> U2F is a challenge-response protocol extended with phishing and MitM protection, application-specific keys, device cloning detection and device attestation. There are two flows: registration and authentication.
> For the full package of FIDO U2F specifications, visit the FIDO Alliance Specifications homepage.