WordPress.org

Forums

[resolved] Possible Security Vunerability: admin-bar.php (23 posts)

  1. Another Guy
    Member
    Posted 1 year ago #

    I am noticing a pile of traffic all of a sudden on different wordpress installs, attempting to directly post to admin-bar.php. It looks like an attempt to add malware onto the admin bar, which would potentially permit either a user privilege escalation or to try to obtain credentials or similar.

    Thankfully, I get errors like this:

    PHP Fatal error: Call to undefined function add_action() in /var/www/website/wp-includes/admin-bar.php on line 48

    Interestingly, I didn't see these before installing 3.9.1, which means either the hack was on previous version, or they have found something new.

    I did find one cached page on Google (not the actual page anymore) that showed this being used to install a rootkit. Again, not sure of the mechanics, but I am seeing plenty of activity on this.

  2. esmi
    Forum Moderator
    Posted 1 year ago #

    Just because hackers are targeting your sites' admin bars does not mean that the admin bar itself is the vector. Only that it's a victim of the hack. You need to start working your way through these resources:
    http://codex.wordpress.org/FAQ_My_site_was_hacked
    http://wordpress.org/support/topic/268083#post-1065779
    http://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/
    http://ottopress.com/2009/hacked-wordpress-backdoors/

    Anything less will probably result in the hacker walking straight back into your site again.

    Additional Resources:
    Hardening WordPress
    http://sitecheck.sucuri.net/scanner/
    http://www.unmaskparasites.com/
    http://blog.sucuri.net/2012/03/wordpress-understanding-its-true-vulnerability.html

  3. Another Guy
    Member
    Posted 1 year ago #

    Thank you, but my sites were NOT hacked - I am seeing people make direct calls to that function, which is highly unusual.

    My sites are as secure as wordpress sites can be. So pointing me to a bunch of "your sites has been hacked" information isn't helping.

    I am reporting an issue, not asking for help. Is it hard to tell the difference?

  4. esmi
    Forum Moderator
    Posted 1 year ago #

    I am noticing a pile of traffic all of a sudden on different wordpress installs, attempting to directly post to admin-bar.php
    [...]
    PHP Fatal error: Call to undefined function add_action() in /var/www/website/wp-includes/admin-bar.php on line 48

    Hmm... That sounds like a hacked site to me.

  5. Another Guy
    Member
    Posted 1 year ago #

    Nope. That is a direct call attempting to use that functions to do something. See, you can access that function without being logged in, which appears to be pretty silly.

  6. esmi
    Forum Moderator
    Posted 1 year ago #

    That is a direct call attempting to use that functions to do something.

    Then can we see the full error message?

  7. Another Guy
    Member
    Posted 1 year ago #

    That is all that ends up in the error log at this point, I don't have full verbose logs on (it would be a machine killer to do that). But looking at it, it appears to be a direct call (as it isn't attributed to another page), with no referring page.

    Looking at the code, it appears to be trying to call a function that has not been loaded, as they are directly calling the admin-bar.php file.

  8. kyle_t
    Member
    Posted 1 year ago #

    I have been noticing the same error coming through our logs. I am interested in any more information that you find about this attempted exploit.

  9. esmi
    Forum Moderator
    Posted 1 year ago #

    That is all that ends up in the error log at this point

    Then how do you know that this is a direct call? It still smacks of a hacked site.

  10. kyle_t
    Member
    Posted 1 year ago #

    I was able to recreate the error in the error logs with our ip by visiting /wp-includes/admin-bar.php directly, I did not try posting any data to it
    I have to agree with another guy that the site is not hacked, it is just an attempt to exploit.

  11. esmi
    Forum Moderator
    Posted 1 year ago #

    So where is the issue?

  12. kyle_t
    Member
    Posted 1 year ago #

    I don't see any issue, as of now. Obviously these files are not supposed to be accessed directly, and accessing admin-bar.php directly doesn't do much since the add_action() function is not defined within that file. (It is defined in wp-includes/plugin.php)

    But I'm going way out on a limb here and saying maybe there is a plugin or some other malware that makes an edit to that file so that when that file is accessed directly it leads to a backdoor into wordpress admin. Again just speculation and also worst case scenario.

  13. esmi
    Forum Moderator
    Posted 1 year ago #

    None of the plugins hosted at wordpress.org make edits to any core WordPress files.

  14. Another Guy
    Member
    Posted 1 year ago #

    "I don't see any issue"

    In simple terms, if someone is knocking on a particular file on more than one installation, then you have to ask why. You make the assumption of an already hacked wordpress install, my feeling is this is much more an attempt to create a hole, not to profit from it.

    I tend to go with Kyle T on this one, it looks like someone has figured out a potential hole, or that a different hack modifies this file to allow for a back door to create a recurring hack. It looks potentially like someone checking to see if an installation has been hacked or modified.

    It's also the first file in that directory, alphabetically.

  15. In simple terms, if someone is knocking on a particular file on more than one installation, then you have to ask why.

    That parts easy: some installations get compromised, that file get's hacked and BOOM! you're done.

    You make the assumption of an already hacked wordpress install, my feeling is this is much more an attempt to create a hole, not to profit from it.

    That's just not the case.

    I tend to go with Kyle T on this one, it looks like someone has figured out a potential hole, or that a different hack modifies this file to allow for a back door to create a recurring hack. It looks potentially like someone checking to see if an installation has been hacked or modified.

    There are a lot of insecure hosts and installations running insecure add-on code. The bad guys look for systems that have been compromised already. That is all that those probes mean.

    Now if someone does know of a means to exploit the stock WordPress files then please report it. But this part:

    I am noticing a pile of traffic all of a sudden on different wordpress installs, attempting to directly post to admin-bar.php

    Doesn't mean that file is exploitable. It means someone is looking for a copy that has already been hacked.

  16. Another Guy
    Member
    Posted 1 year ago #

    I understand your points Jan, but I think you are missing context here.

    Why this file, and not any others? It's not generally a file people would access (unless they are logged in) but potentially code added here would be executed by someone with admin level privileges. If they are just testing to see if wordpress exists, there are easier ways. Moreover, as emsi pointed out, these are not files that generally can be modified by a plug in, so it wouldn't be some simple thing.

    Moreover, I did find at least one cached example of this file turned into a rootkit install point. It basically Google caching the page, but there is no current version. So it suggests someone has found a way either to exploit that file directly or to use it as the "exploited file" for some other hack. Either way, it's worth noting.

    I have to ask though: Why is there such a strong resistance to accepting a report of potential hacking activity?

  17. I understand your points Jan, but I think you are missing context here.

    I'm really not. ;)

    I've explained why that sort of probe happens. Would anyone say that repeated knocking on wp-login.php indicates that that file is exploitable? It gets loaded hundreds of times a day.

    (By the way, if you do see that then this plugin is the way to go.

    http://wordpress.org/plugins/limit-login-attempts/

    Very useful. Don't let the "hasn't been updated in 2 years" worry you. It works well.)

    I have to ask though: Why is there such a strong resistance to accepting a report of potential hacking activity?

    There is zero resistance to accepting any report of potential hacking activity. None, nada, zilcherino.

    I myself really don't know why anyone has resistance to anyone replying as Esmi and I did when someone asks a question.

    *Drinks more coffee*

    Posting concerns is 100% fine. But so is posting replies like "Unless you can demonstrate an exploit or weak code that could be exploited then there's nothing to see here."

    If you do have an exploit defined and reproducible i.e. can demonstrate proof of concept code then do not post it here. Report it instead to the security team list.

    http://codex.wordpress.org/FAQ_Security#Where_do_I_report_security_issues.3F

    That's the responsible way to report those issues. Patches to WordPress has been the result of that reporting and that's useful and good.

    What is an unfortunate trend that some people have (not yourself or anyone on this thread) have is to post "The Sky is falling!"

    I mean they say "WordPress is insecure". ;)

    This article remains a good read on that topic.

    http://wpengine.com/2013/05/08/wordpress-core-is-secure-stop-telling-people-otherwise/

  18. Nicki Faulk
    Member
    Posted 1 year ago #

    I am also seeing this in error logs on multiple WordPress installs after upgrading to 3.9.1:

    PHP Fatal error: Call to undefined function add_action() in /home/folder/public_html/wp-includes/admin-bar.php on line 48 -"error_log"

    All error logs point to the exact same line number on the exact same file. I do not believe this is an exploit, but a bug.

  19. It's not a bug.

    When I access my test installation and visit http://test-installation-URL/wp-includes/admin-bar.php I get this in my error log.

    2014/06/07 08:41:53 [error] 1963#0: *35 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Call to undefined function add_action() in /usr/share/nginx/www/wp-includes/admin-bar.php on line 48" while reading response header from upstream, client: 10.1.1.26, server: test-host-here, request: "GET /wp-includes/admin-bar.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "test-host-here"

    On my test install I'm running nginx but the error is the same for apache2.

    Here's why: that admin-bar.php is not supposed to be called directly. It lacks the included files that will permit the other needed functions to work by itself.

    When it references a function called add_action() PHP does not know what that is or where that function lives. It was never meant to be called directly like that.

    What calls it is /wp-settings.php in line 154.

    require( ABSPATH . WPINC . '/admin-bar.php' );

    Which is at the end of a very long list of requires.

    https://core.trac.wordpress.org/browser/tags/3.9.1/src/wp-settings.php#L154

    Scroll up after that link.

    This line explains it with

    // Load most of WordPress.

    https://core.trac.wordpress.org/browser/tags/3.9.1/src/wp-settings.php#L111

    If the rest of those includes (or at least one of them) is not loaded then you get that error. That's not a bug, that's what is supposed to happen when you call that file directly.

    When I use the dashboard correctly that error does not appear. When I call that file directly then yes, that's what happens.

    Again, my guess is that someone or something is probing installations looking for compromised versions of that file.

  20. Another Guy
    Member
    Posted 1 year ago #

    Jan, I still think you miss the point. People knocking on a door suggests that they think the door may actually open. It is incredibly silly to knock on a door that generates a clear and obvious error message, as your door knocking stands out rather obviously. It's an error that is written to the apache error.log file on the default settings of a standard LAMP install.

    Everything you say is correct, except totally lacking on context. Yes, directly accessing the file generates the error. We know that already. The question is why is it being accessed? Is it a hacking attempt, or is it a bug in wordpress or certain themes that tries to access this file when users are not logged in?

    The functionality of wordpress under normal circumstances is clear, and we all understand it (I looked at the code before I even bothered to post). Door knocking this particular file seems a bit off, and having found a cached hack on someone else's site makes me wonder.

    This piece of oddness got my attention, it's the standard "c99" rootkit being used to specifically attack admin-bar:

    [ Moderator note: Link to cached exploit code deleted. If your site is hacked please follow this advice as above. ]

  21. Jan, I still think you miss the point.

    ...

    Everything you say is correct, except totally lacking on context.

    I'm not and frankly, you know that I'm not. This all seems circular and utterly pointless. You continue to ignore what I've said which is fine but I've already answered the question definitively with actual examples.

    *Checks*

    Ha. Oh, that's really funny.

    Look, don't create and use sock puppet accounts. That will really, really, really get you into trouble here and blocked for good.

    http://wordpress.org/support/profile/rawalex

    Pick one account and please be on point. Circular discussions like this one are pointless and I'm closing this down now.

    This piece of oddness got my attention, it's the standard "c99" rootkit being used to specifically attack admin-bar:

    Right. You've once again totally missed what I've been repeatedly saying. What you've linked to shows that that installation was hacked. Thank you for providing an example that clearly illustrates what I've been saying. ;)

    See this part?

    I've explained why that sort of probe happens. Would anyone say that repeated knocking on wp-login.php indicates that that file is exploitable? It gets loaded hundreds of times a day.

    Also see this part too?

    If you do have an exploit defined and reproducible i.e. can demonstrate proof of concept code then do not post it here. Report it instead to the security team list.

    http://codex.wordpress.org/FAQ_Security#Where_do_I_report_security_issues.3F

    That's the responsible way to report those issues. Patches to WordPress has been the result of that reporting and that's useful and good.

    I'm particularly fond of this reply of mine. It's in depth and demonstrates what I've been saying.

    And that's it. I'm closing this topic. If you have a new problem to discuss then please do with a new topic.

  22. Door knocking this particular file seems a bit off

    Not really. The admin-bar.php is the first file, alphabetically, in the wp-includes directory.

    Say I have a script that gains access to a site. It has access enough to run some simple shell commands. What does this script do? It finds the first file with a PHP extension, injects some code into it, then records it. Some other process hits this file via http.

    But, you might think, this is stupid. If they have the ability to put code into files, they're already in! Yes, they are, but these aren't sophisticated hackers here. These are script kiddies. They're running various known exploits with a simplistic payload. Then later, they access the site through whatever web-root-interface they stuck onto whatever file the script stuck it in.

    So, they run their script on a bunch of sites all in a batch, then come back later and run another script to see what sites actually got their malware injected into them.

    There's nothing special about admin-bar.php, other than it starts with an "A".

    The admin-bar.php file is the place the payload might have been dumped. It's not the point of entry.

  23. Nicki Faulk
    Member
    Posted 1 year ago #

    Restricting the wp-includes directory resolves this issue for my sites. I'd already performed other suggestions listed on the Hardening WordPress page; it turns out I was missing that step.

    Thank you all for the helpful information, for both cause and resolution.

Topic Closed

This topic has been closed to new replies.

About this Topic