iThemes Security false positive ITSEC_Lib::get_ip()

  • Resolved bdolor

    (@bdolor)


    11 years, 2 months ago

    WP version 4.1.1, multisite
    Plugin version: Version 4.6.10
    PHP Version: 5.4.38
    OS: RHEL 6.6

    Plugin config: Disable Proxy Detection is on/checked/enabled (relying on $_SERVER['REMOTE_ADDR'] to return an IP address when logging brute force attempts.)

    Description: Two login events are occurring at the same/similar times from two distinct IP addresses. This has been verified by analyzing apache access_log files. One login attempt is legitimate, the other is a brute force attempt occurring multiple times over a number of seconds — at least one login attempt per second. The desirable affect is a lockout based on IP, triggered by one of the lockout rules. The undesirable affect is the legitimate user also gets locked out. What is recorded in the itsec database table makes it appear as though the brute force login attempts were launched from both the legitimate IP address and the brute force IP address. This is known to be false — confirmed from both our firewall and apache logs. The same, simultaneous lockout behaviour has occurred on at least 5 other secured networks where our legitimate users are attempting to login from. We’ve ruled out the possibility that those networks were compromised and are pursuing a line of inquiry that we’re seeing this behaviour as a result of a false positive.

    My feeling is that ITSEC_Lib::get_ip() isn’t returning the correct IP, despite relying on $_SERVER['REMOTE_ADDR'] to obtain the IP of the client. Is it possible that concurrent requests to the static method ITSEC_Lib::get_ip() will return a previously stored value, or is there certainty that the value being returned is the actual value at the time of the request? Please advise.

    thanks

    https://ww.wp.xz.cn/plugins/better-wp-security/

Viewing 12 replies - 1 through 12 (of 12 total)
  • dwinden

    (@dwinden)

    11 years, 2 months ago

    Not sure whether this will help but a brute force attack (assuming it is performed from a single ip address and multiple login attempts are performed\failing using the same user name) may trigger the iTSec plugin to generate not 1 but 2 (types of) lockouts at the same time.

    The host lockout type will only affect the source of the brute force based on ip address.
    However the user lockout type will affect anyone trying to login with that same user account …

    What (type of) lockouts are active at any given moment can be monitored from the iTSec plugin Dashboard page in the “Active Lockouts” metabox.

    If the legitimate login attempt is hitting a user lockout type that user will get the following (default) message:

    You have been locked out due to too many invalid login attempts.

    Note this message can be customized in the iTSec plugins settings page
    (User Lockout Message).

    The brute force attack source however will receive a different (default) message:

    error

    This message can also be customized in the iTSec plugins settings page
    (Host Lockout Message).

    Not an answer to your question but just what flashed through my mind when reading your post.

    dwinden

    Thread Starter bdolor

    (@bdolor)

    11 years, 2 months ago

    Thank you dwinden, for presenting a possible scenario. The only thing the two types of login attempts share in common is the time of the attack/attempted login.

    My attempt at encapsulating the problem: A brute force attack launched from one IP gets interpreted as having come from two IPs. My proposal: It’s not actually happening; data recorded in the database is incorrect.

    Reasoning that apache’s access_log is the source of truth, data in the plugin’s [prefix]_itsec_log table isn’t accurate. What we’re seeing is a host/IP lockout on both legitimate and illegitimate attempts.

    On the server I see 5 login attempts from the ‘nefarious’ IP over a period of 8 seconds. A 200 status code is returned for all 5 of those login attempts. During that same 8 second period I also see 1 login attempt from the legitimate user coming from a different IP which also returns a 200 status code.

    The plugin interprets that pattern as 5 invalid login attempts from the ‘bad’ IP (this is good) and 5 invalid login attempts from the legitimate user’s IP. We tried interpreting this literally; that the attack was indeed coming from our network and also from another foreign network, until we ruled it out by looking at firewall and apache logs.

    On the server, over the next 20 seconds I see more attempts from the ‘nefarious’ IP to POST to the wp-login.php page, but a 403 status code is returned. I also see a 403 status code returned for the legitimate user.

    Both the ‘nefarious robot’ and the legitimate user get locked out.

    dwinden

    (@dwinden)

    11 years, 2 months ago

    Ok, (I think) I see your point.

    Did a quick test (not multi-site and no WP caching plugin, WP 4.1.1, PHP 5.5.15, Apache 2.4.10, MySQL 5.6.20, Windows 7 platform) and was not able to reproduce the behaviour. After the test the data in the 3 relevant iTSec tables looks like this (cleared all old data before running the test):

    Table: [prefix]_itsec_lockout (1 record)

    lockout_id lockout_type lockout_start lockout_start_gmt lockout_expire lockout_expire_gmt lockout_host lockout_user lockout_username lockout_active
    22 brute_force 2015-03-21 09:54:51 2015-03-21 08:54:51 2015-03-21 09:59:51 2015-03-21 08:59:51 6.6.6.6 NULL NULL 1

    Table: [prefix]_itsec_log (7 records)

    log_id log_type log_function log_priority log_date log_date_gmt log_host log_username log_user log_url log_referrer log_data
    102 brute_force Invalid Login Attempt 5 2015-03-21 09:54:27 2015-03-21 08:54:27 6.6.6.6 wp_test 1 a:0:{}
    103 brute_force Invalid Login Attempt 5 2015-03-21 09:54:32 2015-03-21 08:54:32 6.6.6.6 wp_test 1 a:0:{}
    104 brute_force Invalid Login Attempt 5 2015-03-21 09:54:36 2015-03-21 08:54:36 6.6.6.6 wp_test 1 a:0:{}
    105 brute_force Invalid Login Attempt 5 2015-03-21 09:54:39 2015-03-21 08:54:39 1.1.1.1 wp_test 1 a:0:{}
    106 brute_force Invalid Login Attempt 5 2015-03-21 09:54:47 2015-03-21 08:54:47 6.6.6.6 wp_test 1 a:0:{}
    107 brute_force Invalid Login Attempt 5 2015-03-21 09:54:51 2015-03-21 08:54:51 6.6.6.6 wp_test 1 a:0:{}
    108 lockout Host or User Lockout 10 2015-03-21 09:54:51 2015-03-21 08:54:51 6.6.6.6 0 a:3:{s:7:”expires”;s:19:”2015-03-21 09:59:51″;s:11…

    Table: [prefix]_itsec_temp (12 records)

    temp_id temp_type temp_date temp_date_gmt temp_host temp_user temp_username
    1 brute_force 2015-03-21 09:54:27 2015-03-21 08:54:27 6.6.6.6 NULL NULL
    2 brute_force 2015-03-21 09:54:27 2015-03-21 08:54:27 NULL 1 wp_test
    3 brute_force 2015-03-21 09:54:32 2015-03-21 08:54:32 6.6.6.6 NULL NULL
    4 brute_force 2015-03-21 09:54:32 2015-03-21 08:54:32 NULL 1 wp_test
    5 brute_force 2015-03-21 09:54:36 2015-03-21 08:54:36 6.6.6.6 NULL NULL
    6 brute_force 2015-03-21 09:54:36 2015-03-21 08:54:36 NULL 1 wp_test
    7 brute_force 2015-03-21 09:54:39 2015-03-21 08:54:39 1.1.1.1 NULL NULL
    8 brute_force 2015-03-21 09:54:39 2015-03-21 08:54:39 NULL 1 wp_test
    9 brute_force 2015-03-21 09:54:47 2015-03-21 08:54:47 6.6.6.6 NULL NULL
    10 brute_force 2015-03-21 09:54:47 2015-03-21 08:54:47 NULL 1 wp_test
    11 brute_force 2015-03-21 09:54:51 2015-03-21 08:54:51 6.6.6.6 NULL NULL
    12 brute_force 2015-03-21 09:54:51 2015-03-21 08:54:51 NULL 1 wp_test

    Where 1.1.1.1 is the legitimate ip and 6.6.6.6 is the nefarious one.
    I did 3 bad logins from 6.6.6.6 and then 1 bad login from 1.1.1.1 followed by another 2 bad logins from 6.6.6.6. (all bad login attempts using the same existing username: wp_test).
    After the test while 6.6.6.6 was locked out 1.1.1.1 was still able to login (no host lockout).
    Timings are not similar and I may not have followed all the correct steps (due to missing\uncertain info) but I just did this test to see whether the iTSec plugin lockout code logic is correct. And judging from the test results it seems to be.
    Still wonder how my test data compares to\differs from yours. For example you probably have 2 (host lockout) records in the [prefix]_itsec_lockout table.

    Oh perhaps worth mentioning, while testing I did run into a bug which turns out to be introduced recently (4.6.8) but it is not related to host lockouts.

    “Locked out users” usernames will not be displayed in the Dashboard “Active Lockouts” metabox:
    It currently shows:
    Locked out users [ ] – Expires in x minutes.
    while is should display:
    Locked out users [ ] wp_test – Expires in x minutes.

    Next thing that popped up in my mind is caching …
    Are you using a WP caching plugin ?

    dwinden

    Thread Starter bdolor

    (@bdolor)

    11 years, 2 months ago

    Thanks for running tests, although I do suspect that the rate at which the test logins are being attempted is generous, comparatively. The frequency of login attempts would need to tighten up to mimic what we are experiencing. That said, if this problem comes down to caching, this detail is a moot point.

    Indeed, PHP is installed with the APC extension http://www.php.net/manual/en/apc.configuration.php and the APC Object Cache Backend is installed, which ‘provides a persistent memory-based backend for the WordPress object cache’.

    By identifying that we are using a caching plugin, are we confident that this plugin is incompatible with object caching?

    dwinden

    (@dwinden)

    11 years, 2 months ago

    I guess that is a question for iThemes to answer.

    I just visited the “APC Object Cache Backend” plugin page on ww.wp.xz.cn and was met with the following message:

    This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

    Just mentioning it so you are aware of this.

    dwinden

    Thread Starter bdolor

    (@bdolor)

    11 years, 2 months ago

    In most circumstances it is relevant to highlight that a plugin hasn’t been updated in a while, but in this particular case, I can’t imagine how it would play any part in why we are seeing what we are seeing.

    thank you for your feedback, dwinden.

    dwinden

    (@dwinden)

    11 years, 2 months ago

    Please be aware that a bug has been identified in the get_ip() method/function.

    For further details read this topic:

    https://ww.wp.xz.cn/support/topic/incorrect-visitors-ip-detection

    Probably not relevant for your issue anyway.

    dwinden

    Thread Starter bdolor

    (@bdolor)

    11 years, 2 months ago

    Thanks for letting me know. If it continues to be helpful while troubleshooting issues with get_ip() — After disabling the cache plugin for a week we see the same behaviour. I also disabled APC on the server this weekend. The problem persists. This should remove any doubt that the problem is either our server configuration or installed plugins.

    What I continue to see in the access logs are 4 or 5 login attempts per second coming in from a malicious IP, one login attempt from our user, then more, rapid attempts from the same malicious IP. What I see in the database are 5 invalid/brute_force login attempts attributed to our user’s IP. The application seems to attribute the brute force behaviour to the wrong IP.

    dwinden

    (@dwinden)

    11 years, 2 months ago

    If requests are proxied it may be worth to do a test with the following changes in place:

    – “Disable Proxy Detection” checkbox unticked.
    – replace the get_ip() method/function with the fixed code version from the earlier mentioned topic.

    But again this is only relevant when requests are being proxied.
    Which I think is not the case in your situation.

    dwinden

    Thread Starter bdolor

    (@bdolor)

    11 years, 2 months ago

    We do not sit behind a proxy server so you are correct in thinking it will not be relevant. As mentioned, Disable Proxy Detection is on/checked/enabled — we are relying on $_SERVER[‘REMOTE_ADDR’] to return an IP address when logging brute force attempts.

    Thread Starter bdolor

    (@bdolor)

    10 years, 12 months ago

    2 months later…we find the source of the problem to be unrelated to this plugin.

    The default settings of our f5 (BIG-IP) appliance/load balancer which sits in front of Apache on our network does not always preserve source IP addresses. A blast of HEAD requests from a ‘bad IP’, probing for the existence of known WP vulnerabilities, triggered the f5 to share an open TCP connection to our machine with another client. Hence, the false positives detailed above. It is all here in the f5 documentation.

    I understand the efficiency aspect of this ‘feature’, but why it’s desirable to trade efficiency for accuracy in the logs is beyond me. At any rate, I wanted to mark this as resolved and document it here for anyone else who may come across it with similar issues.

    dwinden

    (@dwinden)

    10 years, 12 months ago

    Great, appreciate your feedback.

    dwinden

Viewing 12 replies - 1 through 12 (of 12 total)

The topic ‘iThemes Security false positive ITSEC_Lib::get_ip()’ is closed to new replies.