Jump to content

Search the Community

Showing results for tags 'wordpress'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Talk
    • Everything Else
    • Gaming
    • Questions
    • Business and Enterprise IT
    • Security
    • Hacks & Mods
    • Applications & Coding
    • Trading Post
  • Hak5 Gear
    • Hak5 Cloud C²
    • WiFi Pineapple Mark VII
    • USB Rubber Ducky
    • Bash Bunny
    • Key Croc
    • Packet Squirrel
    • Shark Jack
    • Signal Owl
    • LAN Turtle
    • Screen Crab
    • Plunder Bug
  • O.MG (Mischief Gadgets)
    • O.MG Cable
    • O.MG DemonSeed EDU
  • WiFi Pineapple (previous generations)
    • WiFi Pineapple TETRA
    • WiFi Pineapple NANO
    • WiFi Pineapple Mark V
    • WiFi Pineapple Mark IV
    • Pineapple Modules
    • WiFi Pineapples Mark I, II, III
  • Hak5 Shows
  • Community
    • Forums and Wiki
    • #Hak5
  • Projects
    • SDR - Software Defined Radio
    • Community Projects
    • Interceptor
    • USB Hacks
    • USB Multipass
    • Pandora Timeshifting

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Enter a five letter word.

Found 5 results

  1. This is not meant to be an all-encompasing guide to security WP, this is just to get you started Why is it WordPress has a bad name when it comes to security? Primarily because the attack surface (files available to exploit) is MASSIVE. Take a look at your installation, see all the 100s of php files and folders? Well every single one of them could be another spot to exploit. To start, remove all files that say README, or INSTALL.txt etc. Next of the very most core steps to secure your new WP install, lock down the /wp-admin (also renaming it would be better in addition) by IP Address. Even if you allow your home ISP cablemodem /24 like 67.32.229.0/24, your blocking millions of ips, and only allowing 255 to actaully get at your login page. Change username to not equal – adminThere is many scripts out there to enumerate wordpress usernames from from linux command link (google: git wpscan3)If this script cant get AT your login page, its going to have a hell of a time enumerating usernames, and dictionary attack is out of the question. Set proper permissions on ALL files and folders. I cannot speak for WP indefinately, however, all the scripts, css/html on my website are chmod 644, all the folders (directories) are chmod 755 . I have had no problems with those. The only time a file on your webserver should be chmod 777 (read write execute for the world), is temp files, and specific files that need to be modified on the fly, like cache, temp, etc. Take a look (with filezilla for instance) at your files right click them / properties look at the chmod values for various files. if you see 777, you need to take a step back and re-examine if this file/dir needs rwx world permissions (very very few files need this). My last suggestion other then the very basic obvious thing (UPDATE daily, and MINIMIZE themes and plugins, if you arent actively using a theme or plugin, it is another attack vector surface to exploit. Disable anything not being used. WP will tell you if its needed. Last suggestion(s):Setup a custom 404 (error not found) page .. take a look at mine https://tranceattic.com if you goto ANY page off my domain that doesnt exist, or try to hack it (ie: https://tranceattic.com/youareowned) .. Youll see my custom 404 page, custom picture and your IP, and user agent, time date and what you tried to view/modify. This gets logged into a mysql DB and after 3, it trips an alarm and blocks your ip for an hour)Verify your robots.txt file is allowing OR disallowing the proper directories. For instance I would nearly garuntee you do NOT want /wp-admin/* to be crawled by any search engines .. Add:Disallow: /wp-admin/*Disallow: /wp-admin?*You get the idea.Hopefully this helps if you want more suggestions or want your site checked out, id be happy to give you a quick rundown of how it looks from hacker perspective. thanks,DJ Substabcehttps://tranceattic.com#9x / efnet :: @tranceattic twitter
  2. Hi everybody! im trying to use wordpress long password dos auxiliary in metasploit ... but it keeps getting some bad ass error about a month ago i was still using ubuntu and this module was working so god ... but since i moved in to kali im having trouble with it [Forgive me for my fucked up english] these are the error(s): [*] Checking if user "admin" exists... [+] Username "admin" is valid [-] Auxiliary failed: ActiveRecord::StatementInvalid PG::InvalidTextRepresentation: ERROR: invalid input syntax for type inet: "myhost(that i set for rhost)" : SELECT "hosts".* FROM "hosts" WHERE "hosts"."address" = $1 AND "hosts"."workspace_id" = $2 ORDER BY "hosts"."id" ASC LIMIT 1 [-] Call stack: [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/postgresql_adapter.rb:602:in `exec_prepared' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/postgresql_adapter.rb:602:in `block in exec_cache' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract_adapter.rb:484:in `block in log' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activesupport-4.2.7.1/lib/active_support/notifications/instrumenter.rb:20:in `instrument' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract_adapter.rb:478:in `log' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/postgresql_adapter.rb:601:in `exec_cache' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/postgresql_adapter.rb:585:in `execute_and_clear' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `exec_query' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/database_statements.rb:356:in `select' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/database_statements.rb:32:in `select_all' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/querying.rb:39:in `find_by_sql' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation.rb:639:in `exec_queries' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation.rb:515:in `load' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation.rb:243:in `to_a' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation/finder_methods.rb:500:in `find_nth_with_limit' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation/finder_methods.rb:484:in `find_nth' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation/finder_methods.rb:127:in `first' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/activerecord-4.2.7.1/lib/active_record/relation.rb:155:in `first_or_create' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-credential-2.0.5/lib/metasploit/credential/creation.rb:555:in `create_credential_service' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-credential-2.0.5/lib/metasploit/credential/creation.rb:423:in `create_credential_origin_service' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-credential-2.0.5/lib/metasploit/credential/creation.rb:353:in `create_credential_origin' [-] /usr/share/metasploit-framework/vendor/bundle/ruby/2.3.0/gems/metasploit-credential-2.0.5/lib/metasploit/credential/creation.rb:117:in `create_credential' [-] /usr/share/metasploit-framework/lib/msf/core/auxiliary/report.rb:34:in `create_credential' [-] /usr/share/metasploit-framework/modules/auxiliary/dos/http/wordpress_long_password_dos.rb:88:in `report_cred' [-] /usr/share/metasploit-framework/modules/auxiliary/dos/http/wordpress_long_password_dos.rb:100:in `user_exists' [-] /usr/share/metasploit-framework/modules/auxiliary/dos/http/wordpress_long_password_dos.rb:119:in `run' [*] Auxiliary module execution completed
  3. Sooo .. I was googling a totally unrelated search term and found what I thought was a relevant link ... ... except the user replaced his wordpress installation with a default one - UNCONFIGURED. Which means when I went to the site, I got this: Sooo, I can now simply configure Wordpress, access the database and the server by using a couple of WordPress plugins to install any PHP I desire on the server. I am sending an e-mail to the website owner to inform him of his unconfigured setup.. but if I would have my black hat on (do caps count, or is it only fedoras?) I would simply take over this hosting account. What would you do when you see this in the wild? Configure it to secure it, then report it to the owner? Leave it as is?
  4. OK, so I believe a member of this community has developed a hot new WordPress attack scanner. I've got my scanner plugins installed but I still feel like my WordPress site is a huge pile of SQL vulnerabilities and opporunities for leaking databases, XSS, RFI/LFI, and other penetration. Beyond having a scanner plugin, what more can I do to harden WordPress? Is it an intrinsically vulnerable system or can the security be pretty tight? Frankly, I have a $100 reward for anyone who hacks my site and I want to post even more tempting challenges for people to hack it, but I feel like right now it's just not up to snuff [it's not really ready yet, so don't ask for the URL lol]. In addition to security I would like my WordPress to look leet, have some leet features, and ideally not be recognized as WordPress. I used to build websites in the 90's and early 00's, but I just have not had the time to stay current, thus WordPress is a very attractive option. But I feel like some lamer having this cookie-cutter pre-coded solution... so can I at least hack it in the sense of making it appear to be a hand coded site? I have a plugin called hide-login that changes some of the default WordPress directories and I've modified a public domain theme to remove the dead giveaways, but what more can I do? Finally, what are your favorite themes for hacking/tech stuff, if any? I like the Commodore theme but its formatting doesn't hold up well on anything but desktop based IE and Chrome.
  5. My site gets attacked daily, and for whatever reason, someone or some group truly wants into my site. This has been going on for about two years now, and they are pretty relentless, hitting me a few hundred times a day, sometimes taking it down with DoS attacks, and almost always with the same stupid attacks, looking for TimThumb flaws in my site, so they can try to get a reverse shell. They also try a number of other types of attacks as well, like XSS, SQLi, RFI and LFI attacks, all of which fail, but none the less, they keep trying. So I started writing a decoder and grepping my logs every day for all of their shell scripts. After a few weeks of downloading and decoding their shell scripts, I realized this wasn't some random drive by, but targeted attacks. I went on the offensive, and started tracking down the attackers, their sites, the sites they compromised and so on. A few people took notice on Twitter about my complaining and such, one of whom is our very own Brian Wallace, aka Bwall, from the forums and FireBwall and Ballast Security. He took a look at what I was doing, and wrote his own decoder, which decodes more types of obfuscation than my decoder was doing. This also spawned a few papers he wrote on the subject of RFI attacks and Bot-Nets that he invited me to work on with him and MaXe from Inern0t. When the paper was done, I had collected somewhere around 200mb's of shell scripts, perl and php bots, and so on. What was I going to do with all these files? Nothing really, but I was using the decoded bots and scripts to track down who my attackers were, and with the help of Brian, shutting down some of these bot nets. My attackers didn't seem to like that to much, and as such, took notice of the paper Bwall had written and also the decoder site we we're using to reverse their bots and infiltrate their IRC channels. Then it dawned on me, We needed an easier way to catch these attacks, instead of me grepping logs on a daily basis, we needed an attack scanner to do the work for us. Initially, all we we're doing, was sending any RFI attack to FireBwall.com, and while thats great for decoding and collecting their shell scripts, I figured if we we're going to be checking and logging these attacks, we might as well start blocking them as well. Thats when I asked Brian to help me re-write some horrible code I had thrown together to log the attacks, and he turned it into a nice little Firewall for WordPress. Right now, we have a free version of our WordPress Attack Scanner Plug-in up for anyone to download and use, check it out and see whats happening to your own WordPress based site. You might be surprised by some of the things you see show up on the logs. The free version is only a logging utility, which lets you see what attacks we're tried against your site, but also where and who your attackers are. We do Geo-IP lookups from our own database now as well, and offer some basic stats on the various attacks. Here is a sample of what one of the attacks looks like. We're still working on this and will also be releasing the full blown Firewall based version within the next few weeks, but we wanted to offer up the free one to anyone who wants to give it a try, send us feedback, feature requests, bugs or hacks you may have discovered with it, etc, and we will be sure to add those fixes and look into adding more features. Again, this is still under heavy development, but we wanted to give everyone a chance to try it out and give us some feedback on what they thought. While the free version does not block the attacks, its till a very useful tool in discovering things you might not have known were happening to your WordPress based site. Check our http://www.attack-scanner.com/wp-attack-scanner-firewall.php'>http://www.attack-scanner.com/wp-attack-scanner-firewall.php to see all the things we currently check for. If you have ideas on things we should add, we're all ears!! Also, another plug-in I wrote, that works well with this one, is a Login Alerts plug-in that notifies you when someone is trying to brute force their way into your WordPress site. one of the things our attack scanner does, is check to see if anyone is trying to do user name enumeration. If they find the true admin name for the site, they will then try brute forcing their way in, and WordPress by default has no lockout periods or ways to notify site owners this is happening, so check out our Attack Scanner as well as our Login Alerts plug-in and let us know what you think. Links to both can be found on http://www.attack-scanner.com We're also going to be working with Dave Kennedy, aka Rel1k of TrustedSec and SET fame, to integrate the Artillery IP Ban list from his central database of banned attackers, so hopefully we'll have that in the full version when we are ready to release sometime before Derbycon is here. Thanks guys, let us know what you think, or if you run into any problems with installing them, etc. Big shout out to Bwall for all his help. You can learn more about this project on our site. NOTE!!! Once you activate the attack scanner, go to the configuration panel, and CHANGE THE DEFAULT PASSWORD!!! If you don't, and someone sees you are running it, they can download and read your logs. This password, encrypts your logs, and if you forget what the password is when migrating the file to another site running the same plug-in, there is no way to read the logs without the original password you used to encrypt the logs!!
×
×
  • Create New...