Blog
Identifying Transport Insecurities

Any time an application makes a network request, you should protect the communication channel to guard against eavesdropping or tampering, regardless of whether the data being sent and received is sensitive. A common misconception is that applications need to encrypt only sensitive transactions such as authentication. Any data transfer or actions that take place over a cleartext channel, such as an HTTP request to a web application, are susceptible to modification, and this could have differing consequences depending on how the request is implemented. For example, consider an application that uses a UIWebView to make a simple request to a web application, transferring no sensitive data. An attacker in a position to perform a man‐in‐the‐middle attack against this communication is able to inject JavaScript to perform a cross‐site scripting attack. The consequences can vary depending on how the UIWebView is configured and range from something as simple as modifying the user interface, to stealing content from the filesystem; these types of attacks are detailed later in this chapter in the section, “Injecting into UIWebViews.” To identify when applications are making cleartext requests, you can apply the traditional methodology used for web or thick‐client applications. First, you may want to consider passively monitoring the traffic from the device using a packet‐capturing tool such as Wireshark (https://www.wireshark.org/). Alternatively, you may route your device’s communications through a proxy such as Burp Suite (http://www.portswigger.net/). This method helps identify HTTP‐based traffic only. To avoid the risk of unencrypted eavesdropping, many applications employ the Secure Socket Layer (SSL) or Transport Layer Security (TLS) to tunnel their communications. The SSL protocol and its successor, the TLS protocol, are widely accepted as the de facto standard for secure network communications on the Internet and elsewhere and are extensively used as a secure transport medium for HTTP. Although you may on occasion find applications that use a third‐party or custom implementation for SSL or TLS (such as OpenSSL or PolarSSL), the majority of applications on iOS use one of the APIs Apple provides. Apple provides three ways to implement SSL and TLS:

  • The URL loading system—This API contains a number of high‐level helper classes and methods such as NSURLConnection and NSURLSession that can be used to make secure HTTP requests. The URL loading system is perhaps the simplest method for making URL requests and for this reason is the most widely adopted.
  • The Carbon framework—This API is more granular than the URL loading system and gives developers a greater level of control over network requests; it is typically implemented using the CFNetwork class.
  • The Secure Transport API—This low‐level API is the foundation upon which the CFNetwork API and URL loading system are built. The API provides the greatest control over the transport and is relatively complex to implement. For this reason, developers rarely use it directly, preferring the abstracted approach offered by CFNetwork and the URL loading system.

Regardless of the API that your application is using, an SSL or TLS connec- tion can be weakened in number of ways, and as a security professional or a developer, you should be aware of them. We will now walk through some of the common implementation flaws that can occur when using these APIs to make SSL/TLS connections.

Certificate Validation

SSL and TLS are built on the fundamental concept of certificate‐based authen- tication; this ensures that you are communicating with the server you intended to, and it also prevents eavesdropping and tampering attacks. Any weakening in the validation of the certificate chain can have serious consequences for an application and may leave user data exposed and vulnerable to eavesdropping and modification. Assuming certificate pinning is not in use, perhaps the most dangerous thing an application can do when setting up an SSL session is to accept a certificate that is not signed by a trusted certificate authority (CA). The legitimacy of a self‐signed certificate cannot be guaranteed because it has not undergone the verification process that is performed by the certificate authority. An application accepting a self‐signed certificate is therefore unable to verify that the server presenting the certificate is indeed the server it purports to be, which leaves the app susceptible to eavesdropping and tampering from any adversary who is suitably positioned in the network. As a security professional conducting an audit of an iOS application, verify- ing whether the app permits self‐signed certificates is something that should be in your methodology. A number of ways exist for an application to permit self‐signed certificates depending on which API it is using; some common ways are detailed here.

When you’re using the NSURLConnection class, self‐signed certificates can be permitted within the didReceiveAuthenticationChallenge delegate method in a way similar to the following:

– (void)connection:(NSURLConnection *)connection \ didReceiveAuthenticationChallenge: \ (NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; return; } }

The NSURLSession class is the preferred way to implement HTTPS using URL loading in applications using the iOS 7 SDK or higher. In such cases, during a code review, you might find that self‐signed certificates are permitted, using code similar to the following:

– (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { if([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { NSURLCredential *credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust]; completionHandler(NSURLSessionAuthChallengeUseCredential, credential); } }

An application that permits self‐signed certificates using the Carbon frame- work, however, might set up an SSL settings dictionary with the kCFStreamSSLValidatesCertificateChain constant set to false in a similar way to the following code:

NSDictionary *sslSettings = [NSDictionary dictionaryWithObjectsAndKeys: (id)kCFBooleanFalse, (id)kCFStreamSSLValidatesCertificateChain, nil];
CFReadStreamSetProperty(readStream, kCFStreamPropertySSLSettings, sslSettings);

When an application is using the Secure Transport API, you may find that the kSSLSessionOptionBreakOnServerAuth option is set on the SSL session. This disables the API’s built‐in certificate validation but does not necessarily mean that the application does not implement its own custom trust evalua- tion routines, and therefore you should further explore the code to check for implantation of chain validation code. Here is an example of how you may set this option on an SSL session:

SSLSetSessionOption(ssl_ctx->st_ctxr, kSSLSessionOptionBreakOnServerAuth, true)

 

Identity theft

Defining Identity Theft

Identity theft is a crime involving someone impersonating a victim for the purpose of financial gain or other personal gain.The victim could be an individual or a business, and the perpetrator could be one person or several individuals acting as part of a theft or fraud ring. Often, the theft of a person’s or business’s identity is used to commit other crimes as well, such as credit card fraud, submitting loan applications in another person’s name, and so on.Read More

Cross-Site Scripting (What is XSS?)

Cross-Site Scripting (XSS)

1 Overview

Cross-site scripting (XSS) is a type of vulnerability commonly found in web applications. This vulnerability makes it possible for attackers to inject malicious code into victim’s web browser. Using this malicious code, the attackers can steal the victim’s credentials, such as cookies. The access control policies employed by the browser to protect those credentials can be bypassed by exploiting the XSS vulnerability. Vulnerabilities of this kind can potentially lead to large-scale attacks. To demonstrate what attackers can do by exploiting XSS vulnerabilities, we have set up a web-based message board using phpBB. We modified the software to introduce an XSS vulnerability in this message board; this vulnerability allows users to post any arbitrary message to the board, including JavaScript programs. Students need to exploit this vulnerability by posting some malicious messages to the message board; users who view these malicious messages will become victims. The attackers’ goal is to post forged messages for the victims.Read More

DNS ID Hacking

You might be wondering what DNS ID Hacking is. DNS ID Hacking isn’t a usual way of hacking/spoofing such jizz or any-erect. This method is based on a vulnerability on DNS Protocol. More brutal, the DNS ID hack/spoof is very efficient is very strong because there is no generation of DNS daemons that escapes from it.Read More

Blind SQL Injection Discovery

While performing web application and penetration testing following scenario is very common and it hides potential exploitable SQL injection scenario:

1. We have SQL injection point but it is not throwing any error message out as part of its response. Application is sending customized error page which is not revealing any signature by which we can deduce potential SQL flaw.Read More

What is a compiler?

A compiler is a program that translates a high-level language program into a functionally equivalent low-level language program. So, a compiler is basically a translator whose source language (i.e., language to be translated) is the high-level language, and the target language is a low-level language; that is, a compiler is used to implement a high-level language on a computer.

Read More

Python Tops The List of Programming Languages by Popularity

Python is a widely used high-level programming language for general-purpose programming,  first released in 1991. An interpreted language, Python has a design philosophy which emphasizes code readability, and a syntax which allows programmers to express concepts in fewer lines of code than might be used in languages such as C++ or Java. The language provides constructs intended to enable writing clear programs on both a small and large scale.

Python features a dynamic type system and automatic memory management and supports multiple programming paradigms, including object-oriented, imperative, functional programming, and procedural styles. It has a large and comprehensive standard library.

Python interpreters are available for many operating systems, allowing Python code to run on a wide variety of systems. CPython, the reference implementation of Python, is open source software[26] and has a community-based development model, as do nearly all of its variant implementations. CPython is managed by the non-profit Python Software Foundation.

Social Engineering Attacks

What is Social Engineering?

Social engineering is the art of gaining access to buildings, systems or data by exploiting human psychology, rather than by breaking in or using technical hacking techniques. For example, instead of trying to find a software vulnerability, a social engineer might call an employee and pose as an IT support person, trying to trick the employee into divulging his password. The goal is always to gain the trust of one or more of your employees. Famous hacker Kevin Mitnick helped popularize the term “social engineering” in the ‘90s, but the simple idea itself (tricking someone into doing something or divulging sensitive information) has been around for ages. What Social Engineers Want The goal for many social engineers is to obtain personal information that can either directly lead them to financial or identity theft or prepare them for a more targeted attack. They also look for ways to install malware that gives them better access to personal data, computer systems or accounts, themselves. In other cases, social engineers are looking for information that leads to competitive advantage. Items that scammers find valuable include the following:

  • Passwords
  • Account numbers
  • Keys
  • Any personal information
  • Access cards and identity badges
  • Phone lists
  • Details of your computer system
  • The name of someone with access privileges
  • Information about servers, networks, non-public URLs

Read More