Hacking & Security
Chris Camejo, Director of Assessment Services for NTT Com Security (formerly Integralis), comes from a technical assessment background, having personally coordinated and conducted numerous large-scale, multi-discipline penetration tests spanning multiple countries for global clients. As part of NTT Com Security’s threat intelligence capabilities, he follows the latest tactics and techniques of attackers and have conducted […]
The post Interview: Chris Camejo, Director of Assessment Services for NTT Com Security appeared first on InfoSec Institute.
Po phishingové vlně z minulého týdne, která mířila na elektronické bankovnictví Komerční banky, jsme dnes zaznamenali téměř totožný e-mail určený pro klienty GE Money Bank. Uživatele tento podvodný e-mail navádí k aktualizaci certifikátů, a to z důvodu nově nalezené zranitelnosti. Po kliknutí na odkaz v e-mailu je uživatel přesměrován na falešnou stránku GE Money Bank, která vyžaduje zadání přihlašovacích údajů do elektronického bankovnictví.
Ukázka phishingové zprávy:
Introduction: NodeJS is an extremely powerful and lightweight technology, which is being widely adopted. Just like any other technology sometimes developers make mistakes during the development process, which may lead to serious vulnerabilities. In this series of articles, we discuss various NodeJS specific and traditional vulnerabilities that we may come across when dealing with NodeJS […]
While developing tasks for PHDays’ contest in reverse engineering, we had a purpose of replicating real problems that RE specialists might face. At the same time we tried to avoid allowing cliche solutions.
Let us define what common reverse engineering tasks look like. Given an executable file for Windows (or Linux, MacOS or any other widely-used operating system). We can run it, watch it in a debugger, and twist it in virtual environments in any way possible. File format is known. The processor’s instruction set is x86, AMD64 or ARM. Library functions and system calls are documented. The equipment can be accessed through the operating system only. Using tools like IDAPro and HеxRays makes analysis of such applications very simple, while debug protection, virtual machines with their own instruction sets, and obfuscation could complicate the task. But large vendors hardly ever use any of those in their programs. So there’s no point in developing a contest aimed at demonstrating skills that are rarely addressed in practice.
However, there’s another area, where reverse engineering became more in-demand, that’s firmware analysis. The input file (firmware) could be presented in any format, can be packed, encrypted. The operating system could be unpopular, or there could be no operating system at all. Parts of the code could not be changed with firmware updates. The processor could be based on any architecture. (For example, IDAPro “knows” not more than 100 different processors.) And of course, there’s no documentation available, debugging or code execution cannot be performed―a firmware is presented, but there’s no device.
Our contest’s participants needed to analyze an executable fileand find the correct key and the relative email (any internet user was able to take part in the contest).
Part One: Loader At the first stage, the input file is an ELF file compiled with a cross compiler for the PA-RISC architecture. IDA can work with this architecture, but not as good as with x86. Most requests to stack variables are not identified automatically, and you’ll have to do it manually. At least you can see all the library functions (log, printf, memcpy, strlen, fprintf, sscanf, memset, strspn) and even symbolic names for some functions (с32, exk, cry, pad, dec, cen, dde). The program expects two input arguments: an email and key.
It’s not hard to figure out that the key should consist of two parts separated by the “-“ character. The first part should consist of seven MIME64 characters (0-9A-Za-z+/), the second part of 32 hex characters that translate to 16 bytes.
Further we can see calls to c32 functions that result in:
t = c32(-1, argv, strlen(argv)+1) k = ~c32(t, argv, strlen(argv)+1)
Name of the function is a hint: it’s a СRC32 function, which is confirmed by the constant 0xEDB88320.
Next, we call the dde function (short for doDecrypt), and it receives the inverted output of the CRC32 function (encryption key) as the first argument, and the address and the size of the encrypted array as the second and third ones.
Decryption is performed by BTEA (block tiny encryption algorithm) based on the code taken from Wikipedia. We can guess that it’s BTEA from the use of the constant DELTA==0x9E3779B9. It’s also used in other algorithms on which BTEA is based on, but there are not many of them.
The key should be of 128-bit width, but we receive only 32 bits from CRC32. So we get three more DWORDs from the exk function (expand_key) by multiplying the previous value by the same DELTA.
However, the use of BTEA is uncommon. First of all, the algorithm supports a variable-width block size, and we use a block of 12-bytes width (there are processors that have 24-bit width registers and memory, then why should we use only powers of two). And in the second place, we switched encryption and decryption functions.
Since data stream is encrypted, cipher block chaining is applied. Enthropy is calculated for decrypted data in the cen function (calc_enthropy). If its value exceeds 7, the decryption result is considered incorrect and the program will exit.
The encryption key is 32-bit width, so it seems to be easily brute-forced. However, in order to check every key we need to decrypt 80 kilobytes of data, and then calculate enthropy. So brute-forcing the encryption key will take a lot of time.
But after the calculation, we call the pad function (strip_pad), which check and remove PKCS#7 padding. Due to CBC features, we need to decrypt only one block (the last one), extract N byte, check whether its range is between 1 and 12 (inclusive) and each of the last N bytes has value N. This allows reducing the number of operations needed to check one key. But if the last encrypted byte equals 1 (which is true for 1/256 keys), the check should be still performed.
The faster method is to assume that decoded data have a DWORD-aligned length (4 bytes). Then in the last DWORD of the last block there may be only one of three possible values: 0x04040404, 0x08080808 or 0x0C0C0C0C. By using heuristic and brute force methods you can run through all possible keys and find the right one in less than 20 minutes.
If all the checks after the decryption (entropy and the integrity of the padding) are successful, we call the fire_second_proc function, which simulates thelaunch of the second CPU and the loading of decrypted data of the firmware (modern devices usually havemore than one processor—with differentarchitectures).
If the second processorlaunches, it receives the user’s email and 16 bytes with the second part of the key via the function send_auth_data. At this point we made a mistake: there was the size of the string with the email instead of the size of the second part of the key.Part Two: FirmwareThe analysis of the second part is a little bit more complicated. There was no ELF file, only a memory image—without headings, function names, and other metadata. Type of the processorand load address were unknown as well.
We thought of brute force as the algorithm of determining the processor architecture. Open in IDA,set the following type, and repeat until IDA showssomething similar to a code. The brute force should lead to the conclusion that it is big-endian SPARC.
Now we need to determine the load address. The function 0x22E0 is not called, but it contains a lot of code. We can assume that is the entry point of the program, the start function.
In the third instruction of the start function, an unknown library function with one argument == 0x126F0 is called,and the same function is called from the start function four more times, always with arguments with similar values (0x12718, 0x12738, 0x12758, 0x12760).And in the middle of the program, starting from 0x2490, there are five lines with text messages:
00002490 .ascii "Firmware loaded, sending ok back."<0>000024B8 .ascii "Failed to retrieve email."<0>000024D8 .ascii "Failed to retrieve codes."<0>000024F8 .ascii "Gratz!"<0>00002500 .ascii "Sorry may be next time..."<0>
Assuming that the load address equals 0x126F0-0x2490 == 0x10260, then all the arguments will indicate thelines when calling the library function, and the unknown function turns out to be the printf function (or puts).
After changing the load base, the code will look something like this:
The value of 0x0BA0BAB0, transmitted to the function sub_12194, can be found in the first part of the task, in the function fire_second_proc, and is compared with what we obtain from read_pipe_u32 (). Thus sub_12194 should be called write_pipe_u32.
Similarly, two calls of the library function sub_24064 are memset (someVar, 0, 0x101) forthe email and code, while sub_121BC is read_pipe_str (), reversed write_pipe_str ()from the first part.
The first function (at offset 0 or address 0x10260) has typical constants of MD5_Init:
Next to the call to MD5_Init, it is easy to detect the function MD5_Update () and MD5_Final (), preceded by the call tothe library strlen ().
Not too many unknown functions are left in the start() function.
The sub_12480 function reverses the byte array of specified length. In fact, it’s memrev, which receives a code array input of 16 bytes.
Obviously, the sub_24040function checks whether the code is correct. The argumentstransfer the calculated value of MD5(email),the array filled in function sub_12394, and the number 16. It could be a call tomemcmp!
The real trick is happening in sub_12394. There is almost no hintsthere, but the algorithm is described by one phrase—the multiplication of binary matrix of the 128 by the binary vector of 128. The matrix is stored in the firmware at 0x240B8.
Thus, the code is correct if MD5(email) == matrix_mul_vector (matrix, code).
Calculating the KeyTo find the correct value of the code, you need to solve a system of binaryequations described by the matrix, where the right-hand side are the relevant bits of the MD5(email). If you forgot linear algebra: this is easily solved by Gaussian elimination.
If the right-hand side of the key is known (32 hexadecimal characters), we can try to guess the first seven characters so that the CRC32 calculation result was equal to the value found for the key BTEA. There are about 1024 of such values, and they can be quickly obtained by brute-force, or by converting CRC32 and checking valid characters.
Now you need to put everything together and get the key that will pass all the checks and will be recognized as validby our verifier :)We were afraid that no one would be able to solve the task from the beginning to the end. Fortunately, Victor Alyushin showed that our fears were groundless. You can find his write-up on the task at http://nightsite.info/blog/16542-phdays-2015-best-reverser.html. This is the second time Victor Alyushin has won the contest (he was the winner in 2013 as well).
A participant who wished to remain anonymous solved a part of the task and took second place.
Thanks to all participants!
According to The New York Times and Bloomberg News, four men in Florida and Israel have been arrested in connection to the 2014 hack against JPMorgan Chase, which resulted in gigabytes of bank data being exfiltrated. The news outlets, citing anonymous sources, did not fully explain how all the suspects were connected.
The United States Attorney in Manhattan announced that the two Florida men were arrested Tuesday and were formally charged with operating an unlicensed Bitcoin exchange, coin.mx.
However, their criminal complaints make no mention of JPMorgan Chase. The two Israelis were named as Gery Shalon and Ziv Orenstein and were arrested by authorities there. A fifth man, Joshua Samuel Aaron, an American living in Israel, is reportedly still at large.
A security researcher has taken umbrage at Italian malware developer Hacking Team after discovering that his open source exploit tools were included in Android surveillance software sold to governments around the world.
Collin Mulliner, well-known in security circles for exposing vulnerabilities in mobile devices, published a blog post Tuesday that attempts to set the record straight. To wit: his tools—which among other things surreptitiously capture conversations and other sounds within earshot of infected Android phones—were used without permission or notice by Hacking Team. He learned about the use only after the breach of Hacking Team computers, which resulted in a 400-gigabyte leak of confidential company documents, including these e-mails showing company engineers discussing Mulliner's tools.
In Tuesday's post, Mulliner wrote:
Patched with ms15-044 CVE-2015-1671 is described as TrueType Font Parsing Vulnerability.
Silverlight up to 5.1.30514.0 are affected, but note : most browser will warn that the plugin is outdated
Out of date Plugin protection in Chrome 39.0.2171.71Out of date ActiveX controls blocking in Internet Explorer 11
(introduced in August 2014)
and also consider that Microsoft announced the end of Silverlight at beginning of the month.
Angler EK :
Around the 1st of July some new Silverlight focused code appeared in Angler EK landing.
It even seems coders made some debug or something wrong as you could see this kind of popup several hours long on Angler EK.
Deofuscated snipet of Silverlight call exposed to Victims in Angler EK
2015-07-02I failed trying to get something else than a 0 size silverlight calls.
I heard about filled calls from Eset and EKWatcher.
The exploit sent was 3fff76bfe2084c454be64be7adff2b87 and appears to be a variation of CVE-2015-1671 (Silverlight 5 before 5.1.40416.00). I spent hours trying to get a full exploit chain....No luck. Only 0size calls.
But, it seems it's back today (or i get more lucky ? ) :
Disclaimer : many indicators are whispering it's the same variation of CVE-2015-1671, but I am still waiting for a strong confirmation
Silverlight 5.1.30514.0 exploited by Angler EK via CVE-2015-1671 in IE 11 on Windows 7
Silverlight 5.1_10411.0 exploited by Angler EK via CVE-2015-1671 in Chrome 39 on Windows 7
Silverlight 5.1.30514.0 exploited by Angler EK via CVE-2015-1671 in Firefox 38 on Windows 7
Two x86 - x64 dll are encoded in the payload stream with XTea Key : m0boo69biBjSmd3p
Silverlight dll in DotPeek after Do4dot
Sample in those pass : ac05e093930662a2a2f4605f7afc52f2
(Out of topic payload is bedep which then gather an adfraud module - you have the XTea key if you want to extract)
Files: Fiddler (password is malware)
[Edit : 2015-07-26, has been spread to all Angler Threads]
Thanks for help/tips :
Eset, Microsoft, Horgh_RCE, Darien Huss, Will Metcalf, EKWatcher.
Read more :
CVE-2013-0074/3896 (Silverlight) integrates Exploit Kits - 2013-11-13
A recently disclosed bug in OpenSSH software used to remotely access Internet-facing computers and servers allows attackers to make thousands of password guesses in a short period of time, a defect that could open systems to password cracking, a security researcher has warned.
Under normal circumstances, OpenSSH will allow just three or six login attempts before closing a connection, the researcher who goes by the moniker KingCope wrote in a blog post published last week. The recently discovered vulnerability, however, allows attackers to perform thousands of authentication requests during an open login window, which by default lasts two minutes. As a result, attackers who cycle through the most commonly used passwords face much better odds of finding the right one, since the vulnerability allows them to try many more candidates than they otherwise would.