Risks associated with developers using their own domain for development services

We have some development and test environments being served of our canonical domain, e.g. dev.example.com. We also have some services using obscure domains names from 3rd party providers like xjkhasdkjvhas.dns.ashdfb.3rdparty.io.

The canonical domain is maintained strictly by our sys admins.

Furthermore some services are not served on port 80 which means any new instances need to be opened on our company firewall. And also some of these services have dynamic IP which also causes our firewall to need updating/scripting.

To clean it all up I’d like our developers to use their own public dns, e.g. dev.ex.io. They can then standardise easily memorable names for services, create reverse proxies with certbot for dynamically changing services on obscure ports and also clean up our canonical DNS so it’s only used for production services.

Are there any real risks associated with this? The only thing I can think of is a public domain will provide clues as to our company and what services lie behind the domain (but that’s already an issue with dev.example.com). As long as developers don’t use this domain for production services is there a problem with this approach?

Are there security risks in exposing a certificate?

  1. If an attacker would have access to a certificate, could he build an attack out of that?

or rephrasing it:

How could an attacker profit from a device certificate, that he gets his hands on?

For example: A certificate that is used for a device (IoT-Device) gets public, which is in my mind part of the idea of using it, could an attacker profit from that? For example clone it for a different device. Deleting or making the certificate invalid is not an attack in scope in this scenario.

Assumption is:

  • the private-key is still safe
  • the CA oder ICA that signed the certificate is valid and secure
  • Data in the certificate is not confidential, but there is an ID for the device
  • the attacker is in possession of the certificate file

And following out of that question, if the answer is no, there is no threat.

  1. I could store the certificate on the device, without thinking to much about security (except deletion and changes that lead to invalid behavior)?

Security risks of file shares vs ssh or sftp, in “backward” direction?

I work for a municipal government, using mostly Windows servers. In recent days several similar governments in our geographic area have been attacked, some successfully, by ransomware. So our security folks are alarmed, and have decreed (among other things) no more using SMB file-sharing to upload files from the “internal” network to the DMZ. I have a PowerShell script that does just that, to migrate databases; plus we have many other cases to use file shares such as uploading web sites.

They are saying we need to convert to using SSH or SFTP to transfer files. OK, this would be possible, but it would need setup work on every DMZ server, and changing all our current processes, and for what? (We don’t have enough people to do that plus everything else, although we’ve tried to get more warm bodies budgeted.) Anyway I don’t see how that’s more secure. If DMZ server D is listening on a share, and the firewall prevents access from anywhere but authorized internal workstations or servers A, B, and C, then how can that be any more a security risk (specifically, the risk of malware on server D going back the other way and compromising A, B, or C) than server D listening on an SFTP port or an SSH port, with the same firewall restrictions?

If the issue is something like “the file share is open all the time, but SSH isn’t,” then that would be somewhat understandable, and we might deal with that by mapping and unmapping to the shares when needed. But I don’t think this is their reasoning; I think it’s something else. Actually I get the impression it’s kind of a vague “feeling” on their part, that file shares are inherently and materially less secure, in the “backward” direction, even if firewall-protected as described above. If this is actually so, then why? I just don’t see it. Actually I don’t see why any of those protocols would pose a risk in the “backward” direction.

Potential Risks Using Reference Code Based Authentication For Web Based Application Form That Contains SSN [migrated]

I’m currently building a web based membership application form that will require a user to enter an SSN and other identifiable information. Part of the requirements of the membership application is to allow a user to be able to resume their application and pre-fill of the information they already entered into the form fields. The stakeholders do not want to burden the user with a username and password. We have come up with the following alternative authentication method.

A user can start an application and click a button to “Save” their application. When they click “Save” an email is sent to them and they receive a 6 character alpha numeric reference code.

To “resume” the application the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN.

My question is, on a scale of 1 to 10 what would the risk factor in allowing a user to authenticate in this manner. What is the probability that someone could load someone else’s application if they brute force attacked the web based form. And if the risk scale is high, then what can I do to increase the security on this form. I can’t implement a password system and the reference code needs to be simple enough that someone could over the phone present the code to a customer service agent.

Additional Security:

Reference Codes will expire after 1 week on non-use. Reference Codes will expire once the form has been submitted. The web application is using HTTPS and TLS to transfer the data.

About 200 applications will be submitted per week, so around a max of around 200 applications might have active reference codes in a given week.

Potential Risks Using Reference Code Based Authentication For Web Based Application Form That Contains SSN

I’m currently building a web based membership application form that will require a user to enter an SSN and other identifiable information. Part of the requirements of the membership application is to allow a user to be able to resume their application and pre-fill of the information they already entered into the form fields. The stakeholders do not want to burden the user with a username and password. We have come up with the following alternative authentication method.

A user can start an application and click a button to “Save” their application. When they click “Save” an email is sent to them and they receive a 6 character alpha numeric reference code.

To “resume” the application the user must then enter the 6 character reference code as well as their birth date, last name, and last four digits of their SSN.

My question is, on a scale of 1 to 10 what would the risk factor in allowing a user to authenticate in this manner. What is the probability that someone could load someone else’s application if they brute force attacked the web based form. And if the risk scale is high, then what can I do to increase the security on this form. I can’t implement a password system and the reference code needs to be simple enough that someone could over the phone present the code to a customer service agent.

Additional Security:

  • Reference Codes will expire after 1 week on non-use.
  • Reference Codes will expire once the form has been submitted.
  • The web application is using HTTPS and TLS to transfer the data.

About 200 applications will be submitted per week, so around a max of around 200 applications might have active reference codes in a given week.

Risks of allowing users to upload PDF and XML files to be stored/retrieved from a DB (ASPNET MVC 5)

I’m modifying an ASPNET MVC 5 web site and a requirement is to allow users to upload an XML and PDF file.

The XML file will be used to layout text on the PDF based on variables coming from within the system.

I have a schema for the XML that can be uploaded – so I can validate against a malformed XML – and that the XML matches the schema.

Where I’m unsure is in worries about DOS and malicious code in the XML. Is checking against the schema enough or can malicious code pass the schema check?

Also, the PDF is just stamped with text content using iText – would I need to worry about something nefarious in the PDF?

Both files are stored as byte[] in a database and never on a file system directly.

Part of the site prepares the PDF with the XML content and displays to the user and another part prepares the PDF to attach to an email. (Just trying to give some context in its use)

There seems to be so many places this could open security vulnerabilities and the client is using a 3rd party IT security vendor for this as well. I have to allow the functionality as I can’t get around it.

VLC 3.0.4 security risks

This is latest security advisory from VLC

Security Advisory 1901

Summary : Read buffer overflow & double free Date
: June 2019 Affected versions : VLC media player 3.0.6 and earlier ID : VideoLAN-SA-1901 CVE reference : CVE-2019-5439, CVE-2019-12874

Details

A remote user can create some specially crafted avi or mkv files that, when loaded by the target user, will trigger a heap buffer overflow (read) in ReadFrame (demux/avi/avi.c), or a double free in zlib_decompress_extra() (demux/mkv/utils.cpp) respectively Impact

If successful, a malicious third party could trigger either a crash of VLC or an arbitratry code execution with the privileges of the target user. Threat mitigation

Exploitation of those issues requires the user to explicitly open a specially crafted file or stream.

ASLR and DEP help reduce exposure, but may be bypassed. Workarounds

The user should refrain from opening files from untrusted third parties or accessing untrusted remote sites (or disable the VLC browser plugins), until the patch is applied. Solution

VLC media player 3.0.7 addresses the issue.

According to them, installing VLC media player 3.0.7 will fix the issue.

However, the one available in Ubuntu is the old version 3.0.4

user@linux:~$   apt show vlc Package: vlc Version: 3.0.4-1ubuntu0.2 Priority: optional Section: universe/graphics Origin: Ubuntu 

Isn’t this considered as high security risk?

What is the best way to make sure our softwares in Ubuntu is updated since sudo apt update && sudo apt upgrade clearly won’t help in this issue.

Do we really need to manually check and update each software in our computer?

VLC 3.0.4 security risks

This is latest security advisory from VLC

Security Advisory 1901

Summary : Read buffer overflow & double free Date
: June 2019 Affected versions : VLC media player 3.0.6 and earlier ID : VideoLAN-SA-1901 CVE reference : CVE-2019-5439, CVE-2019-12874

Details

A remote user can create some specially crafted avi or mkv files that, when loaded by the target user, will trigger a heap buffer overflow (read) in ReadFrame (demux/avi/avi.c), or a double free in zlib_decompress_extra() (demux/mkv/utils.cpp) respectively Impact

If successful, a malicious third party could trigger either a crash of VLC or an arbitratry code execution with the privileges of the target user. Threat mitigation

Exploitation of those issues requires the user to explicitly open a specially crafted file or stream.

ASLR and DEP help reduce exposure, but may be bypassed. Workarounds

The user should refrain from opening files from untrusted third parties or accessing untrusted remote sites (or disable the VLC browser plugins), until the patch is applied. Solution

VLC media player 3.0.7 addresses the issue.

According to them, installing VLC media player 3.0.7 will fix the issue.

However, the one available in Ubuntu is the old version 3.0.4

user@linux:~$   apt show vlc Package: vlc Version: 3.0.4-1ubuntu0.2 Priority: optional Section: universe/graphics Origin: Ubuntu 

Isn’t this considered as high security risk?

What is the best way to make sure our softwares in Ubuntu is updated since sudo apt update && sudo apt upgrade clearly won’t help in this issue.

Do we really need to manually check and update each software in our computer?

VLC 3.0.4 security risks

This is latest security advisory from VLC

Security Advisory 1901

Summary : Read buffer overflow & double free Date
: June 2019 Affected versions : VLC media player 3.0.6 and earlier ID : VideoLAN-SA-1901 CVE reference : CVE-2019-5439, CVE-2019-12874

Details

A remote user can create some specially crafted avi or mkv files that, when loaded by the target user, will trigger a heap buffer overflow (read) in ReadFrame (demux/avi/avi.c), or a double free in zlib_decompress_extra() (demux/mkv/utils.cpp) respectively Impact

If successful, a malicious third party could trigger either a crash of VLC or an arbitratry code execution with the privileges of the target user. Threat mitigation

Exploitation of those issues requires the user to explicitly open a specially crafted file or stream.

ASLR and DEP help reduce exposure, but may be bypassed. Workarounds

The user should refrain from opening files from untrusted third parties or accessing untrusted remote sites (or disable the VLC browser plugins), until the patch is applied. Solution

VLC media player 3.0.7 addresses the issue.

According to them, installing VLC media player 3.0.7 will fix the issue.

However, the one available in Ubuntu is the old version 3.0.4

user@linux:~$   apt show vlc Package: vlc Version: 3.0.4-1ubuntu0.2 Priority: optional Section: universe/graphics Origin: Ubuntu 

Isn’t this considered as high security risk?

What is the best way to make sure our softwares in Ubuntu is updated since sudo apt update && sudo apt upgrade clearly won’t help in this issue.

Do we really need to manually check and update each software in our computer?