The summer conference constellation rises over Las Vegas for about one week every year. The trio of Black Hat, BSidesLV, and DEF CON historically generates loud, often muddled, concerns about personal device security. Sometimes the concern is expressed through hyperbole in order to point out flawed threat models. Sometimes it’s based on ignorance tainted with misapplied knowledge. Either way, perform the rituals and incantations that make you feel better. Enjoy the conferences, have fun, share knowledge, learn new skills.

Whatever precautions you take, ask why they’re necessary for one special week of the year. If the current state of security for devices and web sites can’t handle that week, I find that a failure of infosec and an indictment of appsec’s effectiveness after three decades.

It’s another way of asking why a device’s current “default secure” is insufficient, or asking whether we need multi-page hardening guides vs. a default hardened configuration.

Keep in mind there are people with security concerns all 52 weeks of the year. People who are women. People in minority groups. People in abusive relationships. People without political representation, let alone power. Most often these are people who can’t buy a “burner phone” for one week to support their daily needs. Their typical day isn’t the ambiguous threat of a hostile network. It’s the direct threat from hostile actors – those with physical access to their devices, or knowledge of their passwords, or possibly just knowledge of their existence. In each case they may be dealing with a threat who desires access to their identity, data, and accounts.

There are a few steps anyone can take to improve their baseline security profile. However, these are just a starting point. They can change slightly depending on different security scenarios.

(1) Turn on automatic updates.

(2) Review authentication and authorization for all accounts.

• Use a password manager to assign a unique password to every account.
• Enable multi-factor authentication (MFA), aka two-factor authentication (2FA) or two-step verification (2SV), for all accounts that support it.
• Prioritize enabing MFA for all accounts used for OAuth or social logins (e.g. Apple, Facebook, Google, LinkedIn).
• Prefer WebAuthn authentication flows. It cryptographically binds credentials between the user device and server. This prevents replay attacks if the traffic is intercepted and reuse attacks if the server’s credential store is compromised.
• Review third-party app access (usually OAuth grants) and remove any that feel unnecessary or that have more permissions than desired.

(3) Review MFA support (or activation factors as NIST 800-63B calls them)

• Prefer factors that rely on FIDO2 hardware tokens, biometrics, or authenticator apps.
• Only use factors based on SMS or email if no better option is available.
• For authenticator apps, enable backups or multi-device support in order to preserve access in case of a lost device.
• Record and save recovery codes associated with enabling MFA. Choose a storage mechanism sufficient for your needs, such as printed and placed somewhere safe or in a password-protected keychain.

Talk to someone who isn’t in infosec. Find out what their concerns. Help them translate those concerns into ways of protecting their accounts and data.

Apple recently released Lockdown Mode in iOS 16, iPadOS 16, and macOS Ventura. It provides users with increased protection for their system by ensuring a secure default as well as disabling features that typically have security issues. It’s effectively a one-click hardening guide and attack surface reduction. By disabling feeatures prone to abuse, it carries a useability cost. But ultimately it’s an easy way for any user to have more security when they need it.

Not everyone has an iPhone and not everyone has threats limited to account takeover.

One resource with technical recommendations in non-technical jargon is Speak Up & Stay Safe(r).

The EFF has a wide collection of practices and tools in its Surveillance Self-Defense guide. Notably, it lists different security scenarios you might find yourself in and how to adapt practices to each of them.

The expectation for modern devices and modern web sites should be that they’re safe to use, even on the hostile network of an infosec conference. If an industry can’t create a safe environment for itself, why should it be relied on to create a safe environment for anyone else.

The alphabetically adjacent domains when this site was hosted at WordPress included air fresheners, web security, and cats. Thanks to Let’s Encrypt, all of those now support HTTPS by default.

Even better, WordPress serves the Strict-Transport-Security header to ensure browsers adhere to HTTPS when visiting it. So, whether you’re being entertained by odors, HTML injection, or felines, your browser is encrypting traffic.

Let’s Encrypt makes this possible for two reasons. The project provides free certificates, which addresses the economic aspect of obtaining and managing them. Users who blog, create content, or set up their own web sites can do so with free tools. But the HTTPS certificates were never free and there was little incentive for them to spend money. To further compound the issue, users creating content and web sites rarely needed to know the technical underpinnings of how those sites were set up (which is perfectly fine!). Yet the secure handling and deployment of certificates requires more technical knowledge.

Most importantly, Let’s Encrypt addressed this latter challenge by establishing a simple, secure ACME protocol for the acquisition, maintenance, and renewal of certificates. Even when (or perhaps especially when) certificates have lifetimes of one or two years, site administrators would forget to renew them. It’s this level of automation that makes the project successful.

Hence, WordPress can now afford – both in the economic and technical sense – to deploy certificates for all the custom domain names it hosts. That’s what brings us to the cert for this site, which is but one domain in a list of SAN entries from deadairfresheners to a Russian-language blog about, inevitably, cats.

Yet not everyone has taken advantage of the new ease of encrypting everything. Five years ago I wrote about Why You Should Always Use HTTPS. Sadly, the article itself is served only via HTTP. You can request it via HTTPS, but the server returns a hostname mismatch error for the certificate, which breaks the intent of using a certificate to establish a server’s identity.

As with all things new, free, and automated, there will be abuse. For one, malware authors, phishers, and the like will continue to move towards HTTPS connections. The key point there being “continue to”. Such bad actors already have access to certs and to compromised financial accounts with which to buy them. There’s little in Let’s Encrypt that aggravates this.

Attackers may start looking for letsencrypt clients in order to obtain certs by fraudulently requesting new ones. For example, by provisioning a resource under a well-known URI for the domain (this, and provisioning DNS records, are two ways of establishing trust to the Let’s Encrypt CA).

Attackers may start accelerating domain enumeration via Let’s Encrypt SANs. Again, it’s trivial to walk through domains for any SAN certificate purchased today. This may only be a nuance for hosting sites or aggregators who are jumbling multiple domains into a single cert.

Such attacks aren’t proposed as creaky boards on the Let’s Encrypt stage. They’re merely reminders that we should always be reconsidering how old threats and techniques apply to new technologies and processes. For many ”astounding” hacks of today, there are likely close parallels to old Phrack articles or basic security principles awaiting clever reinterpretation for our modern times.

Finally, I must leave you with some sort of pop culture reference, or else this post wouldn’t befit the site. This is the 400th anniversary of Shakespeare’s death. So I shall leave you with a quote from Julius Caesar:

Nay, an I tell you that, Ill ne’er look you i’ the

face again: but those that understood him smiled at one

another and shook their heads; but, for mine own part, it

was Greek to me. I could tell you more news too: Marullus

and Flavius, for pulling scarfs off Caesar’s images, are

put to silence. Fare you well. There was more foolery

yet, if I could remember it.

May it take us far less time to finally bury HTTP and praise the ubiquity of HTTPS. We’ve had enough foolery of unencrypted traffic.

Developers who wish to defend their code should be aware of Advanced Persistent Exploitability (APE). It’s a situation where broken code remains broken due to incomplete security improvements.

Code has errors. Writing has errors. Consider the pervasiveness of spellcheckers and how often the red squiggle complains about a misspelling in as common an activity as composing email.

Mistakes happen. They’re a natural consequence of writing, whether code, blog, email, or book. The danger here is that mistakes in code lead to vulns that can be exploited.

Sometimes coding errors arise from a stubborn refusal to acknowledge fundamental principles, as seen in the Advanced Persistent Ignorance that lets SQL injection persist more than a decade after programming languages first provided countermeasures. Anyone with sqlmap can trivially exploit that ancient vuln by now without bothering to know how they’re doing so.

Other coding errors stem from misdiagnosing a vuln’s fundamental cause – the fix addresses an exploit example as opposed to addressing the underlying issue. This failure becomes more stark when the attacker just tweaks an exploit payload in order to compromise the vuln again.

We’ll use the following PHP snippet as an example. It has an obvious flaw in the arg parameter:

<?php
$arg = $_GET['arg'];
$r = exec('/bin/ls ' . $arg);
?>

Confronted with an exploit that contains a semi-colon to execute an arbitrary command, a dev might choose to apply input validation. Doing so isn’t necessarily wrong, but it’s potentially incomplete.

Unfortunately, it may also be a first step on the dangerous path of the ”Clever Factor”. In the following example, the dev intended to allow only values that contained alpha characters.

<?php
$arg = $_GET['arg'];
# did one better than escapeshellarg
if(preg_match('/[a-zA-Z]+/', $arg)) {
    $r = exec('/bin/ls ' . $arg);
}
?>

As a first offense, the regex should have been anchored to match the complete input string, such as /^[a-zA-Z]+$/ or /\A[a-z][A-Z]+\Z/.

That mistake alone should worry us about the dev’s understanding of the problem. But let’s continue the exercise with three questions:

• Is the intention clear?
• Is it resilient?
• Is it maintainable?

This developer declared they “did one better” than the documented solution by restricting input to mixed-case letters. One possible interpretation is that they only expected directories with mixed-case alpha names. A subsequent dev may point out the need to review directories that include numbers or a dot (.) and, as a consequence, relax the regex. That change might still be in the spirit of the validation approach (after all, it’s restricting input to expectations), but if the regex changes to where it allows a space or shell metacharacters, then it’ll be exploited. Again.

This leads to resilience against code churn. The initial code might be clear to someone who understands the regex to be an input filter (albeit an incorrect one in its first incarnation). But the regex’s security requirements are ambiguous enough that someone else may mistakenly change it to allow metacharacters or introduce a typo that weakens it.

Additionally, what kind of unit tests accompanied the original version? Merely some strings of known directories and a few negative tests with ./ and .. in the path? None of those tests would have demonstrated the vulnerability or conveyed the intended security aspect of the regex.

Code must be maintained over time. In the PHP example, the point of validation is right next to the point of usage (the source and sink in SAST terms). Think of this as the spatial version of the time of check to time of use flaw.

In more complex code, especially long-lived code and projects with multiple committers, the validation check could easily drift further and further from the location where its argument is used. This dilutes the original dev’s intention since someone else may not realize the validation context and re-taint or otherwise misuse the parameter – such as using string concatenation with other input values.

In this scenario, a secure solution isn’t even difficult. PHP’s documentation gives clear, prominent warnings about how to secure calls to the entire family of exec-style commands.

$r = exec('/bin/ls ' . escapeshellarg($arg));

The recommended solution has favorable attributes:

• Clear intent – It escapes shell arguments passed to a command.
• Resilient – The PHP function will handle all shell metacharacters, not to mention the character encoding like UTF-8.
• Easy to maintain – Whatever manipulation the $arg parameter suffers throughout the code, it will be properly secured at its point of usage.

It also requires less typing than the back-and-forth of multiple bug comments required to explain the pitfalls of regexes and the necessity of robust defenses. Securing code against one exploit is not the same as securing it against an entire vuln class.

There are many examples of this “cleverness” phenomenon, from string-matching alert to dodge XSS payloads to renaming files to avoid exploitation.

What does the future hold for programmers?

Pierre Boule’s vacationing astronauts perhaps summarized it best in the closing chapter of La Planète des Singes:

Des hommes raisonnables ? … Non, ce n’est pas possible

May your interplanetary voyages lead to less strange worlds.