About Tishna: Tishna is complete automated pentest framework for web servers, application layer to web security. Tishna was tested on:Kali Linux, Parrot Security OS, Black Arch, Termux, Android Led TV. Tishna's interface: Tishna has 62 options with full automation and can be use for web security swiss knife.
Tishna's installation:First, boot your Kali Linux or Parrot Security OS up. Then open Terminal and enter these commands
Appeared:
Cyber Space (Computer Security).
Terror Security (Computer Security).
National Cyber Security Services.
Brief Introduction
Tishna is useful in Banks, Private Organisations and Ethical hacker personnel for legal auditing.
It serves as a defense method to find as much as information possible for gaining unauthorised access and intrusion.
With the emergence of more advanced technology, cybercriminals have also found more ways to get into the system of many organizations.
Tishna software can audit, servers and web behaviour.
Tishna can perform Scanning & Enumeration as much as possible of target.
It's first step to stop cyber criminals by securing your Servers and Web Application Security.
Tishna is false positive free, when there is something it will show no matter what, if it is not, it will give blank results rather error.
In Hacking the main focus is over gathering the information about victim or victim's machine. Which will help to find out which type of exploit will works according to the given circumstances. Gathering the network and host information means to find out by which network, the which victim's machine is connected and communicating over the network. Moreover, scanning is also performed for gathering information about open and closed ports. After that they'll able to find the vulnerabilities in the target system and try to get access to the system.
Types Of Scan
As a CEH you should know the scan types and uses:
SYN
SYN scan doesn't complete the TCP three way handshake that is why it is known as a half-open scan. An attacker send a SYN packet to the victim machine if SYN/ACK packet is received back to attacker, then it clarify that the port is listening due to the acknowledgment by the victim that it has completed the connection. While if the attacker is received the RST/ACK packet then it assumed that the port is closed or open.
XMAS
XMAS scan works only on target system that has the RFC 793 development of TCP/IP and it doesn't works against any version of windows. XMAS scan send a packet with by setting up the FIN, URG and PSH flags of the TCP header. The function of this scan is if the port is active there will be no response but if the port is closed the target responds with a RST/ACK packet.
FIN
A FIN scan send a packet by setting up only the FIN flag of the TCP. This scan is similar to XMAS scan. FIN scan receives no response if the port is active while if the port is closed it receives the RST/ACK packet.
NULL
NULL scan is also similar to the XMAS scan. But the only difference is that it sends a packet without setting up the any flag of TCP header. NULL scan receives no response if the port is open but if the port is closed it receives the RST/ACK packet.
IDLE
It is just like spoofing an IP address by sending a SYN packet to the victim's machine to find out which services are available over the system. This scan is completed with the help of another system called as "Zombie" (that is not receiving or transmitting any information).
Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.
The issue: CORS misconfiguration
Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.
Misconfiguation
Description
Developer backdoor
Insecure developer/debug origins like JSFiddler CodePen are allowed to access the resource
Origin reflection
The origin is simply echoed in ACAO header, any site is allowed to access the resource
Null misconfiguration
Any site is allowed access by forcing the null origin via a sandboxed iframe
Pre-domain wildcard
notdomain.com is allowed access, which can simply be registered by the attacker
Post-domain wildcard
domain.com.evil.com is allowed access, can be simply be set up by the attacker
Subdomains allowed
sub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain
Non-SSL sites allowed
An HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption
Invalid CORS header
Wrong use of wildcard or multiple origins,not a security problem but should be fixed
The tool: CORStest
Testing for such vulnerabilities can easily be done with curl(1). To support some more options like, for example, parallelization we wrote CORStest, a simple Python based CORS misconfiguration checker. It takes a text file containing a list of domain names or URLs to check for misconfigurations as input and supports some further options: CORStest can detect potential vulnerabilities by sending various Origin request headers and checking for the Access-Control-Allow-Origin response. An example for those of the Alexa top 750 websites which allow credentials for CORS requests is given below.
Evaluation with Alexa top 1 Million websites
To evaluate – on a larger scale – how many sites actually have wide-open CORS configurations we did run CORStest on the Alexa top 1 million sites: This test took about 14 hours on a decent connection and revealed the following results: Only 29,514 websites (about 3%) actually supported CORS on their main page (aka. responded with Access-Control-Allow-Origin). Of course, many sites such as Google do only enable CORS headers for certain resources, not directly on their landing page. We could have crawled all websites (including subdomains) and fed the input to CORStest. However, this would have taken a long time and for statistics, our quick & dirty approach should still be fine. Furthermore it must be noted that the test was only performed with GET requests (without any CORS preflight) to the http:// version of websites (with redirects followed). Note that just because a website, for example, reflects the origin header it is not necessarily vulnerable. The context matters; such a configuration can be totally fine for a public sites or API endpoints intended to be accessible by everyone. It can be disastrous for payment sites or social media platforms. Furthermore, to be actually exploitable the Access-Control-Allow-Credentials: true (ACAC) header must be set. Therefore we repeated the test, this time limited to sites that return this header (see CORStest -q flag): This revealed even worse results - almost half of the websites supporting ACAO and ACAC headers contained a CORS misconfigurations that could be exploited directly by a web attacker (developer backdoor, origin reflection, null misconfig, pre-/post-domain wildcard):
The Impact: SOP/SSL bypass on payment and taxpayer sites
Note that not all tested websites actually were exploitable. Some contained only public data and some others - such as Bitbucket - had CORS enabled for their main page but not for subpages containing user data. Manually testing the sites, we found to be vulnerable:
A dozen of online banking, bitcoin and other payment sites; one of them allowed us to create a test account so we were able to write proof-of-concept code which could actually have been used to steal money
Hundred of online shops/e-commerce sites and a bunch of hotel/flight booking sites
Various social networks and misc sites which allow users to log in and communicate
One US state's tax filing website (however, this one was exploitable by a MitM only)
We informed all sites we manually tested and found to be vulnerable. A simple exploit code example when logged into a website with CORS origin reflection is given below.
The Reason: Copy & Paste and broken frameworks
We were further interested in reasons for CORS misconfigurations. Particularly we wanted to learn if there is a correlation between applied technology and misconfiguration. Therefore we used WhatWeb to fingerprint the web technologies for all vulnerable sites. CORS is usually enabled either directly in the HTTP server configuration or by the web application/framework. While we could not identify a single major cause for CORS misconfigurations, we found various potential reasons. A majority of dangerous Access-Control-* headers had probably been introduced by developers, others however are based on bugs and bad practices in some products. Insights follow:
Various websites return invalid CORS headers; besides wrong use of wildcards such as *.domain.com, ACAO headers which contain multiple origins can often be found; Other examples of invalid - but quite creative - ACAO values we observed are: self, true, false, undefined, None, 0, (null), domain, origin, SAMEORIGIN
Rack::Cors, the de facto standard library to enable CORS for Ruby on Rails maps origins '' or origins '*' into reflecting arbitrary origins; this is dangerous, because developers would think that '' allows nothing and '*' behaves according to the spec: mostly harmless because it cannot be used to make to make 'credentialed' requests; this config error leads to origin reflection with ACAC headers on about a hundred of the tested and vulnerable websites
A majority of websites which allow a http origin to CORS access a https resource are run on IIS; this seems to be no bug in IIS itself but rather caused by bad advises found on the Internet
nginx is the winner when it comes serving websites with origin reflections; again, this is not an issue of nginx but of dangerous configs copied from "Stackoverflow; same problem for Phusion Passenger
The null ACAO value may be based on programming languages that simply return null if no value is given (we haven't found any specific framework though); another explanation is that 'CORS in Action', a popular book on CORS, contains various examples with code such as var originWhitelist = ['null', ...], which could be misinterpreted by developers as safe
If CORS is enabled in the crVCL PHP Framework, it adds ACAC and ACAO headers for a configured domain. Unfortunatelly, it also introduces a post-domain and pre-subdomain wildcard vulnerability: sub.domain.com.evil.com
All sites that are based on "Solo Build It!" (scam?) respond with: Access-Control-Allow-Origin: http://sbiapps.sitesell.com
Some sites have :// or // as fixed ACAO values. How should browsers deal with this? Inconsistent at least! Firefox, Chrome, Safari and Opera allow arbitrary origins while IE and Edge deny all origins.
Most of the people don't go with videos and read books for learning. Book reading is a really effective way to learn and understand how things work. There are plenty of books about computers, security, penetration testing and hacking. Every book shows a different angle how things work and how to make system secure and how it can be penetrated by hackers. So, here I have gathered a few of the best hacking books of 2018 available on the market.
BEST HACKING BOOKS OF 2018
There are hundreds of books about hacking, but I have streamlined few of best hacking books of 2018.
1. THE HACKER'S PLAYBOOK PRACTICAL GUIDE TO PENETRATION
This handbook is about experting yourself with the hacking techniques in the hacker's way. This is about penetration testing that how hackers play their techniques and how we can counter them.
CONTENTS
Introduction
Pregame – The Setup
Setting Up a Penetration Testing Box
Before the Snap – Scanning the Network
The Drive – Exploiting Scanner Findings
The Throw – Manual Web Application Findings
The Lateral Pass – Moving Through the Network
The Screen – Social Engineering
The Onside Kick – Attacks that Require Physical Access
The Quarterback Sneak – Evading AV
Special Teams – Cracking, Exploits, Tricks
Post Game Analysis – Reporting
Download the Hacker's Playbook Practical Guide to Penetration.
2. ANDROID HACKER'S HANDBOOK
The Android Hacker's Handbook is about how the android devices can be hacked. Authors chose to write this book because the field of mobile security research is so "sparsely charted" with disparate and conflicted information (in the form of resources and techniques).
CONTENTS
Chapter 1 Looking at the Ecosystem
Chapter 2 Android Security Design and Architecture
Chapter 3 Rooting Your Device
Chapter 4 Reviewing Application Security
Chapter 5 Understanding Android's Attack Surface
Chapter 6 Finding Vulnerabilities with Fuzz Testing
Chapter 7 Debugging and Analyzing Vulnerabilities
Chapter 8 Exploiting User Space Software
Chapter 9 Return Oriented Programming
Chapter 10 Hacking and Attacking the Kernel
Chapter 11 Attacking the Radio Interface Layer
Chapter 12 Exploit Mitigations
Chapter 13 Hardware Attacks
Download Android Hacker's Handbook.
3. PENETRATION TESTING: A HANDS-ON INTRODUCTION TO HACKING
This book is an effective practical guide to penetration testing tools and techniques. How to penetrate and hack into systems. This book covers beginner level to highly advanced penetration and hacking techniques.
CONTENTS
Chapter 1: Setting Up Your Virtual Lab
Chapter 2: Using Kali Linux
Chapter 3: Programming
Chapter 4: Using the Metasploit Framework
Chapter 5: Information Gathering
Chapter 6: Finding Vulnerabilities
Chapter 7: Capturing Traffic
Chapter 8: Exploitation
Chapter 9: Password Attacks
Chapter 10: Client-Side Exploitation
Chapter 11: Social Engineering
Chapter 12: Bypassing Antivirus Applications
Chapter 13: Post Exploitation
Chapter 14: Web Application Testing
Chapter 15: Wireless Attacks
Chapter 16: A Stack-Based Buffer Overflow in Linux
Chapter 17: A Stack-Based Buffer Overflow in Windows
Chapter 19: Fuzzing, Porting Exploits, and Metasploit Modules
Chapter 20: Using the Smartphone Pentesting Framework
Download Penetration Testing: A Hands-On Introduction To Hacking.
4. THE SHELLCODER'S HANDBOOK
This book is about learning shellcode's of the OS and how OS can be exploited. This book is all about discovering and exploiting security holes in devices to take over.
Authors: Chris Anley, John Heasman, Felix "FX" Linder, Gerardo Richarte.
CONTENTS
Stack Overflows
Shellcode
Introduction to Format String Bugs
Windows Shellcode
Windows Overflows
Overcoming Filters
Introduction to Solaris Exploitation
OS X Shellcode
Cisco IOS Exploitation
Protection Mechanisms
Establishing a Working Environment
Fault Injection
The Art of Fuzzing
Beyond Recognition: A Real Vulnerability versus a Bug
Instrumented Investigation: A Manual Approach
Tracing for Vulnerabilities
Binary Auditing: Hacking Closed Source Software
Alternative Payload Strategies
Writing Exploits that Work in the Wild
Attacking Database Software
Unix Kernel Overflows
Exploiting Unix Kernel Vulnerabilities
Hacking the Windows Kernel
Download The ShellCoder's HandBook.
5. THE HACKER'S HANDBOOK WEB APPLICATION SECURITY FLAWS
This handbook is about finding and exploiting the web applications.
Authors: Dafydd Stuttard, Marcus Pinto.
CONTENTS
Chapter 1 Web Application (In)security
Chapter 2 Core Defense Mechanisms
Chapter 3 Web Application Technologies
Chapter 4 Mapping the Application
Chapter 5 Bypassing Client-Side Controls
Chapter 6 Attacking Authentication
Chapter 7 Attacking Session Management
Chapter 8 Attacking Access Controls
Chapter 9 Attacking Data Stores
Chapter 10 Attacking Back-End Components
Chapter 11 Attacking Application Logic
Chapter 12 Attacking Users: Cross-Site Scripting
Chapter 13 Attacking Users: Other Techniques
Chapter 14 Automating Customized Attacks
Chapter 15 Exploiting Information Disclosure
Chapter 16 Attacking Native Compiled Applications
Chapter 17 Attacking Application Architecture
Chapter 18 Attacking the Application Server
Chapter 19 Finding Vulnerabilities in Source Code
Chapter 20 A Web Application Hacker's Toolkit
Chapter 21 A Web Application Hacker's Methodology
Download The Hacker's Handbook Web Application Security Flaws.
So, these are the top 5 best hacking books on the market. There may be more fascinating books in the future that make take place in the top list. But for now, these are the best hacking books. Read and share your experience with these books.
We posted our take on the Trump's server story. If you have any feedback or corrections, send me an email (see my blog profile on Contagio or DeepEnd Research)
Over the past number of months the Board of Directors has been working on the feedback received from the community. This feedback aligned with our key strategic goals for the year. One of our key goals was to further strengthen the "P" in OWASP. To this end we have been working with the Open Security Summit to put more of a focus on improving project development and growth and hope to enable projects through events such as this.
Another goal is to strengthen our student outreach. One idea I had was to work with colleges all over the world to support our projects development as part of their internships. I wonder if there would be anyone in the community to assist in this effort by creating a Committee under the revised Committee 2.0 model - https://www.owasp.org/index.php/Governance/OWASP_Committees. To simplify things I have added a quick start guide at the beginning of the document.
Diversity is something that we hold dear to our hearts. There are a number of people in our community that have driven this initiative to enable OWASP to be a more diverse community, without naming any names, we would like to thank them and encourage more of those in and outside of the OWASP community to get involved and help OWASP grow.
Last but not least, planning for our global conferences is well under way with OWASP Global AppSec Tel Aviv coming up at the end of May – one small ask is that everyone share information on this conference in your communities,https://telaviv.appsecglobal.org.
Thanks for all your hard work.
Owen Pendlebury OWASP Vice Chairman
OWASP FOUNDATION UPDATE FROM INTERIM EXECUTIVE DIRECTOR:
For these first few months I have been focused on business operations retooling. As you know, Mailman was recently retired. There is now an online static archive of historical messages. Our goal before Q3 is to have most of our tools on managed, trusted hosted services.
We have increased our use of JIRA to manage inbound requests and last month the team closed 98.6% of service tickets within their prescribed SLA. In January it was 20.4%. This is a very big accomplishment and demonstrates our progress on this work effort. There have also been a number of back office changes that most members won't notice, but we're focused on stronger business continuity for the long term.
In addition to all our upcoming events, the staff along with some members of the community are actively prototyping how we will completely update the website this summer. This effort will not be simply cosmetic, it will be a foundational change in how we manage and publish content that we believe will better connect with our community - and more importantly help us grow. Expect more updates on this in the coming months.
The Project Showcase at Global AppSec Tel Aviv has received a great deal of interest. Anyone attending will be in for a steady stream of information on OWASP Projects. The following projects are proposed for the showcase (the actual schedule has not been developed so the order is not indicative of time slots):
Project
Presenter(s)
Glue Tool
Omer Levi Hevroni
Internet of Things
Aaron Guzman
Embedded AppSec
Aaron Guzman
Software Assurance Maturity Model (SAMM)
John DiLeo
API Security
Erez Yalon, Inon Shkedy
Mod Security Core Rule Set
Christian Folini, Tin Zaw
Automated Threats
Tin Zaw
Application Security Curriculum Project
John DiLeo
Defect Dojo
Aaron Weaver
Web Honeypot Project
Adrian Winckles
Damned Vulnerable Serverless Application
Tal Melamed
The scheduled for project reviews at Global AppSec Tel Aviv are the following:
If you are attending Global AppSec Tel Aviv 2019 and can participate in the project reviews (to be held on Monday and Tuesday prior to the conference, schedule pending), then please send an email to project-reviews@owasp.org
COMMUNITY
New OWASP Chapters Amaravathi, India Belo Horizonte, Brazil Bhopal, India Cusco, Peru Dindigul, India Kharkiv, Ukraine Meerut, India Rio de Janeiro, Brazil San Jacinto College, Texas San Pedro Sula, Honduras Seoul, Korea West Delhi, Delhi
MEMBERSHIP
We welcome the following Contributor Corporate Members
