Henrique Schunck

Hello

Get a powerful SEO Boost with our all in one SEO MAX Package and beat your
competition within just 1 month

Whitehat SEO plan, check out more details here
https://www.creative-digital.co/product/seo-max-package/

thanks and regards
Creative Digital

Unsubscribe:
https://mgdots.co/unsubscribe/

You might have harvested many things upto now but what we are going to harvest today is something bad :)

Requirements:

A Linux box (I'm using Kali Linux)
theharvester program (already available in Kali Linux)

So what does theharvester harvest? Well it harvests email addresses. theharvester is an Information gathering tool. If you want a list of emails to spam you can get that easily from theharvester tool and go on Spamming (I'm joking its illegal). It's a security tool that helps you in pentesting an organization (as always it can be used for evil as well). You can gather emails from an organization and look for potential victims to attack or use brute-force techniques to get their passwords or Social Engineer them into doing something that will let you compromise some or all systems in the organization. Uhh there are so many things that you can do when you have access to someone's email address.

OK stop talking and start doing.

Fire up a terminal in your kali box and type this command:

theharvester -d hotmail.com -l 50 -b google

In a small amount of time you'll see your terminal flooded with 200 hotmail.com email address. What does this command mean?

theharvester is the tool name that we are using
-d <domain_name> specifies the domain (or website) who's email addresses we're looking for, in our case it was hotmail.com
-l <number> specifies the number of results that we want in the output, I limited it to 50
-b <source> specifies the source on which to look for email addresses, I specified google as the source

Besides google we can specify any of the follow as source:
google, googleCSE, bing, bingapi, pgp, linkedin, google-profiles, people123, jigsaw, twitter, googleplus, all
Here the last entry all means look in every available source.

Let's say you wanted to look in every available source they you should specify the following command:

theharvester -d hotmail.com -b all

-f is another great flag which can be utilized to save the output in case we want to SPAM them later (just kidding) or for other reasons (I'm thinking positive). -f flag saves the result in html or xml format. Let's do just that:

theharvester -d gmail.com -l 50 -b google -f emailaddresses.html

here -f flag is followed by the location where we want to store the file and the name of file, in our case we stored it in our pwd (present working directory) with the name emailaddresses.html.

Above picture shows an html output generated by harvester.

That's it for this tutorial hope to see you next time!

More info

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

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

The Double Ratchet

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

Conceptual depiction of Double Ratchet in Signal two years ago (acknowledgments were only protected between client and server). The asymmetric ratchet fully updates the local secrets after one round-trip of payload messages.

Research on Ratcheting

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

Protecting Acknowledgments ...

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

... Supports Asymmetric Ratchet

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

Conceptual depiction of Double Ratchet in Signal now (acknowledgments encrypted). The asymmetric ratchet fully updates the local secrets after an acknowledgment for a message is received.

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

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

[1] https://eprint.iacr.org/2016/1013.pdf
[2] https://eprint.iacr.org/2016/1028.pdf
[3] https://eprint.iacr.org/2018/296.pdf
[4] https://eprint.iacr.org/2018/553.pdf
[5] https://eprint.iacr.org/2018/889.pdf
[6] https://eprint.iacr.org/2018/954.pdf
[7] https://eprint.iacr.org/2018/1037.pdf
[8] https://eprint.iacr.org/2017/713.pdf
[9] https://web-in-security.blogspot.com/2017/07/insecurities-of-whatsapps-signals-and.html
[10] https://web-in-security.blogspot.com/2018/01/group-instant-messaging-why-baming.html

More info

Download Here

Are you tired of managing your tens of thousands of files like jpgs, pngs, or others and you want a way to manage them as quick as possible then RenApp is solution for all problem.

RenApp lets you change names of many files of a particular type to a common name with added numbering. So no more time wasting in file management just four clicks and your files will be ordered.

Beside that RenApp can clean your folders and subfolders from backup files of .bak or .*~ extension. Removing backup files in order to make space available manually is a tedious work and can take lots of time but why do it that we've got RenApp just locate the folder and click remove it'll remove them all from that folder and its subfolders.

Some of the features of RenApp are as:

Rename files to a common name.
Rename files of different extensions to a common name in one shot
Remove backup files from folder and subfolders.

R RenApp is free and Opensource, written in Python with QT interface. Check out the source code at sourceforge.

Continue reading

Although REST has been a dominant choice for API design for the last decade, there is still little dedicated security research on the subject of REST APIs. The popularity of REST contrasts with a surprisingly small number of systematic approaches to REST security analysis. This contrast is also reflected in the low availability of analysis tools and best security practices that services may use to check if their API is secure.

In this blog series, we try to find reasons for this situation and what we can do about it. In particular, we will investigate why general REST security assessments seem more complicated than other API architectures. We will likewise discuss how we may still find systematic approaches for REST API analysis despite REST's challenges. Furthermore, we will present REST-Attacker, a novel analysis tool designed for automated REST API security testing. In this context, we will examine some of the practical tests provided by REST-Attacker and explore the test results for a small selection of real-world API implementations.

Author

Christoph Heine

Overview

Understanding the Problem with REST

When evaluating network components and software security, we often rely on specifications for how things should work. For example, central authorities like the IETF standardize many popular web technologies such as HTTP, TLS or DNS. API architectures and designs can also be standardized. Examples of these technologies are SOAP and the more recent GraphQL language specification. Standardization of web standards usually influences their security. Drafting may involve a public review process before publication. This process can identify security flaws or allow the formulation of official implementation and usage best practices. Best practices are great for security research as a specification presents clear guidelines on how an implementation should behave and why.

The situation for REST is slightly different. First of all, REST is not a standard in the sense that there is no technical specification for its implementation. Instead, REST is an architecture style which is more comparable to a collection of paradigms (client-server architecture, statelessness, cacheability, uniform interface, layering, and code-on-demand). Notably, REST has no strict dependency on other web technologies. It only defines how developers should use components but not what components they should use. This paradigm makes REST very flexible as developers are not limited to any particular protocol, library, or data structure.

Furthermore, no central authority could define rules or implementation guidelines. Roy Fielding created the original definition of REST as a design template for the HTTP/1.1 standard in 2000. It is the closest document resembling a standard. However, the document merely explains the REST paradigms and does not focus on security implications.

The flexibility of the REST architecture is probably one of the primary reasons why security research can be challenging. If every implementation is potentially different, how are we supposed to create common best practices, let alone test them consistently across hundreds of APIs? Fortunately for us, not every API tries to reinvent the wheel entirely. In practice, there are a lot of similarities between implementations that may be used to our advantage.

Generalizing REST Security

The most glaring similarity between REST API implementations is that most, if not all, are based on HTTP. If you have worked with REST APIs before, this statement might sound like stating the obvious. However, remember that REST technically does not require a specific protocol. Assuming that every REST API uses HTTP, we can use it as a starting point for a generalization of REST API security. Knowing that we mainly deal with HTTP is also advantageous because HTTP - unlike REST - is standardized. Although HTTP is still complex, it gives us a general idea of what we can expect.

Another observation is that REST API implementations reuse several standardized components in HTTP for API communication. Control parameters and actions in an API request are mapped to components in a generic HTTP request. For example, a resource that an API request operates on, is specified via the HTTP URL. Actions or operations on the said resource are identified and mapped to HTTP methods defined by the HTTP standard, usually GET, POST, DELETE, PUT, and PATCH. API operations retain their intended action from HTTP, i.e., GET retrieves a resource, DELETE removes a resource, and so on. In REST API documentation, we can often find a description of available API endpoints using HTTP "language":

Since the URL and the HTTP method are sufficient to build a basic HTTP request, we can potentially create an API requests if we know a list of REST endpoints. In practice, the construction of such requests can be more complicated because the API may have additional parameter requirements for their requests, e.g., query, header, or body content. Another problem is finding valid IDs of resources can be difficult. Interestingly, we can infer each endpoint's action based on the HTTP method, even without any context-specific knowledge about the API.

We can also find components taken from the HTTP standard in the API response. The requested operation's success or failure is usually indicated using HTTP status codes. They retain their meaning when used in REST APIs. For example, a 200 status code indicates success, while a 401 status code signifies missing authorization (in the preceding API request). This behavior again can be inferred without knowing the exact purpose of the API.

Another factor that influences REST's complexity is its statelessness paradigm. Essentially, statelessness requires that the server does not keep a session between individual requests. As a result, every client request must be self-contained, so multi-message operations are out of the picture. It also effectively limits interaction with the API to two HTTP messages: client request and server response. Not only does this make API communication easier to comprehend, but it also makes testing more manageable since we don't have to worry as much about side effects or keeping track of an operations state.

Implementing access control mechanisms can be more complicated, but we can still find general similarities. While REST does not require any particular authentication or authorization methods, the variety of approaches found in practice is small. REST API implementations usually implement a selection of these methods:

HTTP Basic Authentication (user authentication)
API keys (client authentication)
OAuth2 (authorization)

Two of these methods, OAuth2 and HTTP Basic Authentication, are standardized, while API keys are relatively simple to handle. Therefore, we can generalize access control to some degree. However, access control can be one of the trickier parts of API communication as there may be a lot of API-specific configurations. For example, OAuth2 authorization allows the API to define multiple access levels that may be required to access different resources or operations. How access control data is delivered in the HTTP message may also depend on the API, e.g., by requiring encoding of credentials or passing them in a specified location of the HTTP message (e.g. header, query, or body).

Finding a Systematic Approach for REST API Analysis

So far, we've only discussed theoretical approaches scatching a generic REST API analysis. For implementing an automated analysis tool, we need to adopt the hints that we used for our theoretical API analyses to the tool. For example, the tool would need to know which API endpoints exist to create API requests on its own.

The OpenAPI specification is a popular REST API description format that can be used for such purpose. An OpenAPI file contains a machine-readable definition (as JSON or YAML) of an API's interface. Basic descriptions include the definition of the API endpoints, but can optionally contain much more content and other types of useful information. For example, an endpoint definition may include a list of required parameters for requests, possible response codes and content schemas of API responses. The OpenAPI can even describe security requirements that define what types of access control methods are used.

{     "openapi": "3.1.0",     "info": {         "title": "Example API",         "version": "1.0"     },     "servers": [         {             "url": "http://api.example.com"         }     ],     "paths": {         "/user/info": {             "get": {                 "description": "Returns information about a user.",                 "parameters": [                     {                     "name": "id",                     "in": "query",                     "description": "User ID",                     "required": true                     }                 ],                 "responses": {                     "200": {                         "description": "User information.",                         "content": {                             "application/json": {                                 "schema": {                                     "type": "object",                                     "items": {                                         "$ref": "#/components/schemas/user_info"                                     }                                 }                             }                         }                     }                 }             }         }     },     "security": [         {             "api_key": []         }     ] }

As you can see from the example above, OpenAPI files allow tools to both understand the API and use the available information to create valid API requests. Furthermore, the definition can give insight into the expected behavior of the API, e.g., by checking the response definitions. These properties make the OpenAPI format another standard on which we can rely. Essentially, a tool that can parse and understand OpenAPI can understand any generic API. With the help of OpenAPI, tools can create and execute tests for APIs automatically. Of course, the ability of tools to derive tests still depends on how much information an OpenAPI file provides. However, wherever possible, automation can potentially eliminate a lot of manual work in the testing process.

Conclusion

When we consider the similarities between REST APIs and OpenAPI descriptions, we can see that there is potential for analyzing REST security with tools. Our next blog post discusses how such an implementation would look like. We will discuss REST-Attacker, our tool for analyzing REST APIs.

Acknowledgement

The REST-Attacker project was developed as part of a master's thesis at the Chair of Network & Data Security of the Ruhr University Bochum. I would like to thank my supervisors Louis Jannett, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk for their continued support during the development and review of the project.

Related word

Henrique Schunck

sexta-feira, 30 de junho de 2023

<> SEO Max to improve ranks in 30 days <>

segunda-feira, 5 de junho de 2023

Theharvester: Email Harvesting Throughout Year

More info

Why Receipt Notifications Increase Security In Signal

The Double Ratchet

Research on Ratcheting

Protecting Acknowledgments ...

... Supports Asymmetric Ratchet

More info

domingo, 4 de junho de 2023

RenApp: The Ultimate File Renaming App

Automating REST Security Part 1: Challenges

Author

Overview

Understanding the Problem with REST

Generalizing REST Security

Finding a Systematic Approach for REST API Analysis

Conclusion

Further Reading

Acknowledgement

Você é meu visitante:

Páginas