Tor Guide

What Is Metasploit?   June 27, 2018

Tor Guide

If you want to browse through a vast sea of unindexed internet, aka the Dark Web, you will have to use something called Tor, otherwise you won’t be able to access the Darknet inside Deep Web.

So, what is Tor and why do I need it?

Tor stands for The Onion Router. You’ll soon see why the onion and not some other veggie.

It provides fairly good level of online anonymity, privacy and security to the user. It’s  the most well know tool for internet privacy

If you’ve ever stumbled upon a 16-character alpha-semi-numeric hashes followed by .onion, and tried to open it in your regular browser; it returned the “This webpage is not available” result, right? This address can only be accessed by Tor browser, specially designed to provide a safe and private environment.

Tor browser bundle can be downloaded for free here https://www.torproject.org/download/download-easy.html.en.There is no need for installation; you simply extract it anywhere on your computer and run it.

If you open the extracted folder with Browser folder in it, you will notice that the actual application is called Firefox, and that’s what Tor browser actually is – a modified Firefox browser with a set of plugins installed.

However, if you try to install any other plugin you might compromise your anonymity online, and it is not advisable to make any changes in settings unless you know exactly what you are doing.

Don’t even enable scripts or flash player, because those applications demand direct internet connection, not via Tor network, which will compromise your IP address and other information and make you an easy target for hackers.

Tor network can also be used for online chatting. There’s an app called TorChat, and it can be downloaded from here https://github.com/prof7bit/TorChat. Many journalists use it for interviews with their confidential sources or whistleblowers.

To put it briefly…

…Tor is essential; there are no two ways about it. If you wish to browse the deep web, you will have to use Tor. However as I mentioned, it will also protect your anonymity by passing your computer through several relays.

Drawbacks:

The main drawback that I see with it is that it can lull you into a false sense of security. For anonymous browsing, it’s an excellent first step, but it’s not the only one you need to take.

For more protection, I would strongly advise using Tor within a VPN service that allows P2P (peer to peer) networking.

Without this, while the sites you visit can’t be seen, any eavesdroppers will be able to see that you are using Tor. While that is not illegal by any means, it does stand out, so you lose some of the anonymity you fought to get.

Other non-important drawbacks include not being able to run torrents over Tor, and not being able to use browser plugins.

How deep down the rabbit hole do you wish to go?

Those were really the basics of Tor browser and Tor network and these would probably suffice if you only wish to explore and experiment with it.

But if you want to know the core mechanics behind Tor network and the way it provides the anonymity and privacy, I’ll be happy to get into more details about it.

Regular internet

Before going into any details about Tor, let me first cover how the regular internet works.

Let’s say that Alvin for example wishes to send a message to Barbara, or visit Barbara’s webpage. When Alvin sends his message, a data package is created,containingAlvin’s message, his and Barbara’s IP addresses.

This data package travels directly from Alvin’s to Barbara’s computer, making it an easy target for anyone who wishes to intercept the message or learn the information about Alvin or Barbara.

Spooky, isn’t it? Even if your messages aren’t confidential at all; why would you allow anybody to have access to you messages? It’s insane.

So, if you want to keep your privacy intact, I suggest using Tor, even for browsing that is not related to Deep Web.

Almighty Tor

How it works?

Well, as mentioned earlier, here is the detailed explanation for the choice of a veggie. Tor stands for The Onion Router and Tor Network is a series of connected routers.

When using Tor, Alvin’s data package would firstly be encrypted, and then sent through three routers, called nodes, before the data package reaches Barbara.

Mathematical Cryptography comes first

Remember that data package that was created when Alvin sent his message to Barbara? Now using Tor, that data package is encrypted – not once, but three times.

Mathematical encryption basically means that you take a set of information, Alvin’s message, and together with the encryption key you put it in a box.

When opening the box without the decryption key, the message looks totally different than the original data package. It can look like some other message or like a random messed-up code.

To decrypt the code you simply put in reverse – take the encrypted data package and the decryption key, put them in the box together, and you get the original message when you open the box. Simple, right?

Now, Tor takes this encrypted data package and encrypts it twice more, both times using different encryption keys.

Journey through a tunnel

As mentioned earlier, Tor is a series of routers connected to form a tunnel. They’re “a set of relays volunteering their resources to forward traffic for Tor users.” Now let’s see how they work.

After encrypting the data package 3 times, it’s ready for sendoff. Unlike regular network, the data package is not going directly from Alvin to Barbara.

Its first stop is the entry node – the first router or node as they call it.

In order for the data package to reach the entry node it must be addressed to it, right? So, the package contains information about the receiver and the sender, in other words Alvin and the entry node.

Once the data package reaches the entry node it’s being decrypted only one time. One layer of encrypted information peels and the other will be peeled when it reaches the middle node.

Once the data package reaches the middle node the process repeats – one more layer of encryption down.

It kind of reminds the onion layers, no? The package that reached the middle node contains a different set of information about the sender and the receiver: the sender is the entry node and the receiver is the middle node.

Now, Alvin’s message is sent to the last router, the exit node. The last layer of encryption is peeled at the exit node.

The information of the data package that exit node has received is again – different. It contains info about the middle node as the sender and the receiver – the exit node.

Once the message has been decrypted at the exit node, it is finally ready for Barbara.

Barbara gets the message that Alvin sent her, but the information about the sender and receiver is different.

Barbara knows it came from Alvin, because he probably signed it, but if anybody intercepts the message and tries to find out who sent it to Barbara, the data package will only give him information about the exit node as the sender.

The only possible way to reconstruct the journey of the message is to have access to all routers and have all three decryption keys.

So, now that you know how Tor works, if you still feel you need more protection, try using VPN with Tor, but that’s the story for another time.

What Is Penetration Testing?

What Is Penetration Testing?

What Is Penetration Testing?   June 25, 2018

What Is Penetration Testing?

A penetration test, also known as a pen test, is a simulated cyberattack against your computer system to check for exploitable vulnerabilities. In the context of web application security, penetration testing is commonly used to augment a web application firewall (WAF).

Pen testing can involve the attempted breaching of any number of application systems, (e.g., application protocol interfaces (APIs), frontend/backend servers) to uncover vulnerabilities, such as unsanitized inputs that are susceptible to code injection attacks.

Insights provided by the penetration test can be used to fine-tune your WAF security policies and patch detected vulnerabilities.

The process typically identifies the target systems and a particular goal—then reviews available information and undertakes various means to attain the goal. A penetration test target may be a white box (which provides background and system information) or black box (which provides only basic or no information except the company name). A penetration test can help determine whether a system is vulnerable to attack if the defenses were sufficient, and which defenses (if any) the test defeated.

Security issues that the penetration test uncovers should be reported to the system owner. Penetration test reports may also assess potential impacts to the organization and suggest countermeasures to reduce risk.

The goals of a penetration test vary depending on the type of approved activity for any given engagement with the primary goal focused on finding vulnerabilities that could be exploited by a nefarious actor and informing the client of those vulnerabilities along with recommended mitigation strategies.

Penetration tests are a component of a full security audit. For example, the Payment Card Industry Data Security Standard requires penetration testing on a regular schedule, and after system changes.

Flaw hypothesis methodology is a systems analysis and penetration prediction technique where a list of hypothesized flaws in a software system are compiled through analysis of the specifications and documentation for the system. The list of hypothesized flaws is then prioritized on the basis of the estimated probability that a flaw actually exists, and on the ease of exploiting it to the extent of control or compromise. The prioritized list is used to direct the actual testing of the system.

PENETRATION TESTING STAGES

The pen testing process can be broken down into five stages.

1. Planning and reconnaissance
The first stage involves:
• Defining the scope and goals of a test, including the systems to be addressed and the testing methods to be used.
• Gathering intelligence (e.g., network and domain names, mail server) to better understand how a target works and its potential vulnerabilities.
2. Scanning
The next step is to understand how the target application will respond to various intrusion attempts. This is typically done using:
• Static analysis – Inspecting an application’s code to estimate the way it behaves while running. These tools can scan the entirety of the code in a single pass.
• Dynamic analysis – Inspecting an application’s code in a running state. This is a more practical way of scanning, as it provides a real-time view into an application’s performance.
3. Gaining access
This stage uses web application attacks, such as cross-site scripting, SQL injection and backdoors, to uncover a target’s vulnerabilities. Testers then try and exploit these vulnerabilities, typically by escalating privileges, stealing data, intercepting traffic, etc., to understand the damage they can cause.
4. Maintaining access
   The goal of this stage is to see if the vulnerability can be used to achieve a persistent presence in the exploited system— long enough for a bad actor to gain in-depth access. The idea is to imitate advanced persistent threats, which often remain in a system for months in order to steal an organization’s most sensitive data.
5. Analysis
The results of the penetration test are then compiled into a report detailing:
• Specific vulnerabilities that were exploited
• Sensitive data that was accessed
• The amount of time the pen tester was able to remain in the system undetected
This information is analyzed by security personnel to help configure an enterprise’s WAF settings and other application security solutions to patch vulnerabilities and protect against future attacks.

PENETRATION TESTING METHODS

EXTERNAL TESTING

External penetration tests target the assets of a company that are visible on the internet, e.g., the web application itself, the company website, and email and domain name servers (DNS). The goal is to gain access and extract valuable data.

INTERNAL TESTING

In an internal test, a tester with access to an application behind its firewall simulates an attack by a malicious insider. This isn’t necessarily simulating a rogue employee. A common starting scenario can be an employee whose credentials were stolen due to a phishing attack.

BLIND TESTING

In a blind test, a tester is only given the name of the enterprise that’s being targeted. This gives security personnel a real-time look into how an actual application assault would take place.

DOUBLE BLIND TESTING

In a double blind test, security personnel have no prior knowledge of the simulated attack. As in the real world, they won’t have any time to shore up their defenses before an attempted breach.

TARGETED TESTING

In this scenario, both the tester and security personnel work together and keep each other appraised of their movements. This is a valuable training exercise that provides a security team with real-time feedback from a hacker’s point of view.

PENETRATION TESTING AND WEB APPLICATION FIREWALLS

Penetration testing and WAFs are exclusive, yet mutually beneficial security measures.

For many kinds of pen testing (with the exception of blind and double blind tests), the tester is likely to use WAF data, such as logs, to locate and exploit an application’s weak spots.

In turn, WAF administrators can benefit from pen testing data. After a test is completed, WAF configurations can be updated to secure against the weak spots discovered in the test.

Finally, pen testing satisfies some of the compliance requirements for security auditing procedures, including PCI DSS and SOC 2. Certain standards, such as PCI-DSS 6.6, can be satisfied only through the use of a certified WAF. Doing so, however, doesn’t make pen testing any less useful due to its aforementioned benefits and ability to improve on WAF configurations.

What Is a Penetration Testing Tool?

Penetration testing tools are used as part of a penetration test(Pen Test) to automate certain tasks, improve testing efficiency and discover issues that might be difficult to find using manual analysis techniques alone. Two common penetration testing tools are static analysis tools and dynamic analysis tools. CA Veracode performs both dynamic and static code analysis and finds security vulnerabilities that include malicious code as well as the absence of functionality that may lead to security breaches. For example, CA Veracode can determine whether sufficient encryption is employed and whether a piece of software contains any application backdoors through hard-coded user names or passwords. CA Veracode's binary scanning approach produces more accurate testing results, using methodologies developed and continually refined by a team of world-class experts. And because CA Veracode returns fewer false positives, penetration testers and developers can spend more time remediating problems and less time sifting through non-threats.

Manual Penetration Test

Manual penetration testing layers human expertise on top of professional penetration testing software and tools, such as automated binary static and automated dynamic analysis, when assessing high assurance applications. A manual penetration test(Pen Test) provides complete coverage for standard vulnerability classes, as well as other design, business logic and compound flaw risks that can only be detected through manual testing.

Penetration Testing Methodology

Once the threats and vulnerabilities have been evaluated, the penetration testing should address the risks identified throughout the environment. The penetration testing should be appropriate for the complexity and size of an organization. All locations of sensitive data; all key applications that store, process or transmit such data; all key network connections; and all key access points should be included. The penetration testing should attempt to exploit security vulnerabilities and weaknesses throughout the environment, attempting to penetrate both at the network level and key applications. The goal of penetration testing is to determine if unauthorized access to key systems and files can be achieved. If access is achieved, the vulnerability should be corrected and the penetration testing re-performed until the test is clean and no longer allows unauthorized access or other malicious activity.

What Is HTTP?

What Is HTTP?

What Is HTTP?   June 25, 2018

What Is HTTP?

In this post I will explain what HTTP is.

HTTP (Hypertext Transfer Protocol) provides a network protocol standard that web browsers and servers use to communicate. It's easy to recognize this when visiting a website because it's written right in the URL (e.g. https://eztechnicalbots.blogspot.com/ ).

This protocol is similar to others like FTP in that it's used by a client program to request files from a remote server. In the case of HTTP, it's usually a web browser that requests HTML files from a web server, which are then displayed in the browser with text, images, hyperlinks, etc.

HTTP is what's called a "stateless system." What this means is that unlike other file transfer protocols such as FTP, the HTTP connection is dropped once the request has been made. So, once your web browser sends the request and the server responds with the page, the connection is closed.

Since most web browsers default to HTTP, you can type just the domain name and have the browser auto-fill the "http://" portion.

Components of HTTP-based systems

HTTP is a client-server protocol: requests are sent by one entity, the user-agent (or a proxy on behalf of it). Most of the time the user-agent is a Web browser, but it can be anything, for example a robot that crawls the Web to populate and maintain a search engine index.

Each individual request is sent to a server, which will handle it and provide an answer, called the response. Between this request and response there are numerous entities, collectively designated as proxies, which perform different operations and act as gateways or caches, for example.

In reality, there are more computers between a browser and the server handling the request: there are routers, modems, and more. Thanks to the layered design of the Web, these are hidden in the network and transport layers. HTTP is on top at the application layer. Although important to diagnose network problems, the underlying layers are mostly irrelevant to the description of HTTP.

Client: the user-agent

The user-agent is any tool that acts on the behalf of the user. This role is primarily performed by the Web browser; a few exceptions being programs used by engineers, and Web developers to debug their applications.

The browser is always the entity initiating the request. It is never the server (though some mechanisms have been added over the years to simulate server-initiated messages).

To present a Web page, the browser sends an original request to fetch the HTML document from the page. It then parses this file, fetching additional requests corresponding to execution scripts, layout information (CSS) to display, and sub-resources contained within the page (usually images and videos). The Web browser then mixes these resources to present to the user a complete document, the Web page. Scripts executed by the browser can fetch more resources in later phases and the browser updates the Web page accordingly.

A Web page is a hypertext document. This means some parts of displayed text are links which can be activated (usually by a click of the mouse) to fetch a new Web page, allowing the user to direct their user-agent and navigate through the Web. The browser translates these directions in HTTP requests, and further interprets the HTTP responses to present the user with a clear response.

The Web server

On the opposite side of the communication channel, is the server which serves the document as requested by the client. A server presents only as a single machine virtually: this is because it may actually be a collection of servers, sharing the load (load balancing) or a complex piece of software interrogating other computers (like cache, a DB server, e-commerce servers, …), totally or partially generating the document on demand.

A server is not necessarily a single machine, but several servers can be hosted on the same machine. With HTTP/1.1 and the Host header, they may even share the same IP address.

Proxies

Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at either the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, or not (changing requests going through them), and may perform numerous functions:

• caching (the cache can be public or private, like the browser cache)
• filtering (like an antivirus scan, parental controls, …)
• load balancing (to allow multiple servers to serve the different requests)
• authentication (to control access to different resources)
• logging (allowing the storage of historical information)

Basic aspects of HTTP

HTTP is simple

Even with more complexity, introduced in HTTP/2 by encapsulating HTTP messages into frames, HTTP is generally designed to be simple and human readable. HTTP messages can be read and understood by humans, providing easier developer testing, and reduced complexity for new-comers.

HTTP is extensible

Introduced in HTTP/1.0, HTTP headers made this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.

HTTP is stateless, but not sessionless

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

HTTP and connections

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP subsequently relies on the TCP standard, which is connection-based, even though a connection is not always required.

HTTP/1.0 opened a TCP connection for each request/response exchange, introducing two major flaws: opening a connection needs several round-trips of messages and therefore slow, but becomes more efficient when several messages are sent, and regularly sent: warm connections are more efficient than cold ones.

In order to mitigate these flaws, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the Connection header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm, and more efficient.

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

What can be controlled by HTTP

This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.

Here is a list of common features controllable with HTTP.

• Cache
  How documents are cached can be controlled by HTTP. The server can instruct proxies, and clients, what to cache and for how long. The client can instruct intermediate cache proxies to ignore the stored document.
• Relaxing the origin constraint
  To prevent snooping and other privacy invasions, Web browsers enforce strict separation between Web sites. Only pages from the same origin can access all the information of a Web page. Though such constraint is a burden to the server, HTTP headers can relax this strict separation server-side, allowing a document to become a patchwork of information sourced from different domains (there could even be security-related reasons to do so).
• Authentication
  Some pages may be protected so only specific users can access it. Basic authentication may be provided by HTTP, either using the WWW-Authenticate and similar headers, or by setting a specific session using HTTP cookies.
• Proxy and tunneling
  Servers and/or clients are often located on intranets and hide their true IP address to others. HTTP requests then go through proxies to cross this network barrier. Not all proxies are HTTP proxies. The SOCKS protocol, for example, operates at a lower level. Others, like ftp, can be handled by these proxies.
• Sessions
  Using HTTP cookies allows you to link requests with the state of the server. This creates sessions, despite basic HTTP being a state-less protocol. This is useful not only for e-commerce shopping baskets, but also for any site allowing user configuration of the output.

HTTP flow

When the client wants to communicate with a server, either being the final server or an intermediate proxy, it performs the following steps:

1. Open a TCP connection: The TCP connection will be used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same.

   GET / HTTP/1.1
   Host: developer.mozilla.org
   Accept-Language: fr

3. Read the response sent by the server:

   HTTP/1.1 200 OK
   Date: Sat, 09 Oct 2010 14:28:02 GMT
   Server: Apache
   Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
   ETag: "51142bc1-7449-479b075b2891b"
   Accept-Ranges: bytes
   Content-Length: 29769
   Content-Type: text/html
   
   <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

4. Close or reuse the connection for further requests.

If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.

HTTP Messages

HTTP/1.1 and earlier HTTP messages are human-readable. In HTTP/2, these messages are embedded into a new binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

There are two types of HTTP messages, requests and responses, each with its own format.

Requests

An example HTTP request:

Requests consists of the following elements:

• An HTTP method, usually a verb like GET, POST or a noun like OPTIONS or HEAD that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using GET) or post the value of an HTML form (using POST), though more operations may be needed in other cases.
• The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the protocol (http://), the domain (here developer.mozilla.org), or the TCP port (here 80).
• The version of the HTTP protocol.
• Optional headers that convey additional information for the servers.
• Or a body, for some methods like POST, similar to those in responses, which contain the resource sent.

Responses

An example response:

Responses consist of the following elements:

• The version of the HTTP protocol they follow.
• A status code, indicating if the request has been successful, or not, and why.
• A status message, a non-authoritative short description of the status code.
• HTTP headers, like those for requests.
• Optionally, a body containing the fetched resource.

APIs based on HTTP

The most commonly used API based on top of HTTP is the XMLHttpRequest API, which can be used to exchange data between a user agent and a server.

Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the EventSource interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate Event objects, delivering them to the event handlers that have been registered for the events' type if known, or to the onmessage event handler if no type-specific event handler was established.

How HTTP Works

HTTP is an application layer protocol built on top of TCP that uses a client-server communication model. HTTP clients and servers communicate via HTTP request and response messages. The three main HTTP message types are GET, POST, and HEAD.

• HTTP GET messages sent to a server contain only a URL. Zero or more optional data parameters may be appended to the end of the URL. The server processes the optional data portion of the URL, if present, and returns the result (a web page or element of a web page) to the browser.
• HTTP POST messages place any optional data parameters in the body of the request message rather than adding them to the end of the URL.
• HTTP HEAD request works the same as GET requests. Instead of replying with the full contents of the URL, the server sends back only the header information (contained inside the HTML section).

The browser initiates communication with an HTTP server by initiating a TCP connection to the server. Web browsing sessions use server port 80 by default although other ports such as 8080 are sometimes used instead.

Once a session is established, the user triggers the sending and receiving of HTTP messages by visiting the web page.