Summary The research for this post was done sometime in January of 2022, I was diagnosed with Cancer in February of 2022, and have been struggling to find to the time to finally post it. Much of it was written in chunks, so hopefully it makes sense. In this post I will talk about what led me down the path of researching the security of IoT digital picture frames. My research on these picture frames and supporting mobile application led to the creation of four CVE’s. The vulnerabilities I discovered allowed me to access client information, clear-text credentials, bypass authentication and access controls of the frames.
Merry Christmas Mimi! During our annual brainstorming of Christmas gift ideas for my wife’s elderly grandmother, we thought a digital picture frame would be perfect. Mimi is 94 years old, and lives in a local nursing home. Covid has made it difficult for family to visit her and for her to leave the home as much as she used to. We decided to look for a picture frame that would allow us to frequently send pictures of what the family is up to outside the walls of the nursing home. We researched different brands and functionality. We decided we wanted a wifi enabled picture frame, that would allow multiple family members to send photos to it.
Focusing on the Settings area It was apparent that this picture frame was a blackbox with little to no troubleshooting or audit information to offer end-users. The “User Management” area showed all the family members that I had added to the picture frame, and a built-in administrator account that came on the picture frame. The process of adding a person requires that you bind your account in the Ourphoto mobile application to the picture frames unique frame id. Once a request has been made to bind to the picture frame, you must use the physical frame to accept the request through the touch screen. My current theory was that the built-in administrator account on the frame has sent the photos of the women in error and it was clearly some bug/glitch in the back-end api or infrastructure.
The first thing I checked was the presence of an Insecure Direct Object Reference (IDOR) with my user_id number. I took my unique number and decreased it by 1 number. For example, if my number was 123456, I changed it to 123455. This seemed to fail as I hoped it would.
Time to make some more coffee While finding these vulnerabilities is great, my goal is to figure out how these random photos ended up on the picture frame. I still didn’t prove or disprove my theory that the built-in admin account sent the photos to the frame. The problem was lack of information. I had a good understanding of how the mobile application worked, and interacted with the back-end api, but little to no information on how the picture frame itself interacted with the back-end api. It was time to see if I could capture web traffic from the digital picture frame itself.
Lastly, I joined the digital picture frame to the “iot-test” wireless access point I created and all the web traffic from the frame started passing through the proxy tab. Booyah!
So, binding my user account through the Ourphoto mobile application to someone else’s picture frame is no problem. No let’s look at accepting that bind request on the picture frame without having physical access to it. When the request comes it to the picture frame it looks like the screenshot below.
Once the user clicks on the “Accept” button, the picture frame issues a web request to the /device/AcceptBind endpoint. This end-point also does not require authentication, and only requires the user_id and device_id for information. We have both pieces of information needed to accept our own bind request.
So, I ran through each step of sending a request to each end-point and I was successfully able to bind my user account through the Ourphoto mobile application to my digital picture frame without ever having to hit “Accept” on the screen. I’d also like to note I was also able to unbind or remove my account from the digital picture frame without having to click “Remove” from the “User Management” area. So technically, I could bind to someone else's picture frame, upload a photo, and remove myself from the frame without anyone knowing I did so.
I confirmed that if I spoofed an email address that was added to my frame, I could send pictures to the frame without any roadblocks. I ended up discovering that the subject line in the email which is supposed to contain the unique device_token is ignored. If I sent an email to the picture frame email address from an authorized email account with any subject line, the picture would make it to the frame. It would be easy for an attacker to scrape every authorized email and every unique frame email from the api, then send an email with the same picture to all the email addresses. I was thinking in terms of political messages, advertisements, or nefarious pictures.
Found it!!! After reviewing all the log files and understanding their contents, I found what I was looking for. I made a list of the user_id numbers that belong to all the family members I had originally added to the picture frame. I then used grep and awk to look for user_id’s that weren’t in my list. That is when I got a hit on a user_id that was not in my list. The log entry provided the sender_id, sender_name, filename, url, sender_platform and some other information. On Sunday, January 16, 2022 at 7:50:17 PM a user sent the first picture to mimi’s picture frame via email.
You can see in the log information that the “senders_platform” was email. This was interesting because I didn’t authorize any of the family members email on the frame, just the mobile application. I looked up the user_id number against the api and found that it belonged to the built-in admin account I referenced in my original theory. The “url” parameter was interesting because it appeared to be a content delivery network address where the photo was uploaded before it hit the frame. Was this photo still available? Yup, it sure was. I found the random women whose picture showed up on mimi’s picture frame.
I decided to do a factory reset on the frame and to make sure nothing weird was going on with the built-in admin account. I used the option in the settings area of the user interface and waited for it to reboot. When it rebooted, I was greeted with a surprise. A setup menu for the frame I had never seen before. I thought that was interesting. I followed the new setup screen. Part of this setup was to provide a username which I had never seen before. When I completed the factory reset I found that the username I provided during setup was now the admin user account on the device. The admin account I now created was named differently than the built-in admin account I had been seeing before. This meant the admin account that came on the frame device was not setup by me, it was already on the device when I pulled it out of the box.