Non-attribution: CNO Snake Oil

We have all heard to some extent, "we offer non-attribution." This bold claim is generally not true if we break down what we consider non-attribution including the difficulties associated with substantiating this claim. As a cyber-security professional, I am critical of this claim, because I understand not only what it takes to certify how non-attribution is perceived, but also the technical requirements necessary to validate the process from end-to-end. To focus our discussions of attribution, we should be honest about how attribution, in general, is possible by breaking down how the process of anonymity and privacy is possible. 

Non-attribution discussions are plagued by charlatans, highly motivated and influential sales staff, and a non-discerning customer base of misinformed decision-makers. This has led us to often generalize attribution of Internet activity to an imaginary state of comfort regarding what level of anonymity we consider we have versus what we really can offer or obtain. Other industries have clauses, like "Truth in Lending," yet InfoSec, Cyber, and IT operations may find it difficult to ensure that a cyber infrastructure can be anonymized since we have no standardized governing principle that equates to "this is how we can certify non-attribution is ensured and maintained.”

Before we jump in, let’s summarize the use of Tor, proxies, and virtual private networks (VPNs).

Tor

Tor ("The Onion Router") is an anonymizing service that uses a series of servers on the Internet - nodes - and successive layers of encryption to prevent potential men-in-the-middle, whether they be nodes or passive observers, from knowing the source and destination of traffic. Tor is an anonymizing service, however your connection to the Tor network and exit traffic are subject to monitoring. Tor routes your request through the use of Tor nodes across the globe. Your exit node is the place where traffic becomes visible as cleartext. Let’s say you requested a site over HTTPS; will a random exit node have TLS termination properly configured? More than likely not, however after using Tor since 2005 I have seen TLS errors that suggest efforts to man-in-the-middle TLS requests over Tor. The exit node will log all activity, yet it does not know who made the original request within the Tor, unless you configure your Tor client to enter through a known exit node as your entry node, as a bridge, and by chance, it also becomes your exit node (you should never enter an exit node as a bridge without configuring your Tor client to never use said node as an exit node). Your entry node, guard or bridge, will log your origin connection. It is important to note that an exit node is perhaps misconfigured or does not properly handle requests. It may also have firewall rules to prevent undesired requests from ever reaching the destination, or perhaps it is configured to simply redirect all requests to how they chose. For example, you request 23.23.23.23 and instead get redirected to 24.24.24.24; is this not a proxy at this point? 

Proxies

A proxy forwards requests on your behalf. Think of your HOA, yes I know it hurts, but if they have a vote and you cannot go, what do you do? You may "trust" your neighbor to vote and represent you at the meeting, but you cannot ensure they will act in your best interest and vote for the things you would want. Let's say during the meeting, your neighbor, with a proxy form, votes on your behalf on something you do not want; can you take it back after the fact? Generally, no. Proxy services work in a similar way; how do you trust the proxy service will route/process your original request in the scope of what you asked for? The simple answer is you have no control over what they do. Do proxy services have a BBB rating score or similar validation/accreditation process? No. Should they? Yes. What if they simply cannot process the request due to errors and omissions? How can you ensure your traffic is not being monitored when the proxy provider could be tampered with on the backend? You can't.

VPNs

Unlike a proxy, a VPN becomes an extended connection from your origin connection across the levels mentioned above. You can chain these levels, but each level simply inherits all the problems already existing at that level. As a different level of anonymity is perceived to be achieved, we often forget that we are never truly anonymous. VPN's are commonplace within IT; it's cost-effective and repeatable to implement. VPN providers are now common in our landscape and it is difficult to accurately determine who is using a VPN provider. Although it is possible to identify VPN providers and the IP blocks assigned by organizations such as ARIN, and its global counterparts, any user can make a VPN link to anywhere else either through a Cloud Provider or the use of “black hat” techniques. With users either creating VPN services for themselves or opening the service freely for others, we must measure the difficulty of pinpointing activity within services that offer “hiding within the noise” or “redirection of original requests.” 

VPN providers, with claims of bulletproof hosting, are popular for researchers and black hats alike, due to the perception that they are resistant to warrants when compelled to identify user activity. Often, operators of these services that do not willingly collaborate with law enforcement are taken down with physical raids (not the disk drive kind) and electronic redirection. Is it worth it? Probably not. Do some VPN providers have 100% guarantees about integrity and confidentiality? If they claim this, they better operate on some non-existing governed land-mass since any VPN provider attributed to black hat activity will ultimately either “open the books and cooperate” or close - forcibly.

Understanding Attribution

Because of these misconceptions, we as an industry should break down the attribution process into different levels to help govern ourselves without sacrificing the integrity of our offerings related to privacy expectations while following legal principles.

Attribution of origin, or your entry point to the Internet, is generally the first technical challenge related to masking a users presence on the net. Your initial entry connection to the Internet is generally attributable to you or your company and therefore additional connections are needed to mask your origin, while adhering to legal requirements. For example, you can argue that using an open Wi-Fi at a coffee shop is sufficient to mask your origin since your connection to the net is now attributable to the coffee shop’s ISP. For some, this may be enough, however for sustained operations having a large dependency of the stability and availability of the coffee shop’s ISP is undesired and therefore the technical process to use your existing origin connection to mask your presence on the net requires some familiarity with networking technologies. 

To help bring awareness to origin of connections in relation to attribution, I propose the use of levels of disassociation (LOD) in order to illustrate how a user can become disassociated from origin through the use of proxies and VPNs in conjunction with combinations of network hops to become disassociated from a true origin connection.

Levels of Disassociation vs. Non-Attribution

I consider that an open request for comments (RFC) for classifying disassociation levels based on origin is necessary due to market confusion and a general misunderstanding of how users and services can become disassociated. It would help our industry if we provide feedback to an open RFC with the purpose of clearly defining what constitutes disassociation levels based on origin of connection in relation to services used to mask a users origin. Currently, no such model exists. An RFC could help define an industry standard of the technical requirements for redirection and disassociation by detailing how the infrastructure provides multi-hop redirection and obfuscation of true origin of a connection as it traverses multiple services or providers.

Level 0: True Self or “This is You”

To start, we all have some attributable connection to the Internet. This could be a commercial/residential line, which you presumably pay for in  your real name or real company name and is simply tied to your account. An example level 0 scheme: You pay for Internet access and regularly use the Internet for personal/business purposes.

Level 0 is the direct DOD/government or personal origin line (BLUE) which is usually attributable directly to the end-user or the organization. Using services like Tor, a proxy, or a VPN directly from IP space attributable to the DOD can offer some improvements to anonymity, but it provides few protections when the individuals or providers of these services begin to analyze origin connections to their services and can determine “this is DOD” simply based on origin IP addresses. In this case, the use of Tor (light gray in scheme diagrams), a proxy service (dark gray) or a VPN (black) simply becomes a modifier to level 0, and thus we should standardize how we label and present actual communications, redirection, etc. At level 0, your origin connection is logged by all of these services when connections are initiated, in some way, and thus masking the users origin is difficult since the origin connection has been shared through the use of these services. Given restrictions on VPNs within the DOD, and the acquisition process to purchase said services, DOD operations at Level 0 with modifiers are seldom and perhaps unobtainable. 

Level 1: DOD-affiliated Origin

Since Level 0 provides no disassociation of origin when using Tor, proxies, or VPNs, the origin of connection is generally contracted out to a DOD-affiliated company through a contract which provides a new origin of connection and a non DOD IP space. Like Level 0, the DOD (blue) uses a DOD contractor (green) to help disassociate. The use of a DOD affiliated origin to the DOD Contractor line adds an interesting problem not discussed yet: “crossing the green mile.” Let’s say DOD contracts a line to Contractor A and also contracts Contractor B for another line. Level 1D would be the result of chaining a line from Contractor A and Contractor B.  In this case, using a DOD Contractor to go to another DOD Contractor adds no value towards disassociation, besides generating more money for the involved contracting companies. “Crossing the green mile” should be avoided at all costs.

Level 2: DOD Contractor to Non-DOD Contractor or Private Company

At Level 2, we begin to move closer to true anonymity. It is important to note that none of the level classifiers, such as 2A, can account for data-tampering in transit, eavesdropping, or malicious redirection performed by the providers. This presents an interesting risk that increases as attributable actions become recognized by the system owners. At Level 2, a DOD contractor has purchased access to a non-DOD company line as themselves and have now disassociated the origin connection of the DOD customer by two levels. This is generally a sufficient level of disassociation where the use of level modifiers can help protect the origin of connection even further, thus providing some level of anonymity and privacy of the origin connection.

Level 3: DOD Contractor to Tor to Non-Contractor or Private Company

Level 2 is generally simple to perform; however, the attribution of origin becomes more difficult when redirection is performed in conjunction with Tor. In this case, Level 3 could offer better protection for sustained communications by sacrificing speed. Another interesting aspect of this level is Tor traffic works over TCP, so UDP traffic is not generally simple to route over Tor. To overcome this, by connecting Tor to a non-contractor VPN for example (Level 3B), UDP functions become available again since you are encapsulating traffic within the VPN. In this case, Level 3B offers three levels of disassociation between your origin connection and your intended destination.

By combining the previous levels, a company can accurately state they truly offer some form of non-attribution. Simply put, no one can accurately determine origin by network traffic alone following this model. The model does not safeguard against other attributable activity, such as TTPs, that could facilitate a determined responder or investigator attributing activity based on habits or patterns on the recipient side.

Level 4: Sanctioned Activities

Disassociation at Level 4 is perhaps the most difficult level to explain, for various reasons. Stakeholders operating at this level and beyond are restricted by authorities and approvals beyond the scope of this document. This limits the firing capacity, range, and utilization of the resources due to restrictions of use.

Non-attribution of Origin

The proposed levels of dissociation can help buyers and sellers of infrastructure explain how disassociation of origin is possible through the use of modifiers within each respective level. However, it does not help bridge the gap between what the customer actually needs in relation to the multiple options presented at each LOD. For example, I have heard government customers “need non-attribution” to disassociate activity based on the perception of the following:

1. Non-Government origin

2. Non-US origin

3. Non-contractor origin

4. Non-commercial provider origin

Requesting a non-attributable connection generally falls into an area of language confusion where perhaps a customer is asking for disassociation using the blanket term “non-attributable.” The actual requirements a customer has could be to disassociate traffic into one or more of the aforementioned items and thus the requirement for disassociation is much simpler versus building and procuring a non-attributable line. 

Conversely, a commercial entity may use non-attribution to conduct market research against competitors using one of three options:

1. Not attributable to us as a company (90% of the times)

2. Not geographically the same as us or intended recipient

3. Not possible to traceback what so ever (non-attribution implied)

It’s interesting to think that market research would ever require the third option since they already make assumptions that the competitor in question has their OPSEC process so well established that they also have a personal law enforcement connection to help unmask the originating company. 

We have covered a lot of ground here without necessarily addressing some key issues. Let’s break down some technical/tradecraft challenges before we go further:

• We overstate or inflate the need to have non-attribution to account for uncertainty and doubt

• We doubt that our systems, our team, and our efforts will work as intended

• We doubt consequences related to poor OpSec and Tradecraft

• We would rather err on the side of caution vs react to issues related to attribution

• We believe we need to be anonymous to even conduct simple research

• We are unsure what happens when the desired redirection infrastructure fails

  • Does the backend alert the user?

  • Does the backend prevent the request?

• Do we really need to concern ourselves with blowback from public attribution?

Based on experience in this space, I often hear conflicting requests that make non-attribution difficult:

• Desired features versus measurability of performance

• Access/deployment speed needs to be fast

• DNS resolution needs to be stable and anonymized to prevent DNS leakage

• Access needs to be stable and perhaps even self-repairing/self-deploying

• The process needs to be portable

• Everything needs to be simple to use 😊

Here is where the line blurs. 

Example of implementation:

Company A makes another company, Company B (dummy company) that operates somewhere else and exists only to provide access to the customer from Company A. The company may or may not have a skeleton crew and may even generate legal revenue.

Bad example of implementation:

Company A hires another company, Company B (real company) to provide non-attribution. Company B assures Company A that communications are now non-attributable to them since communications are now mixed with Company B traffic. I call this “walking the green mile” since this equates to contracts and blind trust.

The “bad example” not only jumped the shark but also potentially ignored the steps needed to develop and validate the non-attribution as a Service (NAaaS) model. Simply redirecting Company A’s traffic with Company B fails to function if we carefully examine the following:

Does Company A and Company B have public information such as contracts, PR releases? This creates the risk of  attribution by putting information together and “following the money” by understanding financial relationships in relation to goods and services purchased.

Does Company B offer Non-attribution services Publicly? This creates the risk of attribution through marketing where the advertisement of services provides a strong signal of intent and could be a good indicator that Company A is attempting to limit or hide some activity for whatever reason.

Does Company B have multiple satellite offices worldwide with no defined use? This creates a risk of attribution by unexplained expansion where simply having satellite locations worldwide without explaining why they are operating at that location can suggest that the office is simply a front of some sorts.

Does Company B have a sole purpose to support covert and clandestine organizations? The risk presented by attribution by secrecy is perhaps difficult to summarize yet some companies simply exist and have one customer base.

Conclusion

To overcome and determine what level of attribution is necessary, ask “what are you concerned about?” Overstating the fact that less is more and is often less expensive in terms of progressing through different levels of disassociation in this proposed scale could help address valid concerns. The result is always the same; given potential blowback versus budget, do you truly understand what you are asking for regarding what you want to use non-attribution for? Without transparency from vendors and a better informed industry clientele, we will keep perpetuating false assumptions of risk controls with snake oil. 

Download this article here.

Magazine Home | About CYBER | Author Guide | Masthead | Archive Articles