Categories
Cracking Password WordPress WPScan

Brute Force WordPress Passwords with WPScan and Tor


Visit Center City Security for WordPress Penetration Testing and Security services.

I took another crack, pun intended, at brute forcing my WordPress password using WPScan.  Unlike when I tried it the other day, this time I used Tor and set up a SOCKs proxy to make use of a false IP address.  My thinking was that my web host might black list my IP after a certain number of failed attempts, so by using Tor I could simply switch IP addresses once the blacklist went into effect.

I am happy to say the proxy worked and the following command worked as expected:

sudo wpscan --url technicalagain.com --wordlist darkc0de.txt --username [redacted] --proxy socks5://127.0.0.1:9050 -v

The behavior of my web host did not match what I expected. Instead of blacklisting the IP, as soon as the 38th incorrect password was entered, the web host put up a 406 error and stopped allowing  log in attempts for five minutes. Why does it allow 38 password attempts? Good question. So, to work around this I would have to enter 37 passwords, then wait five minutes, then enter the next 37 passwords, then wait five minutes, and slowly work through the entire dictionary list. At 37 passwords per five minutes it would take 121 days to exhaust the list of passwords on darkc0de.txt.  Suffice it to say that this password policy control in place by the web host is a satisfactory deterrent for 99.99% of attackers that are not going to wait up to half a year just in hopes that my password is on the darkc0de list.  It isn’t.

Visit Center City Security for WordPress Penetration Testing and Security services.

Categories
Cracking Ophcrack Password Projects

More Password Cracking – Windows Edition with Ophcrack

I continued the work I previously explained by attempting to crack a Windows administrator password. This time I created a new windows administrator, booted up using a Kali Linux USB and launched Ophcrack to go after the administrator account I set up.

After lauching Ophcrack, I navigated to the Windows partition and then \WINDOWS\System32\Config to access the SAM database.  I then downloaded a Rainbow Table called Vista Free and after about 10 minutes, the admittedly weak password I setup hello123 was cracked.  I was not able to crack all of the accounts – presumably because they were adequately complex.

I think next time I will experiment with chntpw to reset the Administrator password instead of attempting to crack it.

 

Categories
Cracking John Password

Password Cracking with John the Ripper

I did some preliminary experimenting with password cracking utility John the Ripper to test the security of my own root password.  I started by installing John and  dumping the /etc/passwd file.

sudo apt-get install john

unshadow /etc/passwd /etc/shadow > mypasswd.txt

The mypasswd.txt file now holds a salted hash of my root password.  I then passed this over to John to work its magic.

john mypasswd.txt

John is very powerful.  I experimented with the most basic of cracking settings starting with single mode, then word lists and John would have moved to an incremental mode.  I am happy to say I chose a sufficiently complex password that withstood John’s single crack mode and word lists.

Password cracking is very CPU intensive and the 10+ year old server that I am working with is probably about the least appropriate computer to attempt a rigorous cracking approach.  The fan kicked on immediately and my laptop starting running hot.  After more than 10 minutes of cracking attempts I aborted John and you can see the output below.

This was a fun and great learning exercise.  I am going to continue experimenting with John. I will test John on the passwords stored in my Password Manager next.  Using this technique I will also mount the Windows partition I have on my server and attempt to access and crack the Windows password hashes from Ubuntu.

Categories
Password

The Password Ladder

Where are you on the Password Ladder and what can you do to move one rung higher?

You’re standing next to the ladder, holding it if you are using one of the world’s most common passwords like 123456, password, qwerty, 123456789, or letmein.  Amazingly, even in 2018, 8-10% of people still use these most basic of passwords.  If your username is discovered, your password is immediately compromised by even the simplest of dictionary attacks. Heck, you don’t even need a dictionary to guess the password.  Forget about if just the password hash is discovered or an encrypted version of the password is acquired.  You’re sunk no matter what.

You’re on the first rung of the ladder, if you are reusing the same username and password combination on the majority of the websites you visit.  This is especially problematic if the credentials you use for your bank account or email address are not unique.  Most email accounts serve as a gateway to other account credentials.  If you’re on the first rung of the ladder, basically any website getting hacked puts in jeopardy your identity and financial assets.

You’re on the second rung of the ladder, if you are reusing the same username and a password that is made up of a basic combination of personal information like your children’s names and your anniversary date.  The second rung is barely any better than the first rung.

Third rung if you are using a single base word and then substituting special characters and capitalization instead of random word combinations. Thank you xkcd.  No simpler way to describe this than below.

If you made it here you are in the top 5%. The fourth rung has two factor authentication turned on for important accounts like your email, bank, benefits, and retirement vehicles.  Incredibly, it is estimated that only 5-10% of people have voluntarily enabled two factor authentication on Gmail even though it has been available for a number of years.

Top of the ladder if you are randomly generating usernames and passwords (not reusing them), you have two factor authentication turned on and you are using a structured approach to manage your passwords like using a password manager or browser autocomplete to make sure your passwords are maximum length and complexity.

Please remember that there is no perfect system. Even the fifth rung here can be debated about whether the use of password managers and browser autocomplete provide additional security or if they introduce additional risk vectors. The debate is warranted, but I believe the benefits outweigh the risks. Just know that no approach is impervious to all attacks and keep in mind:

1. Phishing attacks actually work.

2. Credential theft via phishing and administrator credential theft are the most common way external actors gain access.

3. Social engineering attacks (pretext calling), over the shoulder snooping, and man-in-the-middle attacks are still a very effective way to steal credentials.

4. Many people still write their passwords down, store them in text documents on their hard drive or server, or hard code passwords into source code and stored procedures. This includes storing encryption keys in the same folder as the encrypted material.

5. If there is data loss or ex-filtration, it is much more likely to come from an internal actor’s intentional or unintentional activities (mis-configurations, forgetting to encrypt, copying the whole file instead of one record, etc.).

6. Zero day (undiscovered defects) happen only 1-5% of the time. It is much more common that a known defect will be exploited. Some known defects are aged 5 or more years and still unpatched in production. Bad actors scan and fingerprint unpatched defects and they have open source exploit kits to take advantage of the defect once spotted. Malicious actors don’t even have to be that technical to be effective.

Control what you can and take necessary precautions.  Move yourself up one rung of the ladder.

Categories
Password Projects ProjectSuccess

Rolling My Own Password Manager (Part 2)

Continuing the review of how I implemented my own password manager, this is part two.  If you’d like to read part 1, you can do so here.  For somewhat obvious reasons I am not going to share the product name or the specific details about my implementation broadly here.  I would be glad to provide a bit more information: if you are so interested, leave a comment below and I can reply to your question directly.

I picked a product that fit the following desirables:

  • Standalone install on my own server – does not rely upon any third party
  • Open source and more than 10 years old.  Reasonably active developer community, penetration tested and uses proven encryption algorithms.
  • The installation was modular allowing me to customize the front- and back-ends I wanted to use.
  • The solution has logging in place so I can monitor log in attempts.

Stumbling Blocks

I mentioned in part 1 that I had two remaining control efficiencies which I can share now as I have those patched up.  The first issue was a silly mistake.  I had uploaded into my password manager the username and password for the server that hosts the password manager itself.  The issue here is that if the password manager was ever breached and the data stolen, by including the credentials of the host server, a malicious actor could then delete the password manager itself leaving me in a world of hurt.  I have since deleted those credentials.

The second issue I realized was that I never had a certificate attached to the server leaving me vulnerable to possible man-in-the-middle attacks.  Since one of the pleasures of using a password manager is that I can log in to copy/paste my credentials from my laptop or phone, the chance of using the password manager on a public access point is pretty high.  So I signed up for a free certificate from Let’s Encrypt to encrypt all the traffic.  My host made it extremely easy to apply the certificate.

Learnings

I had a few challenges in this project.  For one thing, I had a really difficult time forwarding all traffic to use https instead of http after I got my certificate installed.

I was finally able to get forwarding to work by adding the following lines to the .htaccess configuration file located at the root of the public directory.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^(<directory name>.*)$ https://www.domainname.com/sub-directory/sub-directory/sub-directory/etc.$1 [L,R=301]

This was particularly nasty because I had intended to use an .htpasswd configuration on the server to require “double credentialing” – one where you log into the directory containing the password manager and one where you log into the password manager itself.  The forwarding rules and the authentication rules for Apache kept stepping on each other and so I decided to abandon the directory authentication.  I definitely lost a lot of time and effort on this, but since directory level authentication in Apache isn’t really secure anyway, I decided to cut my losses.

Another less challenging but important learning was to turn off web crawling using a robots.txt file.  I realize this provides limited control utility, but why have search engines indexing my password manager?  That only creates more visibility and opportunity for malicious actors to find it and attempt exploits on it.  I know that malware crawlers can and do simply ignore robots.txt configurations, but I also know that utilities like amass use legitimate search engines that do respect robots.txt for intel.  Again, why make it easy?

Amass searches Internet data sources, performs brute force subdomain enumeration, searches web archives, and uses machine learning to generate additional subdomain name guesses.  I am going to do some experimentation with amass on my own servers to get more familiar.

Further Work

This has been a fun project.  I have learned a lot and vastly improved my web security and habits.  I have a few more ideas that I plan to work on related to the password manager:

  • I am going to minify the entire application by removing any reference to its name or any other identifiers in the source code.  It will still be possible for bots to fingerprint my use of the application, but it will take more work for any malicious actors because the basic search phrases and configurations won’t work on my instance.
  • I am still not pleased with the complexity of the passwords I used for the front and backends to communicate – so I’ll add more hardening there.  I am also in the process of turning two factor authentication on for all of my assets and need to finish up activating the last few.
  • I also need to come up with a backup plan for two factor authentication in the event that my phone is lost or broken.
  • I am going to experiment with John the Ripper to test the encryption and try to crack my own passwords.
  • I would like to set up a service to download my log file every few minutes, compare it, and send me a text message whenever there is new activity.  That way I am aware of any brute force login attempts that did not originate from me or any other approved user.
Categories
Password Projects ProjectSuccess

Rolling My Own Proper Password Manager (Part 1)

On previous posts here I shared my poor hygiene when it comes to password management (reusing the same password and not having passwords complex enough). I’m really happy to say I’ve made some major improvements. I’ve been meaning to roll my own password manager and I had a few requirements in mind.

1.) I wanted to host the web application myself on my own server so I could access it from any device and share access with my spouse.

2.) I wanted a password management application that would make it easy to generate maximum complexity usernames and passwords that I could copy and paste.

3.) I wanted the password manager to be free standing and not rely on any cloud or external services outside the scope of one of my servers.

4.) I wanted an open source solution, relying on established encryption protocols.

The primary attack vector that I am guarding against is breaches at the various third party sites I use – take the recent breach at MyFitnessPal as an example. This impacted me personally due to too much password-reuse. I am on a quest to eliminate both password and username re-use as well as start enabling two factor authentication on my email and sites with my financial assets. I am not concerned, primarily, about the physical security of my devices – which means I use Chrome and allow the passwords to be saved and even allow Chrome to sync across devices.

Overall the solution has a pretty nice experience. I use my password manager to generate random usernames and passwords and then copy and paste them when I need to. Chrome then saves the username and password and I don’t have to worry about it again.

In this post I am not going to share which solution I picked, where I installed it, or what customization I made in this post. I still have two control gaps in the solution I have implemented. I will share more details once I have those patched up in the next couple of weeks.