The preshared key (PSK) is not actually the encryption key.  It is a "common" starting point used by the two devices to negotiate encryption without making the exchange vulnerable to a man in the middle attack.

An attacker would need both the PSK and the initial exchange between AP and client to be able to decrypt the transmission.  Wireless PSK's will never be as secure as the 802.1X counterparts, and if security is a concern then you should transition from PSK to WPA2-Enterprise as soon as possible.

Your concern seems to be with how the PSK is stored, but if an attacker has access to the router/AP itself, then all data passing through the device is vulnerable no matter how the PSK is stored.  What I mean by this is that the encryption "ends" at the radio interface and is no longer encrypted while being processed and/or while exiting another interface.


E-Mail attachments can be opened using their URL in webmail even after logging off

Use proper settings on your browser.

All attachments opened directly from your browser are cached by it, so yes, you can access them later. They did that as a feature...so they say. To prevent that, in all browsers now-days you can open your e-mail in private/no history mode and that way when you close the browser nothing is saved.

Personally, I don't open any files directly from browsers. I save them to a specific location and then I open/edit/delete them from there as needed.


There are a few different kind of labs available. There are ones you can construct yourself in VM's such as Vulnhub and they have a lot of links to good resources there. Another site i can recommend with good resources is Pentesterlab, i tend to steer clear of the online sites such as hackme so can't give much as to online but hope these help.


Worst-case scenario for ShellExecute(0,"open",arbitrary_string)

There are a variety of things you could do with this issue:

Set up a shared directory on the network, put an executable on it, then send the path to that share.
Open the user's browser to a page containing browser exploits, by passing the URL.
Launch a game in order to generate a temporary DoS whilst it loads.
Launch a maintenance script for a known-installed application in order to damage or destroy data.
Launch a network service that's available on the system, then use that to gain further access.


Am I affected by the Intel AMT/ISM/SBT escalation of privilege vulnerability?

Based on Matthew Garrett - Intel's remote AMT vulnerablity, which is among the most reasonable (in terms of amount of hyperbole) articles I've seen so far, you can only be affected if your system meets all four of the following criteria:

A CPU supporting Active Management Technology
A motherboard chipset supporting AMT
Supported network hardware
The Management Engine firmware contains the AMT firmware

There is no guarantee if your system meets all four criteria that it is affected, but if it does not meet all four, then it cannot be affected by the vulnerability as currently known.

Based on your statement that the chipsets in both your systems do not support vPro (of which AMT is one part), we can then conclude that neither meets all four criteria and thus neither system can be affected.

Specifically, in order to be affected, you need to have vPro, but having vPro-capable hardware alone is not sufficient to be affected; your system also needs to have the AMT nuts and bolts (e.g. its firmware) installed. That would under every normal circumstance be done by your system vendor.

Apparently, under Linux, you can check for AMT by looking at the lspci output; if lspci lists no communications controller with MEI in the description, then AMT is not running and you are safe.


Exploit failed [unreachable]: Rex::ConnectionTimeout The connection timed out(remote host ip)

You asked this question and it was downvoted before. There could be a lot of reasons for this happening, your question is too broad, and lacks a lot of relevant information. For example, can you ping that host, is it running a firewall, it is vulnerable to that exploit. What you are experiencing is the host not responding back after it is exploited. This could be because of a firewall on either end (the attacking machine, the exploited machine). I would start with firewalls since the connection is timing out. From there I would move and set a different "LPORT" since metasploit tends to act quirky at times. E.g., set LPORT 2468. If that doesn't work, then jump on the metasploit forum and ask there, you'll likely get an accurate explanation.


Multiple 4625 audit failures on WS2012 R2

So according to some small search on the internet, you're most likely under some sort of attack. If it is not, then someone must have done a huge mistake while configuring a connection script.

What we learn from your log :

Someone is trying to access your server from outside (logon type 3), through RDP.
The attempts are for now, all failures (event id 4625)
It is most likely a script, according to the frequency of the failed logons
You don't have any information about the source machine trying to access your server.

Why do you have no information ? Most likely due to the RDP, which prevents your server from logging such informations.

What you should do then ?

Try to restrict access to your server through whitelisting. Allowing only trusted workstation in your network to access the server.

Also, if you don't have one, some IDS/IPS can prevent such try.

If you can't afford either of these solutions, since the attack looks random and most likely based on a list of "most commonly used username and password", changing some critical usernames with unconventionnal ones might delay or even negate the attack.

Also in case one of your accounts match a tested username, a common practice is to lock an account after X failed authentication trials, or generate a new password for it. On the one hand you limit the risk that script finds the good username/password couple and exploit it, on the other hand, you're exposing your system to administration outages, by having some of your important accounts locked.

Be aware this is only a workaround, this is not meant to be a durable solution. Restricting access to your server would probably be best.


Does broken site functionality pose any security threat?

Broken functionalities in a web application are not a security threat per se, but they might be one. For you as a penetration tester, look out for:

Information leakage about the system (stacktraces, version numbers, error messages, file paths, ...) as they might help an attacker
Missing security features (if the functionality to change the password is broken, then you should include this in your report)
System crashes (DoS)
And generally any unexpected behaviour.

As each and every line of code (and therefore each feature, whether working or not) increases the attack surface of the application, the client should avoid to deploy (partly) broken features to their servers.


Session resumption really depends on what you are pushing through the SSL. Since you talk about a Web browser, then I assume that you are talking about some sort of Web server, serving pages written in HTML.

How things go typically looks like this:

The browser opens a first connection, with a full handshake.
The browser may open one or a few extra connections, so that several requests may be issued concurrently (to load images and scripts and other elements). The number depends on the browser version, OS, HTTP protocol version, and maybe other parameters (see this for a summary of how these things went in 2008). The new connections will use session resumption.
The browser will try to keep the connections "alive" for as long as possible. Usually, the server will close connections which have been inactive for one or two minutes, but this depends on the server type, load, and configuration. Also, the client may be behind some NAT router that will kill connections that have been inactive for some time (typically 20 minutes or so).
When opening new connections, browser will try session resumption. A browser will remember session parameters for hours, as long as its process was not terminated (i.e. the browser forgets all session parameters when all its windows are closed).
The server will typically remember SSL sessions for 5 to 20 minutes after closure of the last connection that was using that session. This can be configured; it depends on the server type, version, configuration, and (notably) its use of session tickets.

The bottom-line is that a typical client will perform a new handshake only when it opens a new connection, which normally occurs rarely; you will get a few connections at the start, and then whenever the client interacts with your server after having not-interacted with the server for a minute or two. Under normal conditions and typical servers, only the very first of these handshakes is a full handshake; all others are abbreviated handshakes (session resumption). From the description above, you see that new connections occur at a rate which is no more than a couple of times per minute, and less so if the client is "active" (i.e. clicks more than once per minute).

By forfeiting session resumption, you make all the handshakes full, with server certificate sending and asymmetric cryptography.

The other half of the question is how much these extra full handshake will cost you. A full handshake implies mostly three extra costs:

The latency is increased. A full handshake implies an extra round trip:

Client sends ClientHello
Server sends ServerHello, Certificate...
Client sends ClientKeyExchange, ChangeCipherSpec, Finished
Server sends ChangeCipherSpec, Finished
Client can begin to send the HTTP request

To compare with what happens with a session resumption:

Client sends ClientHello
Server sends ServerHello, ChangeCipherSpec, Finished
Client sends ChangeCipherSpec, Finished
Client begins its HTTP request (crucially, this can be done over the
same IP packets as the ChangeCipherSpec and Finished messages)

Whether the extra latency is tolerable or not should be measured. Latency is usually what matters most for user experience.
The full handshake implies more network traffic, the bulk of which being the server's certificate chain (say, 2 to 5 kilobytes).
The asymmetric crypto involved in a full handshake requires a bit more juice from the server CPU. Note that a quad-core 3.1 GHz server from a few years ago (that's my server) can do more than 3000 RSA private key operations per second (for a very decent 2048-bit key).

Since we are talking about a couple handshakes per minute and per client, the extra network and CPU costs are probably negligible (although it should be measured, like all things related to performance). The extra latency, though, may be more problematic, because it is part of what the user sees, and it depends on how the user is connected to the Internet (in particular, people with satellite Internet access tend to have a high latency and dearly feel the cost of each extra round trip).

Summary: for a Web site, the influence of using or not using session resumption will mostly be a question of user experience with regards to latency. The most important parameter will be how long the server accepts to keep inactive client connections alive.

Since all of this depends a lot on how your site is organized (e.g. number of extra images, CSS and scripts to load; whether interactions are mostly in the client with Javascript, or imply client-server activity; how long a user is expected to stare at a page before clicking anywhere...), how the users behave (how many pages they look at, how often they come back...), and the expected peak load (how many users connected at the same time), statistics obtained on sites other than your own are unlikely to offer an accurate vision of what will happen for you.


Chrome: Your connection is private but someone might be able to change the look of the page

The page that your browser displays on the screen might consist of many elements: the HTML code, CSS, images, etc. Also some of the content might be provided, enhanced, or altered by (legitimate) scripts downloaded from the site. These elements might be included from the same server or from other servers.

For Chrome to display the "Your connection to this site is private" message, for each element of the page:

an encrypted HTTPS connection must be established
site certificate (identity) must be valid
non-deprecated protocols and algorithms must be used

If one or more of the elements is included through a non-encrypted HTTP link, then:

if it is a script, Chrome will display a message:

  Your connection to this site is not private because the site loaded an insecure script.

In such case there is a possibility that the script was replaced with a malicious one. Any data you receive from the site or sent to the site can be intercepted and changed.
if it is (only) a passive content (like an image), Chrome will display a message:

  Your connection to this site is private but someone on the network might be able to change the look of the page.

In such case no one would be able to sniff on your data or read the information that the site provided. However by altering the look of the page you might be tricked into performing an action you did not originally intend to, for example resetting your password. Although the password change itself would be secure and legitimate, it might benefit the attacker.

Also, this message is not 100% accurate. Depending on the actual passive content being included, a passive attacker can deduce what actions did you take on the encrypted site. Unlike with HTTPS, with HTTP the full URL would be visible, so if a certain page loaded a unique set of icons, an attacker would be able to tell you reached that page.


Should I delete lost GPG key from GitHub?

I don't see any reason, why you would need to remove it. Losing the key changes nothing about its security. The key could have leaked, or could be broken later but that applies to a key you did not loose as well. You should rotate your keys in general.

In my opinion, it would be a better idea to keep it for as long, as you trust the key, so people can see you still trust the signatures. You can likely remove it, once the commits signed by it are no longer relevant.

A commit hash includes the hash of the previous commit, which means a single commit signed with the new key verifies all commits that came before it. Hence, the old key is only relevant, if some branches don't have a new commit or if the users work with old versions of the code.


I am fairly sure your answer lies in the error message.

  The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

I guess Google wants you to be super-duper sure that you want to allow XSS. Try running a local server that returns either of these headers:

X-XSS-Protection
Content-Security-Policy

This can be pretty annoying if you are trying to do a simple demonstration using a locally created file, but it is in our best interest, I guess. It may be that Firefox/IE are worth a shot if you just want to see/show how XSS works, but don't want to set up an http server.

EDIT: also make sure you close all instances of chrome when you run a command line.


Does mysql_escape_string have any security vulnerabilities if all tables using Latin1 encoding?

The issue is that mysql_escape_string() does not check the database for character encoding. As a result mysql_escape_string() would be unaware of your database encoding and may treat multi-byte characters as single byte characters. This could result in the last two bytes being escaped into a reserved character such as ’ as well as countless other character which have special relevance for the SQL engine.

In such a case, the attacker could append additional SQL commands to gain access to data or functions not intended. This is why the function is deprecated and the use of mysql_real_escape_string() is recommended.

mysql_real_escape_string() works almost identically except that it connects to the database to determine what encoding is used by the database, preventing known multi-byte escaping issues.

Also note that mysql_escape_string()  and mysql_real_escape_string()  do not escape the % and _ characters (as per the manual reference http://php.net/manual/en/function.mysql-escape-string.php and http://php.net/manual/en/function.mysql-real-escape-string.php see notes). This could allow access to data that not intended when used with keywords such as LIKE, so special care should be taken.

Update

  So, what encoding does mysql_escape_string assume?

I believe it is ASCII, however I am unable to confirm this. Regardless it makes no difference to the result which is; using Latin1 for database encoding could result in a security vulnerability if not properly encoded.

Also note that this is not just vulnerability with the database. Within the application/server-side script you must be careful when handling input to be aware of how strings are passed from function to function and ensure that correct encoding is preserved. Ideally using UTF-8 end-to-end would be good but not always an option.


Can an HTTPS site be malicious or unsafe?

No, HTTPS does not necessarily mean that a site is not malicious.  HTTPS means very little as to the security of a site.  It's specifically geared to keep your communication with the site secure from eavesdroppers and tampering, but offers nothing as to the security of the site itself.

Yes, a site serving content over HTTPS has a certificate.  That means that the individual who requested the certificate from the CA has an email address that is associated with the domain. Except in the case of Extended Validation certificates (the ones that offer a green address bar) this is literally all it means.  Nobody from the CA is validating that the site is safe, secure, and not serving malware.   Any site, with an SSL cert or without, can have bugs and vulnerabilities that allow an attacker to leverage them to serve an exploit.  Or a admin or user who has the ability to either maliciously or unknowingly cause the site to serve malware. Even if the site itself does not, if it serves advertisements (or any other content, for that matter) from an ad network or another site, that could be vulnerable.

So, HTTPS means that nobody should be able to view or tamper with your traffic.  That is all that it means.


How do I figure out if a piece of software contains malware?

Unfortunately this is not usually possible.

In many cases, the software is signed, so that you can verify the company who authored the software. However, in your case you are getting the software directly from the author so you know who they are.

As you understand, even knowing the author, there is still a risk that Malware was included by the author. Many larger companies will not do this because they have so much to lose, but it is technically possible.

It may be wise to do some research to see if other users have reported issues.

There is no practical way to scan for 'unknown' malware. Anti-virus programs can only scan from a database of previously reported malware. (also you would have to disable auto-update features)

So the bottom line is

Either you trust the creators enough to run the software. (and install their updates)
Or, you restrict the scope in which the software can run.

Restricting the scope means

Run on a separated VM, which has no access to any of your operational systems.
Restrict internet access so that potential malware cannot call home.
Optionally run on a separate physical computer as well, but this is probably overkill.

Following these steps will limit the risk associated with running malware, but is quite distinct from your original request to detect whether malware is present.

Some final points:

Is it better for the software to be open source or not? That's worth considering, but not in this answer.
It is technically possible to de-compile the program and inspect it manually, but this is not practical.
You could write your own tools that serve a similar purpose.


Web Proxy through browser vs through system - is there a difference?

If the DNS lookups are done by the proxy or by the client itself depend on the kind of proxy configured and less if the proxy is configured in the browser or global to the system. When using a HTTP proxy (which works for HTTPS requests too) the DNS lookup is done by the proxy. If this is a SOCKS4 proxy it needs to be done by the client. With SOCKS4a and SOCKS5 it depends on the actual client and maybe additional configuration.

Anyway, even if the DNS lookup is done by the proxy the ISP can still see which domain name gets accessed, no matter if you access HTTPS sites or not. In none of the proxy protocols the traffic between client and proxy gets encrypted by default. This means the target domain can be extracted from the SNI extension of the TLS handshake. Note that some proxies might be able to use a HTTP proxy over HTTPS. But this is not the case for most browsers and needs special add-ons or advanced configuration access for other browsers (like in Firefox).

Thus, to hide which domain you access you should use a VPN and not a proxy or make sure that you access the proxy itself by HTTPS and not only the site you visit.


Encrypted offsite storage using sshfs and cryptsetup/dm-crypt/LUKS

For dealing with remote drives, you're probably better off using a file-level encryption system like eCryptFS.  Alternatively, if you're just looking to store backups or something similar, you can use the built-in encryption in tools like duplicity (that uses GnuPG for encryption).

Using LUKS like you've described should be fine, and is essentially creating an encrypted container, but you'll probably have suboptimal performance and it'll be more difficult if you ever want to encrypt more data than you've prepared the container for.


Difference between "weakness" and "vulnerability"?

Your understanding is correct within the framework of the CWE1.

Typically when you encounter problems with terminology, it is best to focus on the scope where the term is used. The word weakness in itself has several meanings according to the Merriam-Webster dictionary, for instance:

  1 : the quality or state of being weak; also : an instance or period of being weak
  2 : fault, defect
  3 a : a special desire or fondness
  3 b : an object of special desire or fondness
  pizza is my weakness

How the word weakness is used by the CWE is explained in their FAQ which you have linked. They even have a question in there which is more or less exactly phrased like yours "What is the difference between a software vulnerability and software weakness?"

There they state the following:

  Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE®) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network.

So what kind of error can lead to a vulnerability and could therefore be called a weakness? Let's have a look at a randomly selected weakness from the CWE database.

  CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

  Description
  The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.

There are also examples given, let's look a short one:

  Example 2

  This code allocates a socket and forks each time it receives a new connection.

sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
 newsock=accept(sock, ...);
 printf("A connection has been accepted\n");
 pid = fork();
}

  The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.

Now it gets interesting:
In itself this represents a working interface, but the consumption of resources is not controlled by the system. This is a weakness that leads to a vulnerability because it can be controlled by an attacker. If new connections can not be established by an attacker, this would still be a weakness, but it would not lead to a vulnerability.

To put it in other words:
All vulnerabilities rely on weaknesses, but not all weaknesses entail vulnerabilities.

1:
For instance in the ISO 27000 framework the term weakness is not defined as a separate term. They only define vulnerability:

  vulnerability
  weakness of an asset or control that can be exploited by one or more threats


Vulnerability by leaving an open port in a pc

If I understand correctly, you did something like this from your home PC:

homepc$  ssh -R2222:localhost:22 remote-linux-server.example.com

So if you connect to port 2222 on that remote linux server it gets forwarded to port 22 on your home computer. You'd normally start VNC on port 22 to let you get a VNC session, but you forgot to start VNC this time.

If that's the case, and there's no SSH daemon or VNC session listening on port 22, there's nothing you can do to connect to your home PC.

Leaving port 22 open to the world without any service listening on that port should not be a security risk (other than announcing the existence of a computer at that IP address), but could possibly be used to execute a DoS attack since it takes some work to respond to a request on a closed port even though no service is listening.

Though I question why you run your VNC server on port 22? Why not run it on some other port, and leave 22 for SSH, then you can forward both port 22 and your VNC port back to your home computer, giving you a way to log in even if VNC isn't running?


What are the risks of a localhost signed cerificate?

With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. Therefore, no extra security issue.

Of course, the certificate only authenticates the host name. It says nothing about whether the server is malicious or benign, only about who the server is.

Mind, though, that if someone modifies the local "hosts" file, then accesses to "localhost" could be redirected elsewhere -- but someone who can do that on your machine already owns it and could insert his own rogue CA in your trust store anyway.


Can simply opening an email lead to a hack?

There have been such vulnerabilities that allows code execution when the message is opened or previewed. A recent example is the Microsoft Outlook Memory Corruption Vulnerability CVE-2018-0852 affecting all Outlook products from 2007 through 2016.

  Note that where severity is indicated as Critical in the Affected
  Products table, the Preview Pane is an attack vector.

Similar vulnerabilities could be found on ANY email client, but the fewer features a client has, the fewer potential security risks, e.g. Mozilla mentions in Security Advisory 2019-12 about critical vulnerabilities:

  In general, these flaws cannot be exploited through email in the
  Thunderbird product because scripting is disabled when reading mail,
  but are potentially risks in browser or browser-like contexts.

This gets broader, if you also consider the possibilities provided by the intended features of some email clients, such as downloading any external content like images. Although your computer doesn't get infected, the sender can get information on when you open the email and possibly the location (IP address). Reading all messages in plain text mode enables the least additional features.


Does SSLv3 uses SHA256 as hashing algorithm?

TLS 1.0 (SSLv3 successor) was published in January 1999 (RFC 2246). SHA-2 was first published in FIPS 180-2 in 2001. Thus, there's no way an implementation following just the SSL3 specifications could have supported SHA-2.

The version used by SSLv3 would have been SHA-1, just like TLS 1.0:

SHA
   The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
   produces a 20-byte output. Note that all references to SHA
   actually use the modified SHA-1 algorithm. [SHA]

rfc2246 page 59


Effectively you do not ever want administrative consoles, administrative applications, or insecure applications exposed to untrusted networks such as the Internet.

It is possible to run these web-apps on other internal ports or simply ports that are not accessible to the outside world or other untrusted networks, then access the web-apps via a VPN. This would allow you to VPN to your server to do web-based configuration tasks and/or use the untrusted apps without exposing them to the Internet or untrusted networks.

The concern is that in some cases when you add such web-based administration tools these can be exposed to both the external (untrusted) and internal (trusted) networks at the same time, especially if it's via the same server daemon. So you will want to do a test to confirm this is not the case.

Alternatively, what some people do is run two different webservers on the same system (For example you could run IIS for external apps on ports 80 and 443, then run Apache with another app on a high port such as 32443 which is either blocked by a firewall or run on an internal loopback address such as 127.0.0.1. There are many ways to do this.

Back to your question of relative risk. The system with more code/applications accessible to the untrusted networks will be at greater risk from the untrusted networks. If you are comparing two applications side by side it will be a relative comparison at a given point in time taking into account the security controls in place for each application at it's most current version level.

In a direct comparison of the following two:

1.) ISS + PHP + phpMyAdmin
2.) ISS + PHP + phpMyAdmin + XAMPP

One would expect the second combination to be likely to have more vulnerabilities at a given point in time because it effectively exposes more attack surface. There are exceptions where added software adds additional security controls but in general this is an easy way to look at your exposed attack surface.

Note: There are many other ways to solve the problem you are trying to solve. You could also look at using tools like mod_security and the use of static IP's with firewall configurations too.

Finally, I have to point out that no matter which way you go you will want to do a lot more to secure this system if it is exposed to the Internet.


Is it necessary to update JRE in an Apache Tomcat Server?

Given that your system is exposed to the internet, you should do all the tasks you mention in your question. Sooner or later an automated attack against Java 7 will be available, and bots will find your server.


What is the security value of chattr +s?

That is correct.

There is no guarantee that the setting of the attribute will cause the complete zeroing of all bytes in all relinquished sectors for all kernel-driver-firmware-hardware combinations.  There is also no guarantee that the cases where it is not guaranteed will be reported to the terminal when the attribute is set.

The +s attribute is a reasonably good idea that may or may not eventually see universal or near universal coverage.

Note that on a correctly configured system, only root has access to the raw device to acquire intact or partially intact sectors that may contain fragments of deleted files.  How much of a concern physical access to the disk or breach of root access is for your particular system plays into the decision making regarding security of these sectors.

For highly critical data where people or organizations may pay for advanced and continuous attack, the use of encryption within the context of a proven effective security protocol is preferable to than relying on chains and layers of software to cooperate to zero all relinquished sectors.

Statistical results from an adequate sample size would be required to answer your second question.  I doubt if an authoritative answer will emerge, simply because it would require a large investment of both time and money to produce the raw data to analyze.


Buffer overflow due to strlen, strcpy, strcat

You're using C++ (because you couldn't use new char if you weren't); you should really be using std::string here, including as the return value.  You can then dereference .c_str to get a const char * pointer if you need that in your upstream code.

You don't want to just return the std::string.c_str from your function however; the std::string will go out of scope and you'll be invoking undefined behavior.

That avoids having to deal with any of this character-counting stuff.


Can we use network hub as an MITM sniffing device?

An alternative to purchasing a separate hub is to get a regular consumer router/switch combo and install OpenWRT (or any other firmware with mirroring type functionality).

This will copy all traffic on the router to a specific IP. Attach your laptop to the router and sniff with promiscuous mode.

There's several ways you can do this. You can run tcpdump on the router and stream that to your laptop see here for instructions.

Or you could use the iptables TEE extension

To answer your original question, yes you can use a hub. Most devices sold these days are switches, or even routers with switches built in.  You may have better luck looking for a used hub, especially at a second hand store where older devices are common.


This is a perfectly reasonably approach, especially when you want to automate the downloads.

Considerations:

Make sure the credentials only give access to the log files and nothing else
Keep the private keys secure
Don't make the key lifetime too long a year, maybe 2 at the most
Use a long key and generate with plenty of entropy

That's about it. There are loads of tutorials on how to do this.


What is the incident Plan and Disaster recovery plan for Fire

I am no clue on those issue. What should I do?

This should be a good sign that you should not be the one planning such things.

An incident response plan is a plan you should follow during the incident to mitigate, reduce and contain the damage. Such a plan should clearly list out what everyone's role is supposed to be and what steps have to be taken so there is no confusion or panic when an incident occurs.

A disaster recovery plan is a plan that hopefully allows the business to recover from damages after the incident has occurred. This could include things like an alternative location to work etc.


How to secure sensitive data in application with message queue

What is your threat model?  Always answer that first.

It looks like existing data is probably safe (given most reasonable threat models).  However, you are as strong as your weakest link.  The front-facing servers still have to hold onto the data during processing.  Does your threat model include a hacker that compromises that server and simply begins siphoning off sensitive data as it is entered by users?


How to exploit this buffer overflow. Where is the return address?

Correction.. I’ll look again but in order to overwrite EIP you’d need to input a buffer that is buf +whateverIsAboveItOnStack + EBP (4bytes) + whateverYouWantEIPtoBe . Run the program in gdb and type disass strcpy() the you’ll be able to see where the overflow happens and where your buffers are located. Hope this helps.

    (gdb) run $(python -c 'print "a" * 270')
Starting program: /home/bob/C/Disassembler_Fun/SE_Vuln/se_vuln $(python -c 'print "a" * 270')

Program received signal SIGSEGV, Segmentation fault.
0x0040068b in main (argc=<error reading variable: Cannot access memory at address 0x61616161>,
    argv=<error reading variable: Cannot access memory at address 0x61616165>) at se_vuln.c:10
10  }
(gdb) i r
eax            0x0  0
ecx            0x61616161   1633771873
edx            0xb7fbc870   -1208235920
ebx            0x61616161   1633771873
esp            0x6161615d   0x6161615d
ebp            0x61616161   0x61616161
esi            0x2  2
edi            0xb7fbb000   -1208242176
eip            0x40068b 0x40068b <main+139>
eflags         0x10286  [ PF SF IF RF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

If I overflow a buffer in a program with a vulnerable function that returns execution somewhere (main()) I can overwrite EIP

    #include <string.h>

void vuln(char *arg) {
    char buffer[10];
    strcpy(buffer, arg);
}

int main( int argc, char** argv ) {
    vuln(argv[1]);
    return 0;
}

    (gdb) run $(python -c "print ('a' * 22) + ('b' * 4)")
Starting program: /home/bob/C/Disassembler_Fun/overflow $(python -c "print ('a' * 22) + ('b' * 4)")

Program received signal SIGSEGV, Segmentation fault.
0x62626262 in ?? ()
(gdb) i r
eax            0xbffff286   -1073745274
ecx            0xbffff520   -1073744608
edx            0xbffff296   -1073745258
ebx            0x61616161   1633771873
esp            0xbffff2a0   0xbffff2a0
ebp            0x61616161   0x61616161
esi            0x2  2
edi            0xb7fbb000   -1208242176
eip            0x62626262   0x62626262
eflags         0x10282  [ SF IF RF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51
(gdb)

Note the B's (0x42 is the hex for b) overwriting EIP. I guess this is the kind of overflow in your example can be used for a DOS attack but not necessarily code execution. I'd suggest enlarging the buffer in my example if you want to use it for tests involving storing a nop sled and shellcode in the buffer. Good luck have fun! Hope this helped.


Store password securely but being able to check separate characters in that password

You can't - at least not in software, for reasons given by Matthew.

If you have a five character password with a-z, that's 26*26*26*26*26, or 11881376 possibilities. However, if you can probe one character at a time, it's 26+26+26+26+26, or 130 possibilities.

Even for long, complex, passwords this reduces the amount of work that has to be done to trivial levels.

In addition it's bad security. People should use password managers, to have unique passwords everywhere. Password managers do not support this kind of queries. And even if it's a typed password, it's difficult, as many people rely on muscle memory to enter passwords. I wouldn't be able to give you the third character of my password without typing it out and checking.


How can I found a source of HTTP request in Wireshark?

In Linux the command

netstat -anp

Will list all network connections and will include the ip, port , and program name

So in wireshark you can find the ip and port for the web request

Then run netstat and search for that ip and port to find the program using it


How a connection string injection attack is performed?

Some database providers has the "last one wins" algorithm.
So if there is a  KEYWORD=VALUE pair which is found more than once in the connection string, the value associated with the LAST occurrence is used.

So in a web application, If a user enters the username and password; a connection string is generated to connect to the back end database.
For eg:

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX;

After entering the username and password if the attacker adds something like

Intergrated Security = true;

the string becomes

Data Source = myDataSource; Initial Catalog = db; Integrated Security = no; User ID = myUsername; Password = XXX; Intergrated Security = true;

now here Intergrated Security = no; is overridden by Intergrated Security = true; by the "last one wins" principle.

The web application will then connect to the database using the operating system account under which the application is running to bypass normal authentication.


What is the threat of having the clipboard enabled on Citrix and other rdp?

Depending on the configuration, there may be the ability to copy and paste to a local document. This could become a compliance issue depending on your industry. Say for example you deal with credit card numbers, social security numbers, etc. Someone could copy that data into an email or text file. It really depends on what kind of data you need to protect.

What is the specific industry?
What is the proposed infrastructure structure and flow of work to be completed?
Do you have to comply with HIPAA/HITECH, PCI, or any other types of compliance?

UPDATE: The best option might be to assign company assets that have security measures implemented on them (full disk encryption, USB ports disabled, Logging and auditing enabled, block personal email and networking sites not needed in the HOSTS file, etc.) Not doing so could put information in the lawson system at potential risk. Never underestimate the human element, plan and engineer for it.

UPDATE2: This should help you out. check out http://support.citrix.com/proddocs/topic/xenapp5fp-w2k8/ps-admin-policy-rules.html

which shows:
Prevent cut-and-paste data transfer between the server and the local clipboard

Resources > Other > Turn off clipboard mapping

and turn off clipboard mapping.

The only other thing is that you may want to also consider the ability to print screen to be considered a possible security hole as well. To disable this through group policy check out http://www.sdmsoftware.com/group-policy-preferences/disabling-print-screen-through-group-policy/

Also I would disable USB ports as well just to be more safe and secure.


What are the differences between the arcfour, arcfour128 and arcfour256 ciphers in OpenSSH?

The "arcfour" cipher is defined in RFC 4253; it is plain RC4 with a 128-bit key.

"arcfour128" and "arcfour256" are defined in RFC 4345. They use a key of 128-bit or 256-bit, respectively. Moreover, and contrary to plain "arcfour", they also include a "discard" step: the very first 1536 bytes produced by the cipher are dropped. This is done because the first bytes of RC4 output tend to exhibit biases, which are rarely fatal to your security, but worrisome nonetheless. "arcfour128" and "arcfour256" are thus "more secure" than plain "arcfour".

Note that the extended key size of arcfour256 does not buy you much: a 128-bit key is already more than enough to defeat key cracking through brute force. A 256-bit key is more for aesthetic than rational reasons (there is a widespread belief among auditors that bigger keys are always better, just like there is a widespread belief among people in general that bigger cars are always better).

Note also that while dropping the first 1536 bytes of output fixes issues with the biases in the first 1536 bytes (of course...), it does nothing against the other biases in RC4 output (RC4 output can be distinguished from randomness after about one gigabyte). There again, these biases have never proven fatal in any deployed protocol; however, they "look bad" in audit conditions.

As for performance, there shall be no difference whatsoever, since RC4 speed does not depend upon key size. The extra 1536 bytes implied by arcfour128 and arcfour256 theoretically induce a small one-time extra cost, but that's way below the millisecond worth of CPU even on an asthmatic embedded ARM or Mips, so this would be very hard to even detect in practice.

Summary: use arcfour128 when possible, fallback to arcfour. Use arcfour256 if you need to impress bureaucrats by spewing out huge numbers that they will not understand, but which will cow them into submission.

However, network is usually the bottleneck, so even over gigabit ethernet, AES-based ciphers should provide the same actual speed than RC4, and with arguably better security (even in the skewed view of auditors). If unsure, measure; don't believe one cipher to be faster than another because you read it as some old lore which was thought out at a time when a PentiumPro was the summit of Earth-based technology.


Data Transport Encryption - Small Scale Solution

It looks for me that you try to invent your own security solution not because the existing solutions don't work but only because you don't understand how the existing solutions work. In other words: don't roll your own crypto.

In detail:

  Lets Encrypt requires internet access and OpenSSL requires you to add an additional trusted CA to client machines.

You are comparing apples and apple trees. Let's Encrypt is a CA which can be used to issue certificates. OpenSSL is a library which implements TLS and also can be used to create your own certificates.

  ... robust TLS may be overkill but I would still like to protect some information in transport.

You feel that TLS may be overkill but don't explain why. If it is about certificates - TLS can be used without these, i.e. it can work with a pre shared key too.

  ... When serving the page first generate a high entropy random token and relate this token to the un-validated session ID. ...

Basically the server creates a secret which is later used by the client - i.e. a shared secret. Only the client cannot even be sure that the secret is created by the server since it can be created by a man in the middle. Without proper authentication of the server the client does not know who it is communicating with, it might be the server but it might also be an attacker. In TLS certificates or pre shared keys provide this authentication you are missing.

Thus basically you just assume that the first connection will be to the real server. This is called TOFU - Trust On First Use. It can be achieved with TLS too: the server might have some certificate the client has never seen before but the client will trust it once and later check that the same certificate is used for all following connections.

  A successful login will destroy the key and generate a new session ID while invalidating the previous ID.

Only it is not really TOFU since the clients seems to forget the server as soon as it logged in and will hopefully connect to the proper server and not some attacker for the next login too - but that's just hoping since the client will not actually check.

  Please explain to me why this solution may not be recommended ...

The main problem with this is that you don't have enough understanding of established methods so that you think that established methods don't work in your case. Again, don't roll your own crypto but instead use established ones were lots of experts worked on it.


What are your actual requirements? "Enterprise level" doesn't say much, at least no more than it will be a large project. If NIST is a requirement, then PBKDF2 is all you've got. From a security perspective, I would recommend bcrypt, as it is slightly more secure than PBKDF2 which is based on SHA variants. bcrypt itself has baked long enough to be a good alternative to PBKDF2, even though the NIST doesn't say anything about it (yet).

When it comes to implementation, you really should use a well-established library. You don't want to manually check the implementation details and neither should you. A quick search revealed that there are several bcrypt implementations for C# that are well supported in the C# community.

For more details about PBKDF2 vs bcrypt also see the answer by Thomas Pornin.

Update

I wouldn't go with the SHA1+AES option. Doing this will not actually resolved the problem, but only mitigate the risks for certain types of attacks. Still if the application somehow were to leak database contents, you can only trust on SHA1. It feels to me like a hack, and the last thing you want is to cook up something yourself.


Are there any guidelines for passwords that need to be read out loud?

Microsoft already has done something like this with their product key alphabet. They selected a subset of characters that are distinctive, and excluded characters that could lead to either confusion or offensive words.

The 24 used are:
2346789BCDFGHJKMPQRTVWXY

The 12 unused are:
015AEILNOSUZ

The hyphen character is used to separate five character groups, but is not significant.

Product keys are broken into five character groups, separated by hyphens for readability.  The fifth character of each group serves as an independent check character, ensuring only that the group of five was typed correctly. (It's just a check sum, and doesn't indicate if that group is part of a valid password or not.)

Why this relates to you is that if you are generating passwords, these can be completely unambiguous whether spoken or typed. Nobody has to ask "Oh or zero?" "Two or zed?" There are no symbols that can cause the difficulties you encountered. Furthermore, you would translate them to upper case in software to avoid case issues. And they are common to all languages that use the Latin alphabet.

The drawback is that with only 24 possible symbols, one character can offer only 4.8 bits of unpredictability. For equivalent security a password has to be three times longer than a password that can have upper case, lower case, numeric digits, and symbols.  To that, add another 20% for the check characters. That makes every 128-bit password a hefty 35 characters long, or seven groups of five. (Microsoft's five group scheme offers 96 bits of uncertainty.)


What data leaks when an android apk is built?

You can get Developer ID, name, location, organization from the certificate. Thou developer id or details may change in the play store, the original cert are always in use especially if the developer is providing and update to their apk.

Developer changing details in the play store does not change their original certificate.

Android requires that all APKs be digitally signed with a certificate before they can be installed.

A public-key certificate, also known as a digital certificate or an identity certificate, contains the public key of a public/private key pair, as well as some other metadata identifying the owner of the key. The owner of the certificate holds the corresponding private key.

More information regarding the certificate details can be found at android developer site


Securing protected routes/pages with JWT

I think the issue here is a misunderstanding of what needs protected. Let me lay out your situation to make sure I understand it:

You have a JS frontend that renders all pages
You have some pages that shouldn't be accessed without authentication
You're not sure how to protect those pages, given that users may spoof "show this page" responses to the client

The important question is, does the page need protected, or does the data on the page need protected?

If it's just the data that matters, simply have the server avoid sending the data unless the user is authenticated. The user can display the page all they want, but they won't have the data that makes the page useful, so it doesn't really matter.

If the page itself must be kept secret (are you sure? It seems odd to me to keep a layout secret...) then you must not include it in your frontend. If you put it in your frontend and send it to unauthenticated users, they will be able find it if they're determined.


WebSockets protocol is a tricky beast to evaluate right now, as it's changing frequently. After the flaws in draft-hixie-thewebsocketprotocol-76 of the WebSockets protocol discovered by Adam Barth et al. a few months ago, Firefox disabled WebSockets implementation in about:config preferences. Since then, a new protocol version is in the works, currently up to draft-ietf-hybi-thewebsocketprotocol-07, that tries to fix the flaws discovered. The browsers quickly adapt to the new version - see e.g. Mozilla bug #640003. But - on the other end, WebSocket servers still try to maintain backward compatibility, e.g. Socket.IO server still supports version pre-76.

So you might still succeed in trying to connect to WS server outside the browser, forcing older version of the protocol (see my tool already mentioned in the comments above).

But still - you are unable to send completely arbitrary traffic through WS connection. The frames begin with NUL byte, end with \xFF, with UTF-8 string inbetween (+ a handshake), so cross-protocol-attacks are not so easy to perform. Still, I'd rather use  WSS:// encrypted version than the plaintext one.


Should the recent Tiny Chip attack teach us to invest less in our security posture?

No, for so many reasons.

First, let's lay out there that right now (2018-10-05) there has been discernible concern within the Security community about the fact that "what we know" so far is very thin and rests heavily on the reputation of the reporters.  The "targeted" companies have published denials which are "heavily detailed, denying the Bloomberg report point-by-point."  The GCHQ has publicly supported those denials, and Homeland Security on 10/06 agreed that they "have no reason to doubt the statements from the companies named in the story."

It's very possible that people with enough clearance to know more have too much clearance to talk about it, but as it stands, there's a chance this could be FUD.

That said -

All the non-Tiny-Chip threats still exist, and are just as worth spending money to mitigate tomorrow as they were yesterday.
With what little we know about Tiny Chip today, there's no reason to think that traditional Security architecture, engineering, and operational practices won't reduce or eliminate the threat.  For example, segmentation has been cited as a countermeasure that might be effective.
Tiny Chip has always existed as part of the threat model.  All that's (potentially) changed is the scope of it, and if a threat becomes industrialized enough to widen the scope like that, that's exactly the time to bring Security Professionals to bear on the problem.  Industrial* problems are more susceptible to well-designed countermeasures than one-offs.
Tiny Chip falls into the category of Nation-State Actor threats.  There are many things that Nation-States can do to compromise your security, which you can do nothing about.  Always have been.  Always will be.  Fortunately, for most of the businesses out there, Nation-State attacks are a limited or even non-existent part of their threat landscape.  Kim Dotcom ticked off a lot of governments - Kim's Nails on Wabash Way, Plainfield, very few of them.
You might, even more plausibly, propose that business simply stop using computers as an effective method of reducing the risk of Chip Hacking.  The business would be less vulnerable, less reliant on Security professionals, and go out of business even faster - win, win, win!

*When I say "Industrial", I mean "rolled out in a systematic way, which implies some commonality of devices, methods, and behaviors."  If you want to chip 5 laptops by hand, that's fine.  If you want to chip a production line of 50,000 laptops, you're going to have to industrialize the process, and the result will carry a uniformity which makes detection and countermeasures easier.


What are those http://123.249.24.233/POST_ip_port.php POST requests I get on my server?

It's a malicious bot, that is trying to scan web application for security vulnerabilities.

Look at these links for more information about blocking it:

https://serverfault.com/questions/700404/huge-traffic-from-post-123-249-24-233-post-ip-port-php

https://gist.github.com/renancouto/0ad35842f1c536c1dbbe


Is it really that unsafe to store passwords in a text file on my computer?

Yes, it is unsecure. Here are some reasons.

It can be that you installed (intentionally or not) some malware or virus, that scans your files and sends data to some external server.

It can be that your create backups to some external drive and they are not encrypted. If you lost your back up drive, somebody can get access to it.


Receiving random numbers in GET request query string. Exploit?

I would guess this is a spider doing cache busting. The get parameter is ignored by the server and client, but since the get parameters are part of the url (as far as the caches are concerned) the url has never been seen before, so it forces a fresh load from the web server.


The CPU is where the code is executed so, no, you can't "hide" processing from it. At least, not if you have just a single CPU.

But if you have additional processing units that you can program in a safe way, then you can protect some processing from the machine's CPU.

Smartcards are an exemple of such offloading: they are programmed in advance with the keys that will let them do their job. Later, they can be inserted into untrusted system and still maintain the integrity of process they were designed for. For instance, you can use a smartcard to store a RSA private key and allow the smartcard to be used from an untrusted computer while still retaining reasonable trust that these keys haven't been leaked.


You'll only be able to identify which server the email came from by checking the 'Received' headers. This isn't reliable though, since systems can be hijacked for sending spam. The FROM header isn't reliable since it can be manipulated using an SMTP client to be just about anything. Changing it is trivial really.

You can report phishing attempts to Amazon using the information on this page: https://aws.amazon.com/security/report-suspicious-emails/


Does HTTPS mean that packets can't be read by intermediaries (like listeners at a VPN node, for instance)?

If Bob is just listening, he can not decrypt the HTTP message (encrypted with TLS to become HTTPS). The TCP/IP packet that holds the HTTPS packet is not encrypted though (it can’t be, it’s needed for the network to work).
In the TCP/IP packet you store target and source IP, TTL And some more flags. If you see a packet on the network you can track it’s time of seeing.
In short Bob needs to break HTTPS or do a specific attack on you, just listening is not enough. Some of the metadata of your connection is present in clear text for the systems to work, this part of it will be visible to Bob.


Login with AD credentials on behalf of a user

Will security officers (CSO) in companies in general accept this or not for a 3rd party solution installed on prem?

Nobody CSO can tell you how another CSO will answer that question. Personally, as an Active Directory admin I successfully advised against implementing dozens of applications already, that provide LDAP or local authentication already.

At first this seemed a very bad idea which was my initial reaction. But it seems it is an acceptable pattern.

Yes, it's common that applications provide only LDAP authentication. That does not negate the drawbacks.

Your application is asking your company's employees for their credentials to your company's internal Active Directory. There is trust there. (From the Stackoverflow answer)

Trust has nothing to do with security. Hundreds of thousands of companies trust in Cisco, yet they implemented backdoors in some of their switches. Trust can be betrayed.
As an Active Directory sysadmin I generally advise against implementing any software that asks my users for their password for several reasons:

It opens up a new attack surface, for no good reason.
Code audits are cost and time expensive, if possible at all. And they still don't provide 100% security.

If the application asks for credentials, an attacker (which may even be the developer itself) is able to collect users Active Directory credentials. Regardless of whether they're never logged or stored in the app. With the credentials, the attacker is able to access everything outside the app the user has access to.
Many companies provide passwordless authentication mechanisms like Kerberos/AD, SAML/ADFS/AzureAD, oAuth/ADFS/AzureAD. And for good reason. They work passwordless and if any attacker targets the third-party system, they will not be able to gain access with credentials outside the application they compromised.


Anything in the consultancy side of the field will leave you at home some percent of the time.   That favors jobs such as security audits/assessments, penetration testing, or security design work.

When consulting, you'll spend some percent of your time at the client site and some amount of time in you home office.  The trade-off is that travel to the client site can be more painful than getting a regular job in the office 45 minutes down the road.  Some jobs may be 10% client location, others may be 90%.  Some travel may be local, some may be on a plane, depends on the consultancy's clientele.

Consulting can be great, and it can be terrible, but it sure does present an alternative to a standard office job.  You can see a lot more, learn a lot more, and have a totally different accountability profile (it's not how often you're at your desk, it's how good and how timely your deliverables are).  If you're smart, flexible, and willing to work hard, you can get some rewarding years out of it.

I do agree with @Robert David Graham, standard jobs security haven't caught on to work-at-home yet.


Is encrypting data with a private key dangerous?

It seems that the code you are looking at is taking a bit too literally the first description of how RSA signatures work.

When RSA was first described, it was an asymmetric encryption system: sender encrypts data with the recipient's public key, and the core operation is a modular exponentiation which takes as input a number modulo n (n is the modulus, a part of the public key) and returns a number modulo n. Then somebody said: hey, if we reverse the process and decrypt some input data (with a private key, necessarily), then we get a signature since anybody can perform the reverse operation (encrypt with the public key), which counts as signature verification.

This is an over-simplistic description of RSA signatures, and it does not actually work, because it neglects the effect of padding, which is necessary for security (see PKCS#1 for the Right Way to do RSA encryption and signatures). But the idea that signatures are encryption-in-reverse (or "encrypt with the private key") is unfortunately widespread, and lead to scores of homemade solutions which are all, invariably, weak in some way (but not necessarily in an obvious way). Chances are that you observe such a homemade solution.


There is indeed a lot of unclear information out there. Your first idea was correct, to the best of my knowledge. While I can't seem to find an authoritative source right now, this DD-WRT wiki page explains it the way I understand it:

  TKIP vs AES-based CCMP

  Defines the algorithm used for message integrity and confidentiality.

  WPA was designed to be used with TKIP (and WPA2 designed to use
  stronger AES-based).

  However, some devices allow WPA (not WPA2) with AES (and WPA2 with
  TKIP).

  AES is optional in WPA; in WPA2 both AES is mandatory, but TKIP is
  optional.

  Note that TKIP is not directly comparable to AES; TKIP is an integrity
  check, AES is an encryption algorithm. In the context of wireless
  security this actually means TKIP vs "AES-based CCMP" (not just AES).

  TKIP is a lower end encryption protocol (WEP2) and AES is a higher end
  (WPA2/802.11i) encryption protocol. AES is preferred.

  TKIP+AES

  This is what the encryption standards are for WEP2 (TKIP) and
  WPA2/802.11i (AES). It will attempt to use AES if available and fall
  back to TKIP if not. This setting offers the most compatability but
  won't guarentee a higher level of encryption if a device falls back to
  TKIP.

It gets even more confusing; my access point running OpenWRT supports the following modes, among others:

WPA with CCMP, TKIP, or both
WPA2 with CCMP, TKIP, or both
Mixed WPA/WPA2 with CCMP, TKIP, or both

Nowadays, the only relevant option is WPA2 with CCMP (or WPA3, of course).


Is it possible to issue a certificate with different attributes than in .csr?

The certificate request is just a container to transport your public key and some information you like to have included in the certificate. The only thing the CA really needs from this is your public key. Everything else can be ignored by the CA and will often be ignored and instead the CA will create a new certificate request which includes your public key and the information the CA likes to include into the certificate. This new certificate request then gets signed, i.e. usually not your original certificate request.


What is the safest way to close a popup window?

Click the red X --> Popups can masquerade as a browser dialog window
Alt+F4 / Taskbar>Exit / Browser>File>Exit --> Javascript can indeed trigger an action on page close (which also happens on exiting the browser because the page has to be closed to do so - just tested while writing this post)

Therefore it is correct to say that the safest option is to to Ctrl+Alt+Del and kill the process. This is safe because (in Windows) Ctrl+Alt+Del is a secure key combination that can only be intercepted by the OS, so it can't trigger any Javascript in the browser (it can't trigger anything actually).

The Ctrl+Alt+Del link above also has some commentary about what it does in other Operating Systems.


How to protect data integrity in IoT network?

If you consider that an attacker has access to the device, and can clone it, all bets are basically off. The attacker can probably read the key from the device, unless extra protection such as secure processors are used - and even then bugs in the design is likely to let a sufficiently skilled attacker retrieve the private keys.

However, if an attacker only has access to listen to the traffic, it's relatively feasible to secure it. HMAC is one way of ensuring that. It ensures integrity and authenticity of the data in question, and is stateless.

But by itself it does not protect against replay attacks. Replay attacks could very well be a real risk in this scenario.

To reduce attack surface, you should also change keys, e.g. in between patients, ensuring that if Patient A, who had physical access to the device managed to grab keys, those keys are invalid for Patient B.

As blood pressure is health related information, you should consider encryption as well, to ensure secrecy, in addition to ensuring it's authenticity.

You may also consider things such as frequencies and tx power that ensures the attacker has to be physically close to both intercept and transmit. This does not provide security by itself, but it makes it harder both to intercept traffic and inject traffic.


@p____h already answered pretty well most of what occurs when an account is hacked, but I wanted to add my salt regarding a recently hack of a Gmail account that is very interesting to read!

It's the recent Cloudflare attack.

This is just AMAZING, the attacker used 4 flaw in various services, not only Cloudflare's :

  AT&T was tricked into redirecting my voicemail to a fraudulent voicemail box
  Google's account recovery process was tricked by the fraudulent voicemail box and left an account recovery PIN code that allowed my
  personal Gmail account to be reset
  A flaw in Google's Enterprise Apps account recovery process allowed the hacker to bypass two-factor authentication on my CloudFlare.com
  address; and
  CloudFlare BCCing transactional emails to some administrative accounts allowed the hacker to reset the password of a customer once
  the hacker had gained access to the administrative email account.

I highly recommend you to look at the blog post, and if you are hurry, just read the infographic that shows the sequence of events. This attack would be worth a short movie!


How to best manage multiple applications using the internet with Firewall

usually you trust your egress traffic and try blocking only ingress traffic. Most application do not need or use ingress. statefull firewalls are "smart" and look who initialised the connection.... for example if you are trying to connect to the steam server connection starts from your "end" and firewall will allow responses from steam server, as you "requested" it. However, if you are planning on running a mincraft server you need to know which port is used for the server and allow incoming connections on that port. So in general acceptable security posture for home use is allow all outgoing traffic, and for incoming traffic open only ports that are required when you want other people to access services you provide, otherwise block all incoming traffic.


Reasons to encrypt filenames on cloud backup

If filenames are sensitive then encrypt them, if not then don't. Eg. are you happy for staff at your backup service or possibly others (in the case of breach) to see Secret Government Contract bid.docx listed?

That's all it comes down to. A cost/benefit analysis for your particular usage. You should also find out if the client software can restore the original folder structure and filenames upon recovery from backup. Consider if this original information stored encrypted in the cloud and where the decryption key is kept.


How to use master password for GPG encryption after setting up Yubikey?

The "master password" is not a replacement for your private key -- it is simply a security measure to prevent someone from reading your private key from disk (before being written to the disk, the private key is encrypted itself using your passphrase).

In other words, now that your key is on the Yubikey, you must always use the yubikey in order to sign or decrypt anything.


Is there any asymmetric scheme provides signature with length of 30 bytes?

AFAIK you should check elliptic curves. Since BitCoin "account number" is a public key itself, I would suggest:

http://blog.ezyang.com/2011/06/the-cryptography-of-bitcoin/

You should be even able to find an implementation in a BitCoin client.

However, I don't see a reason to use asymmetric cryptography in your case. Your application can just obtain a shared secret from the server and then use just HMAC to authenticate. Why not?


Is there a way to use clear key encryption for protecting media HTML5 media streams?

The point of EME with clear key encryption is to provide an easier to implement encryption for content that is slightly more difficult to steal and share. If you really need to protect your content, DRM is currently the strongest solution, ignoring the scenario of not sharing the content in the first place.

On the easy to implement and easy to bypass end is putting a single non-rotating key in the master manifest and trying to control access to the manifest. Once a user gains access to the master manifest it's all in plain sight and can be shared openly with others.

On the harder to implement and harder to bypass end is using short duration key rotation on each segment and utilizing short-lived signed URLs. This means a user has to deal with different keys for different segments and downloading the different segments with valid keys in a timely manner. A user could still pull all the pieces together to steal and share the content but it is no longer just a copy and paste away.

THEOplayer has a slightly more detailed post on the things that I have mentioned here if it's still up and you are interested https://www.theoplayer.com/blog/content-protection-for-hls-with-aes-128-encryption


can malware operate on the login screen of windows 10?

Yes is it possible. It is possible to record input anywhere. For example with a kernel based keylogger, which are pretty common, even input from the login screen can be gathered.

Depending on the context of execution (user, run type...) the keylogger will have different rights, and may or may not trigger uac windows when first ran.


What is the proliferation of IMSI Catchers?

A 2014 discvery by prominent newspaper Aftenposten in Norway's capital, Oslo revealed several fake stations.
This image shows the german crypto phone in action (revealing fake stations)

Mind you, this is a small investigation that focused on politically/business sensitive areas of Oslo such as goverment buildings, embassies, high-profile enterprises etc.

The image is from this article
http://nottmagazine.com/2015/04/05/a-norwegian-watergate/

As for international statistics, your google is as good as mine.

EDIT: if you're curious about the phone, it has a built in firewall to detect suspicious behaviour http://www.cryptophone.de/


Is there a standard way to check if a requirements.txt has potential security issues?

All my github repos have requirements.txt files in them, and GitHub will email you a warning if there are security issues. (it appears that GitHub will scan any file named requirements.txt anywhere in your repo)

The dependency graph will also display some information.

As a previous commenter mentioned synk which is a nice tool, I found that for python, pyup was nicer as it allowed me to publish the results of the scan for anyone to see.

Hope this helps.


On Gmail I received an Incoming TLS Encrypted Message. Will my reply be encrypted by default to different email provider?

TLS transport security between federated servers is fairly common now, however this is not encrypted email.
Gmail does not support email encryption.The content of your email is NOT encrypted, nor the replies. The email content is in clear text on all the servers involved.


How does Remote Access Trojan / Backdoor Software work?

I can't see how a javascript can run the malicious code and automatic install the RAT into our/visitors PC and gaining access to their PC.

Javascript in and of itself cannot - the implementation of javascript usually has very, very limited access to the local system by design. That's assuming all works as designed.

Software systems rarely do; the larger the piece of software, the more likely bugs are to creep in. If one of those bugs happens to let you run arbitrary code, that's a problem.

To be clear, this arbitrary code is typically actually a specially crafted piece of input into the program. For example, let's assume there's a bug in the .image renderer (a file type we've made up for the purposes) where I read data that should look like this:

FF 00 99 00 00 00

For reasons unknown, I've chosen to do crazy things like storing this RGB code in strings and am assuming string terminates with 00 and there's actually only one character. I don't know, maybe I'm anticipating bazillion colour screens. This may be a poor example. It's late. Bear with me. Anyway, let's assume I just use standard string functions in by renderer to copy that information out of the file. Now, if I send a valid file, great. However as an attacker, I could send a file that looks like this:

FF 00 99 11 11 11 11 11 11 <lots of 11s> 11 11 <some code> 00

How could I send that file? Easy. Include it in the html of the web page with bog standard img tags. The browser will then open/render the image (as it does with jpgs, pngs etc) and my broken dodgy code happily executes that buffer overflow. I might even be sneaky and display: none; it via css, but only if the browser still processes it.

At this point, those instructions in <some code> get executed, which allows me to do whatever I need to. Typically, this downloads an executable of some sort and runs it, which means the exploit only needs to be small and I can download something meatier if the exploit worked.

From there, the "payload" can begin attempting to elevate privileges and installing backdoors. You already have a good answer on what a backdoor could do and how it might work.

I've chosen to make up an image file with a very simple mistake nobody should make; however, in the real world there are all sorts of media which have very complex results:

Javascript - it's a programming language, needs parsing etc.
PDF - a document format with bells and whistles, also includes javascript.
PNG/JPG/GIF - I'd expect a bug in these to be rare, but I believe it has happened (not sure if it caused a remote execution vulnerability though).
More complex movie formats, e.g. MP4 etc.
Flash.

Now, two scenarios are slightly more complicated:

Java applets allow arbitrary code execution - in Java. There are three possible outcomes here:

You can avoid the signing dialog display via some mechanism and so load your class without user interaction, giving you the ability to download/exec code.
You can find a bug in the classloader or jar parser that you can exploit.
There is some bug in the Java language and/or runtime you can convince the user to use.

ActiveX controls: these are, effectively, DLLs or EXEs with "special magic". It's Open Season with one of these; the only barrier here is avoiding (by getting a valid signature, social engineering or a bug) the authenticode (code signing) screen you (should) get before running one.

Baaasically, the browser environment is incredibly complicated and there are a lot of moving parts that must all read untrusted input and correctly handle it.

Now, where does Javascript come into the mix? Well, it might not contain the vulnerability itself, but it certainly can enumerate lots of useful client side information to determine what vulnerability to send - much more than simply the browser version. This could be part of the attacker's landing page, for example, to decide what if any exploits can be run.

Now, that little comment of Rory's:

  Point 5 is dramatically understating what the attacker can do.

Massively, really, megarly (that's a word now) understating what the attacker can do. Since a remote access trojan has full control of your PC, a few things an attacker may do:

Install further code, on demand, to carry out or co-ordinate attacks on other systems. This is commonly referred to as being part of a botnet.
Harvest any interesting-looking information from the current system.
Go around damaging things. Quite rare these days.
Drop payloads onto any media/medium likely to enable the attacker to an exploit another system, e.g. infecting all USB drives that are plugged in.

The possibilities are pretty limitless; the first point is actually reasonably likely, as is the last.

I can haz tl;dr?

Javascript is usually used to perform reconnaissance on the target system; beyond that, an exploit allowing arbitrary code execution must exist in the browser or one of its plugins. From there, you can persuade the computer to download more information, and from there, the computer is your oyster.


Would running VMs inside of VMs be a more secure way to study viruses, etc?

Firstly, there is no guarantee you'll even be able to run a VM inside a VM. It may seem obvious but it is by no means certain it will even work. This is because VM's may rely on virtualization features of your hardware which are not exposed inside the VM itself.

Secondly, why two, why not three, four, five, etc... There is such a thing as overkill security. If the virus can "escape" the inner VM, then it can just as easily escape the outer VM, and reach the host. Besides, most viruses transmit themselves via the network and not through some hole in the VM, and in that case just nesting VM's changes nothing since the host network will be equally visible on every level.

If your virus is dangerous enough for you to even consider nesting multiple virtual machines, it must be one hell of a virus, and consequently you should just grab a cheap netbook with no network/bluetooth capability and roll with that. Otherwise, a single VM ought to be enough.


Is it possible data which was generated with JavaScript in Google Chrome could exist in my Mac'sRAM?

Very unlikely. The memory used by that page will have been freed and will almost certainly have been decommitted from the process, which means the OS will have scrubbed it by now.

At best you could try taking a memory dump of the process using Volatility, which can also carve out useful structures and look for sensitive information (probably including certificates and RSA private keys, although I haven't looked into that) but I'd imagine that the data is completely gone by now.


I see absolutely no issue in allowing people from one CTF session to meddle into the CTF of another.  Since it is, in principle, a competition and that would be fair game.

Yet, if, for example, you want to make the CTF open to anyone and everyone (as in, to anyone on the internet) then maybe making sandboxes is actually a good idea.  Someone may use your system as a phishing ground (by, e.g. scripting an invasion into other user's session and presenting links), shich would not be nice.

Fortunately Linux has an built-in sandbox system.  You can simply use KVM and libvirt to give each session their own sandbox.  There is even a virt-sandbox, which is an effort to make the use of KVM/QEMU easy to use.

Of course, sandboxes/VMs have bugs.  And sometimes it is possible to cross over form a VM.  As with everything else, there is no guarantee of security (e.g. there may be zero day attacks on KVM out there, but so may be with all other virtualisation software).


How to know when to install a certificate?

Cert is fine.
Cert is fine. (It chains up to good root CA. I checked manually on Win10.)
This certificate is valid ONLY for smtp.gmail.com. (See below.) So if you access by ANY other DNS-Name or IP, then this is going to fail.
What name do you use? How is the proxy involved?
$ openssl x509 -in smtp.gmail.com.cer -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5464163569050496664 (0x4bd49bd0cfe2ae98)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
        Validity
            Not Before: Nov 12 19:03:23 2015 GMT
            Not After : Feb 10 00:00:00 2016 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=smtp.gmail.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:a6:96:46:f6:3c:58:75:f3:79:d4:e0:83:6d:
                    16:d8:e6:ae:30:e6:2f:22:40:b5:ab:6c:a3:8d:48:
                    4d:62:3e:22:b5:44:1d:83:aa:0d:35:23:59:1a:b7:
                    d3:09:c9:0e:3a:f2:2b:8d:b7:79:89:4a:b1:b8:3b:
                    e8:02:54:09:e4:84:80:f7:26:7c:d0:a9:b4:65:c2:
                    e0:49:ab:c7:2b:bf:b9:d7:0d:f8:56:cb:e9:bf:57:
                    d5:89:76:00:26:5f:41:32:06:98:b9:e7:3f:8c:56:
                    35:16:13:2a:aa:3d:c1:2a:27:2f:44:4e:bf:5f:94:
                    f4:a2:0e:40:84:61:1c:65:fb:e5:1a:21:19:bf:26:
                    16:5a:46:39:9b:9f:ab:16:2b:87:2c:d6:a9:27:6c:
                    5c:d0:7d:f3:28:6a:53:0e:9d:f9:8a:0c:61:f1:cd:
                    d8:33:0f:c3:83:76:45:77:43:15:6d:88:b1:b5:8e:
                    83:a9:c3:6c:f3:4d:59:cf:ca:ef:70:76:44:5a:cc:
                    2a:81:7b:f0:75:51:80:19:63:12:26:6f:a3:b4:17:
                    bc:0e:2c:d0:87:e0:8d:05:55:0f:b3:fb:98:02:2a:
                    82:36:12:c2:b8:bf:1c:1e:80:4d:c1:16:61:ea:e4:
                    1f:01:ea:1d:e6:43:ee:b4:3d:85:76:d6:49:37:69:
                    4b:dd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                DNS:smtp.gmail.com
            Authority Information Access:
                CA Issuers - URI:http://pki.google.com/GIAG2.crt
                OCSP - URI:http://clients1.google.com/ocsp

            X509v3 Subject Key Identifier:
                9F:78:EC:82:3D:C9:AA:A6:B9:92:F9:82:EB:7A:13:3C:2B:65:56:8D
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F

            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.11129.2.5.1
                Policy: 2.23.140.1.2.2

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://pki.google.com/GIAG2.crl

    Signature Algorithm: sha256WithRSAEncryption
         31:73:17:3a:b1:0f:42:73:5d:69:50:86:33:b0:0b:e9:59:fd:
         f3:c0:c3:26:4a:dc:9c:ab:6b:12:51:64:21:33:5e:41:6c:cc:
         75:e3:47:e0:04:2c:f6:be:f3:d0:a0:ef:8d:92:84:b3:c7:5b:
         3d:96:a6:d6:9b:8d:a1:6e:05:be:49:54:01:af:23:63:c2:a1:
         c6:61:68:93:48:c9:9c:b8:65:b0:01:b8:1d:75:9a:9e:83:73:
         f6:7d:7c:b5:17:2f:b6:35:22:7e:7a:93:c8:88:cf:33:62:2e:
         e5:9b:a5:36:f3:ff:13:81:ae:f8:6d:2b:01:e9:3b:f0:2a:b3:
         15:27:0e:b3:4f:cc:92:4e:0b:f1:d1:69:59:e0:26:51:51:66:
         0b:e1:c6:d8:67:a4:d0:f8:e5:e9:90:0e:3b:89:7b:bb:8f:f6:
         b0:d4:07:6e:cb:44:c6:76:c2:0e:73:01:13:f1:dd:19:c4:e5:
         c4:9b:cb:30:29:65:d8:c0:2b:48:e5:d6:6a:ae:54:c2:d6:a1:
         c6:df:82:b9:5d:91:8c:a5:82:85:e7:df:b7:f5:4e:75:e9:39:
         d4:c9:97:ac:91:f7:1f:c1:63:26:40:dc:9e:73:ec:cb:a7:1f:
         b7:fc:36:98:ad:b8:b5:70:03:3e:a9:98:a5:c1:78:b5:4e:2a:
         3e:7a:31:f8

(Side note: I didn't this certificate in the two useful certificate repositories that I like to use. Neither at ssl-tools.net. Nor at Crt.sh. But maybe it'll eventually find its way into those two useful repositories.)
No need to install it though.
You should not really have to install this manually. Otherwise something is wrong. It's correctly signed by a well known CA and should work out of the box on all modern operating systems.


How will we stop BlueBorne on older devices?

It really depends on your use case, but generally if you're wanting to defend your company:

If you are worried about employees or visitors bringing in older, unpatched devices onto your network, segment those devices to a completely separate WiFi network that doesn't in any way touch your main network.
Similarly, if your organization uses IoT devices, create a special segmented network that only those devices are given the password to. Don't let this network touch either your public WiFi network or your main network.
For monitoring these networks, there are products that specifically monitor networks for unusual IoT and BYOD activity (Senr.io is one example). These products can monitor these vulnerable networks and alert you when unusual or malicious traffic occurs.

Beyond that, there is not much you can do. Turn off Bluetooth on any vulnerable device you have control over and educate your employees on this danger.


Cisco ASA Security Contexts: Any Real World Installs?

Context works great, what you want to know before deploying it is the unsupported feature in context mode: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/contexts.html#wp1146747

I never see any performance drop when enabling context mode


Which of these DBMS offers the lowest security for SQLI?

All of these database platforms give developers the ability to execute parameterized queries, which is the industry standard for preventing SQL Injection.

Based on this - I would say none are more vulnerable than the others.


Modern GPU drivers (not just limited to Linux) are really, really insecure. The way an application communicates with a GPU is through the Direct Rendering Manager, or DRM interface, using ioctl(2). These syscalls are used to pass references to complex data structures between the userland and kernel. The DRM interface is available in the form of two character devices:

The master node, which handles privileged operations (e.g. display control). It is exposed as the character device /dev/dri/cardX. It is often only writable by users in the video group. This device is traditionally kept open by the X server, which makes itself DRM master. The DRM master node has a considerable attack surface area and uses a complex API.

The render node, which handles generally unprivileged operations (e.g. GPGPU computing and rendering). It is exposed as the character device /dev/dri/renderDX. This device has a considerable attack surface area, despite only handling unprivileged operations.

Permissions checks for the DRM nodes are done when the device file is being opened, with a few exceptions. Once the file descriptor is present, any application with that descriptor in its set will be able to send arbitrary privileged commands to the graphics subsystem. This means that your isolation ends as soon as your untrusted process has a valid file descriptor to a DRM node. The security of the graphics subsystem depends on both the security of the DRM layer (which has a very complex interface), as well as the hardware-specific interfaces defined by the graphics driver itself. Different drivers define different interfaces, with some being more complex than others.
You said you were using seccomp-bpf. This is good! You will be able to vastly reduce the security issues intrinsic in a complex graphics subsystem. Make sure you are filtering any IOCTL which is called against a DRM node. Whitelist the commands which the IOCTL is permitted to send. Although you cannot whitelist the data structures being passed to the kernel, whitelisting the overall command is often sufficient and will vastly reduce the surface area available for an attacker.

A far from exhaustive list of severe graphics driver bugs:
Radeon

CVE-2005-0767
CVE-2011-1016

Nvidia (proprietary)

CVE-2013-5987
CVE-2016-7382
CVE-2016-7389

Intel (i915, etc)

CVE-2012-2383
CVE-2012-2384
CVE-2013-0913
CVE-2017-5727

Any driver (bug in the underlying DRM subsystem)

CVE-2011-1013
CVE-2012-0044

Modern x86 hardware is a scary beast. It is complex and not designed with security in mind. Even if absent of driver software vulnerabilities, GPUs can still pose a threat simply due to their complex nature and interaction with a complicated computer architecture over arcane protocols governed by membership-only thousand-page long specifications. Security is Hard™.


Is HSTS Header Helpful For Mobile Applications?

You are correct. There would really be no point here. It would only be useful if somebody chooses to directly hit the api from a browser, but if there is no use case for that, then its not necessary.


Multiple encrypted messages known to have matching (unknown) content

If the encryption system is any good, even noticing that two messages encrypted with distinct keys are, in fact, identical, would be considered a "break". An encryption algorithm has a "security level" expressed in bits; when the security level is k, then this means that the computational effort to enact a "break" should be on the amount of 2k-1 invocation of the underlying encryption function (to be precise, the success probability should be e*2-k where e is the effort, so e = 2k-1 implies a 50% success probability for the attacker).

For instance, if using AES with a 128-bit key, then you are supposed to achieve a "128-bit" security level. This means that if the attacker is ready to invest enough CPU power to compute, say, 270 invocations of AES, then he has probability about 2-58, aka "1 in 288230376151711744", to succeed. 270 AES invocations is a substantial effort; a good multi-core CPU can produce about 230 AES invocations per second, so we are talking about ten thousand big PC running for... three years. And this achieves a success rate considerably lower than winning millions of dollars at the lottery.

What counts as a break is anything which makes the system depart from its theoretical model, i.e. a pseudorandom permutation: using the encryption with a given key is akin to selecting a permutation on the space of messages, and a new key should mean a new random selection, independently of the previous. Noticing that two encrypted messages, with two distinct keys, proceed from the same plaintext message, would be a break, and the best attack method ought to be the generic one, i.e. trying all possible keys until a match is found. This method yields the probabilities explained above, i.e. "does not realistically work".

Right now, no such breaking method is known for AES.

Beware of outdated thinking. You appear to use notions of "correlation" and "unknown method" which were adequate about fifty years ago, but cryptographic research has gone a bit forward since that time. In particular:

We are now very strict about acceptable information leaks (your "correlations"), namely we accept none. And yet we have candidate algorithms (e.g. AES) which seem to achieve this high level of quality.
Encryption methods have been split into an algorithm and a key. The "algorithm" is what becomes code. The algorithm is supposed to be public, because all the secrecy is concentrated in the key; at least, there should be no harm into publishing the algorithm, if it is any good, and it would be very hard to prevent such publication anyway. See this answer for details.

Of course, if the algorithm was used sloppily, then anything goes. A core algorithm like AES is only an elementary brick; it processes 16-byte blocks. To encrypt a message (a possibly long sequence of bytes), you have to use the block cipher with a mode of operation, which is a matter of subtlety and can be done poorly -- sufficiently poorly to imply a total security loss.

There can also be side-channel attacks exploiting the information leaks through the behaviour of the encryption implementation, e.g. through timing. For instance, many AES implementations use in-memory tables, which implies data-dependent and key-dependent memory accesses, thus cache behaviour; in lab conditions, this has sometimes been exploited to extract the key. This is not an attack against the algorithm but against its implementation. Bottom-line is that implementation of cryptographic algorithms is a tricky task.

All of the above is about symmetric encryption, but the same kind of reasoning can be applied to asymmetric encryption, e.g. with RSA. A 2048-bit RSA key, properly generated and used, ought to offer a security level of about 112 bits, which is more than enough.


No, that is not possible. In case the user types 'https://', the secure tunnel is generated, and SSLStrip cannot interfere anymore.

SSLStrip works by intercepting HTTPS redirects sent from the server. SSLstrip then sets up a HTTPS connection with the server (the server thus thinks everything is ok), but keeps an HTTP connection with the victim. SSLStrip can only capture these HTTPS redirects if they are sent to the browser using plain HTTP. Otherwise, SSLStrip would be able to 'break into' the SSL tunnel, which it doesn't.

HSTS is an implementation that could be used to tell the browser to always connect via HTTPS (and thus to not rely on https redirects from the server anymore).


Should remote access (RDP/SSH) only be allowed for VPN clients? Or should RDP and SSH be opened the public?

There are two risks that immediately occur to me that would be reduced by using a VPN

You're avoiding the risk that a single vulnerability provides access to your systems.  With straight SSH/RDP a remote code execution vulnerability in the service could allow complete compromise of your environment. With a VPN which then allows access to the service, the attacker would need to compromise the VPN service and the remote access service.
Username/password guessing.  Most base RDP access (and SSH unless you're using key based authentication) is done using username/password combinations.  If you expose this directly on the Internet you run the risk of someone either getting access to the system directly by guessing the creds (and there are lots of bots out their doing password guessing attacks these days) or locking out your users (assuming you have account lockout in place).  VPNs tend to have better support for 2FA, so it's likely to be easier to implement that control with a VPN in use.  Also if you de-couple the logins, at least if they attack the VPN accounts it may not affect the underlying OS logins.


Is it possible to log all file reads performed by an application in Windows 7?

Process monitor can do that for you:

https://technet.microsoft.com/en-us/library/bb896645.aspx


Why does the first call to DecryptUpdate in AES-CBC return 16 fewer bytes?

AES operates over blocks of 16 bytes.  The EVP_DecryptUpdate() will operate on blocks of 16.  As long as you are using EVP_DecryptUpdate() it assumes that you will give it more data to decrypt, and retains the last block of data within the crypt context.  This is because in CBC mode it needs the next cipher block to be the IV for the next block of decryption because it can't predict when it will need it to calculate  the padding.

Wiki Image

The "decrypted length" will be exactly one block (16 bytes) less than what you give it for the first iteration because it retains the 2nd block of data.  Once you decrypt the 2nd iteration it outputs block 2 and block 3 (32 bytes), and retains block 4.  Extrapolating this out to the end of your encrypted file you'll realize that you would be 1 block short.  Once you call EVP_DecryptFinal the final block is decrypted (padding taken care of if necessary), and output to the buffer given for the full 32 blocks (512 bytes in your example).

Example Code

char *decrypt (char *key,
               char *iv,
               char *encryptedData,
               int encryptedLength)
{
    // Initialisation
    EVP_CIPHER_CTX *cryptCtx = EVP_CIPHER_CTX_new();
    EVP_CIPHER_CTX_init(cryptCtx);
    int decryptedLength = 0;
    int allocateSize = encryptedLength * sizeof(char);
    int lastDecryptLength = 0;
    char *decryptedData = (char *) malloc (allocateSize);
    memset(decryptedData, 0x00, allocateSize);
    int decryptResult = EVP_DecryptInit_ex(cryptCtx,
        EVP_bf_cbc(), NULL, key, iv);

    // EVP_DecryptInit_ex returns 1 if it succeeded.
    if (decryptResult == 1)
    {
        decryptResult = EVP_DecryptUpdate(cryptCtx, decryptedData,
            &decryptedLength, encryptedData, encryptedLength);

        // Note that EVP_DecryptUpdate will alter the value of the third parameter
        // to be equal to the amount of data that was written. This is not always the
        // entire length of the decrypted data! To finish the decryption process, use
        // EVP_DecryptFinal_ex. This will decrypt any remaining data.

        // Cleanup
        if (decryptResult == 1)
        {
            // Stick the final data at the end of the last
            // decrypted data.
            EVP_DecryptFinal_ex(cryptCtx,
                decryptedData + decryptedLength,
                &lastDecryptLength);
            decryptedLength = decryptedLength + lastDecryptLength;
            decryptedData[decryptedLength – 1] = ”;
            printf ("Decrypted size: %d\n", decryptedLength);
            printf ("Decrypted data: \n%s\n\n", decryptedData);
        }
        else
        {
            printf ("EVP_DeccryptUpdate failure.\n");
        }
    }
    else
    {
        printf ("EVP_DecryptInit_ex failure.\n");
    }
    EVP_CIPHER_CTX_free(cryptCtx);
    EVP_cleanup();
    return decryptedData;
}