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.
Hackers Could Read Your Hotmail, MSN, and Outlook Emails by Abusing Microsoft Support Portal
> A hacker or group of hackers had first broken into a customer support account for Microsoft, and then used that to gain access to information related to customers’ email accounts such as the subject lines of their emails and who they’ve communicated with.
> But the issue is much worse than previously reported, with the hackers able to access email content from a large number of Outlook, MSN, and Hotmail email accounts, according to a source who witnessed the attack in action and described it before Microsoft’s statement, as well as screenshots provided to Motherboard. Microsoft confirmed to Motherboard that hackers gained access to the content of some customers’ emails.
2FA is Still Too Complicated for Most People
> What is there to be familiar with? Terminology for one. What do you mean “Google Authenticator” isn’t a Google service that is automatically backed up and instead it’s an implementation of something called OATH-TOTP? Are recovery codes backup codes? How does that compare with something called recovery tokens? Are backup codes exclusively backups for 2FA or for the whole login? What do you mean a password reset via email doesn’t allow me to deactivate 2FA? Is it possible to change my password without 2FA? Can I deactivate 2FA if I lost my device, but still have an active session? How often do I need to use my second factor device for login anyway?
Using a Yubikey as smartcard for SSH public key authentication
> However, ssh(1) has another method to talk to smartcards. It can load a PKCS#11 library that contains the functions to access the SmartCard. On OpenBSD, this library is provided by the opensc package. In turn, it needs the pcsc-lite package, that actually talks to a smartcard reader.
> I tried the following with a Yubikey NEO and a Yubikey 4. Newer Yubikeys have more features. The NEO only supports RSA keys, Yubikey 4 and 5 support Elliptic Curve ECDSA keys. They also have another nice feature “touch-policy=always“: you have to touch the Yubikey to be able to use it (in addition to entering the PIN). That way it cannot be used without your consent, with a method independent from your computer keyboard.
Protecting Basecamp from breached passwords
> We started by checking that our users aren’t already caught up in a number of high profile, widely available data breaches. We went straight to the source: we scanned the data breaches themselves for user emails, extracted any associated plain-text passwords, and securely checked whether they match user logins.
Increasingly common practice.