Is sharing a Speccy report with others safe?

In your scenario, there are (at least) 3 things to be mindful of or possibly concerned with:

Are you sharing any PII or other personally sensitive information? This could include unique technical identifiers such as MAC addresses and public IP addresses, or more personal information. Just glancing at the report, I'd say probably not, but that may differ by individual opinion. One thing to note is that the report contains a list of IP addresses you were connected to; this could reveal what sites and services you were using at the time.
Are you sharing any sensitive technical information? The data contains what applications are running, what patches you have, and what network services are listening. If you were running anything vulnerable or unpatched, this could be an issue.
Is the person friend or foe? Obtaining basic system information could be a legitimate request, but it could also be used maliciously by a social engineer to demonstrate their credibility and/or learn more about your machine. It gives them the ability to say, "oh no, your report says you have explorer.exe running; that's a virus! I better remote in right away to fix it!" or "looks like you have Microsoft Word installed; lucky you, just download this document and it has all the steps to fix your computer! Just make sure you enable macros first."

I don't think you need to worry too much about the information you already shared, but proceed with caution and don't let them connect in or run any software that you don't understand.


How might this Amazon account hack occur?

What can we do to stop the attack?

The damage and the extent of the breach might be more than you think of.
The email account that is tied to the Amazon account needs the same security steps implemented or re-implemented, like changing your passwords to one with a completely different set of characters & theme/nature and the setting up of 2FA.
It is possible for the breached access to have gotten past the need to enter 2FA. Under 'Two-Step Verification (2SV) Settings' > 'Require OTP on all devices'

Do check on the number of 2FA apps enrolled as well.

You can also rule out the possibilities of her cellphone being breached by using your phone's authenticator app as hers. Find the breach, plug it!


Has this method ever been used by viruses to check if system has already been infected?

So I have "Practical Malware Analysis" by Sikorski and Honig in front of me. They describe the use of threading, but I think the more popular form of what you're describing is a mutex. Malware can create mutexes at the kernel level with specific names using the KeInitializeMutex system call, and use that mutex to mark that system. If another piece of the same malware drops on the system it can then look to see if that named mutex is a) present, or b) owned by another process. If it is, then it is reasonable to assume that you've already infected the computer. Of course, it becomes a great signature for anti-virus and other pieces of competing malware.

They also describe the use of the registry. Malware can look for specific values in the registry, and achieve persistence by embedding itself as a service.

So yes, this technique is used. I believe some of the sample "malware" they ship with the book uses these techniques.


Is it bad that my ed25519 key is so short compared to a RSA key?

No, longer is not better.

Let me explain. In symmetric cryptography, keys are just bunches of bits, and all sequences of bits are valid keys. They have no internal structure. Provided that you use decent algorithms, the best possible attack on a key for symmetric encryption is brute force: the attacker tries all possible keys until he finds the right one. If the key has n bits, then there are 2n possible keys, and the attacker, on average, will find the right one after trying half of them, i.e. 2n-1. Longer keys thus make brute force harder; in that case, longer is better.

(Note that there is a limit to that; when keys are sufficiently long that brute force is no longer feasible, increasing the key length does not make things "more secure" in any meaningful way. So, for symmetric keys, longer is better until they are long enough, at which point longer is just longer.)

RSA and EdDSA relate to asymmetric cryptography where things are completely different. A key for asymmetric cryptography is a mathematical object that has a specific internal structure; breaking the key consists in unravelling that structure, and can be done a lot more efficiently than trying out all possible private keys. Note the two points:

Against brute force, what matters is not the length of the public key, but that of the private key, since what the attacker wants is the private key, not the public key.
Brute force is not the most efficient attack against keys used in asymmetric cryptography.

For RSA keys, attack succeeds by factoring the modulus. Integer factorization is a long-studied problem; with the best known algorithm, breaking a 2048-bit RSA key (i.e., a RSA public key whose modulus is a 2048-bit integer) requires about 2110 or so elementary operations.

For EdDSA keys, the public key is a point P on an elliptic curve, such that P = xG where x is the private key (a 256-bit integer) and G is a conventional curve point. The best known algorithm for recovering x from P and G requires about 2128 elementary operations, i.e. more than for a 2048-bit RSA key. In general, to break a n-bit elliptic curve public key, the effort is 2n/2.

Breaking either key is way beyond that which is feasible with existing or foreseeable technology. But in an "academic" viewpoint, the EdDSA key is somewhat stronger than the RSA key; also, elliptic curves give you more security per bit (technically, we say that integer factorization is a sub-exponential problem).

See this site for more information on that subject.


Is it common to allow local desktop and/or active directory admin access and rights for developers in organizations?

Here's one data point from a software company that has an interest in security. I know this is common in similar organisations.

There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables.

Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email etc. All users are strictly locked down, and there's strict device and access control.

In addition to this, each developer has an 'engineering' machine. This has full admin access, and the user can do whatever they like. However it is connected only to the engineering network (no route to the Internet).

In most software development contexts this could be seen as extreme, but in orgs that have conflicting requirements of high security and developer freedom, this is a common solution.

To answer your question, yes it is common to allow developers admin access, but this doesn't always mean admin access to a machine that could cause information security issues.


How to forward an specific FTP User to a Honeypot?

To do this, you would need an FTP proxy which was capable of proxying to different actual FTP servers based on the username that was supplied.

Frox has this essential functionality; it can route users when they use user@actual.ftp.host syntax for their username.  So clearly it is possible to implement a proxy that does what you want.  However, I don't think Frox does exactly what you want, because you want one subset of users with normal names to be sent to one server, and all users not in that subset to default to a honeypot instead.

It might be possible to do what you want using the Connection Translation feature of ftp.proxy, but I've no experience with which to say.


The language a malware is written with is irrelevant. First, because at the end, it is all compiled into machine code and second because there is no language dedicated to write malware.

What makes a malware what it is, is its behaviour. Algorithms can be implemented in every language you are interested in.

Obviously, the malware has to be able to trigger the right functions where it is executed, so this might bias the choice of language a bit. You won't write with javascript if you need to get an executable file, but you can use it if your malware is web-based.

So the simplest answer to this would be "whatever floats your boat".


How does Intel SGX protect itself from being simulated?

The SGX enclave uses a built-in secret key for transmission of information to and from the enclave. Even if you wrap SGX in rogue software, you still cannot decrypt information sent to it. The best you can do with rogue software is trick a client in sending you encrypted data.

The vulnerability lies with a rogue SGX manufacturer who could save the built-in secret key when the SGX hardware is produced.


How can a SYN flood affect a router in this scenario?

If you connect from a decive in the LAN of router B to an external service, router B and A each do network address translation (NAT) so your device can receive an answer.
So basically there is a temporary port open to receive the answers and send them back to your device.
The impact should be very limited, since normally the router accept only incoming traffic, if a device started the communication from the inside and the packages belong to that communication.
But in RFC 5382 is a possibility for port reuse: https://tools.ietf.org/html/rfc5382#section-4.3
If such a feature is enabled, an outside service could try to establish a connection through SYN packages. Does your routers support that feature?


What is the safest way to store passwords in a company for the case when the CISO leaves?

What's the best way to store passwords?

This is a very broad subject that encompasses many different areas of IT. It also has the tendency to be opinion-based. However, there are some very important things we can know, and then use to make an informed decision.

Also, there are many different ways to handle passwords. What size company? Small? Medium? Large? Colossal? In my opinion, you can't just ask for the best way to store passwords, nor store them all in the same place in all cases. You have to know why people need passwords, and when they need them.

You also need to know what will happen if you have to change the passwords (due to a breach, etc). And after that, you have to know the impact of changing the passwords. Will it break your applications? If so, how quickly can the developers update their code? Does it violate the CIA triad? CIA Triad = Confidentiality, Integrity, Availability.

Your passwords should be hashed with a proper algorithm, and not stored in plain-text, but at the same time, many different roles require a lot of plain-text passwords. There's a difference between a plain-text print-out, and storing unhashed passwords in the database. Do not mix these concepts up.

Information Security is all about risk management. You cannot 100% account for every scenario, but you can do your due diligence to dramatically minimize risk.

  The scenario is: The person responsible for IT has to manage a lot of passwords for servers and third-party services. It would be bad if these passwords are only known to the person in charge. The person can get sick, let go, etc. pp. So there needs to be a way for management to retrieve said passwords and make them accessible for other people - if needed. But they also need to be secure and only accessible in this case.

What kind of polices should be in place?

Upper Management should be able to request password changes for all accounts, even if they don't know the passwords, so that password changes aren't a problem. There should also be an audit trail for this to help avoid framing someone. For Windows, Active Directory can do this, and is very powerful.
All important usernames and passwords should be split up and only given to those with the correct role(s).

Development teams frequently need important passwords

If you have a development team, chances are you'll have lots of different passwords. Not just passwords, but usernames as well. For example, you may have broken up your your development, testing, and production environments. If you haven't done that, you have terrible IT practices.

No one except trusted DBAs should have root access to the production database. And only the trusted System Administrators should have access to the production servers.

Storing passwords in plain text can be a bad idea. In the case of customer data, it's definitely a terrible idea. A good use-case example would be for development teams. How is the development team going to upgrade the database? How are they going to test their changes?

The developers can't if they don't have access. If they have to keep requesting passwords to test their changes, productivity falls, ideas are lost, and your company can't remain competitive.

You need separation of concerns. In order to change the production database, you should have the appropriate permissions and instructions. Your run-of-the-mill developer should not have access to either the production database or server.

However, your developer definitely needs access to the development and testing environments. In this case, your developers should be given a print-out of database usernames and passwords that are relevant to them. As a further stop-gap, you should have enterprise profiles that only allow access to those accounts if they have permission, so even if they get the password, they can't connect without appropriate permission.

Within a medium-to-large company, being able to properly develop without too many hindrances is critical. Being held back by red tape is extremely detrimental to the development process.

Get off your soap box and let's get back to password storage!

  My approach would be to use a simple plain text file on an encrypted USB drive + one backup (also USB drive) in a secure (physical) location. Then provide management with the password for the drive. The person in charge can carry the drive around like a key. If stolen, it is useless. If lost, there is a backup. If person isn't available anymore, management can access it.

This is the way many companies do it. However, I would take it a step further due to tinfoil hattery:

Create an application where you are able to change passwords.
Plug 4 USB devices into the computer.
Application writes passwords to multiple flash drives for redundancy. Can update just as easily, and role-appropriate print-outs can be given to the correct users.
Ensure that all passwords can be changed by a master account. Ideally, you'd want more than one.
You'd also need paper documentation in a locked room that few have access to.


What are the implications of adding a self signed certificate to the Windows Trusted Root Certification Authorities store?

When you install a CA certificate as "trusted root" then this means that your applications will trust whatever certificates are issued by this CA certificate. This is not, by default, restricted to a specific domain. X.509, the standard for certificates, includes a way to specify that a given CA is for issuing certificates only in a specific "area", e.g. for servers in a domain (that's the Name Constraints extension, see section 4.2.1.10), but it is poorly supported, or not supported at all, by existing implementations. So I would recommend against relying on this feature.

So the basic rule is that when you install a new trusted root, you are entrusting the owner of the private key with your browsing security. If you are the owner (that's your self-signed certificate, which you generated yourself), then it is up to you to keep the CA key safe. As long as nobody else gets a copy of the private key, then there is no problem. This leads to the following method:

Create a new key pair and a self-signed certificate.
Use that newly created CA to issue a certificate for your server.
Import the CA certificate as trusted root.
Forget the CA private key (destroy the key; ideally, the key is in a file which you put on a RAM-backed filesystem, making suppression reasonably complete).

and you are done. If the private key is no more, it is, in particular, out of reach of malevolent adversaries.

An alternate method is to use a self-signed certificate for the server itself, and instruct your Web browser to nonetheless trust that certificate for your site only. If your browser can do that, then no need to fiddle with root CA. Firefox can do that; they call it a security exception.


One Time Password via Text Message: Possible exploits?

If your friend is telling the truth then there are a few different ways the attackers could have gotten the code:

If the phone is a GSM it's possible they could have cloned his SIM and received his text messages that way
Text messages are processed by systems called SMS-Cs - servers running software that handles text messages which are located in the cell provider's network. If the phishers managed to hack the SMS-C they could have access to every text message in the system
His phone was hacked - phone malware could have given the phishers access to text messages on his phone
An app on the phone leaked the information using permissions. On Android when you install an application it will pop up a message with all the access the app requires. Apps offering the most minor functionality sometimes request to access email, sms, contacts, photos, location, and browsing history - way more than required to do what they say. If you permit an application access to SMS messages it will be able to legitimately forward every SMS you send or receive to a third party. Most of the time this is done to sell to advertisers, however some of these applications are known to have been developed by criminals expressly for the purpose of identity theft and to assist in wider crime.

So it is entirely possible that your friend did not give the criminals the SMS details directly, instead it's quite likely that he gave them indirectly through the apps he installed.


Social Engineering Attack awareness using .doc and spoofed email

It sounds like what you're attempting to do is a phishing campaign on your company network. While you have a good idea with the .doc file, the implementation would be way too messy. You could do this with Macros, but there will be a ton of pop ups asking the user to enable macros and confirm that its dangerous etc. Ultimately, I think most of the employees would get scared off by it. You could dig a little deeper and use msfvenom to embed malware in a file, but now you're physically exploiting the machine of every user in the company who clicks on it which is also a bad idea. If you have any company resources that require login with company credentials, I would recommend sending out a verbatim copy of an email that would be generated by that service requesting action by the user by clicking on a link (make sure the link is not from the company url otherwise they will trust it and defeats the purpose of making them look before clicking). Have the URL redirect to a web server (could probably do this internally with DNS without buying the domain) displaying a copy of a login page they are familiar with, and then redirect to a "You've been caught" page. Based on the login info, you can determine who was caught.

In the interest of security, I recommend NOT logging any of the passwords on the web server and including a snippet in the "You've been caught" page instructing them to change their password immediately. Best practice would be to ensure the web form doesn't even send the password or replaces it with random text before sending over the network.

To address your firewall question, I would advise not doing any part of this outside the company network if at all possible. That would increase the chances of information being intercepted by malicious actors. In the event any of this traffic does go out network, that will depend on the ACLs but most HTTP traffic is not very restricted.

Most importantly, make sure to hold a meeting after the fishing campaign so that you can explain to the employees what happened, how to look out for it, and what to do if it happens again.

Edit 1:

If you are concerned about deceiving users that are using their machine out of network, I would recommend using a registered domain name with TLS directed to a webserver owned by your company and hosted on the company domain. By default, the ACLs will probably not allow for HTTP traffic to just any machine from the internet. If the webserver is in a datacenter, it could be more likely. You will have to work with the NetOps, team or whoever is in charge of the network ACLs to confirm this.


Why/how does Firefox bypass my employer's SSL decryption?

It's quite simple really, it's your employer that hasn't secured their network properly. I guess that they add a system proxy settings or they configured the other browsers to use their interception proxy, and interception only happens when you are using their proxy, but they didn't put a network firewall to block traffic that doesn't go via the proxy.


List of web session attacks and counter measures

You asked: "does anyone know of a better way to prevent xss?"

The best way to prevent XSS is to educate yourself about XSS, and avoid introducing XSS vulnerabilities into your code.  Start by reading the following document:

OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

(See also PHP functions for preventing XSS.)

Next, I recommend that you read about web security.  Start by reading the following introductions to web security for developers:

An excellent overview for developers -- this should be a must-read for every programmer doing web development.
Web security tutorials at Google Code University

That will help you avoid XSS.  There are many more resources on the web and on this site; take a look.

Note: The HTTPonly flag does not prevent XSS.  Also, contrary to popular belief, it provides little additional security: if your web site contains a XSS vulnerability, then it will often still be possible for an attacker to do bad things to the user.  The HTTPonly flag makes the attacker work harder, but in the end, you should assume that a sophisticated attacker will probably still get just as far.  Now I'm not arguing against HTTPonly.  The HTTPonly flag is a fine idea, if it doesn't break site functionality. But you should not rely upon it as a defense against XSS.  It is a particular porous defense.


How to protect against clickjacking attack but allow legit iframes?

Share buttons will often use an iframe to protect them selves from CSRF.  In this context CSRF and ClickJacking have an identical impact which is sometimes called "LikeJacking".   You have to choose to be vulnerable to CSRF OR you can use an iframe prevent CSRF but then you expose your self to ClickJacking. It so happens that ClickJacking is the lesser of two evils.  FaceBook solves this logic problem with Legal Action.   You can make "LikeJacking" and ClickJacking against your against your Terms of Service and sue them like FaceBook.

There maybe a technical solution to this problem. I emailed Google Security on this topic and they said that they where using "Signal Analysis" to determine if behavior was taking place.  Which is a pretty gaseous answer to say the least.  Being Google they do spider all of the pages that are liked,  and they could determine if a clickjacking method,  such as an SVG mask was applied to their iframe by the parent page.  But this is just speculation.


Strictly speaking, any software that is added to your computer potentially increases its attack surface.  So, it is best practice to only install (or leave installed) software that you actually need.

Additionally, if software is installed without your knowledge or consent, this can be an indicator of an underlying security problem.  Either:

Somebody else has Administrator-level access (legitimately or not) to your computer, who does not respect your rights to manage your own computer's software and configuration.
You, or someone else allowed on your computer, may have downloaded (intentionally or not) some malware which has installed the toolbar.

A quick perusal of Google seems to generally indicate that BuzzDock is really nothing more than an annoyance to those who don't want to use it.  However, as @schroeder outlines in his answer, it does exhibit some behavior generally associated with spyware.  If you no longer want it on your computer, I'd suggest trying to uninstall it via appwiz.cpl, also known as "Add/Remove Programs" or "Programs and Features".

Additionally, you should ask yourself and other users of the computer the following questions:

Are you the only person with Administrator-level rights on your computer?
If the answer to #1 is no, do the others really need Administrator-level rights?

2a.  If not, down-grade their accounts to "Limited User".

2b.  If they do, make clear your expectations of what they may and may not use their Administrator-level privileges for on your computer.
Have you or anyone else installed anything on your computer recently?
If the answer to #3 is yes, is the software known to include BuzzDock?

4a. If yes, un-install BuzzDock and move on.  Ensure that all users who have permission to install software are aware of how to prevent installation of crapware in the future.

4b. If no, or if the answer to #3 is no, run a full scan of your system with your antivirus and antimalware programs of choice.

If any viruses or malware are detected which give you any trouble in removal, or if the software itself is hard to remove, a full system re-build may be your best resolution option.

In any case, there's rarely a time when an antivirus/antimalware scan is a bad idea - just so long as it's not during a period where it will impede the performance of the system under active use.


You might need to re-read the advisory, the important part is this:

  A text containing carefully mixed square and angle brackets confuses
  the splitting process and results in HTML code getting partially
  texturized.

  An attacker can exploit the bug to supply any attributes in the
  allowed HTML tags. A style attribute can be used to create a
  transparent tag covering the whole window, forcing the execution of
  its onmouseover handler.

The exploit is injecting a onmouseover attribute by mixing the square and angle brackets. It is likely that you cannot inject a scipt tag at all. And since the injected text requires partial texturisaiton you will not see the actual output with your regex url. It will only let you determine which chunks are sent to be texturized. In order to see the rendered output you would need a vulnerable version of wordpress to inject into,


How to secure upload from desktop client to web application?

HTTPS should be the default for everything.   You can use a self-signed certificate for FREE,  and hard-code the certificate with your desktop client.   Anything else would be a serious mistake.

But let me be clear,  this doesn't prevent a hacker from gaining access to this interface.  Nothing will ever be able do this because the attacker is running your client on his machine and there for has complete control.   SSL only protects the data in transit,  and makes sure your delivering it to the right person.


Yes.  In your case, since the VPN connects to your company, it is possible that they may have visibility into your outgoing web traffic.  They will see anything over plain HTTP, but many companies nowadays are breaking SSL/TLS at their boundaries in order to inspect it.  A good indicator to check if they are doing this is to go to a site that uses HTTPS (like Google) and then click the lock icon in your browser to view the certificate.  If the certificate doesn't have Google's information in all of the fields, it means that they are decrypting HTTPS and can see your traffic.


Know of any HTTP tarpits/blackholes to use for redirecting malicious traffic?

I'm afraid all those IPs are nothing but victims clicking on phished/malicious links.

Your client was hacked and malicious scripts were hosted on their server in order to infect inconspicuous victims. Whether you like it or not, your client contributed to spread malware.

The next step for you is to just serve a 404 Not Found on those requests and make sure your customer doesn't help spreading malware again. If you like you could just setup a 301 or a 302 pointing to a law enforcement site or serve a static page telling your visitors that they probably just clicked on a phishing/malicious email link.

As per your initial question, any tarpit (e.g. keeping TCP sessions open) you setup on a webserver will only slow your server down more than those guys. Seriously, there's no point on doing that.


How useful is the default configuration of ModSecurity for a generic web application?

TL;DR: Not really useful for security, and will probably break the app somehow.

A lot of ModSecurity's default rules are the textbook example of how not to protect from attacks. XSS is the best example: they block requests that look like they contain certain HTML tags, thus breaking any site where people try to post innocuous code samples. (The correct way to defend against XSS is to escape user-provided data that ends up in HTML, without having to block any data outright.) The rest of its rules follow similar patterns, blocking things that "look" dangerous but aren't actually dangerous if the app is written correctly, and are highly prone to false positives. As such, all ModSecurity is really good for is security theater, or checking a box that you have a WAF to satisfy some regulation. There's no real harm in turning it off, and it doesn't reflect badly on the software at all that it tells you to. (Even MediaWiki, which powers Wikipedia, tells you to turn it off.)


Can malware change the website visited by browser?

There are several ways to achieve this:

Malware working as a proxy or directly hooked into the browser (like with browser extensions) can change the content of the site itself, that is one will still visit the original site but the  content will be changed in transit or gets changed inside the browser with script injection or similar. This kind of malware is often used to inject advertisements.
By changing the DNS settings it will return attacker-controlled IP addresses for a host name instead of the real IP addresses. This way all traffic to these hosts goes to the attacker which then can provide different content. DNS settings can be changed on the computer itself or even on the router. In the later case all systems in the local network are effected. See https://nakedsecurity.sophos.com/2012/10/01/hacked-routers-brazil-vb2012/ for a detailed example.
Otherwise compromised middleboxes (routers, firewalls, proxies) can also be used to change or redirect traffic.


We were discussing a technique in another thread that would likely accomplish this.  NSTX and ICMPTX both take advantage of common protocol holes that organizations have.  NSTX is the most likely candidate since it's not likely the organization with the captive portal prevents access to the DNS proxy/server you're using to resolve the captive portal name.

If you can issue a DNS query to resolve your nameserver then you're pretty much set.  This requires you manage your own DNS machine externally, but with EC2 costing what it does figure you're out 20 bucks a month to accomplish this task.

NSTX essentially uses the DNS query mechanism as a data channel.  Pentesters have been using this technique for a while, and the idea is not new (botnets have even used DYNDNS C-Name resolution to create passive C&C structures.)    It's a dirty world, but DNS administrators have done a great job of creating a shadow network to pass your traffic around.

A quick reference: http://think-security.com/ip-over-dns/

Good ol' Howto: http://thomer.com/howtos/nstx.html


Possibility Of Cracking WPA Password with Additional Information

It's a great advantage, It's no longer a full brute-force (all charsets and and lengths), but rather a specific brute-force (16 long and two basic charsets)

Your best shot would be to do a space-time-tradeoff pre-computing all the possible keys with tools like pyrit, then use OCLHashcat to use GPU to compare the keys with the MIC.

If you don't own a powerful GPU or don't want to skyrocket your electrical bill, you can also leverage the cloud to crack it yourself, renting some EC2 instances on Amazon, Azure, Bluemix, etc. for few bucks, or online cracking services like the long-time-dead Cloudcraker or OnlinceHashCrack, GPUHash.me etc.

I've already answered this: aircrack-ng fed with crunch taking ages


"SSL: CERTIFICATE_VERIFY_FAILED" with my own certificates

I have no problems accessing www.hybridml.com with python and requests library. Tested with 2.7.6., 2.7.12 and 3.5.2. Also the SSLLabs report looks fine, i.e. no missing chain certificates and the subject matches. And the browsers work fine.

This together suggests that you have something that is intercepting the SSL connection. Such SSL man in the middle results in a new certificate for the target site signed by the CA of the interception software. Since the browser throws no warnings this is probably legal interception, typically done by a corporate firewall but also by various antivirus solutions for desktop. It might also be that the browser and the proxy is connecting differently to the target, i.e. one through a proxy and the other not. Such differences can happen because python and ruby neither share the list of trusted CA nor the proxy settings with the browser.

I suggest that you check the certificate chain inside the browser and see if it actually results to the expected Comodo CA as a root or something else, i.e. the CA from the man in the middle.


On most Unix systems the command line is visible to all users, via the ps command. This may not matter greatly if you're on a single-user system, but this is the reason that this approach is generally labelled as insecure. For example: MySQL manual.

A better alternative is to store the password in a file, which avoids this leak. You need to make sure the permissions on the file are appropriate. The link I provided explains how to do this for MySQL. A lot of other software support this in some way.


It seems your exploit does not succeed. You may try different payload or change LPORT. Sometimes ports may be blocked by firewall and you won't get reverse shell. And once your exploit is successful, you will get reverse shell immediately, no need to type "sessions -l" command.


Is it safe to log into crypto exchange account using coworking space or coffee shop wifi network?

1.a. No. Any shared network that you do not control exposes risks.

1.b. Practically, I doubt any question will solve the reality of 1.a.

2.a. See 1.a.

VPNs are exactly the tool for this problem. They create a secure tunnel out of and through untrusted networks. We cannot speculate on the security of any one product or service, although paid options are more likely (caveat emptor) to provide you with better security.


Setting passwords for domain users, not expiring them, and not allowing them to be changed by users

There are two massive cons: attribution and liability. Although this is currently a reality in your company, this does not mean that it should continue.

All it will take is for someone with access to the password to do something negligent or malicious with someone else's account, and you will need to change this policy instantly. You will have no idea, or even a reasonable understanding, about who did the negligent or malicious thing, and all it will take is a user to say, "it wasn't me - it must have been someone in IT".

So, as you suspect, in your current reality, choosing passwords for your users should actually make your passwords stronger against the outside threats against those accounts. But for the inside threat, you have a gaping maw of risk.


Is there any recommended approach for "upgrading" MD5 hashes to something secure?

Yes, double hashing can be safely done, to give the older MD5 hashes more protection immediately.

Just make sure you can distinguish such double hashes from regular hashes, and update them as soon as possible. The verification process should be done differently for the two kind of hashes, otherwise leaked md5 hashes could be used directly as password, tried to explain it in this answer.


I don't see how this is helpful for home use.   The error "MAC ADDRESS INTRUDER",  is even less useful because that is not a real security measure,  its trivial to spoof your mac address.   WEP cracking is greatly sped up by packet injection which can be detected,  but that isn't as helpful as just using WPA.  The attack against WPA is offline,  so an IDS isn't really going to help.  In these these cases,  the problem is relying upon a broken security system and logging this isn't very helpful.

You could install Linux on an old Desktop and use snort.  Snort can detect some wireless attacks. But more importantly,  snort has general purpose IDS rulesets.


Is TLS flawless enough to prevent eavesdropping carried out by an ISP?

Yes, assuming the following conditions

your web browser/email client is properly checking for valid signed certificates from trusted CAs with a valid chain of trust that have not been compromised and use strong encryption (e.g., 128-bit or greater symmetric key; 1024 or greater asymmetric key),
the CA was not fooled into signing a certificate (intermediate certificate) to the wrong organization,
you aren't fooled to go to a different site with a properly signed certificate but is actually phishing you, (e.g., you want to go to https://www.yourbank.com but instead get a link to go to https://www.yourb.ank.com which has a valid certificate for ank.com),
the servers at the other end do not have compromised private certificates and are not willingly sharing your traffic, and
there's no flaw in TLS that your ISP knows about that the rest of us do not.


How does Certificate Transparance detect fake or forked logs?

First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?

Nothing.

  Can the browser tell if a log is legitimate?

It's left unspecified in the RFC:

  TLS clients [...] should validate the SCT by [...] using the corresponding log's public key.  Note that this document does not describe how clients obtain the logs' public keys.

(Note: This sentence was removed from section 5.3 the new RFC that's currently in development. I don't know if they replaced it with anything more specific)

But Chrome for example will by default only trust a handful of hard-coded logs:

  By default, Chrome will check SCTs coming from a list of predefined CT logs recognized by Chrome.

.

  Does the browser or its Auditor component send the SCT to Monitors?
  [...]
  Specifically, how does the browser (Auditor) know which Monitors to talk to?

It depends. As per the Gossip RFC draft this would be the Trusted Auditor Relationship type of gossiping. (Which is 1 of 3 types of gossiping proposed. And all of these mechanisms may be used in parallel.)

And the RFC draft goes on to say that:

  The Trusted Auditor Relationship is expected to be the rarest gossip mechanism, as an HTTPS Client is providing an unadulterated report of its browsing history to a third party.  While there are valid and common reasons for doing so, there is no appropriate way to enter into this relationship without retrieving informed consent from the user.

So I guess it's gonna be either manually configured or configured to come from some trusted party (browser manufacturer I guess).

Update 2018-01-26Fri.: @__agwa-Blog.

There's a recent blog post on this topic:

Andrew Ayer, 2018-01-10, How will Certificate Transparency Logs be Audited in Practice? (Archived here.)

It's an in depth technical read. The TLDR is this last paragraph here:

  All of this is a ways off. CTv2 is still not standardized. Chrome still doesn't do any SCT auditing, and consequentially its CT policy requires at least one SCT to be from a Google-operated log, since Google obviously trusts its own logs not to break its promises. Fortunately, even without widespread log auditing, Certificate Transparency has been a huge success, cleaning up the certificate authority ecosystem and making everyone more secure. Nevertheless, I think it would be a shame if Certificate Transparency's auditability were never fully realized, and I hope we'll be able to find a way to make it work.


The UUID specification details several "versions" which are methods for generating the UUID. Most are aimed at ensuring uniqueness (that's the main point of UUID) by using, e.g., the current date. This is efficient but means that while the generated UUID are unique, they are also predictable, which makes them inadequate for some security usages.

The "version 4" UUID generation method (in section 4.4), however, is supposed to use a cryptographically strong random number generator. 6 of the 128 bits are fixed to a conventional value (to indicate that this is a version 4 UUID, namely), so this leaves 122 bits from the RNG.

If the underlying RNG is secure (e.g. /dev/urandom on a Linux/MacOS/*BSD system, or CryptGenRandom() on Windows) then given many generated UUID, an attacker is not supposed to be able to predict the next one with success probability higher than 2-122, which is adequately small for most purposes, including launch codes for nuclear missiles.

122 random bits ensure uniqueness with high probability. If you generate many version 4 UUID and accumulate them, you may expect to encounter your first collision after about 261 UUID -- that's about 2 billions of billions; simply storing that number of UUID would use more than 30 millions of terabytes. If you consider "only" 1012 such UUID (one thousand of billions, storable over 16 terabytes), then risks of having two identical UUID among these are about 9.4*10-14, i.e. about 700 thousands times less probable than winning millions of dollars at the lottery.

Therefore, UUID are appropriate for security purposes if (and only if) they are "version 4" UUID generated with a secure RNG.


DDoS Detection devices available in the market?

Detection is fairly easy and a well-known problem that your security and incident event monitoring solutions (SIEM) should be able to shine light on, AlienVault (OSSIM) is an example of such a solution, as is Prelude, via event correlation. It's worth keeping up on correlation as an art unto itself:
https://scholar.google.fr/scholar?hl=en&as_sdt=1,5&as_vis=1&q=event+correlation+for+ddos&scisbd=1

The short answer regarding prevention is probably 'no' at this present time albeit vendors like Juniper, Qualys and Cisco will claim to provide DDos mitigation features:
http://www.juniper.net/us/en/products-services/security/ddos/

Depending on the bandwidth available to your infrastructure, at some point you would need to replicate the ability to prevent an attack as per commercial offerings that employ scrubbing centres such as Akamai (formerely Prolexic), Incapsula, CloudFlare, Nexusguard, ArborNetworks and so on.

Scrubbing centers explained and pitched by Akamai/Prolexic:
http://www.prolexic.com/why-prolexic-best-dos-and-ddos-scrubbing-centers.html

These companies can mitigate attacks of significant size. More information on size here:
http://www.csoonline.com/article/2876763/network-security/ddos-attack-size-up-50-fold-over-past-decade.html
http://blog.radware.com/security/2012/02/ddos-attacks-myths/

So the question is also one of risk, i.e. the likelihood that your particular company should expect an attack and the scale of that attack based on your activities, locations of operation in terms of markets and where your infrastructure is located as well as the financial impact to you or benefit to the attacker(s) such as brand damage:
http://www.ccul.org/research/2013/13_0531ARiskBasedApproachtoDDoS.pdf


There is a difference between a hash as defined for a specific protocol and a cryptographic hash. A cryptographic hash simply takes a message of x bits and outputs n bits where x can be any positive number or zero and n is the output size of the hash. So in that sense a cryptographic hash doesn't define any encoding. A cryptographic hash is indistinguishable from random to a person that doesn't know the input (apart from the output size). So you cannot distinguish between SHA-256(x) and SHA-512/256(x) without knowing x.

A hash can however be encoded together with various parameters, especially if it is actually a password hash (which actually is a PBKDF or password based key derivation function). In that case it depends on the protocol that generates the hash. This is what sites like the one pointed out by User456 show. These values should only be interpreted for those specific protocols. These protocols however have not been designed from a common specification; the protocols do not have to adhere to any rules. Output of these protocols may very well overlap.

So the only way to say which encoded hash is for a specific protocol is to compare the encoded hash against the format defined by the protocol. Regular expressions could be used to filter out candidates. You should expect a mix of hexadecimals, base 64, decimal numbers and of course separator characters for most of them.


Is it safe to connect to random SSH servers?

2 options come to mind:

vulnerabilities in the SSH client
"hack back"

I run SSH honeypots, and a colleague wrote a script to take the password that the attacker used to create or change an account on the honeypot and use it to connect back to the attacker's SSH and enumerate the home directory. He has a 10% success rate...

This might be a corner case, but it highlights that once you make a connection to another computer, all bets are off. They know about you, your IP, and can use any information you provide against you.


Is it possible to spoof cellular data? For example place a transceiver some where and communicate with a cell phone similar to wifi spoofing?

As shown by state actors (see: stingray) and attackers around the world:

yes. it is. And it's not even very hard.

In fact, GSM has a very weak sense of providing authentification of the network to the user. So all GSM networks are relatively easy to "spoof".


What you're looking for is called a WORM drive (Write Once, Read Many).  Historically, solutions in this space had more in common with tape drives than with hard drives, but there are some common products.

To quote from the literature for GreenTec, a vendor of one such implementation (emphasis mine):

  WORMdisk™ technologies protect data from Ransomware, accidental or
  intentional modification, alteration, deletion or re-formatting with
  capacities ranging from 500 Gigabytes up to Multiple Petabytes.
  WORMdisks™ act like a one-way data diode where data can only be
  transferred one way, from the disk to the host (i.e. read-only) and
  cannot be transferred from the host to the disk media (i.e. written).

  Protection is performed at the physical disk level, and is embedded in
  the disk drive itself, so it does not matter what operating system or
  access controls are placed on the disk, the data cannot be modified.

CD and DVD media are cheap options which can be used for this, but have limited capacities.

WORM solutions are relatively rare, and as such, generally more expensive per megabyte.


keytool -genseckey -alias TDES -keyalg DESede -keysize 128 works within jre/bin folder but not when the keytool.exe is on another location

Meta: this may better fit security or even superuser; if it migrates take my answer along please.

How big? A (full) TDES aka DESede key contains 168 bits of "real" key, but the stored form includes bits originally reserved for parity
and today often ignored totalling 192 bits = 24 octets. "Two-key TDES" (TDEA keying option 2) has 112 "real" bits, stored
sometimes as 128 bits = 16 octets where the first 8 octets (k1) is duplicated as k3 during encryption and decryption,
sometimes as 192 bits = 24 octets where the first 8 octets are actually duplicated in the last 8 octets so that k3 = k1.

The KeyGenerator for DESede in the Oracle-formerly-Sun provider SunJCE accepts only 112 or 168 bits as the size,
and stores always in the 24-octet form; generating 112 bits produces a stored key with k3=k1. This is apparently because
the Cipher from that provider only works with the 24-octet form. The BouncyCastle provider (which I use) KeyGenerator
accepts either 112 or 128 to generate the 16-octet form and either 168 or 192 to generate the 24-octet form, and its
Cipher works with either form. No DESede implementation I've seen (Java or other) generates or uses
a 256-bit key; are you sure you didn't confuse that with AES?

keytool.exe actually runs a JVM and loads Java classes to do the crypto operations including key generation.
Normally it uses the JRE in the same directory, but if you've moved the .exe it must use some
other method to find the JRE; on Windows I bet it uses same registry entries used to find the JRE for browser applets.
This is not normally the JRE within a JDK like yours, and I'm not sure it can be. If you have the JRE-in-JDK
customized with e.g. Bouncycastle, but the "browser" JRE not, you should get the results you describe.

Caveat: two-key TDES only has 56 bits of strength because of the meet-in-the-middle attack which is now at least nearly practical, and thus is not accepted as secure; see

https://crypto.stackexchange.com/questions/16073/why-is-triple-des-not-vulnerable-to-meet-in-the-middle-attacks
https://crypto.stackexchange.com/questions/24210/128-bit-3des-key-and-aes-key-whats-the-difference
https://crypto.stackexchange.com/questions/25258/can-cycle-finding-techniques-reduce-the-memory-usage-of-the-mitm-attack-against

(and this point is definitely ontopic for crypto).


IP Restricted OTP like Web Admin Authentication Safe or Not

There is unlikely to be a single answer to this question as each may cover different flaws. Here are some, only concerning token derivation and use of 404:

The second part of the token can be directly calculated by any adversary as they know their own IP address. It can therefore be removed without reducing security.

The use of a hash in the first part of the token does not add any security value, but increases overhead (although likely negligible, it is still pointless). The point of the one-time password is that it is difficult for an adversary to guess the randomly-generated value; hashing the value does nothing to increase the difficulty as an adversary needs to guess the 5 original numbers or the hash.

The guess-space with the former is 1e25 values as one can simply concatenate all numbers. This is equivalent to log(1e25) / log(2) = 83.05 bits; you do not magically get MD5's 128.

Do you need to increase this? My guess would be that a brute force attack would sooner DOS you, but there is little harm in using more space so go for it.

The use of 404 errors is security by obscurity which is not security.


Why do you have to be an admin to create a symlink in Windows?

By default, only administrators can create symbolic links, because they are the only ones who have the SeCreateSymbolicLinkPrivilege privilege found under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\ granted.

From Microsoft TechNet: Security Policy Settings New for Windows Vista:

  Symbolic links (symlinks) can expose security vulnerabilities in
  applications that aren't designed to handle symbolic links.


Opening remote MySQL database to office IP address at default MySQL port risks?

The main problem I see is that MySQL does by default not use any encryption so your username and password will be transferred in plaintext every time your or any application using the MySQL Server connects to the database. You can use MySQL with SSL Support, but that would require some extra work. You can have a look at this to determine if it's worth the work: https://dev.mysql.com/doc/refman/5.1/en/building-with-ssl-support.html

My suggestion is that you setup a MySQL Server on the Webserver and then use a socket which isn't only much more secure than establishing an unencrypted connection but also faster because you don't have to deal with the TCP/IP overhead. In my experience MySQL is easy to administer as long as you don't have really huge datasets.


How does SAML signature exchange work between IDP and SP?

This is correct. That is one way that signature varification can be made and it is as far as I know the most common one.

It is also possible to for the entity signing to attach the public certificate to be used for verification, in the signed XML. This then assumes that the certificate is validated by som other mean like verifying that it is signed by a trusted CA.


How to crack password hashed using SSHA?

SSHA,  or more commonly known as salted SHA1  can be easily cracked with John the Ripper.


Could antivirus programs not just scan all files upon creation?

No, scanning for viruses only at creation time is not secure for several reasons:

Anti-virus heuristics and signatures update continuously, so something could be missed upon creation but would be caught at execution time.
The anti-virus system might not be loaded when the file is created:

Perhaps A/V was temporarily disabled for some reason
Perhaps it is a removable drive and the file was created elsewhere
Perhaps the system was booted into another operating system

Does "creation time" include modifications?
What about code executed in-line that is never created as a file?

There are also more complicated scenarios.  For example:  You get an encrypted payload (containing the virus).  A/V can't detect this because it cannot decrypt it.  Much later, you have a second file arrive.  This file isn't technically malicious, but it does decrypt the first file, which then runs and infects your system.  This is an increasingly common trick for avoiding detection in both traditional A/V as well as malware sandboxes like FireEye.

A system that hashes files and checks those hashes against an up-to-date file reputation service would only have to scan unknown hashes.  Cloud sandbox systems like Cisco AMP do this.


I've noticed nobody actually answered this question and while the questioner might be helped already, others might have the same question.

There is no significant difference between a regular website and their mobile version. You use the same technology and therefore the same risks apply to these websites. Of course, there is a big difference between securing a regular website and mobile security - They are fundamentally different.

In this specific case; asking your teacher to clarify the assignment might be your best shot. This could be the answer to your second question "Is mobile security the same as mobile website security" as there is no such thing is 'mobile website security' in the security industry unless your teacher meant the same.


Possible for Lync (Skype for Business) to adopt Activesync-style policies?

It's been a while since I last worked closely with Lync server, but while you can exercise quite a bit of control over the content of the conversations, I don't believe that it directly allows for Activesync style encryption policies.  I sadly no longer have a configured environment to go digging on to verify that though, so take this answer with a large grain of salt as a fair bit speculative.


Is there anything else than DNS leaks that I should be aware of while using VPN?

Assuming you are concerned about privacy and also assuming you are talking about client web traffic you may also want to consider other ways in which your location or identity may be leaking out.

Some of which include:

IPv6 traffic not forwarded through the VPN which may provide geolocation
Cookies from primary website
Third-party Cookies
Cookie-like identifiers stored in things like Flash
HTML5 Geolocation within the http/https traffic
correlation of your web use pattern
correlation of your use of language
correlation of unique browser identity objects especially as they may relate to browser plug-ins
Anything unique to you that may help correlate your actions back to you
etc....

Other protocols will have additional issues.

Think of a VPN as a single security control which provides you with a very specific type of protection from one single vector of attack. It doesn't protect you from all of the other vectors of attack.

That said, ultimately the answer to your question is yes there are many other things to consider in respect to privacy when using a VPN.


Forensic Purposes is far reaching. There are a huge and scattered number of resources that can be important in a forensic analysis. What's more, the relationship of this data to file contents and time stamps are huge.
It sounds like you're interested in collecting specific logs. Forensic purposes really implies a full system copy or "Image".
A middle ground would be a Triage capture of target subsets. Often this includes recently run executable file names and sometimes snapshots of running network connections or even memory dumps, depending upon your objectives.
There is no simple list short of "everything". You'll need to refine your objective.


Is the traversal permission in a Unix filesystem exploitable by itself, in the absence of any other permissions/ACLs?

Granting traversal only (x permission on directories, and nothing else) doesn't let someone do much, but it does create some risks.

With x permission on directories, a user can check whether a file exists. Without the r permission on the directory, the user can't list files, but if they guess a file name, they can test whether there is a file by that name. This usually doesn't leak a lot of data, but it can be a privacy violation.

Beyond this, there is a risk that some file or directory inside the tree is not protected. It's pretty common to have world-readable files lying around. That's safe as long as they're under a directory that unauthorized users can't traverse. If you give traversal permission to everyone, then everyone can access those world-readable files. The same risk exists with world-writable or group-writable files.

Rather than give traversal permission to the toplevel directory, it's safer to expose selected subdirectories. As usual, it's safer to whitelist known public data than blacklist known confidential data. You can expose a subdirectory of a private directory through a bind mount. On FreeBSD, you can create a bind mount with nullfs (built in) or bindfs (FUSE).


Disclaimer: IANAL. This is not legal advice. I do not even know in which jurisdiction you live.

  This email and any files transmitted with it are confidential and contain privileged or copyright information. If you are not the intended recipient you must not copy, distribute or use this email ...

This is pseudo-legal "salad":

a privileged relation is a very special relation (client-doctor, client-attorney) and protects only specific matters, but these footers are added liberally to every email;
the footer does not even know if it is "privileged", "copyright information"(sic)... the "or" is telling!
an email is copied several time before it can reach the recipient inbox;
it is usually automatically retrieved and saved to disk, possibly in different places;
how can the receiver know if he is the "intended recipient"? (What about "Cc" and "Bcc"?)

For this to have any value:

"confidential information" should only be added to emails that really contain confidential information;
"privileged information" should only be added to emails that really contain privileged information;
the intended recipient(s) should be named.

Otherwise, it provides no information at all to the recipient!

Really, if your lawyer think that indiscriminately adding "confidential" on every document you send is proper behaviour, change lawyer. If your lawyer is a "just in case" kind of guy, ask him if "just in case" was ever useful: is there any case where an email footer mentioning "confidential" or "privileged information", automatically added to every email sent (even the most trivial messages) was successfully used in a court?

But why do people do that? you may ask. Because other people do that. Adults tell children to not be influenced by others, to not take drugs just because other children do, etc. but adults, esp. businessmen, usually try to do exactly what others do, including every possible mistake. (That's why we see investment "bubbles" and other economic aberrations.)


Yes. In CSRF attacks, the attacker can submit data but not read data. Normally, the CSRF value is contained in a HTML response, and including it in a JSON response it similar.
Make sure that the response can't be read by cross-origin hosts. This is the case by default, but if you have CORS headers (e.g. Access-Control-Allow-Origin response header) you may have disabled this.
You set the CSRF token as response to the login request. This makes me think that the login request itself does not have CSRF protection. You may want to consider protecting the login against CSRF.
Also, if you use cookie-based authentication I would recommend SameSite cookies, which solve CSRF and related problems. In addition, you may want to check the value of the Origin header if it's present in requests.


How to store openssl CA private key securely

Storing SSL private keys on production server
As I understand your question, you have a web server serving a GUI over HTTPS (IIS, Apache, Tomcat, something) and you want to know how to securely store the private keys on disk for this server.
Typically, people put a lot of effort into protecting their CA private keys, but much less effort into protecting the web server private keys (because the web server needs access to them at all times).
Metaphor: this is similar to asking "best kind of garage for my sports car?". The short answer is: it doesn't really matter  if your car will spend 99% of its time on the highway.
I think this question covers what you're asking:
How should I store SSL keys on the server?
Basically, if you're ok with needing to manually start the web server every time, then the list I have below for CA keys applies, but if you want the server to restart automatically, then your options are either

Store the key on the server in plaintext (applying whatever file permissions you can).

If you're on Windows, use CAPI / DPAPI to add additional protections to the file beyond what you can do without OS help.

Buy an HSM to store the keys for your servers (expensive and you may compatibility / complex setup issues depending on which web server you're using).

Original Answer about storing CA keys
[I assume you mean storage of the CA private key, not of the SSL server keys. I'll update my answer if you clarify]
I'm glad you're putting thought into how to store the CA private key. The goal of protecting a CA private key is to ensure that it can't be copied. How much effort you want to put into protecting it depends on what it's worth, in dollars, if it's stolen.
I'm 95% sure that openssl already encrypts your private key with a password (technically: uses a password to derive an AES key, then encrypts the CA private key with AES). So arguably, putting this inside KeePass isn't gaining you much.
Here are three scenarios with increasing security:

Protect the CA private key with software encryption such as openssl's built-in password encryption, or KeePass.
Pros: Cheap, easy.
Cons: A hacker who breaks into your server can copy the entrypted file and brute-force the password. Then they have your private key.

Store the CA private key on an encrypted USB stick, such as an IronKey. Make sure you always delete the key file from the CA machine after each use.
Pros: When the key is not actively being used, there is nothing on the CA machine for an attacker to steal. There is only one copy of the private key on a physical USB stick. Hard to steal without somebody noticing.
Cons: Malware planted on the CA machine can steal the private key the next time you use it.

Air gap the CA. Run your openssl CA on a machine that has never been connected to the network. Transfer CSR's and signed certificates in and out via IronKey USB sticks.
Pros: Much harder (but not impossible) for an attacker to get malware onto the CA machine and extract the private key
Cons: Complex and inconvenient.

Use an HSM. This is the Cadillac solution: store the CA's private keys in a networked HSM, when the CA needs to sign something it sends the request to the HSM.
Pros: Highest security because the private keys never leave the HSM; if the CA machine never touches them then they can't be stolen.
Cons: Complex, expensive, may require dev time and expertise to configure.


How to red team against firewalled architecture?

There are endless ways to go about this, and no universal answer, whether you're talking about "attacking a firewall" or attacking "against a firewalled architecture" (you mention both). The key to successful attacks is to be creative and think about the big picture. If there was a book or simple answer about how to do this, it wouldn't be a problem that companies spend megabucks trying to solve.

Here are some useful thought processes to get you started: How is the firewall configuration managed? Who manages it? How is its software updated? How do authorized users tunnel through it? Who are the authorized users and what other software do they run? What are the services exposed publicly by the firewall? Do those services have vulnerabilities? What types of systems are behind the firewall? Where do they connect out to, why, when, and using what kind of software? Where is the firewall physically located?

If you're actually worrying about whether a specific attack is useful or not (why aren't you trying it right now?) or trying to determine which attack one can be "sure" is undetectable, you're way out of your league.


Yes, the machines store, process, or transmit cardholder information (CHD) and/or sensitive authentication data (SAD), therefore they are in scope.


Are inactive vulnerable Wordpress plugins still unsafe?

Depends on the plugin, they can be if there is say a PHP script that can be called directly (doesn't depend on wordpress code or includes the right statements to load the wordpress libraries it needs).

You can effectively attempt to block direct access to the files via htaccess/server configuration but there are ways around that. Removing it entirely is better in general after all you can't run a file that doesn't exist.

Ultimately it depends on the vulnerability and the script it's in.


How does Tor preserve anonymity if it uses normal Internet Routing?

Broadly speaking the most basic premise of tor anonymity is that whatever happens between your entry point (usually a socks proxy into tor to which the browser connects) and exit node(s) is completely opaque and cannot be meaningfully reconstructed to determine the actual source of the traffic. (this is known to have limitations)

As Schroeder mentioned, this isn't to do with TCP/IP routing (even though the term is used extensively in tor documentation). If we expand your example from:

Tor Browser -> A -> B -> C -> Server

To

Tor Browser => Ta => Tb => Tc -> B -> C -> Server (where T* are tor nodes [Tc is an exit node] and B and C are Internet hosts that route traffic into the server)

What happens is that:

Server sees incoming requests from Tc incoming from router C;
Tracing of traffic if possible between Server and the public IP address of Tc;
(ignoring limitations, vulnerabilities and client-side surveillance) It is not possible to trace the path of traffic from Tc to the connecting Tor Browser, exactly as per Tor's design. In other words anything inside the tor network is meant to be untraceable;

Again please bear in mind that there are exceptions and caveats for everything. This is the basic concept put forward in a simplified way.


You should wrap your data in CDATA. It's a bit tricky but the technique is well explained here.


sqlmap HTTP 405 error on a vulnerable POST parameter

My preferred method of using SQLmap is to submit a request using a browser which is proxied through Burp, copy the request from Burp into a text file, then call sqlmap with the -r parameter pointing to the text file.

This ensures that the submission is going to the correct location, with the required headers and cookies.

In this case, I suspect that you are POSTing to the wrong location - from your description, it sounds like it may be making a Javascript call to a backend service and then providing an alert box or updating the content on the page. Using a proxy to observe this would allow you to check, even if the scripts on the page are obfuscated or excessively complex to allow for reasonable examination.


Is it safe to store and transmit fingerprint templates in ANSI or ISO formats in cleartext format?

This is not a safe approach! You should encrypt your data and/or use another biometric template protection scheme. For an example, see a technical report of the Indian Aadhaar system, where it is described how they handle it (e.g. on page 47).

Depending on your jurisdition, biometric information may be considered as sensitive. For example, in the EU under GDPR, biometric data is classified under "special categories of personal data" (previously "sensitive personal data").

Furthermore, as you indicated, it may be possible to reconstruct a the phase information of a fingerprint from its minutiae. See e.g. study 1, study 2, study 3. Other studies (see e.g. study) showed that it may be possible to infer gender from fingerprint minutiae. Those are obviously potential breaches of privacy. It is also a security vulnerability, as a reconstructed fingerprint could be used to create a presentation attack instrument (e.g. a gummy finger) and used to circumvent the system by an attacker.

Additionally, by sending your data in plaintext, your system may be vulnerable to man-in-the-middle and replay attacks. So, in conclusion: Do not send your data in plaintext!

Lastly:

  the server needs to send the template from database to the local machine for the SDK to match them

This is a very poor design decision as it makes possible a potential attack vector. If an attacker gains the control of the local machine with the SDK, they could repeatedly issue queries to the server/database for different subjects -- thereby exposing their sensitive information! Depending on the jurisdiction, it may also not be legally allowed for the biometric data to be transmitted outside the enrolment server/database.


Are URL parameters of GET and POST requests over HTTPS secure?

TL;DR: HTTPS provides encryption, and it's the only thing protecting the parameters.

It's well known that GET requests with ?xx=yy arguments embedded can be altered in transit, and therefore are insecure.

If you are not using encryption, everything is insecure: HTTP, Telnet, FTP, TFTP, IRC, SNMP, SMTP, IMAP, POP3, DNS, Gopher...

If I change the request to POST...

...it does not change anything at all.

and use HTTPS...

HTTPS changes everything.
Any HTTP request not protected by TLS is not protected. No matter if you use GET, POST, PUT, if it's a custom header, none changes a thing.
For example, this is a GET request:
GET /test?field1=value1&field2=value2 HTTP/1.1
Host: foo.exam
Accept: text/html

And this is a POST request:
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2

What is the difference? On the GET request, the parameters are on the first line, and on the POST, the parameters are on the last line. Just that. The technical reasons behind GET or POST are not the point here.

Suppose GET style parameters were added to a POST request - would those parameters be reliably ignored?

It depends entirely on the application. On PHP, for example, if the application expects $username = $_POST['username'], sending it as GET parameter changes nothing at all, as the application will get the POST parameter.

What about some sort of security downgrade attack? If the URL manipulator forces HTTPS transactions to fail, and then the client/server "helpfully" downgrade to HTTP, which would allow the unencrypted POST body to be manipulated.

Not easy for properly configured servers. If they use the HTTP Strict Transport Security header, it forces the client to only access the site using HTTPS, even if the user forces HTTP and port 80. The browser will helpfully upgrade to HTTPS, not the other way.
Even on servers that not use HSTS headers, if the first access is done via HTTPS, it's not trivial to downgrade to HTTP. The attacker must send a faked certificate, and the client must accept the faked certificate in order to an HTTPS connection be redirected to HTTP. But if the attacker succeeded on this, he will usually keep using HTTPS as the client already accepted his fake certificate anyway.


Strange address change during Buffer Overflow

Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are techniques used to prevent buffer overflows to be successfully exploited.

ASLR uses random offset locations where a system executable is loaded into memory.

DEP marks areas of memory as either executable or non-executable and allows data only to be executed in the executable marked memory locations.

When the two are combined, it becomes amazingly difficult to exploit vulnerabilities in applications using shell code.

However, it is not impossible. There are ways where these techniques can be bypassed. The following link is a whitepaper that explains a situation where ASLR and DEP are bypassed: https://www.exploit-db.com/docs/17914.pdf


Authentication of support engineers on client systems

I'd use some kind of HOTP-esque system - Event-based One Time Password. Think about the little RSA key fobs some people use with random numbers. You can either buy a bunch of them and give them to your engineers (they have to be programmed in to the machines, though), or set up some phone system for your engineers to call to get the OTP.

One issue is that you can't revoke stolen keys. If you give them to your engineers, and they lose it or leave and don't return it, they can still get in. If these systems have accurate (+/- 30 seconds from real time) clocks, you can get a time-based OTP system instead. Use the same 6-digit number code, but then your engineers can't stockpile a dozen numbers before they walk off the job with their company ID and those passcodes.

You can do this without the keyfobs. The downside is that, if anyone has access to the private key in the code, they can get into any machine anywhere. If you can compile it in, you're pretty set.

The HOTP or TOTP dongles can be purchased, or you can just use a Linux command to generate them at-will.

Simpler way

The simpler way is to have a random number generated by an algorithm. The number changes daily at a specific time. That way a newly non-employee or a stolen code couldn't be used for more than a day. You can actually use the HOTP example from above in this, using the HOTP method to generate the daily code and validate it.


Difference between antivirus and sandbox?

These are two quite different things. A little simplified:

An AV is a piece of software that can (among other things?) scan your system to identify and attempt to isolate and remove threats like viruses or other malware.

A sandbox on the other hand, is basically a context in which a piece of software can be run isolated from the rest of the world. Java applets running in a browser is a classic example, as should be Flash (though it is apparently not nearly as well isolated and safe as would be ideal): These are contexts where programs can run without having access to resources on the host machine (your PC), such as your file system, etc.

Another example can be a set of virtual machines. You could build your own "virus lab" by setting up several VM's running different OS's, then linking them together in an internal network, which will only be visible to those VM's. Now you could experiment by running malware on these machines, and seeing how it affects them, and how they affect one another, without affecting anything outside of their virtual network.

Another way to think of think of a sandbox, is as (ideally) a kind of digital software aquarium.


Drop privileges after startup or start as unprivileged user?

Avoid giving the daemon privileges it doesn't need, even for startup. This rules out option 1 and 3. It doesn't mean you have to go for option 2 though.

First let me recall the basics, just in case:

Run the daemon as a dedicated user, that runs this service only.
Don't allow the daemon to modify its configuration files. This means that all configuration files must be owned by a different user. Support for ACL is ubiquitous these days, so have root or some other user own the configuration files, and use an ACL to allow the daemon's user or group to read them.

Whether there's significant benefit to preventing the daemon to read sensitive configuration files after startup depends on what it uses the sensitive data for and what else it does. If these are credentials that the daemon uses only once during startup and then wipes from memory, there's a benefit to making it impossible to read them again later. If the sensitive data remains in memory there isn't that much benefit, but it also depends which is the most likely: an exploit that allows memory disclosure but not arbitrary code execution (e.g. uninitialized memory or bad pointer — although those usually do allow arbitrary code execution), or an exploit that allows file disclosure but dot arbitrary code execution (e.g. bad path sanitization).

If you decide that the protection of not allowing the daemon to read the sensitive file after startup is beneficial, then let the init system manage the privilege dropping. Open the configuration file from the supervisor process, then drop the associated privilege (a supplementary group, presumably), and pass the file descriptor to the process (--sensitive-config-fd=3 or --sensitive-config-file=/dev/fd/3).


Is possible ot create XSS with theses chars?

No, not in the context you have here.
URIs like javascript will not work in a value attribute, so you'll need to escape that context. You can only do that with ", which you don't have.
With the limited characters you do have, you'd either need an injection where you can use javascript URIs (eg into href), an injection into an attribute value context enclosed by ' (or not enclosed at all), an injection into a JavaScript context (eg a javascript variable enclosed by '), a bypass of the filter (maybe via some encoding, though unlikely), or insecure handling of the value via JavaScript (eg the input being passed to eval).


Is there a benefit to using a different email for every online account?

Indeed I do this quite often.

GMail has a feature where you can do this using the '+' sign. According to Google:

  Append a plus ("+") sign and any combination of words or numbers after your email address. For example, if your name was hikingfan@gmail.com, you could send mail to hikingfan+friends@gmail.com or hikingfan+mailinglists@gmail.com.

The benefits are around 2-fold (at least to me):

It makes credential stuffing much harder, as emails for one account won't match another. Although unique passwords is the best solution for this, different emails is an additional layer of security.
If I get spam emails that originated from a breach -- at least I know where that email came from, and know which breaches affected me.

And because Google makes this so easy (I do not have to create any aliases, it automatically happens), I do this for every accout that requests my email.


Hosted checkout page - who holds liability if there is fraud case?

Not a lawyer, this is not legal advice.

This is a contractual issue, more than anything else.  However, a principal reason for using hosted payment providers is that they handle all the sensitive payment information, not you.  If it is well built, you should never even see that payment information (most redirect completely to the other site and then redirect back to you so that they can be assured as possible they are under their own control - they prevent frame embedding and so forth).  If the payment processor allows you to build the form, including the CC data, and call their backend, you will likely have more liability (because you have that access - you could do something dumb like logging the data before sending it to the processor. Never do this.)

If there is a compromise, you will likely be informed by your payment provider and be the one who contacts your customers, because you are the one they have a relationship with. Even this may not be true, however.

If you want to minimize liability, do everything payment related on their site - you should be only informed that the payment was made, not any payment details.  Get your contract read by a lawyer and make sure it spells out liability issues and your responsibilities and make sure that is acceptable to you.


What are the benefits of using IP whitelists to secure cloud servers/resources?

Security benefits:

If an attacker had stole your client credentials then he or she will have an additional trouble connecting to your server. Basically the intruder will have to connect from one of your client networks to have whitelisted IP address. An example of such a case: client looses his laptop or some one copies his hardrive or stole his flashdrive. IP of the client becomes one of the factors in your multifactor authentication system (credentials + IP address).
If your client has a malicious intent and leaves a simple backdoor on the server then after you revoke his access and remove his IP from the whitelist he would have an additional trouble connecting back to the server using the backdoor. If he didn't have root access to the server before then whitelist would make it impossible for him to connect through backdoor.
There are always some possibility that there will be a zeroday or oneday exploit to your authentication system (SSH or telnet or whatever you using). If your server blocks all traffic except whitelisted IPs then it makes impossible for an attacker to hack you from the internet. He or she would need to search for your whitelisted networks and then hack to some of them first.


How do I list IP addresses a system is connecting to from its memory dump or OS image (obtained from FTK Imager)?

In Linux you can use netstat -ptan and if you don't have netstat you can use ss -neopa
and if you are connected to a server trough a proxy you will not see the ip address of that server is connected to which process.


DOM based if you're basing it on the stored/reflected/DOM classification system.

From OWASP Types of Cross-Site Scripting:

  DOM Based XSS is a form of XSS where the entire tainted data flow from
  source to sink takes place in the browser, i.e., the source of the
  data is in the DOM, the sink is also in the DOM, and the data flow
  never leaves the browser.

Here the source of the data is document.cookie and the sink is also in the DOM (HTML content of a paragraph).

However, classifying XSS in such a way really only boils down to semantics, as the article notes:

  For years, most people thought of these (Stored, Reflected, DOM) as
  three different types of XSS, but in reality, they overlap. You can
  have both Stored and Reflected DOM Based XSS.

Using the above I guess you could classify it as "Reflected DOM Based".

OWASP have attempted to try and get people to reclassify XSS as either server based or client based, where DOM XSS is a subset of Client XSS. Using this system it would be a "Reflected Client XSS" vulnerability.

Regardless of actual classification, the vulnerability here is in the DOM rather than the cookie storage as there is no need to HTML encode for storage into a cookie. Encoding should be done as late as possible when the usage context is known otherwise this cookie could have been poisoned.

e.g.

Website is on example.com and it normally only listens on HTTPS.
Attacker Man-In-The-Middles an HTTP connection from their victim and sends them to example.com over plain HTTP. The HTTP server in this case is the attacker's.
Attacker sets the cookie containing some script code.
The victim later visits the real example.com over HTTPS and the XSS is triggered.

As the code that adds the text to the DOM is not correctly HTML encoding, this is a DOM based XSS attack. As you can see from the above example, not HTML encoding on storage into the cookie doesn't stop the above attack scenario.


I'm not sure if this applies in this case but I thought it may be useful to some people.

CSRF tokens are sometimes rejected because each consecutive request doesn't preserve the cookies which were set on the previous request. This is likely because the CSRF token is either stored as its own cookie or more often, inside a session cookie which will change if Set-Cookie is ignored.


Could a hardware keylogger be installed in a laptop keyboard replacement?

Yes, it would be possible for a laptop keyboard replacement to have a keylogger installed. While they are quite thin, they still have a small low-power microcontroller chip which processes the keyboard input. A different microcontroller of the same form-factor that has its own flash memory and which keeps a log of keystrokes could easily be installed instead. Transmitting the data remotely would also be possible simply by adding a transmitter to the system (which can be very small and very thin).

The chances of a hardware keylogger existing in the keyboard replacement you purchased are remote, unless you work with classified or otherwise valuable information. If it really concerns you, you should try to buy the keyboard locally off the shelf. This will ensure that you are getting the same keyboard that anyone else would get, and that no modifications have been done beforehand specifically for you.

You should be aware that virtually all consumer keyboards actually act like wireless keyloggers in that they emit electromagnetic radiation that specifies the key pressed whenever you press a key. This is not an intentionally malicious design decision, but an unfortunate result of the type of electronics that are used. While it does not mean that keyboards will store what you type, it does mean that someone who is dozens of meters away with specialized equipment may be able to detect what is being entered on the keyboard. Just as with getting a keylogger, the risk that this will be used against you is low.


Which tool (apart from nmap) can I use to scan a range of IPv6 addresses?

There was an interesting presentation from Metasploit on this recently (blog post is here)

From that there are a number of techniques that nmap can use to identify IPv6 hosts on the local network which could be of use to you

Scanning your local subnet for all IPv6-enabled systems in one shot:

nmap -6 --script=targets-ipv6-multicast-*

Port scanning the top 10000 ports on these assets:

nmap -6 --script=targets-ipv6-multicast-* --script-args=newtargets -PS --top-ports=10000


Security for REST api (user/pass auth vs hmac vs oauth)

HMAC is a cryptographic algorithm which makes sense as part of bigger protocols; you should not fiddle with it directly. When you use HTTPS, the SSL layer actually includes some HMAC (among other algorithms).

OAuth is a standard for authorization whose main use case is managing authentication of users without sharing credentials -- the idea being that one user could have credentials (a big word for "password") known to a single server, that can be used to be granted access by several other servers without trusting them enough to show them the actual password. Say, servers S and T trust authentication server A, user U also trusts A enough to show it his password (within some HTTPS connection), and S and T talk to A to make sure that user U is indeed who he claims to be; the nice part is that S and T never see the password and U needs not trust them.

In your case, you have a single "user" (your server H) and since that's a machine, it needs not be picky about his password; H can have a "password" (a long sequence of random characters) which H will use only to authenticate with O, so there is no need for the extra complexity of OAuth.

The inherent vulnerability here is that server H has access to the sensitive data. That's by design, but this means that the data makes it to an hosted server, which implies that you trust the hosting service for not peeking at your data or leaking it through carelessness. You cannot evade that, as per your problem definition. You basically consider server H to be safe, by itself, from eavesdropping and hostile alterations. Under these conditions, HTTP's "Basic" authentication run within HTTPS will be fine.

You might want to tighten a bit server authentication: machine H will need to make sure that it talks to the genuine O server, which normally entails certificate validation. You can configure H to make "direct trust", i.e. import in H a copy of O's certificate (just the public certificate, not the private key), and instructing H to trust that specific certificate and none other. This may avoid issues with Certification Authorities, and, in particular, allows for safe usage of self-signed certificates, which are cheap (since you don't have to pay a CA for such a certificate).


Can Keyloggers get passwords from Windows 7/8 Logon Screen?

The log on screen is created by the WinLogin process. If a program can bind to the WinLogon process then it can most definitely keylog your login password.

The Metapreter Payload from the MetaSploit library is a good example of a tool capable of migrating into the logon process. You may look at "MetaSploit Unleashed", to learn how to compile Metapreter into a binary payload (.exe) or attach that to another (.exe) and obtain the same results.

A good demonstration of the technique can be seen at : Clicky

More References:

http://www.offensive-security.com/metasploit-unleashed/Backdooring_EXE_Files
http://www.offensive-security.com/metasploit-unleashed/Existing_Scripts

Note: Use of any kind of malware or spyware should only be done with prior consent of the system owner and/or users.

Also, look at Polynomial's comment below for other ways. +1 to him ;)


Your Task Manager is showing "Subestrutura: http://shelljacket.us. This is Portuguese for "Subframe: http://shelljacket.us", and means that Site isolation is enabled in your Chrome browser. Google's help page on this feature suggests that you can toggle Site isolation via chrome://flags/#enable-site-per-process

Even when you did not enable site isolation, then site isolation will still be used for websites loaded inside a Chrome extension. In your process list, I see that the item immediately above your unwanted process is an extension. To get rid of the frame, you can try to disable the extension.

Seeing an unknown site in a separate process in itself is not something to worry about. But this site in question seems to only contain a tracker from QuantCast, which I consider suspicious from the privacy perspective.

I looked up the extension in the Chrome Web Store ("Hotspot Shield Elite VPN Proxy") and used my Extension Source Viewer to read the source code of the extension. I found a code snippet in the extension's background script that confirms that the extension is embedding an frame with a QuantCast URL.

        }, {
            key: 'quantcast',
            value: function quantcast() {
                if (!sdk.config.reporting.quantcast) return;
                var iFrame = document.createElement("IFRAME");
                iFrame.setAttribute("src", sdk.config.reporting.quantcast.url + '?rand=' + Date.now());
                iFrame.style.width = 0 + "px";
                iFrame.style.height = 0 + "px";
                iFrame.style.display = "none";
                document.body.appendChild(iFrame);
            }
        }, {

If you are using that VPN extension for privacy purposes, I would recommend you to immediately uninstall it, because this is clearly a sign that your privacy is violated.


CVE-2016-5195 - impacts on virtualization

Looking at this github page and this RedHat page it seems that the attacker can write to /proc/self/mem and ptrace files.
The ACL that will be affected is the ACL of the VM and not the host machine. This means that the files that are shared between the host machine and the VM (remember the VMWare file sharing bugs) will remain vulnerable. Apart from that, I don't think the host machines will get affected.


Meterpreter (Metasploit) anonymous reverse connection over Tor2web

You may want to consider the following:

Tor exit nodes might only allow a small set of outbound ports; perhaps move your listener to 443/tcp
Are you using SSL?
Have you tried simplifying it to the bone, for example using a basic https egress from your exploit via tor2web and see what is the success rate on the listener end. Then add complexity by using meterpreter (staged/stageless) and measuring what happens? It could be that your exploit simply drops the connection.

Basically, reduce the variables until you can pinpoint the problem..


Security considerations for USB keyboard/mouse switches

Points on the product page

  Are you just paying for the accreditation here or is there a legitimate security advantage over more basic consumer switches?

Listed by NIAP and pending NIAP Common Criteria validation to EAL 4

This is just the certification, although certification should check for some issues.
Prevents data transfer between classified and unclassified computers

As it is a KVM it means you can swap between using machines without having to change controls, but it doesn't prevent transfer, it just reduces the need to transfer files.
Features no hot keys or OSD to prevent data from being stored on KVM Switch

This may be of use, although a lot of shortcuts could be implemented without logging any data (only intercepting a set combo and not storing any input data)
Non-reprogrammable firmware prevents tampering with KVM logic

This is a double-edged sword, on one hand malware cannot be loaded onto the device, on the other any bugs in the device cannot be fixed.
Provides full support for USB computers, keyboards, and mice

Provides no extra security

Bridging the airgap

  However, the bit that concerns me just by looking at the box is that there is a cable from both of my machines that connects to a central point. These machines are really supposed to be air-gapped from each other.

The KVM would be a path over the airgap, but you also need to consider other ways to bypass it, such as:

Using load to signal over the power line voltage
Using microphones and speakers to communicate using inaudible frequencies
Using fan speed to transmit data

You have to weigh up any bridge over the airgap as:

(likelihood of attack + ease of defence) / necessity

In this case, if you need to use the same inputs you can treat it as an acceptable risk in the same way you would treat plugging both machines into the same power supply as an acceptable risk.


Why is my IP address different when I connect to a vpn?

Hard to sort this out without more info, but I believe:

IP A is probably a private IP only used inside your network (10.x.x.x/192.16.x.x/172.16-31.x.x)

IP O is your public IP (what the rest of the world sees, pre-VPN connection)

IP B is the IP the VPN gives you to browse the web

Go to something like https://www.whatismyip.com/, that'll show you what the world will see as you browse.