This page is an explanation and proof of concept (POC) of a cross-site request forgery vulnerability (CSRF) identified by Free Law Project while gathering data from the PACER websites.
What this Vulnerability Allows
This vulnerability allows any website to use a visitor’s PACER account (their cookie) to download content from PACER including docket reports and PDFs. We also believe it allows a malicious website to upload documents to the ECF website, though this is harder to demonstrate without a testing account.
There is no limit to the number of purchases that could be made while exploiting this vulnerability, and uploaded documents could create innumerable problems for the parties, courts, and The Administrative Office of the Courts.
For users of PACER, unpaid fees can result in damage to their credit, and debt collectors sent to their door at the behest of the AO. They would never know why their PACER bill skyrocketed.
For attorneys using ECF, they would likely assume that their password had been compromised, since new filings would be appearing under their name. No amount of resetting their password would solve the problem.
For courts, misfiled documents would wreck havoc on their smooth operations, as lawyers claimed they had no idea why a document had been filed in their name.
For the Administrative Office of the courts, this vulnerability could create chaos in their billing department, and could badly damage the reputation of the organization.
Is this Vulnerability Already Being Exploited?
It’s quite possible this vulnerability is being exploited in the wild.
The most difficult part about CSRF vulnerabilities is that, when exploited, they look like normal traffic. Illegitimate requests to the PACER servers would come directly from the user’s browser, not from a centralized location that could be blocked or identified. The only way that PACER would know whether this vulnerability was being exploited is on the billing side, or if users were otherwise consistently complaining about unauthorized account usage. Even then, there would be no way to identify what website was using the CSRF vulnerability, and thus no way to quickly stop it.
Update for technical error: When exploited, CSRF vulnerabilities can be identified by using the
Referer headers of the traffic coming in. However if the AO is not monitoring that traffic — which is common — the only time they would know whether this vulnerability was being exploited would be on the billing side when users complained about unauthorized account usage. At that stage, they might connect the dots and review the
Referer logs, but it’s not an obvious jump unless a flood of complaints were coming in.
How this Vulnerability Works
CSRF vulnerabilities work because one website can make requests to another website. By default, such requests are made using the cookies for the second website. In practice, these requests must be blocked or explicitly authorized or else CSRF vulnerabilities like this one will occur.
How to Fix this Vulnerability
CSRF vulnerabilities are typically solved by including a unique token in every
POST request that is made to a server. Then, when the server receives the token, it can verify whether the request was legitimate.
This technique is used throughout the web. Without it, I would be able to make transactions on your Paypal account, move money from your bank to mine, or send emails on your behalf.
Much more detail on the solutions to CSRF issues can be found at this link.
Proof of Concept (POC)
For this POC to work, you must be logged into the PACER Training website. This way, no financial transaction occurs during the POC. The login page for the training site is here (note the user/pass are printed on that page):
Log in using the link above before continuing.
In practice this exploit would work against anybody logged into any NextGen PACER website.
Once you are logged in to the training site, clicking the button below will download a PDF from PACER to your browser using the training login credentials. Note that in a real exploit, we would not use the training site, and there’s no reason that a user would need to click something or that they would even know anything happened.
Click this button to exploit the CSRF vulnerability:
2017-02-17 Notification by Free Law Project with 90 day deadline for fix.
2017-02-22 Acknowledgement by AO staff.
2017-04-18 AO sends email to new developer email list with details of change and with BCC to Free Law Project.
2017-05-10 Ten days before deadline, Free Law Project checks in to see if fix will be in place. AO states that “it will likely come down to a few courts.”
2017-05-18 Deadline for fix.
2017-07-27 Free Law Project checks in again to ensure that all courts are resolved. AO states that all sites are not fixed. Free Law Project proposes new deadline of 2017-08-06.
2017-07-31 Hearing no response, Free Law Project asks again about proposed deadline.
2017-08-03 The AO responds that 186/204 of the PACER/ECF sites have applied the “hotfix” and that the remainder should be done by 2017-08-06.
2017-08-07 AO reports that they are working through last few issues.
2017-08-08 AO reports that Guam and two other jurisdictions are installing that night.
2017-08-09 AO reports that the vulnerability is resolved at all jurisdictions.