A couple of years ago, Equifax was breached and huge tracts of data were dumped. The Equifax CEO and other leadership dumped a bunch of stocks days after discovering the hack and a month prior to the announcement for "unrelated reasons" (yeah, right). The apology by the CEO for the data breach rang hollow with everyone and he eventually stepped down with a $90 million USD golden parachute. The breach was partially caused by lax policies regarding keeping the software running on their servers up to date. But no one in the software security industry was shocked that any of this happened - it's the same old story of greed, lax security policies, and not regularly pentesting infrastructure.
The news this week is covering the landmark FTC settlement with Equifax and a page on the FTC website has been set up that links to the Administrator website for the claim proceedings:
https://www.ftc.gov/enforcement/cases-proceedings/refunds/equifax-data-breach-settlement
The destination website is NOT a government website (i.e. not .gov) and is run by JND Legal Administration. When it comes to Personally Identifiable Information (PII), I take data management extremely seriously so there are warning signs to watch for that most people won't pay attention to. These indicators reveal whether or not a company is actually up to the task of managing PII data. I tend to first look at who is behind a website and then start picking apart the site itself. The first warning sign to me is that JNDLA doesn't appear to have a public GitHub account. Therefore, I can't really start there to see if their website developers are any good at software development. So let's look first at who JND Legal Administration is. The only link from the domain set up specifically for the settlement administration back to their company is the Privacy Policy.
From there, I went to the About Us page to see what they think about themselves: https://www.jndla.com/about-us "Ours is the most seasoned executive management team in the business. With this leadership, our record-setting case settlement history, and superior technology, we guarantee that no other company can provide more successful client delivery."
Wow. And "Superior technology?" Do they have their own hardware fab in their back office and make their own equipment? Probably not. In fact, as I show in a bit, they use Azure and AWS - i.e. they really just use the same tech as everyone else. And the leadership they are so proud of on that page has created a culture of dismissiveness within the company, according to Glassdoor. Pride (and arrogance) goes before the fall and all that.
Properly setting up a new domain and website takes time. A cursory analysis of their main website and the settlement website indicates a hurried and thrown together bunch of pages that are Bootstrap-based. The web development team may be a bit stressed to get things done right now, rather than get them done right. Bootstrap alone is always an indicator of "needed to throw something together quick instead of doing it right." But there are basic HTML errors on various pages on their websites, which also indicates they are doing things under pressure and hand-coding to some degree. When people are under pressure to perform, they tend to miss things - which is good for hackers, bad for PII data management. Looking at the source code for the pages on the settlement website, several things of significant concern also popped up:
Bootstrap CDN
Google jQuery CDN
ASP.NET jQuery plugin CDN
Google "invisible" reCAPTCHA (eligibility checker)
Google Analytics
Google Tag Manager (for Google Ads)
Facebook Pixel (used for ads)
Twitter tag code
Microsoft Advertising UET tag tracking code
In this instance, Ghostery blocks the requests to the advertising and tracking services but not the CDNs or reCAPTCHA. However, none of those things in that list belong on webpages that will be handling sensitive PII data, especially SSNs and associated contact info. For example, if reCAPTCHA is involved, it should only be found on an entry portal page but not any pages that actually collect PII data. Everything about the code feels cookie-cutter and rushed, which again feeds back into the reported corporate culture at JNDLA.
Next, I just threw a few random URLs at the wall to see what would happen:
https://www.equifaxbreachsettlement.com/index.php
https://www.equifaxbreachsettlement.com/blahblah/index.php
Which return the expected 404 and a plain "Not Found" message. Unexpected though was the ~500ms turnaround to return that information the first time it was requested and then about 20ms after that. So something is probably hitting a database the first time for a page request and then caching the response for future requests. Since a single request for a 404 takes 500ms, that's maybe 400ms of CPU on the backend per request even for 404 errors. It's also useful to note that the actual eligibility checking and claim filing bits are happening on entirely different subdomains and hosts from the rest of the website. Pinging the domains reveals that 'www.equifaxbreachsettlement.com' is indeed hitting CloudFront (AWS), which explains the earlier behavior, while 'eligibility.equifaxbreachsettlement.com' and 'secure.equifaxbreachsettlement.com' reside over in Azure.
Actually, I was able to figure out what CMS they are using for the backend. They link to a set of PDFs here:
https://www.equifaxbreachsettlement.com/documents
The PDFs follow this URL scheme:
https://www.equifaxbreachsettlement.com/admin/services/connectedapps.cms.extensions/1.0.0.0/5e30940d-7e11-4b49-b115-6d89a16c0e3f_1033_EFX_-_Final_Claim_Form.pdf
(Love the title of that PDF: "Microsoft Word - EFX - Final Claim Form" Which tells us they just lazily exported the document from Word.)
But we get enough information from the URL. A search for "connectedapps.cms.extensions" turns up related SDK documentation for https://www.connectedapps.com/, which appears to be their backend CMS. If I were an attacker, Connected Apps would be my target instead of going after JNDLA directly because Connected Apps looks woefully unprepared for a real attack.
Sensitive PII data has to be handled with extreme caution. So far, I'm not impressed. As mentioned earlier, there are a bunch of unnecessary third party services on the same pages that also handle sensitive user info. When handling PII data, it needs to be done in complete isolation from the rest of the Internet and that means self-hosting everything with zero third-party dependencies in the content emitted from the server. Very obviously not the case here.
JNDLA's Privacy Policy is what really takes the cake for me. From: https://www.jndla.com/privacy-policy
"D. Security
Protecting the security of PII is very important to JND. When PII is transmitted to JND, it is protected by redundant firewalls (hardware and software which helps keep unauthorized visitors from accessing information within JND’s computer network), as well as industry standard SSL/TLS (Secure Socket Layer/Transport Layer Security) encryption. Once JND receives a transmission, JND will take reasonable precautions to keep that information secure on its systems. Nevertheless, no data transmission over the Internet may be guaranteed to be 100% secure. JND, therefore, cannot warrant or guarantee the security of any PII transmitted to JND online, or be responsible for the theft, destruction, or inadvertent disclosure of that PII."
I read that as, "If you file a settlement claim online and/or use the online eligibility checker, we will gather your information into a database and if THAT database leaks then we are not responsible for it." The $125 you might get for the convenience isn't worth that bunch of hogwash. Equifax tried to pull the "we're not responsible" stunt after THEIR database was leaked so why should this situation be ANY different? JNDLA is clearly focused on firewalls and TLS for PII data management but not the actual protection of the PII data itself and those things didn't help Equifax either. It's been proven time and again in data breaches that security only happens when done in-depth (aka defense in-depth). Firewalls and TLS, while important, don't actually protect PII data. (BTW, please don't use any information provided in this post to go and hack JNDLA or their vendors, because that's illegal.)
PII data is best treated as a write-only (if necessary), heavily audited funnel, not a "SELECT * FROM table". An example of how to do it right: I, as a user, know something about myself and submit it. A backend PII system deep behind a set of firewalls that knows the same information but is set up such that database can't be directly accessed through any of those firewalls. Instead, it presents an internal API that performs the query on behalf of the application and responds as to whether or not the information submitted is correct (ideally there are no open ports at any firewall layer and simply responds with true/false responses). The backend PII data API is strict in the data it retrieves and limits what it sends back and prefers confirmation only (i.e. true/false). When actual data is sent back, each row of data that is returned is carefully audited in a log and only the absolute minimum data is ever returned. If JNDLA has nothing to hide (i.e. their security actually passes muster), then their backend PII server source code for the two critical sites should be publicly viewable on GitHub - minus security access keys/tokens, of course - and linked to from the FAQ on the settlement site. For all we know, the database sits on or is immediately adjacent to the servers themselves, which is always the wrong way to manage PII data.
Superior technology!!!!!11`1!
The news this week is covering the landmark FTC settlement with Equifax and a page on the FTC website has been set up that links to the Administrator website for the claim proceedings:
https://www.ftc.gov/enforcement/cases-proceedings/refunds/equifax-data-breach-settlement
The destination website is NOT a government website (i.e. not .gov) and is run by JND Legal Administration. When it comes to Personally Identifiable Information (PII), I take data management extremely seriously so there are warning signs to watch for that most people won't pay attention to. These indicators reveal whether or not a company is actually up to the task of managing PII data. I tend to first look at who is behind a website and then start picking apart the site itself. The first warning sign to me is that JNDLA doesn't appear to have a public GitHub account. Therefore, I can't really start there to see if their website developers are any good at software development. So let's look first at who JND Legal Administration is. The only link from the domain set up specifically for the settlement administration back to their company is the Privacy Policy.
From there, I went to the About Us page to see what they think about themselves: https://www.jndla.com/about-us "Ours is the most seasoned executive management team in the business. With this leadership, our record-setting case settlement history, and superior technology, we guarantee that no other company can provide more successful client delivery."
Wow. And "Superior technology?" Do they have their own hardware fab in their back office and make their own equipment? Probably not. In fact, as I show in a bit, they use Azure and AWS - i.e. they really just use the same tech as everyone else. And the leadership they are so proud of on that page has created a culture of dismissiveness within the company, according to Glassdoor. Pride (and arrogance) goes before the fall and all that.
Properly setting up a new domain and website takes time. A cursory analysis of their main website and the settlement website indicates a hurried and thrown together bunch of pages that are Bootstrap-based. The web development team may be a bit stressed to get things done right now, rather than get them done right. Bootstrap alone is always an indicator of "needed to throw something together quick instead of doing it right." But there are basic HTML errors on various pages on their websites, which also indicates they are doing things under pressure and hand-coding to some degree. When people are under pressure to perform, they tend to miss things - which is good for hackers, bad for PII data management. Looking at the source code for the pages on the settlement website, several things of significant concern also popped up:
Bootstrap CDN
Google jQuery CDN
ASP.NET jQuery plugin CDN
Google "invisible" reCAPTCHA (eligibility checker)
Google Analytics
Google Tag Manager (for Google Ads)
Facebook Pixel (used for ads)
Twitter tag code
Microsoft Advertising UET tag tracking code
In this instance, Ghostery blocks the requests to the advertising and tracking services but not the CDNs or reCAPTCHA. However, none of those things in that list belong on webpages that will be handling sensitive PII data, especially SSNs and associated contact info. For example, if reCAPTCHA is involved, it should only be found on an entry portal page but not any pages that actually collect PII data. Everything about the code feels cookie-cutter and rushed, which again feeds back into the reported corporate culture at JNDLA.
Next, I just threw a few random URLs at the wall to see what would happen:
https://www.equifaxbreachsettlement.com/index.php
https://www.equifaxbreachsettlement.com/blahblah/index.php
Which return the expected 404 and a plain "Not Found" message. Unexpected though was the ~500ms turnaround to return that information the first time it was requested and then about 20ms after that. So something is probably hitting a database the first time for a page request and then caching the response for future requests. Since a single request for a 404 takes 500ms, that's maybe 400ms of CPU on the backend per request even for 404 errors. It's also useful to note that the actual eligibility checking and claim filing bits are happening on entirely different subdomains and hosts from the rest of the website. Pinging the domains reveals that 'www.equifaxbreachsettlement.com' is indeed hitting CloudFront (AWS), which explains the earlier behavior, while 'eligibility.equifaxbreachsettlement.com' and 'secure.equifaxbreachsettlement.com' reside over in Azure.
Actually, I was able to figure out what CMS they are using for the backend. They link to a set of PDFs here:
https://www.equifaxbreachsettlement.com/documents
The PDFs follow this URL scheme:
https://www.equifaxbreachsettlement.com/admin/services/connectedapps.cms.extensions/1.0.0.0/5e30940d-7e11-4b49-b115-6d89a16c0e3f_1033_EFX_-_Final_Claim_Form.pdf
(Love the title of that PDF: "Microsoft Word - EFX - Final Claim Form" Which tells us they just lazily exported the document from Word.)
But we get enough information from the URL. A search for "connectedapps.cms.extensions" turns up related SDK documentation for https://www.connectedapps.com/, which appears to be their backend CMS. If I were an attacker, Connected Apps would be my target instead of going after JNDLA directly because Connected Apps looks woefully unprepared for a real attack.
Sensitive PII data has to be handled with extreme caution. So far, I'm not impressed. As mentioned earlier, there are a bunch of unnecessary third party services on the same pages that also handle sensitive user info. When handling PII data, it needs to be done in complete isolation from the rest of the Internet and that means self-hosting everything with zero third-party dependencies in the content emitted from the server. Very obviously not the case here.
JNDLA's Privacy Policy is what really takes the cake for me. From: https://www.jndla.com/privacy-policy
"D. Security
Protecting the security of PII is very important to JND. When PII is transmitted to JND, it is protected by redundant firewalls (hardware and software which helps keep unauthorized visitors from accessing information within JND’s computer network), as well as industry standard SSL/TLS (Secure Socket Layer/Transport Layer Security) encryption. Once JND receives a transmission, JND will take reasonable precautions to keep that information secure on its systems. Nevertheless, no data transmission over the Internet may be guaranteed to be 100% secure. JND, therefore, cannot warrant or guarantee the security of any PII transmitted to JND online, or be responsible for the theft, destruction, or inadvertent disclosure of that PII."
I read that as, "If you file a settlement claim online and/or use the online eligibility checker, we will gather your information into a database and if THAT database leaks then we are not responsible for it." The $125 you might get for the convenience isn't worth that bunch of hogwash. Equifax tried to pull the "we're not responsible" stunt after THEIR database was leaked so why should this situation be ANY different? JNDLA is clearly focused on firewalls and TLS for PII data management but not the actual protection of the PII data itself and those things didn't help Equifax either. It's been proven time and again in data breaches that security only happens when done in-depth (aka defense in-depth). Firewalls and TLS, while important, don't actually protect PII data. (BTW, please don't use any information provided in this post to go and hack JNDLA or their vendors, because that's illegal.)
PII data is best treated as a write-only (if necessary), heavily audited funnel, not a "SELECT * FROM table". An example of how to do it right: I, as a user, know something about myself and submit it. A backend PII system deep behind a set of firewalls that knows the same information but is set up such that database can't be directly accessed through any of those firewalls. Instead, it presents an internal API that performs the query on behalf of the application and responds as to whether or not the information submitted is correct (ideally there are no open ports at any firewall layer and simply responds with true/false responses). The backend PII data API is strict in the data it retrieves and limits what it sends back and prefers confirmation only (i.e. true/false). When actual data is sent back, each row of data that is returned is carefully audited in a log and only the absolute minimum data is ever returned. If JNDLA has nothing to hide (i.e. their security actually passes muster), then their backend PII server source code for the two critical sites should be publicly viewable on GitHub - minus security access keys/tokens, of course - and linked to from the FAQ on the settlement site. For all we know, the database sits on or is immediately adjacent to the servers themselves, which is always the wrong way to manage PII data.
Superior technology!!!!!11`1!
Comments
Post a Comment