Introducing System Bus Radio

This new project transmits radio on computers without radio transmitting hardware.

I am releasing it publicly now, and it is based on the recent RAMEAR project.

This is (yet another) TEMPEST / exfiltration project that allows you to transmit data from an air gapped computer. The cool thing is that it works without any additional hardware, and can be received using off-the-shelf radio receivers.

Here is the project page

Slashdotted at


Trust is the biggest threat to privacy & security

Part of the reason I trust Google is because I assume that people who work there have values like me. If unethical marching orders came in one day then engineers might resist them or one person might leak it. It took just one technician to blow the lid off of Room 641A. Google's past record of exiting mainland China because of Chinese spying should illustrate the commitment of Google to its users. This serves as an effective deterrent to people that might think of coercing Google to abuse its power. (Let's ignore the fact that Google did NOT leave the US market when the NSA tapped its server room interlinks.)

Unfortunately, this is not enough. The biggest risk to privacy and security is trust itself. The FBI / Apple case has made obvious that Apple has the ability to collect information from iPhones (before 5s). The effort would be herculean, but is it possible.

Bo Xilai is a political dissident in China and was jailed by premier Xi Jinping for conspiring to take over the national party. The level of assurance provided by Apple's iPhone 5c was not enough for Mr. Bo to conduct his operations. It is assumed that Apple's 5s and on are beyond even the reach of Apple.

In summary, when considering the privacy and security assurances of a system, it is usually the human element or the implementation details that are weakest. This can be quantified with the "ransom factor": 
How many people would need to be served National Security Letters, served with All Writs Act injunctions or have their children taken ransom would it take to break the system?


Internet Marketing Ninjas client report vulnerability


William Entriken and Internet Marketing Ninjas worked together the week of December 7th, 2015 to find and correct a data enumeration vulnerability on IMN's client reporting system.

Following is the dashboard which IMN clients can use to see information related to their account.

Additionally there is a view where clients may see the results of linkbuilding efforts by the company.

This website uses AJAX heavily to refresh and deliver reporting content to the user. It is possible to recreate these requests using a command line interface. (Although this may be a violation of IMN terms of service, so don't do it without their permission!)


The following command can be used to download a list of a client's reports. The number ### is the client's ID number. It requires client access to the website, which is given through the Authorization Basic HTTP header. However, the number can be changed to any number to download that user’s account information.

curl -H "Authorization: Basic XXXXXXXX==" --data "func=reports_list&client_id=###”

Likewise, the following command can be used to download links for that client's site. However, the number ### can be changed to any number to download links for a given account.

curl -H "Authorization: Basic XXXXXXXX==" --data "func=links_report_url_all_download&client_site_id=###"


The risk is that this command can be surreptitiously issued for each number. This would produce IMN's entire client list and all reports created for any client. This vulnerability applies to any client or other user with access to the IMN system. I have not reviewed any other potential vulnerability and there may be other risks.


Another part of the client reporting system, accessible at the /report-files/ URL is secure from this vulnerability. It is recommended that the same security in use there be applied to the two cases above.



Full details of this vulnerability were reported to the vendor on Friday December 11, 2015 at 12:45 and the issue was resolved within two hours and fifteen minutes. We consider Internet Marketing Ninjas' response time to be exemplary. At this time, no evidence has been found to suggest that unauthorized access to client data has occurred. There are no remaining known vulnerabilities for client data at this time.


Poor security at OPM

And OPM wonders how the classified records of ALL their security personnel were lost...


ProDPI ordering system leaking private customer information

First draft 2015-07-01: Reviewed with ProDPI COO Jeffrey Lazo.

Update 2015-07-04: ProDPI has made a blog post at which reasonably notifies customers of the vulnerability. Updated text to reflect this.

Update 2016-07-08: The website is now vulnerable again in nearly the same exact way.


ProDPI is a photo lab which is marketed to professional photographers, specifically wedding photographers. I have used their services in the past.

Technical Overview

ProDPI uses several systems for sales, client interaction, and order processing:
  • -- main sales website
  • -- an order tracking and account management system
  • ProDPI ROES -- a downloadable Java "Remote Order Entry System" system for uploading
  • -- backend server for ROES
  • -- backend server for ROES
  • -- backend server for ROES

The Vulnerability

When accessing the website to review an order, you must be logged in to access any data. However, once logged in, you are able to access billing data from another user's account. A URL for accessing my invoice it at:


However, you are able to modify the number in the URL to access the invoice from a user account which is not yours.

The vulnerability is a user information enumeration attack. It would allow a person to download the contact information (name, business name, address) of all clients as well as any confidential pricing information. If you have done business with ProDPI, you must assume that this information of yours has been leaked.


I wrote in with the following letter to announce this vulnerability to the vendor around midnight Eastern Time late Tuesday 23, 2015. It was emailed to the support email address and the company CEO (found via LinkedIn).

I am writing in to note that your entire list of customers is publicly available online. This includes the studio name and their address.

These can be found by logging in then accessing the URL below and then changing the number at the end to all possible order numbers (which are sequential).

This may sound like a tedious task, however, someone with the right expertise would be able to download all such orders with no more than 5 minutes of effort. (I have not done so. Although others may have already done this.)

I intend to publish this finding on a blog where I discuss security problems with websites. I have set a publication date of July 7, which I believe gives you a reasonable amount of time to fix the problem.

I hope that you are happy to hear this from me, because this will allow you to correct a problem that currently exposes your entire customer list to competitors. After the problem is fixed, I would appreciate if you would give credit to me for finding this by mentioning my name on your blog with a description of what was fixed, and then linking to my blog, which is at Also, if you offer a bounty, store credit or anything else for referring this to you, I would appreciate it.


P.S. If your technical team is not sure how to correct this problem, I am available to discuss this with them. It is a simple fix, I would not charge a fee for this.

William Entriken
WE Design & Consulting
I don't know if my letters are appropriate in asking for a bounty. But I provide these letters in the interest of promoting discussion among security professionals on the topic. Either way, it is definitely appropriate to ask that the vendor fix the problem and inform its users that they were vulnerable. In Europe, of course, data protection laws require it.

The Resolution

The support email / Zen Desk autoresponder replied immediately to note a response time of one business day.

From email quotes, I can see Caitlin Lazo, the CEO, forwarded the message to Jeffrey Lazo, COO and husband, within seven minutes.

Jeffrey replied 39 minutes after my original message to note that the issue has been fixed by temporarily disabling access to invoices. He said it would be secured and brought back online soon. I can confirm this has been done.

ProDPI has made a blog post on its website regarding the potential breach to inform customers that some data may have been compromised.

The Privacy Policy

The ProDPI website privacy policy notes that:
Your personal information is contained behind secured networks and is only accessible by a limited number of persons who have special access rights to such systems, and are required to keep the information confidential. In addition, all sensitive/credit information you supply is encrypted via Secure Socket Layer (SSL) technology.
Previously, "personal information" was defined as:
When ordering or registering on our site, as appropriate, you may be asked to enter your name, email address, mailing address, phone number, credit card information or other details to help you with your experience.
As such by bring this breach to their attention, ProDPI has obliged itself to disclose this to its customers.

Lastly, ProDPI mentions the "California Online Privacy Protection Act". The Act requires disclosure that data breaches such as this should result in notification to customers and posting on the COPPA website. COPPA defines personal information in CAL. CIV. CODE § 1798.80(e) as:
"Personal information" means any information that identifies, relates to, describes, or is capable of being associated with, a particular individual, including, but not limited to, his or her name, signature, social security number, physical characteristics or description, address, telephone number, passport number, driver's license or state identification card number, insurance policy number, education, employment, employment history, bank account number, credit card number, debit card number, or any other financial information, medical information, or health insurance information. "Personal information" does not include publicly available information that is lawfully made available to the general public from federal, state, or local government records.
COPPA may also oblige them to post this incident to their website. However, the disclosure they made on their blog was definitely reasonable in this situation.


ProDPI's technical and business response to this issue was exemplary. They did the right thing (which is difficult!) and properly disclosed the potential problem to their customers, and gave credit. Everyone wins.


Chase Credit Card Privacy Fail -- Email with Transaction Details

If you still use email, you are surely pinged with countless messages to notify you of updated activity on a website that it would like you to come see. Some of them are shameless clickbait, like Slashdot ("Bob sent you a message and you can't see it unless you click here.") Others are classy clickbait, like Facebook ("Sarah told you 'Thanks for the present', click here to see Sarah's page.") These messages are inconsequential and there is minimal privacy risk of sending those message over email, which is usually insecure.

Banking information is another story. Bank eStatements are sent like the Slashdot message above. You are told that a new statement is available, but you must click and login to see the statement. And this is because if they just sent you a PDF then these would get sucked up by anyone monitoring network traffic between the bank's email server, your email server, and your computer. You wouldn't want this, because there's already enough ways that your credit card numbers are getting stolen. (Digressing, I believe this is a conspiracy of the plastic industry to make banks print more cards.)

So it is very surprising to see the following email from Amazon / Chase Visa with a notice to use an updated card they have sent. In an unprecedented and insecure move, they have merged this email with a list of past merchants and purchase dates of places I have done business. Also included is the last four digits of my credit card. This is precisely enough information for someone to call you on the phone posing as a bank and then get your full account number and mother's maiden name ("for your security").

Private financial banking information should only be sent to customers over an insecure medium like email if the users have explicitly requested this and have provided an encryption certificate to the bank just for this purpose.


All Artisan State User-Uploaded Photos are Publicly Accessible

Update 2015-05-15: It appears this one specific issue has been fixed as of today.


Artisan State is a photo printing service that specializes in flush mount books and other photo books. They are managed from San Francisco with fulfillment in Hong Kong and Houston and manufacturing in Shanghai. They have a pretty website and reputation seems somewhere between iPhone-level travel books and professionally-bound books you would get with an in-person event photographer. I was preparing a book for one of my clients and as I am uploading the photos, which are personal, the first thought was... should I really be uploading these photos to this website, we just met?

Just a hint

If you are reading this blog, then you are probably at least a little bit interested in web security. Here is the URL for this page. Now you tell me: what the first thing you would check?
Exactly, right? Following is the result of this URL:

Naturally, this couple probably did not expect that their wedding photos would be online like this. (Note: that URL does not work any more)

Reporting it

I always report these issues to the vendor. And it should go without saying. But responsible disclosure is a hot topic on Slashdot, so we'll be expanding on this. I provided the details and offered to help fix all their issues. Also, it was clear I intended to publish this -- a date was set for 2 months, which is today. The customer support person said they would forward this to engineering and engineering would follow up with me. 

Over the course of 2 months, I replied to note that this is almost fixed (not completely) and asked if there was any bounty or if they would credit me with this finding anywhere. Customer support offered me a $100 store credit (thank you) and would not credit me anywhere (boo). And their engineering not never followed up with me to discuss further, as promised. Also, I speak Mandarin and they have engineering in China, there is no language barrier.

Since my emails are falling on deaf ears and because the (very generous) embargo period has passed, I am posting this live exploit publicly on the internet. Other people have probably already found these items and others. The goal of publishing this is to speed up the fix, provide a case study for other vendors as an example, and allow Artisan State users to know that their seemingly private photos are not secure.

Ethics, responsible disclosure, privacy... the books are still being written on what the right thing to do is. If you hate my guts or support open security research, please share below.

The exploit

There are many attack vectors on this website. The URL scheme above is the most obvious, but not the best. In addition to these project files being susceptible, each image individually is also susceptible.

Here is the URL of one of my photos:
If you are not logged in as me then you have no business accessing that photo. But alas... you can. There is nothing special about that URL, in fact you can access every photo this way. The following command confirms that you have access to a random photo without actually downloading it.
ID=$(php -r 'echo mt_rand(0,8000000);')
curl --head $URL --silent | grep Length
It is not hard to figure out how to edit this command to download all photos. Please don't. Based on how many photos are on Artisan State and the fact that they use Amazon S3, it will cost them about $80 each time you run the edited command. And anyway, the following section (written before this one) shows that this would not be of much interest any way.

The solution to this vector is to either add entropy to each url or authenticate on each image load. Of course there is even a possible solution where the thumbnailing server above does not need to access the database, the files do not need to be renamed, htaccess or cookies are not needed, and security can still be reasonably assured. If you think you have it, discuss in the comments below.


The rest of this article was written before the above minimization technique was found. To demonstrate the problem exists, a random sample of photos was downloaded and then deleted. Because the results are so boring, I believe sharing some details will reduce others' interest in downloading these photos.

Artisan State has about 8,000,000 photos uploaded on this system. (That's how the 800000 got into the code above.)

Here are 64 random photos. To respect privacy, faces are blurred. The goal here isn't to dox anyone.

In general, a majority of photos are wedding-themed. And because this article is being posted to Reddit (where Artisan State is often discussed), I'll answer a few certain questions. No, that girl in the first row is not naked. No, that baby is not CP, nor does anything else seem illegal. Of a random sample of 200,000 photos a reasonable person would not find anything fappable.

In other words, you're not going to uncover any crazy scandal or get much from downloading these photos -- they're just normal people's boring wedding, reunion and vacation photos.

Does hearing this story change your perspective of the vendor? And would you change your mind about placing an order with them?

Slashdotted at