-
-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement digest authentication #199
Comments
Hi @rikosintie ! Thanks for the really detailed issue :) By reading your logs, it seems like everything should be working, yes. As you can see in the logs with the Could you run VLC in your command line with the |
Hello, thanks for the quick response! I can't believe I didn't run vlc with logging. It was right in your FAQ! I am out of town until Friday, As soon as I get home I will do it and post the results. Thanks again for such a great project! |
Thanks and no worries, there's no rush :) We'll figure it out! |
Hello Ullaakut, ->vlc -vv rtsp://aiphone:[email protected]:554/udp/unicast/aiphone_H264 [00007f2e90000980] lua art finder debug: skipping script (unmatched scope) /snap/vlc/770/usr/lib/vlc/lua/meta/art/00_musicbrainz.luac Resending... [00007f2e84000980] lua art finder debug: Trying Lua playlist script /snap/vlc/770/usr/lib/vlc/lua/meta/art/01_googleimage.luac Sending request: DESCRIBE rtsp://192.168.1.12:554/udp/unicast/aiphone_H264 RTSP/1.0 Received 653 new bytes of response data. v=0 [00007f2e98000f00] live555 demux debug: RTP subsession 'video/H264' Received 241 new bytes of response data. [00007f2e940009e0] main input debug: selecting program id=0 Received 241 new bytes of response data. [00007f2e98000f00] live555 demux debug: setup start: 0.000000 stop:0.000000 Received 182 new bytes of response data. [00007f2e98000f00] live555 demux debug: We have a timeout of 60 seconds [00007f2e940009e0] main input debug: Program doesn't contain anymore ES |
Hi @rikosintie! 👋 Ah awesome, thanks, those logs perfectly highlight the issue. Let's go through those few lines:
As you can see, VLC first tries to make a request without specifying the username and password you provided. This is because VLC doesn't know what authentication method to use (both basic and digest are supported by the RTSP protocol). The server then answers VLC then properly adds the necessary authentication headers and gets a 200 OK. Now the reason why this doesn't work in Cameradar is simply because Cameradar currently doesn't support digest authentication. As far as I know, most (I'm guessing at least 90%) IP cameras stream over RTSP servers using However, those 10 other hypothetical percents fully deserve to be cameradared, so I'll update this issue to reflect the feature that's needed for this to work, and I'll get to implementing it as soon as I have some time! Thanks again for opening this issue with so many helpful details and precision and for going through the trouble of troubleshooting with me, I hope I'll manage to fix this ASAP and that you'll enjoy using Cameradar. 🙂 Have a good day! |
I'm so glad I found your project! I had never really used VLC before and I can see it's a very useful tool. The aiphone device is part of a door access control system my company just started selling - https://www.aiphone.com/home/products/ix-dv. It doesn't belong to me but I have if for another couple weeks for development and testing. I can run any tests you need or help any way I can, just let me know. Thanks again for your quick responses and education! |
Ha, funny story, I worked for a company manufacturing access control devices (among other things) too, when I developed Cameradar! I'm getting started on the feature now, I'll let you know when a test branch is ready. |
The feature is done and working pretty well, and I also made a few other improvements along the way so I guess I'll make a new release with this feature as the main shiny new thing hehe. Here's how it looks like when accessing a basic auth protected camera (emulated using RTSPAllTheThings: And with a camera with digest auth: As you can see, the authentication type is recognized automatically and it's also been added in the summary :) You can try it out yourself right now by using cameradar by specifying the tag Again, thanks for the issue, that was a fun one to work on 🙂 |
Etixlabs looks interesting! I tried the new version after I got over the shock of how fast you implemented the digest authentication! I think it worked, the results show the correct username, password, and route. It does have a red x and says streams couldn't be accessed ->docker run -t -v /home/mhubbard/Dropbox/03_Tools:/tmp/dictionaries ullaakut/cameradar:digest-auth -r "/tmp/dictionaries/rtsp.txt" -c "/tmp/dictionaries/my_credentials.json" -t 192.168.1.12 -l
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 403 Forbidden
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 403 Forbidden
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 403 Forbidden
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 403 Forbidden
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 200 OK
< RTSP/1.0 403 Forbidden
✖ Streams were found but none were accessed. They are most likely configured with secure credentials and routes. You can try adding entries to the dictionary or generating your own in order to attempt a bruteforce attack on the cameras. |
Mh, that's interesting 🤔 I'm not able to reproduce this and the RTSP protocol's RFC stipulates that a
But it also specifies the following paragraph:
So my guess is that due to the many requests that Cameradar sent before, it blocks the Also I will add the default credentials and route for Thanks for the issue and I'll keep you updated if I find a solution to this mysterious behavior. See you around! |
Thanks for the update! I am beginning to think that Aiphone is a cut above on security as I have run a lot of directory traversal and other common pen test tools and nothing much to report. Tonight I will create a credentials.json file with just aiphone and a route file with just the correct one and see what happens. If you need anything more from me just let me know. |
We have some Hanwha iPolis cameras also. They used to be called Samsung. I ran Cameradar with and without the digest. The Hanwha's needed the digest auth also. docker run -t -v /home/mhubbard/Dropbox/03_Tools:/tmp/dictionaries ullaakut/cameradar -r "/tmp/dictionaries/rtsp.txt" -c "/tmp/dictionaries/my_credentials.json" -t 10.132.250.29 -l
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 459 Aggregate operation not allowed
✖ Streams were found but none were accessed. They are most likely configured with secure credentials and routes. You can try adding entries to the dictionary or generating your own in order to attempt a bruteforce attack on the cameras. ->docker run -t -v /home/mhubbard/Dropbox/03_Tools:/tmp/dictionaries ullaakut/cameradar:digest-auth -r "/tmp/dictionaries/rtsp.txt" -c "/tmp/dictionaries/my_credentials.json" -t 10.132.250.29 -l
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 401 Unauthorized
< RTSP/1.0 200 OK
< RTSP/1.0 459 Aggregate operation not allowed
✖ Streams were found but none were accessed. They are most likely configured with secure credentials and routes. You can try adding entries to the dictionary or generating your own in order to attempt a bruteforce attack on the cameras. |
Interesting indeed that they show the same behavior. If you want to secure your cameras, anyway, the only way is to change the credentials/ports. Also you might want to try to run camerattack against your cameras if you want to check their resistance to thousands of requests per second :) |
Hey @rikosintie! Just a heads up that I put you in the |
First, make sure that none of the open and closed issues is about the same issue as you are describing, and make sure to check the frequently asked questions in the README file.
Then, replace the parts of this template that are between with the data relative to your issue.
If you're reporting a bug, use the template below. Otherwise, delete this template and write your issue normally.
Context
Please select one:
ullaakut/cameradar
Please select one:
Environment
My operating system:
OS version: Ubuntu 18.04
OS architecture: 64bit Intel
Issue
401 Unauthorized from the camera
What was expected?
Successful connection
What happened?
Hello, I love this project! I am trying to figure out why it isn't working against an Aiphone camera. Below are the logs. The camera is at default with user/pass of aiphone/aiphone.
I read the FAQ and a previous issue titled "can't detect camera feed". Both were very useful but I still can't figure out what I am doing wrong. Can you give me some tips to help troubleshoot?
Thanks!
If I copy this line from the logs and put it in vlc I get the stream:
rtsp://aiphone:[email protected]:554/udp/unicast/aiphone_H264
Here is the command I used to run Docker.
docker run -t -v /home/mhubbard/Dropbox/03_Tools:/tmp/dictionaries ullaakut/cameradar -r "/tmp/dictionaries/rtsp.txt" -c "/tmp/dictionaries/my_credentials.json" -t 192.168.1.12 -l
Here are the files in /home/mhubbard/Dropbox/03_Tools
rtsp.txt
my_credentials.json
Logs
If your issue is with Cameradar's binary or docker image, please run it with
-l
to print logs, and paste them here:The text was updated successfully, but these errors were encountered: