I will point out that this information is all publicly accessible, easily scanned for, and poses potential risk to any information you post on this site - "private" or otherwise.

I suggest that the new site owner take this information seriously, and if you do not currently have a digital security expert on your team, hire one. I am offering this information here and publicly for your consumption, in the hopes that something be done about it for the safety of the information you just forked a bunch of money over for. Consider my services free today.

For some of these I will be copy-pasting ver-batim the information provided by my tools. Not for lack of caring, but simply to show exactly what information can be easily pulled and subsequently exploited.

Note also that I am not going to even list out ALL of the vulnerabilities. The truth is that there are too many to post them all.




JQuery 1.11.0.: JQuery is currently on version 3.4.0. It may surprise you to know, but even older Javascript frameworks (especially JQuery prior to V1.9) can pose security vulnerabilities. Here's a basic example of one of the issues fixed in a now-old version of one of JQuery's dependencies pertaining to security: https://github.com/jquery/jquery/commit/835e9218beef8f0c559d...

I suggest updating the site to use the latest version of JQuery. You will find that some syntax has changed and you will need to account for that with some adjustments to code on the site, but generally this should not be particularly difficult to develop.


XSS Vulnerabilities: XSS vulnerabilities occur when the Web application echoes user-supplied data in an HTML response sent to the Web browser. For example, a Web application might include the user's name as part of a welcome message or display a home address when confirming a shipping destination. If the user-supplied data contain characters that are interpreted as part of an HTML element instead of literal text, then an attacker can modify the HTML that is received by the victim's Web browser.

The XSS payload is echoed in HTML document returned by the request. An XSS payload may consist of HTML, JavaScript or other content that will be rendered by the browser. In order to exploit this vulnerability, a malicious user would need to trick a victim into visiting the URL with the XSS payload.

Impact:
XSS exploits pose a significant threat to a Web application, its users and user data. XSS exploits target the users of a Web application rather than the Web application itself. An exploit can lead to theft of the user's credentials and personal or financial information. Complex exploits and attack scenarios are possible via XSS because it enables an attacker to execute dynamic code. Consequently, any capability or feature available to the Web browser (for example HTML, JavaScript, Flash and Java applets) can be used to as a part of a compromise.

Solution:
Filter all data collected from the client including user-supplied content and browser content such as Referrer and User-Agent headers. Any data collected from the client and displayed in a Web page should be HTML-encoded to ensure the content is rendered as text instead of an HTML element or JavaScript.

This one pertains to  the forum software specifically. Unfortunately the nature of forums makes them easy to toss up, and seemingly "dangerous" to maintain. Why change what isn't broken, right? It looks good, people are using it, so it's good! Except it's not. Same as maintaining an operating system, vulnerabilities come with time as people dig deeper and find exploits. I can guarantee that this is easily exploited, should anyone care to do so.


Login Form Is Not Submitted Via HTTPS: This one has been discussed here before and you really need to fix it. It's a relatively easy fix, it's potentially free, though as I pointed out in the previous discussion, paid options CAN provide better security - the free version of SSL (LetsEncrypt for instance) is more susceptible to attack due simply to sheer volume of use.

Impact:
Sensitive data such as authentication credentials should be encrypted when transmitted over the network. Otherwise they are exposed to sniffing attacks.

Solution:
Change the login form's action to submit via HTTPS. Add SSL to the site. Seriously.

NOTE: I see that there IS an SSL cert associated with the site but it is both expired AND not actually correct for NA:
Certificate #0 CN=www.dainanderson.com ..." target="_blank">www.dainanderson.com ...; is not valid after Nov 15 12:40:01 2018 GMT.
Certificate #1 CN=www.dainanderson.com 

Looks like Dain may have tried to set up SSL and then... got busy or something?


HTTP TRACE / TRACK Methods Enabled: The remote Web server supports the TRACE and/or TRACK HTTP methods, which makes it easier for remote attackers to steal cookies and authentication credentials or bypass the HttpOnly protection mechanism. Track/Trace are required to be disabled to be PCI compliant. Though you don't need to be PCI compliant as you do not collect CC information for sales (currently), this still poses other serious risks (as below). If you ever intend to offer any sort of premium membership or anything of the sort then this will be even more important than it already is.

Impact:
If this vulnerability is successfully exploited, attackers can potentially steal cookies and authentication credentials, or bypass the HttpOnly protection mechanism.

Solution:
Disable these methods in your web server's configuration file.


Web Server Uses Plain-Text Form Based Authentication: The Web server uses plain-text form based authentication. A web page exists on the target host which uses an HTML login form. This data is sent from the client to the server in plain-text.

Impact:
An attacker with access to the network traffic to and from the target host may be able to obtain login credentials for other users by sniffing the network traffic.

Solution:
Please contact the vendor of the hardware/software for a possible fix for the issue. For custom applications, ensure that data sent via HTML login forms is encrypted before being sent from the client to the host.


Some quick tidbits of info I could use to attack you:
 

Service name: FTP on TCP port 21.

Close that shit. Use SFTP and lock it to a whitelist or something.
 

220 Welcome to the NintendoAge.com File Server!

Lol.
 

Vulnerable to slow HTTP POST attack
	Connection with partial POST body remained open for: 194459 milliseconds
	Server resets timeout after accepting request data from peer.

DDoS.

SMB Signing Disabled or SMB Signing Not Required
Unauthorized users sniffing the network could catch many challenge/response exchanges and replay the whole thing to grab particular session keys, and then authenticate on the Domain Controller.


There's more but I won't bore you with all the Low Risk items.
 

Quick additional note:

I highly suggest that if you are like the me from the past, and use one password across multiple sites...

Change your password right now.

That's good advice for any password you have on a non HTTPS site; don't have them the same as any of your other secure ones.
 

If you ever visited my WTB page I utilize CSS to make flexboxes...that shouldn't be possible but it is.

Also....at any time someone can literally just make a div with a style element that looks something like...

display: block; position: fixed; top: 0; left:0;bottom:0;bottom:0;background:yellow;z-index:9999;

And basically bomb any forum page post. It's annoying and easily deleted but still annoying and it's possible that you can just overwhelm the moderators and admins with something like that.

 

More to the point -- change your password on the OTHER sites.

Probably pointless to bother changing your NA password.

Change it on all of them, really. But if you have the password here and it's not already been stolen, then at least changing it here is quick and easy - they'll scrape a useless password.
 

Sure. I have had unique passwords and usernames everywhere for a long time so I am not bothered about that.

It would be nice to see the security concerns taken seriously. Not only is this good for the site, and ALL members, but it is a much needed / overdue improvement. It has been requested multiples times by users, mods, and admins, and from what I understand, is not particularly difficult or expensive to implement. Obviously, like anything else related to the site, there is nothing you HAVE to do as owner, and no, the users aren't owed anything nor should we be entitled to anything. But, these are very solid suggestions and as Gloves pointed out, an additional way to protect an investment, so kind of a win-win.

I'd also like to see the database version updated.

@ Gloves wow man you just gave NA a free security assessment that I have seen companies pay thousands for coming from a Managed Service Provider background.

I truly hope it doesn't fall on deaf ears. Having done my own reconnaissance on this site (it's a force of habit coming from an IT background) I'm not certain that NA is the only customer that occupies this particular web server. I'm thinking the a record hits something like F5 big IP and is routed to a virtual server that is possibly running Apache and listening on virtual directories. Problem is if you update the box all companies are affected. Solution is to containerize via Docker but that would require some downtime. I was surprised at the A record that came back wasn't AWS owned since S3 storage is used but oh well. All educated guesses mind you I could be totally wrong but it's cool to see other IT focused game nerds on the site!

edit: IIS not Apache TCP 445 and all

 

Keep in mind that forum software with such features as S3 tend to be managed through 3rd party plugins. If I had to guess, I'd say there's a plugin involved which manages the connection to S3. Odds are it's not a case of Dain going "I'll set up a CDN to handle image uploads and save on server costs!" but rather "I'll search for 'how to save money on image uploads with forum software X'" and landing on a plugin, installing it, and that's that.

Not to discount HIS web development skills by any stretch of course, that's just what I see people doing generally. And for good reason - why reinvent the wheel eh?

I don't even think CDN would help here as the forum stuff isn't really static content, maybe like the badge icons and images and junk. I don't think it would be worth the monthly cost. I agree with the plugin logic though, no one wants to develop crap that already exists. I figured that the bucket permissions were managed by an IAM role that allows access from the EC2 machines but that logic was shot to crap since the A record goes back to an India IP not owned by AWS.

I guess all this falls back on Jeff and his team now though so we will see what kind of improvements they have in mind.

I'm gonna bump this since this thread seemed to be flat out ignored. What's funny is that firefox is telling me that this isn't secure, but if nobody gives a crap, then whatever...

I give a crap. It's pretty low on the list of things I need to be working on right now, but it's on there. 
 

Is it safe?

Is it secret?
 

Is it safe?

Jeff needs to sell a few more games/comics to fund the cert! Get those black boxes to auction!

So its YOU! (in a dark demonic voice) Get this taken care of gloves! lol
 

Just sent Jeff a message since NA is still http. Hopefully he implements https soon.

This site gives out free certificate authorities (basically https aka TLS encryption aka secure or at least much more secure website)

https://letsencrypt.org/getting-s...

We're well aware of Letsencrypt, but it's not QUITE that simple with the site as-is. We have some potential stuff in the hopper at the moment but I can't say more than that until details are ironed out.
 

Are you working on the site officially now?

I'd not say that, per se.