Renamed page detected by hacker

Jandard, are you sure it has found the renamed login page?

I’m experiencing attacking attempts on my site when using this plugin. It seems like the plugin really doesn’t protect the wp-login.php

Hey Guys, I recently discovered that if you forget to remove the meta widget from the sidebar, it will reveal your login page. This could be how a hacker can access your custom login page. Some themes also add this meta in the footer or on the 404 page. Make sure you check your sidebar widgets.

On that note, I’ve made this mistake yet never had a spam bot crawl the login page. You may have something on your computer that could be revealing sensitive info to a third party. Mac or PC, make sure you are not a victim of spyware or malware.

Hello Jaimequin

I don’t understand what is the related “meta widget” ! Could you please document ?

The server is hosted by professional hosting services, no malware should be involved.

Could they use ‘xmlrpc.php’ to find the information ? (now, iI have disabled this php).

About the previous question, yes, they found the new name. Looking at logs, after few tricky POST, they made a GET with the right ‘fake’ name.

Fortunately, after 3 tries, they are locked for 60 minutes, and I can change the name of the login page. This is tiring and needs a permanent check.

Any ideas to stop this ?

Thanks

There are a few possibilities… Either one other URL redirects to the new login page (something I overlooked maybe), but that would show in your logs? Or the URL is visible somewhere on the front-end of your website (but not by this plugin). Or the attacker correctly guessed the URL… Not sure how obvious the new URL is. Sometimes I ‘rename’ is to login for simplicity, but that doesn’t give you much protection of course.

The typo isn’t obvious in your last sentence:

“Sometimes I ‘rename’ is to login for simplicity, but …”

so I’m not sure what you meant. Cheers.

‘is’ should be ‘it’. Do you have xmlrpc enabled? (It’s enabled by default.) If so, and attacker can still try to long in through that API.

Thanks. All clear now. There used to be a checkbox for XMLRPC (in discussion? – memory is failing on that) until the core team took it away. So now what is the best way to see if it’s on or off and to turn it off if it’s on? Searching for plugins to do it, and have found several. Recommendations?

https://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/

I saw that, too, but elsewhere have read that this can cause breakage elsewhere. Will just have to try and see. Any way to independently test whether it’s on or off?

I don’t get why the wpengineer.com article makes this statement:

Surely a better solution is to create a small plugin.

Why would a plugin be better than a single line in wp-config.php?

Because you can easily turn it on/off without changing code. It’s “safer” if you don’t know what you’re doing.

Disabling xmlrpc.php will break anything that uses it. E.g. I believe Jetpack uses it to communicate with WP.com, but they might have replaced it with a JSON API by now. The mobile apps use it too.

Right. It’s certainly easier for me to change 1 line in wp-config. The effects of that change are another thing. Yes, I mentioned Jetpack and more in the other thread that we’re both writing in (Failed After 1 Day) :).

I definitely understood that turning off XMLRPC would kill any mobile app’s communication with WP, but that’s fine because I don’t use mobile apps when I have a perfectly good browser interface. My vote for the team would be to dump the mobile app and redirect those resources elsewhere. Mobile browsers work fine. Well, I suppose if you have a slow phone it might not be the case, but even the low-end phones are getting fast. In a few years I hope we can look back at the whole concept of mobile apps and laugh.