motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.93k stars 653 forks source link

Is there a way to see unsuccessful attempts to log in in logs? #307

Open azakharov3 opened 7 years ago

azakharov3 commented 7 years ago

@ccrisan first of all, thank you so much for developing this wonderful project. I started using it few days ago and was amazed how incredibly advanced it is.

Please forgive me if I missed it in documentation but I can't find out if it's possible to see unsuccessful attempts to log in. I would like to install fail2ban and make my motioneye accessible from outside of my network. This way, if somebody tries to brute-force my password, their ip will be banned.

Thanks again!

ccrisan commented 7 years ago

Unfortunately there's no way to tell unsuccessful logins.

azakharov3 commented 7 years ago

Cool, thanks for answering. Would be awesome to have this feature in the future.

peppelinux commented 7 years ago

I also saw that user access security is not so strong. For my needs this is not a problem, because an http auth digest could do the job, actually, with auth logs too.

ccrisan have you ever use django framework or ever thought to move motioneye in that direction?

ccrisan commented 7 years ago

@peppelinux what do you mean "the access security is not so strong"? What kind of attack do you think motionEye is susceptible to?

Yes, have been using Django for other projects for more than 5 years now. Django is amazing for big projects but motionEye needs to be lightweight and fast. You do not want all the Django machinery on a Raspberry PI.

There are plans to add support for basic/digest authentication as an option to the signature-based one, by the way.

peppelinux commented 7 years ago

Excuse me Calin, my english is not so good and it could sounds a little ambigous, sometimes. I just found some lacks in session security but I understand the goals of motioneye and I think that the strategy that you have choosen is very good. It was just a technical consideration, nothing else.

I came from Zoneminder experience, I can say that motioneye is a very special software that I found and I love in a way that I could develop on it, if needed.

Thank you for this

ipcctv commented 5 years ago

A huge shout out for all your hard work on this distro is in order!!

On the topic of security though, I've just found several ESTABLISHED outbound connections from my motionEye camera with the output of netstat. I'm still trying to figure out the how they got in as my password is I believe very strong. Even if they got the GUI password right, there must be some other thing going on to account for these. Since a reboot about 8 hours back, I see no dodgy outbound connections but for now the port forwarding is off. However, my Netflix account keeps getting used despite every device being forced off and the password being changed for a lengthy passphrase. Several of the connections were to China and one to the Netherlands where there was a large breach. If more aggressive security was possible, that would be good. Its not a given that the two are related at this time but the IP cam is a problem somehow. Is there any way the OS files can be checked for MD5s or something to see what has been tweaked. The changeable files would of course need to be left alone.

I had:

223.166.74.229 101.249.211.209
h53-211.fcsrv.net:27015 150.255.86.79:46591 124.236.173.143:34773 localhost:56076 150.255.86.79:45348

ccrisan commented 5 years ago

@ipcctv there's still no way to see failed login attempts. However, some outbound connections should be fine for motionEye(OS). If you can let us know your full netstat output when you suspect something, we can help you tell what is (potentially) malicious from what is not.

ipcctv commented 5 years ago

Thanks for your speedy reply. I appreciate you are a busy guy. I've looked at the connections and they are in China and the Netherlands. The latter to a known dodgy domain.

I was more reaching out to let you know there must be some 'way in'.

FYI, following a reboot and closing the port forwarding path, I've not seen any trace of this. I even accessed the web interface from a 192to see if I could activate any malware that may have been listening. Still nothing.

Thanks for the offer of looking into the connections though. If you want to know for your own interests I'll send them on. I'm not on my PC just now. My other 2 motionEye systems seem unaffected? If I find anything further I'll let you know.

Best regards. Tom and thanks again for your work.

On Sun, 28 Oct 2018, 19:32 Calin Crisan, notifications@github.com wrote:

@ipcctv https://github.com/ipcctv there's still no way to see failed login attempts. However, some outbound connections should be fine for motionEye(OS). If you can let us know your full netstat output when you suspect something, we can help you tell what is (potentially) malicious from what is not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ccrisan/motioneye/issues/307#issuecomment-433734408, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbHjTlzpGzmYHD97A7ujvUMJcjkMgLfks5upgZAgaJpZM4J_ZAf .

ipcctv commented 5 years ago

I did a bit of pen testing on the affected unit (192.168.1.100) though I'm no expert. The report may be of interest/use to you? Apologies if not.

I've found nothing yet to explain how they got into the system. I pulled back without logging in /static/js/main.js Is this a problem to a person with more skills than me?

Thanks.

[image: image.png] ZAP Scanning Report

Summary of Alerts Risk LevelNumber of Alerts High 0 Medium 2 Low 4 Informational 0 Alert Detail Medium (Medium)X-Frame-Options Header Not Set Description

X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.

URL http://192.168.1.100/ Method GET Parameter X-Frame-Options URL http://192.168.1.100/manifest.json?v=0.38.1 Method GET Parameter X-Frame-Options URL http://192.168.1.100 Method GET Parameter X-Frame-Options Instances 3 Solution

Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers). Reference

http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx CWE Id 16 WASC Id 15 Source ID 3 Medium (Low)Directory Browsing Description

It is possible to view the directory listing. Directory listing may reveal hidden scripts, include files , backup source files etc which can be accessed to read sensitive information.

URL http://192.168.1.100/static/js/main.js/ Method GET Attack directory Instances 1 Solution

Disable directory browsing. If this is required, make sure the listed files does not induce risks. Reference

http://httpd.apache.org/docs/mod/core.html#options

http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html CWE Id 548 WASC Id 48 Source ID 1 Low (Medium)X-Content-Type-Options Header Missing Description

The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.

URL http://192.168.1.100/static/js/jquery.mousewheel.js?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/favicon.ico?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/js/jquery.timepicker.min.js?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/js/main.js?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/css/jquery.timepicker.css?v=0.38.1 Method GET Parameter X-Content-Type-Options

URL http://192.168.1.100/static/js/jquery.min.js?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/css/ui.css?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/js/css-browser-selector.js?v=0.38.1 Method GET Parameter X-Content-Type-Options

URL http://192.168.1.100/static/js/ui.js?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/img/motioneye-logo.svg Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/ Method GET Parameter X-Content-Type-Options URL http://192.168.1.100 Method GET

Parameter X-Content-Type-Options URL http://192.168.1.100/manifest.json?v=0.38.1 Method GET Parameter X-Content-Type-Options URL http://192.168.1.100/static/css/main.css?v=0.38.1 Method GET Parameter X-Content-Type-Options Instances 14 Solution

Ensure that the application/w

eb server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages.

If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing. Other information

This issue still applies to error type pages (401, 403, 500, etc) as those pages are often still affected by injection issu

es, in which case there is still concern for browsers sniffing pages away from their actual content type.

At "High" threshold this scanner will not alert on client or server error responses.

Reference

http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx

https://www.owasp.org/index.php/List_of_useful_HTTP_headers CWE Id 16 WASC Id 15

Source ID 3 Low (Medium)Web Browser XSS Protection Not Enabled Description

Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection' HTTP response header on the web server

URL http://192.168.1.100/ Method GET Parameter X-XSS-Protection URL http://192.168.1.100/manifest.json?v=0.38.1 Method GET Parameter X-XSS-Protection URL http://192.168.1.100 Method GET Parameter X-XSS-Protection URL http://192.168.1.100/robots.txt Method GET Parameter X-XSS-Protection Instances 4 Solution

Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'. Other information

The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism. The following values would attempt to enable it:

X-XSS-Protection: 1; mode=block

X-XSS-Protection: 1; report=http://www.example.com/xss

The following values would disable it:

X-XSS-Protection: 0

The X-XSS-Protection HTTP response header is currently supported on Internet Explorer, Chrome and Safari (WebKit)

.

Note that this alert is only raised if the response body could potentially contain an XSS payload (with a text-based content type, with a non-zero length).

Reference

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/ CWE Id 933 WASC Id 14 Source ID 3 Low (Medium)Private IP Disclosure Description

A private IP (such as 10.x.x.x, 172.x.x.x, 192.168.x.x) or an Amazon EC2 private hostname (for example, ip-10-0-56-78) has been found in the HTTP response body. This information might be helpful for further attacks targeting internal systems.

URL http://192.168.1.100 Method GET Evidence 192.168.1.3 URL http://192.168.1.100/ Method GET Evidence 192.168.1.3 Instances 2 Solution

Remove the private IP address from the HTTP response body. For comments, use JSP/ASP/PHP comment instead of HTML/JavaScript comment which can be seen by client browsers. Other information

192.168.1.3

Reference

https://tools.ietf.org/html/rfc1918 CWE Id 200 WASC Id 13 Source ID 3 Low (Medium)Password Autocomplete in Browser Description

The AUTOCOMPLETE attribute is not disabled on an HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved.

URL http://192.168.1.100/static/js/main.js?v=0.38.1 Method GET Parameter passwordEntry Evidence <input type="password" name="password" class="styled" id="passwordEntry"> Instances 1 Solution

Turn off the AUTOCOMPLETE attribute in forms or individual input elements containing password inputs by using AUTOCOMPLETE='OFF'. Reference

http://www.w3schools.com/tags/att_input_autocomplete.asp

https://msdn.microsoft.com/en-us/library/ms533486%28v=vs.85%29.aspx CWE Id 525 WASC Id 15 Source ID 3

On Sun, 28 Oct 2018 at 21:32, tom.quaile@gmail.com wrote:

Thanks for your speedy reply. I appreciate you are a busy guy. I've looked at the connections and they are in China and the Netherlands. The latter to a known dodgy domain.

I was more reaching out to let you know there must be some 'way in'.

FYI, following a reboot and closing the port forwarding path, I've not seen any trace of this. I even accessed the web interface from a 192to see if I could activate any malware that may have been listening. Still nothing.

Thanks for the offer of looking into the connections though. If you want to know for your own interests I'll send them on. I'm not on my PC just now. My other 2 motionEye systems seem unaffected? If I find anything further I'll let you know.

Best regards. Tom and thanks again for your work.

On Sun, 28 Oct 2018, 19:32 Calin Crisan, notifications@github.com wrote:

@ipcctv https://github.com/ipcctv there's still no way to see failed login attempts. However, some outbound connections should be fine for motionEye(OS). If you can let us know your full netstat output when you suspect something, we can help you tell what is (potentially) malicious from what is not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ccrisan/motioneye/issues/307#issuecomment-433734408, or mute the thread https://github.com/notifications/unsubscribe-auth/AQbHjTlzpGzmYHD97A7ujvUMJcjkMgLfks5upgZAgaJpZM4J_ZAf .

rotrials commented 5 years ago

I found in the motioneye log things like this:

Mar 01 01:02:55 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:55 alarm meyectl[257]: WARNING: 404 GET /w00tw00t.at.blackhats.romanian.anti-sec:) (140.143.241.113) 2.39ms Mar 01 01:02:55 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:55 alarm meyectl[257]: WARNING: 404 GET /phpMyAdmin/scripts/setup.php (140.143.241.113) 1.98ms Mar 01 01:02:56 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:56 alarm meyectl[257]: WARNING: 404 GET /phpmyadmin/scripts/setup.php (140.143.241.113) 1.93ms Mar 01 01:02:56 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:56 alarm meyectl[257]: WARNING: 404 GET /pma/scripts/setup.php (140.143.241.113) 2.10ms Mar 01 01:02:57 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:57 alarm meyectl[257]: WARNING: 404 GET /myadmin/scripts/setup.php (140.143.241.113) 2.13ms Mar 01 01:02:58 alarm meyectl[257]: ERROR: HTTP 404: Not Found (not found) Mar 01 01:02:58 alarm meyectl[257]: WARNING: 404 GET /MyAdmin/scripts/setup.php (140.143.241.113) 2.21ms Mar 01 01:13:31 alarm meyectl[257]: WARNING: 403 GET /login/?_=1551395613092 (109.166.136.214) 1.64ms

as far as I know "w00tw00t" is not a good sign.....

or like this: Mar 01 22:50:04 alarm meyectl[244]: ERROR: HTTP 405: Method Not Allowed Mar 01 22:50:04 alarm meyectl[244]: WARNING: 405 PROPFIND / (103.55.25.27) 2.17ms Mar 01 22:50:05 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:05 alarm meyectl[244]: WARNING: 404 GET /webdav/ (103.55.25.27) 2.02ms Mar 01 22:50:05 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:05 alarm meyectl[244]: WARNING: 404 GET /802F606D.php (103.55.25.27) 2.05ms Mar 01 22:50:06 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:06 alarm meyectl[244]: WARNING: 404 GET /help.php (103.55.25.27) 1.85ms Mar 01 22:50:06 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:06 alarm meyectl[244]: WARNING: 404 GET /java.php (103.55.25.27) 1.98ms Mar 01 22:50:06 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:06 alarm meyectl[244]: WARNING: 404 GET /_query.php (103.55.25.27) 1.88ms Mar 01 22:50:06 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:06 alarm meyectl[244]: WARNING: 404 GET /test.php (103.55.25.27) 2.60ms Mar 01 22:50:06 alarm meyectl[244]: ERROR: HTTP 404: Not Found (not found) Mar 01 22:50:06 alarm meyectl[244]: WARNING: 404 GET /db_cts.php (103.55.25.27) 1.94ms

If I'm right this is an attack. I'm trying to figure it out how to configure fail2ban in order to ban the http attacks also.

p.s. and if somebody has some concerns about the security, I just started my "server" and in 3 days, the fail2ban, banned 3 ip addresses which tried to access my server by ssh

REYNAUDNicolas commented 4 years ago

Hello, If it interests someone, I use Nginx and fail2ban on Nginx for secure my MotionEye server. I have install my official SSL certificate on Nginx to use https.

Thanks to Calin Crisan for this project !

netw0rk-noob commented 2 months ago

Is this (an auth log) a feature that is planned / being worked on?

Marijn0 commented 2 months ago

You could use this: sudo journalctl -u motioneye -g "WARNING: 403 GET /login/" To get a list of the IP addresses of devices with failed login attempts.

and:

sudo journalctl -u motioneye -g "DEBUG: 200 GET /login/" to get a list of the IP addresses that have successfully logged in.

But for the latter you must first set your log level to debug in: sudo nano /etc/motioneye/motioneye.conf

Personally, I use the 'Monitoring Commands' to get a list of IP addresses of successful logins over the past 24 hours: Screenshot

netw0rk-noob commented 2 months ago

Thanks for the hint, @Marijn0. That log is usable with fail2ban, using the following (probably far from perfect) /etc/fail2ban/filter.d/motioneye.conf:

[Definition]
failregex = .* meyectl\[[0-9]+\]: +WARNING: 403 GET \/login\/\?_=[0-9]+&_username=.*&_login=(true|false)&_signature=[0-9a-fA-F]+ \(<HOST>\).*
ignoreregex =

If you're running motioneye behind nginx (on that same machine) forwarding the connections to 127.0.0.1:8765 this wont work, as it will always log the connections as comming from 127.0.0.1. In that case the actual source ip address is logged in the /var/log/nginx/access.log (if enabled) and may be caught using the following /etc/fail2ban/filter.d/motioneye-nginx.conf:

[Definition]
failregex = ^<HOST>.*\"GET \/login\/\?_=[0-9]+&_username=.*&_login=(true|false)&_signature=[0-9a-fA-F]+.*
ignoreregex =