Yesterday, I received an email from a reader concerning IETF Request for Comments (RFCs):
“I have heard about hackers reading RFCs. Is there a guide on reading RFCs and what to search for? Because there is way too much information in RFCs, one cannot start going through it manually.”
— Afolic
This is a brilliant question and one I have heard before but never covered in a blog post.
Having worked on the security.txt specification (soon to be RFC 9116), I may be able to give some insight into what to look for when reviewing RFCs as a bug bounty hunter.
Before we dive into my advice on how to review RFCs, let me share why a bug bounty hunter may want to review RFC literature.
Why?!
RFCs act as reference material for readers to implement certain technologies and protocols.
For bug bounty hunters, the documents are an opportunity to familiarise oneself with a given technology as defined by the authors of the standard. Rather than relying on a third-party’s rehash, RFCs act as the original source. RFCs allow one to examine what developers may have reviewed when designing their implementation.
Additionally, RFCs allow one to see where implementors deviate from the specification; thus, potentially introducing security flaws.
At the end of the day, an RFC specification is merely a guideline. Implementors are free to develop the technology or protocol as they wish. If I decide I would rather use frogs over pigeons for RFC 1149, that is up to me—the implementor.
Before you dive in
As highlighted by reader Afolic, diving straight into an RFC document may be daunting at first.
Initially, I prefer reviewing a topic by becoming acquainted with the surrounding vocabulary. For example, before reading the ICMP RFC, I might watch a few YouTube videos on the subject until I feel comfortable enough to start examining the RFC.
If you are not sure what terminology to look up, RFCs come with a dedicated “Terminology” section towards the beginning of the document.
Right; now you are ready to read an RFC.
The Security Considerations section
As outlined in RFC 7322, all RFCs must include a Security Considerations section that covers the security practices readers must consider when implementing the RFC.
All RFCs must contain a section that discusses the security considerations relevant to the specification; see “Guidelines for Writing RFC Text on Security Considerations” [BCP72] for more information.
— RFC 7322, Section 4.8.5
Naturally, it would make sense for someone reviewing the security of a target technology to read the security considerations the authors of the RFC made. For instance, are you testing the security of an OAuth 2.0 implementation? Review the RFC 6749 Security Considerations section.
The security.txt specification has a “Security Considerations” section too. Can you think of what flaws may have been introduced by readers not taking the security considerations into account?
Reviewing past versions of an RFC
When targeting an application, certain features and implementations may be following outdated RFC specifications. You can tell an RFC is outdated because the document’s front matter contains an “Obsoleted by:” link.
To simplify the reading process, RFCs come with a diff viewer. The IETF have a dedicated tool called Rfcdiff Tool which makes generating diffs easier.
If you are strapped for time, diffing the table of contents can often reveal a lot about the changes made from one RFC to another.
Errata exist
RFCs can contain mistakes. The authors are only human and sometimes even after hundreds of edits and reviews, a mistake makes its way into the final RFC specification.
To address this, the IETF have errata boards where readers may report mistakes (i.e. errata). When mistakes have been discovered in an RFC, the document will include an “Errata exist” link.
Errata in RFCs may result in developers making mistakes in their implementations. It is worth reviewing the errata for issues relating to security. Then, determine whether your target is affected by a given erratum.
I would recommend keeping notes for each RFC you review containing security-relevant errata that one could test for. That way, in future, you do not have to sieve through the RFC errata again to rediscover these security-related mistakes.
Conclusion
RFCs can be dry and difficult to navigate. I hope this response to the email helps bug bounty hunters more easily review RFCs.
If you would like to have your question answered in the form of a blog post like this, please send me an email.