resource on physical security that calls out doorknobs as being more secure than door handles

I'm not sure that an official report exists, or that one would need to be written. It could be said that a lever is inherently easier to operate and more prone to accidental opening than a knob. Anyone with kids or jumpy pets can tell you that.

Another reason why one might not write a report on the security of the difference is that it might not matter because Accessibility laws might supercede any security considerations. Levers are easier to operate with a closed fist (which is one standard for accessibility).

What is strange to me in your question is that you are asking about a specific feature of that one door handle in which it automatically unlocked when used. That is certainly not a ubiquitous feature of door levers and not confined to levers. Doorknobs can do the same thing. So, in addition to the above points, you have set up a false comparison between the two styles.

You simply cannot state that levers are more or less secure than knobs because your boss' door had an automatic unlock feature. Instead, you would want to determine that a handle with an automatic unlock feature is less secure than a handle without that feature. And I do not think that you need an official report to make that conclusion.


Does WPA2 Enterprise also authenticate clients to the 802.1X protected switch port?

I will start by saying that while some access points can be configured as a client to authenticate to an 802.1X protected switchport, not all can.  Further, you can't enable 802.1X on a trunk/tagged port, so you won't be able to do this if you have an access point configured to handle multiple VLANs (i.e. multiple SSID/VLAN mappings with an autonomous AP or some vendors with 802.11ac are moving away from tunneling all traffic back to controllers).

I am not aware of an access point that will work in a "multiple session" mode as you describe.  I think the first hurdle here is that the AP functions as a NAS itself, so the client is already authenticating to the network.  This would potentially require a second 802.1X authentication by the client to the switch.

The second hurdle is that this would break any ability to run multiple SSIDs on different VLANs or to have the AP management IP address on a separate VLAN than the users.  In a "multiple session" mode typically all devices must have the same VLAN assignment or they will be denied access.

Ultimately access points are part of your infrastructure and you should always look at physical security for all infrastructure.  How are you securing your switch to switch links that are not participating in 802.1X?  This is a security vulnerability as well if not secured properly.

For instance, I would start with some sort of cable locking device such as this one from Panduit.  While not perfect, at less than $10 per AP it does make a cable much more difficult (either accidentally or from tampering) to remove without the "key" tool.

If you wanted more security I would use an enclosure to contain the AP and cabling.  These will range from about $50-300 per location and provide differing levels of security (depending on make/model).  If you go with a metal enclosure, you will need to use an external antenna to prevent the enclosure from interfering with signal, which may add additional costs.


Why do WordPress installations retrieve the crypto secrets remotely on installation?

This is arguably bad design, but one can understand where the design came from.

It is arguably bad design, because it relies upon api.wordpress.org to generate random keys and keep them secret.  If api.wordpress.org gets compromised, then the attackers could arrange to record the keys that are used by new Wordpress installations.  That would be problematic.

(Yes, Wordpress could send you backdoored source code, but that would be detectable in principle by anyone who examines the source code -- as you have done.  In contrast, if api.wordpress.org is secretly recording a copy of the keys it sends to new Wordpress installations, that is not detectable by any amount of source code inspection or any other mechanism available to interested third parties.)

It is understandable, because it is hard to generate crypto-quality randomness in a platform-independent way.

It's still arguably a bit sloppy/lazy.  Arguably, a better design would have been to gather some local randomness (if possible), gather some randomness from api.wordpress.org, and then mix the two securely using a cryptographic hash function.  That way, you'll be secure as long as either of those two values is good.  A compromise of api.wordpress.org would not endanger Wordpress installations running on any platform where the code was able to gather some local randomness; it would only endanger the small minority of installations that were unable to get good randomness.

How can one generate good crypto-quality randomness, from local sources?  There are various ways:

Read 16 bytes from /dev/urandom, if it exists.
Call openssl_random_pseudo_bytes(), which invokes OpenSSL to get crypto-quality pseudorandom bits.
Call mcrypt_create_iv(), with the MCRYPT_DEV_URANDOM flag.
Of course, one can try all available options and mix together everything you get.  As long as at least one of these options work, you'll be good.  And of course, if you mix this together with output from api.wordpress.org using a cryptographic function, it'll never be any worse than today's approach, and will be better if api.wordpress.org ever gets compromised.

So, combining local and remote randomness would have been a better approach.  Unfortunately, that does require a bit more work and a bit more code.  Perhaps the developers took the easier approach of just querying api.wordpress.org.  One could debate that design decision, but you can understand how this approach might have been chosen.

Overall, though, as Thomas Pornin argues, this is probably not the biggest security risk with Wordpress.  We're talking about software with a long history of security vulnerabilities.  So, the incremental risk added by this aspect of their random-number generation might be small, compared to the risk you're already taking either way.

See also Secure random number generation in PHP for more on generating crypto-quality random numbers from PHP, and Would it be secure to use random numbers from random.org in a cryptographic solution? for more on why it is not a great idea to rely upon a remote source of random numbers for your crypto keys.


Store sensitive decryptable data in database

If you ever need access to your users' plain-text credentials, then your system is fundamentally broken from a security perspective.

Passing over this, to make momentary use of plain text credentials, the process is like this: You store the credentials properly encrypted as you normally would, and inaccessible to anyone including yourself. Then,

The user enters the credentials, and you confirm that they are correct using the encrypted hashes
If they are correct, you perform your action and then discard the plain-text credentials

This requires an active involvement of the user, but anything less than this is beyond insecure. If there is a mechanism to decrypt user passwords at will, then the passwords are also accessible to anyone who can access this mechanism, both from within your company, and potentially from without. It is then possible for an attacker to single-handedly decrypt your whole database of credentials into plain-text.


Is there a legitimate reason I should be required to use my company's computer? (BYOD prohibited)

So this is an interesting question with a few points into why you not only should WANT to do this, but should do this for your own safety and security. It helps first if you understand that companies point of view before we talk about how it can benefit you.
Why would a company want to do this?
Many reasons. It makes it assured that your computer can access the network, do what it needs to do, and function how they need it to at a baseline. This way the IT department can maintain it easily, quickly, and up to standard.
Can they make me do this?
YES THEY CAN! They are having you work on their property, with their property, to make sure it works properly. This way you can actually do your job.
Should I do this?
Oh god yes.

This lets you pass the buck if needed. Now if something that is supposed to work, doesn't work, it isn't your fault.
Maintenance becomes a breeze because if your files are backed up to a safe place (any installers you used as well), then if something really bad happens they can restore it to a disk image and have your computer back to you in the matter of a few hours instead of days.
IF you leave the company for any reason, you don't have to relinquish your personal computer to them for driver scrubbing or making sure you don't take any company software or intellectual property with you.
IT has no claim to touch your personal computer for any reason.
For security reasons, you can make sure that your work computer is up to their standards and any potential breach won't be your fault, but their bad policies' fault.

And here's the whammy: It keeps you safe from the company!
In using the company computer your own personal information won't be on the company network, and you can keep your private life away from your work life. This is a big advantage because you can make sure that your own data, is your own data.


How should security user training be provided when implementing a company BYOD strategy?

In the security community, BYOD stands for "Bring Your Own Disaster".

Any realistic implementation would need to be segmented networks with core systems isolated from the more general access network.

Company access should only be through a company supplied encrypted VPN/Tunnel application with 2FA. This in turn implies individual tracking, vice generalized permission.

Limit personal device access to a whitelist of services and protocols.

Comprehensive network activity monitors need to be running and paid attention to, not logged and ignored as is so common.

Training should emphasize network monitoring. Make it it clear and public that individual actions are tracked and recorded.

Good Luck!


How does SSH public key auth link a public key to a login?

The "public key - login" link is inferred from the place where the public key is stored:
it is added to the .ssh/authorized_keys on the server inside a specific user's home directory.

In a typical use case each account has a separate authorized_keys file. If it doesn't exist, you cannot connect to that account with an SSH key-based authorisation.

SSH client provides the account name you want to login to (on Unix-based systems the ssh command executed without account name will request login to the account name currently used on the connecting machine).

SSH server receives that account name and tries to match one of the keys in the authorized_keys file inside the home directory of the provided account.

SSH server also checks permissions to that file and denies login attempt if any user other than the owner could modify it.

In a less typical case a global authorized_keys may be configured. Then the file contains %u token for username (refer to man pages).


Why do Android and iOS not let users view wifi passwords?

People tend to reuse passwords. So if iOS or Android lets someone see your WiFi password, there is a good chance that that person now knows the password for many other situations. That's not a good idea.

Also, these devices are very portable, so they will find their way into other people's home. Imagine that I would like to access your WiFi, and you're Ok with that except that you don't want me to know your WiFi password. So I hand my phone to you so you enter the password, and everything is fine. I have access to the WiFi, but I don't have access to your password.

iOS has a new feature that couldn't possibly work if you could access the WiFi password: If you bring your phone into reach of my network, and you're in my contact list, you can ask for WiFi access, and I press a button on my phone, and you have access. Your phone gets the password, you don't.


Bettercap 2.x SSLStrip Is Not Converting Links

When I go to the Scholastics page, then click the Tumblr link (specifically the Goosebumps one) I get redirected to HTTP. Many of the other links on the site are HTTP and others are HTTPS. This is the desired result and I did not get the same results with weibo.com. So I guess that means it works right? From this, we can conclude that the absence of HSTS does not guarantee an attacker's success. To further prove this, I went to time.com and noticed none of the links were converted to HTTP like they were on the Scholastic site. I guess it depends on how the site is built? I don't know honestly.


Should a bank/financial service use external URL shortener services?

In some of these links there are some long/obscure URLs which link to one of their subdomains, but the long links are ugly and not very user friendly, so they want to have shorter, nicer links to put on the website or email.

Users generally don't have to type any URLs anymore since at least a few decades. In fact, if you have a look at this link, you'll see it is really long and yet you don't need to type any of it. Generally, URL shorteners are only useful if you have to transmit a URL via a medium that doesn't support hyperlinks, such as printing it on paper. And even there, QR codes are slowly getting implemented more and more to solve this exact problem.

  What are the risks of using an external service to do this?

Source: Randall Munroe, xkcd/1698, licensed under CC-BY-NC 2.5

By using URL shorteners, you promise that this URL will link to a trustworthy source. As long as your URL shortener of choice works and remains trustworthy, this works. However, once some time passes, that URL shortener may go out of business, and that domain will go up for sale once again. From that point on, you can't guarantee anymore if those old URLs will work (they probably won't), or what will happen if users visit them. Remember, that in the eyes of a user, this link came from you, so they will trust anything on that site to be from you - even though it might not be.

Has this happened in practice? Yes. In Windows XP, the Windows Media Player does not come with the required license to play DRM protected WMV files. Luckily for the user, Windows Media player has the URL to get the license hard-coded. Unluckily for the user, that URL does not longer point to Microsoft, but rather to a distributor for malware. Any user that still uses Windows XP and wishes to play a DRM-protected WMV file, will be redirected to malware by the built-in media player of their OS, only because of URL shorteners.

A better solution

If you distribute links only digitally, it does not matter how long URLs are. Users just click on the button and that is it. If you really need to distribute URLs in a format that is non-clickable, such as TV advertisements or print media, make your own URL shortener. If ACME Corp. offers a new product called the "Ultra-Gigatron 9001", then make the URL ac.me/ug9001. If that doesn't work, make it acme.com/ug9001. Subdomains are free, and so are path names. Just be aware that that URL needs to be up as long as you expect people to type it.


Executed malicious exe file. Help please

It's impossible to know from this description if your computer is compromised -- but it sounds like you're prepared to do a factory reset. For your peace of mind, and for the integrity of your system, that's what I'd recommend.

If you have access to a backup from which you can restore only records timestamped before you downloaded the malicious executable, that's the way to go. If not, I recommend backing up your data to an external drive. Don't reconnect that drive until you have reset the system, installed a good antivirus program, and performed all updates to the operating system and the antivirus program. Then connect the external drive, scan the files using that antivirus program, and (if they pass the scan) copy them back to your hard drive.

Then I recommend reformmating the external drive.


.NET application protection technique against cracking

You're wasting your time.

  I'm trying to protect my software against cracking. Protection against cracking is crucial before listing the product on market.

Even the big names in software development can't protect their software from cracking. Despite very draconian DRM that drives legitimate users nuts, it all ends up on the pirate sites within days of release.

  Obfuscation, Renaming, anti-debugging

Everyone else does this too. All it does is slightly slow down the attackers.

  Encrypted communications between software and API server (RSA) public key hard-coded

I assume you're hardcoding the public key as a form of key pinning to protect against MITM attacks. However, this doesn't work in this case, since the client is also the attacker. They can just patch the binary and replace the key with their own MITM public key.

  Verify libraries integrity by requesting libraries checksum from API and compare it.

Doesn't work. If the check is on the client, the attacker will just patch it out. If the check is on the server, then the client needs to report the file contents to the server, and the attacker will just make the client lie.

  With all of these layers, can the software cracked?
  Can the custom data layer bypassed?
  If a cracker bypassed the protection layers until the "custom data" part, it's possible to clone the software with the "custom data" meaning the software can operate without need to request the custom data from the API?

Yes, yes, and yes.

If you want any of your data to be safe from the person whose computer is running your client, then the client needs to not have access to any of that data. It all needs to be handled exclusively on the server.


Certificate serial and thumbprint number spacing

It is solely certificate viewer, nothing else. Microsoft time by time tweak/change certificate viewer. Prior to Windows 10, hex values were printed in octets separated by a space, now they removed space. Though, public keys and public key parameters are printed in octets with spaces.

The fact that you see spaces for some certs is related to certificate store. Certificate Viewer uses store-attached properties to fill fields in cert viewer. Since property value wasn't changed, it is shows as it was written (when spaces were used). Unlike certificate contents, certificate properties often use formatted strings instead of byte arrays.

I wouldn't care about this.


How to notify Adobe about a software issue

My 2 cents (even though this is an old, and probably un-monitored, thread).

Organizations don't invest in effort unless it has some return. Let's see if putting effort on closing this vulnerability has any return or not.

This vulnerability affects all trial versions of Adobe software. But, what is the impact here? What happens if someone resets the trial version? Does it become a full version of the software? If yes, then this is cause for concern.

But, if even after resetting the version, it remains a trial version, then it is not much of an impact. It is similar to un-installing the current trial and re-installing it again.

So, i don't think it would be deemed a vulnerability. Even if you reported it, they will not treat it as a vulnerability.


Is a host OS more vulnerable to a hypervisor escape if the guest OS knows the root password to the host?

In order to use the root password, the hypervisor must first be escaped.

The root password is only used by userspace applications to request greater permissions. The way a root password works is simple. When an application wants to switch to a more privileged user, a trusted and privileged program reads the password, hashes it, and compares the hash against the stored password hash in /etc/shadow. If the password matches, this trusted program executes the application as root. This is why the root password is considered sensitive.

In order to (ab)use the root password, a malicious application needs to be able to perform syscalls, the primary API between userspace and the kernel. To use the su program to elevate privileges for example, the execve() and read() syscalls are needed to run the program and pass the root password to it, respectively. A guest operating system running in a hypervisor does not have access to syscalls on the host, only to the hypervisor itself (using so-called hypercalls), and to the kernel which is running virtualized. In order to escape from the hypervisor, a bug in its programming must be exploited. Knowledge of the host's root password thus does not help escape a hypervisor because it can only be used to elevate privileges after the hypervisor has already been broken!

While knowledge of the root password does not make a hypervisor escape easier, it is still not necessarily a good idea to give it to the guest. If the hypervisor is running unprivileged but is not sandboxed (e.g. QEMU with sandboxing disabled), a hypervisor escape may allow the attacker to run with the privileges of the hypervisor software. If they know the root password, they may use it to elevate privileges after they have broken out of the hypervisor.


I looked in about:preferences#privacy for an option regarding fonts,
  but don't see one. So, where is this parameter and how do I configure
  it?

Well, you should have read the complete article you linked :-). It says:

  You need to do the following to use a system font whitelist in Firefox:

  Type about:config in the browser's address bar and hit the Enter-key afterwards. Confirm that you will be careful if the warning prompt is displayed.
  Right-click in the main pane listing all preferences, and select "New > String" from the context menu.
  Name the new parameter font.system.whitelist
  Now add fonts to the whitelist separated by comma: Helvetica,Courier,Verdana is a valid value for instance.

If I do this in my (recent) version of Firefox on Windows 7, the list of fonts displayed by Panopticlick changes as expected.

Before, Panopticlick lists over 40 fonts, both the standard Windows fonts and fonts installed by applications. Afterwards, it only lists "Courier, Helvetica, MS Sans Serif, MS Serif, Times". I'm not sure why the list is different from the whitelist, but the feature does work.

I also tested on Debian Linux, with similar results.

Note that this whitelist not only restricts the list obtainable by web sites, it means Firefox will really not use other fonts for rendering, so sites may use different fonts because of this. Whether that is a problem or a bonus is for you to decide.

If that does not work for you, check whether you are running a different version of Firefox, with different features. Some Linux distributions, for example, create (or used to create) their own version of Firefox.

Try installing the regular version from https://www.mozilla.org/en-US/firefox/new/ (you can just unpack it anywhere you like and run it). Create a fresh profile on startup, and check again.


Just incase anyone stumbles across this in the future, further down the conf file there are other lists, all of which are contained in square brackets.

For listing ports, you seperate these with commas. For listing IP addresses, you seperate these with commas also, however you need to put down the IP address, followed by a slash, followed by the base.

So my final solution was like so:

  [1.1.1.1/24,2.2.2.2/24]


What is it called when someone glides through a building's external door behind you?

tailgating or piggybacking.  See https://en.wikipedia.org/wiki/Piggybacking_(security)


While I don't know of any known good or known bad driver download sites such classification might change rapidly when known good sites get hacked or change their business model maybe after getting sold. This happened in other cases too, for example with trusted browser extensions.

Thus the safest choice is to get the drivers from the original source, i.e. the vendor. While there were hacks of vendor sites in the past it is still the safest choice because the vendor definitely has an interest in providing the user with the correct software while the business model of these 3rd party driver download sites is unclear. And of course use signed drivers only.


How to integrate client certificates for upstream servers with nginx as reverse proxy?

From my understanding you have

VPS with Docker w/ domain name `my-domain` [
  docker-mysql hosting intern ????
  docker-owncloud hosting intern 3000 and internal connect docker-sql
  docker-nginx hosting extern 80/443 and internal connect docker-owncloud:3000)
]

you have 2x options:

my-domain/owncloud-subfolder
owncloud-subdomain.my-domain

If you wanted to go the subfolder route, it is possible to use your my-domain cert as is.  If you are going the subfolder route you would simply set owncloud up as HTTP (not https) and then use location {} to proxy_pass from nginx to docker-owncloud

location /owncloud-subfolder/ {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://docker-owncloud:3000;
    }

My personal pref is that it is easier to setup sub-domains and manage lets-encrypt certs for each of them eg:

ca.ffeineaddiction.com
gogs.ca.ffeineaddiction.com
own.ca.ffeineaddiction.com

in my case ffeineaddiction.com is my vps (vultr) and gogs.* and own.* are mapped to a physical server w/ 2TB of storage via tinc (tutorial on tinc setup)

EDIT:

  Re-read the question which is apparently different then what I understood it to be the first time.  If I am understanding correctly now you are not worried about the external certs that Nginx is hosting but rather the Clientside cert in Nginx to connect to HTTPS instance of owncloud on 127.0.0.1 ... in my setup my solution to this is to not have one ... I simply use HTTP between OwnCloud and Nginx since its all internal to the box (or over TINC in my case).


NAT is mostly a non-issue with IPv6. As you say using a firewall (which should even be used with NAT, because NAT is not a proper security measure by itself) is the proper solution.

Hiding the client's IPv6 address will only cause problems for protocols, traceability and security's Knowing the client's actual address makes writing firewall rules so much easier, and therefore prevents mistakes.

As far as the technical community is concerned the consensus is to avoid NAT with IPv6.

PS: NAT64 is used for IPv6-only networks to connect to the IPv4 world, but the IPv4 world is already full of NAT so it's considered an acceptable solution.


After thinking about it for 15 minutes, and assuming it's implemented correctly and the applications using it use it correctly, the only minor problem I can come up with is a language one:

  1.8 - the token is returned to the user UI (such as a mobile app or login website)

UI implies it is presented to the user. The user has no need to see the token, it should just be returned to the user client, which submits it without the user ever having to see it. This is of course a very minor issue as it doesn't really do any harm for the user to see it, it's just not really necessary.

Of course, you probably want someone better than me thinking about it for more than 15 minutes.

Personally I expect that once a significant enough percentage of people are using 2FA (and enough places support 2FA), phishers will start using proxies like Evilginx, which OTP solutions are vulnerable to. As far as I know the only 2FA method that prevents this right now is U2F, which requires storing a public key for each user.

I don't believe it's even possible to prevent this type of phishing without storing a public key, secret, or something similar per user. If I were implementing 2FA I would try to make it compatible with U2F, or at least try to design it so that U2F or a future method could be easily added if desired.

Also note that neither SMS nor email have strong guarantees that they won't be intercepted. At least with TOPT or HOTP you could use something like Google Authenticator that, while still vulnerable against a malicious proxy, at least doesn't have to send a code that could be intercepted.


I can explain this to you by taking few examples

First is that you have allowed "keep me signed in" on your website, so there are chances of unauthorized access if the user computer gets hijacked or is in hands of an unauthorized person.
A malicious person will be able to get every information residing on the account. However, there are least chances that the the person will be able to do any malicious activity such doing a transaction or changing the password and or email. These require an user to enter the current password.

Second case is that you have enabled 'Remember Email.' The user is comparatively more secure than in the previous case, chances are low that there will be an unauthorized access to the account. However, there is one little possibility of losing the account if there is any malware or say keylogger residing on the computer. The user will lose the control over the account, but it happens mostly in the case of targeted attacks.

In my opinion allowing 'Remember Email' is a better option than allowing 'Keep me Signed In.'


When would a Authenticode signature expire?

I'm curious about how Windows check the Authenticode signature

Microsoft's Authenticode is a mechanism that is based on PKI as any other digital certificate verification process:

Public key verification
Certificate lifespan
Certificate status (revoked?)
Trust chain
Timestamp (if used)

In case of timestamp, the signature will be valid as long as the certificate is valid.
Otherwise, it will expire when the certificate does.

From DigiCert:

  Timestamping ensures that code will not expire when the certificate expires because the system validates the timestamp. If you use the timestamping service when signing code, a hash of your code is sent to the timestamp server to record a timestamp for your code. A user’s software can distinguish between code signed with an expired certificate that should not be trusted and code that was signed with a Certificate that was valid at the time the code was signed but which has subsequently expired.


Windows Firewall - how to block inbound for all .exe files in a folder

You can use a Simple Batch File.  Open Notepad and copy/paste the script below into a blank document.  Save the file as BLOCKALL.BAT.  Now copy that file to the same directory as the EXEs you want to block and double click it.  It will add outbound rules to advanced Windows Firewall settings blocking all EXEs in that folder and sub-folders as well.

It is tested with Windows 7, but it should work with other versions of Windows that use Windows Firewall.

NOTE: Batch starts itself in system32. Thus you need to prepend it with cd /d "%~dp0" to make it work in current directory.

The resulting script would be as follows:

@ setlocal enableextensions
@ cd /d "%~dp0"

for /R %%a in (*.exe) do (

netsh advfirewall firewall add rule name="Blocked with Batchfile %%a" dir=out program="%%a" action=block

)


PCI Logging Data Elements for Network Devices, Databases and Wireless Networking

The absolute minimum you should log is successful and unsuccessful authentication attempts, along with configuration changes (including account changes such as new account, changes of passwords, changes of privileges etc.) and then state changes (device downtime, reboots, etc.), and also software changes including updates and patches being applied.

Then all activity by authenticated accounts that have either administrator access, or otherwise privileges allowing for any security related configurations.

Remember however that the logs need to be protected from tampering where possible (best practice is to have a centralised logging system that requires collusion to have privileged access if possible).

At the end of the day your QSA will determine whether you are logging enough information to provide support for both active alerting on suspicious behaviour, non-repudiation, security process improvement and possible forensics or damage limitation, but this would seem a sensible minimum.


Does a domain with no SPF record count as a DMARC pass or fail?

A DMARC pass requires that there is either a valid and aligned DKIM signature OR an a SPF check which returned Pass and which has an aligned claimed sender.

This means, that if there is a valid and aligned DKIM signature the result of SPF does not matter at all, i.e. it will return DMARC pass no matter what the result from SPF is, which includes the cases where the domain does not have an SPF policy at all.

If instead there is no valid and aligned DKIM signature then the DMARC result fully depends on the SPF result, i.e. a DMARC pass will only happen if there is an SPF Pass with an aligned claimed sender. If there is no SPF policy on the domain the SPF result is None, which means that it is not Pass and thus the DMARC cannot be pass either.


Is a netcat server without -e exploitable?

I you look at:
https://pen-testing.sans.org/blog/2013/05/06/netcat-without-e-no-problem
you can see that there are possibilities, if you are unable to alter the execution, it may be harder.

Note that it requires root, since you need to make a named pipe for sending raw terminal input to the other machine.


need to hide server details using apache server whenever there is 404 or 403 error

Try creating some custom error response pages. A plain old HTML page that just says something along the following lines:

ERROR 403: You are not authorised to access this resource.

It doesn't even need any formatting.


what position should I apply to be an ethical hacker?

Job titles tend to be a bit unreliable. I'd do a search for "security", then read over the resulting job postings' descriptions to see if they fit what you want to do. And when you contact the company, be explicit about your interests, so they can quickly tell you whether this is a good position for you or not without wasting either their time or yours.


... or am I arguing an authentication technology that was never prepared for Cloud driven services?

SPF is not really an authentication technology. It does not authenticate who is sending the mail but only limits from which IP addresses the mail can be sent from and thus tries to limit misuse of your domain as the claimed sender of spam and phishing.

  If they gave me companyx.amazonses.com I would be a tad more interested in including this.

There is no reason to believe that this would be more safe just because the company name is included in the domain name. The real question is which IP addresses are covered by the SPF (i.e. allowed to send mail for this domain) and one might simply set this "company record" to be the same as the global amazonaws record.

If you use the cloud to send mail you are usually doing this to profit from its advantages, i.e. flexibility, scalability, fault tolerance, low latency due to geographic routing etc. But, to implement these advantages it might be necessary to have lots of IP addresses and be flexible in which tasks are assigned to which IP address.

This means that the IP address might be an overly broad trust anchor when using cloud infrastructure. Instead or additionally you should rely on system specific instead IP specific restrictions. This can be done using DKIM where the outgoing mail system signs the mail and the recipient can check that it was actually signed by the mail system belonging to the sender. Both of DKIM and SPF can be combined with DMARC for even better protection against misusing your domain name for spamming and phishing.

In short: don't complain that SPF is insufficient and not designed for the cloud.  Instead use DKIM and DMARC in addition to SPF.


Why is the server returning 3 SYN + ACK packets during a SYN scan?

The normal TCP three-way handshake consists in a SYN from client to server, then a ACK+SYN from server to client, then an ACK from client to server. However, TCP has been designed to provide reliable data transport over a medium which is not reliable: stand-alone IP packets can get lost, damaged, duplicated, or transmitted out-of-order. That's why TCP is needed in the first place.

A server who has received a SYN responds with a ACK+SYN, and then expects an ACK as response. However, the server is well aware that packets can get lost, including its own ACK+SYN. So the server sends the ACK+SYN, then waits... and if it does not receive the final ACK from the client, the server assumes that its ACK+SYN might have been lost, so it emits it again. And again. Until the ACK from the client is received (which will not happen when the client is not a true client, but a port scanner which only sends SYN), or the server loses interest and gives up.

Each given operating system is responsible for deciding when, and how many times, a SYN or SYN+ACK or ACK will be repeated. On a Linux system, see the special files in /proc/sys/net/ipv4/ called tcp_syn_retries and tcp_synack_retries: they contain the number of times the kernel would emit SYN (respectively SYN+ACK) on a given connection attempt when being a client (respectively server). On a 3.2.0 kernel, I see that both files contain "5", meaning that a server subject to a port scan will emit five SYN+ACK packets. If you observe only three, then maybe your particular server was configured that way (this is as simple as echo 3 > tcp_synack_retries). Or maybe the server still uses the default value of 5, but your detection system was not patient enough: successive retransmissions use exponential delays, so the last retries can take a substantial number of seconds before being retransmitted.

Note that, to be able to retransmit SYN+ACK packets, the server must necessarily allocate a bit of RAM for that connection attempt, in order to remember this particular proto-client and retransmit the SYN+ACK. Abusing this allocation is the basis of the SYN flood attack. Lowering the maximum number of retransmission will make the server more robust against such attacks. In the extreme case, SYN cookies are a way for the server to not remember anything; as a consequence, when a server uses SYN cookies, it will respond with only a single SYN+ACK upon an incoming SYN. Since you observe that the particular server you are scanning sends the SYN+ACK several times, then you have demonstrated that this server does not employ SYN cookies, and is thus potentially vulnerable to SYN floods.


For the ciphers, use DHE-RSA-AES256-SHA.

If you use openssl ciphers -v you can get more information about each cipher:

$ openssl ciphers -v DHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
$ openssl ciphers -v AES256-SHA
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1

From this you can see that both ciphers can be used in SSLv3, both use RSA for authentication (Au=RSA), both use 256-bit AES for encryption (Enc=AES(256)), and both use SHA-1 for the message authentication code (Mac=SHA1).

So the only difference between these two ciphers is the key exchange. AES256-SHA uses RSA for the key exchange (Kx=RSA). DHE-RSA-AES256-SHA uses ephemeral Diffie–Hellman (Kx=DH is Diffie-Hellman for the key exchange, and the DHE is ephemeral Diffie–Hellman).

Diffie-Hellman is slightly harder to break in theory than RSA, but not so much that it will be a deciding factor. DHE offers perfect forward secrecy and because the key is ephemeral (i.e., never stored on disk), stealing the private key is much more difficult. Those two are deciding factors, so DHE-RSA-AES256-SHA should win for security.

The question 1024-bit DHE vs 2048-bit RSA has a better comparison of the virtues of the two key exchanges, and the question Is there any particular reason to use Diffie-Hellman over RSA for key exchange? has a very detailed comparson between the two.


Spoof publisher info on Windows applications

It seems very unlikely that you will be able to set the "Publisher" field in that dialong without getting a code signing certificate and applying a signature to your software.  That would be a big security risk for people who are going fast and not reading all the words in these dialogs.
If you are distributing this software to the public and you can afford it, I recommend getting a real code signing certificate.  I wrote a lot about how to do this:  https://www.davidegrayson.com/signing/
If you are only distributing this software to people you are closely affiliated with, you might be able to convince them able to install a certificate from you on their computer (as a trusted root certificate or a trusted publisher), and then Windows would show you has a verified publisher without you needing to pay anything.


How to properly validate HTTP redirects?

Good answer from alexwen, although I think his answer is more of a generic parameter sanitization problem, not exactly what OWASP is referring to. I think OWASP may be referring to any of the following concepts.

Revalidating Data From Redirect

OWASP is talking about a different kind of scheme where one URL does some processing (i.e. validation), then redirects to another URL to complete. For example, imagine two URLs, one is /checkout and the other is /ship. The /checkout URL checks the credit card information, checks that the parts are in stock, etc. then redirects to /ship. The /ship URL actually creates a work ticket to pull the parts and ship them.

If the attacker knows this setup, then attacker can just POST the relevant shipping data directly to the /ship URL, bypassing all of the validation performed in the first URL, and getting some products for free.

I've personally never seen a validation scheme this dumb, but it seems to be what OWASP is referring to.

Post-Redirect-Get Pattern

The PRG pattern means redirecting to a GET request after successfully processing a POST. This is used to avoid the horrendous usability problem of a user clicking the back button in a browser and the browser asking the user an obscure question about whether or not to "repost form data". (I've seen this trip up so many users that it's not even funny.)

I've never seen this used in such a way as to be vulnerable to attack, but in theory a poor authentication scheme might use PRG to process authentication credentials, then redirect to a "members-only" page or something stupid like that. Again, I've never personally seen in this in the wild, so I'm not 100% sure that's what OWASP is talking about, either.

Blind Redirect

I'm not sure that this is what OWASP is talking about, but this is actually a common vulnerability. Unlike the previous two vulnerabilities that I described, I have actually seen this in the wild many times. This common mistake is that the URL to redirect to is specified in the original URL query and is not validated, e.g.:

http://my.badsite.com/redirect.php?destination=http://google.com

If redirect.php unconditionally redirects to whatever URL is passed in (e.g. in PHP, header("Location:$location")), then an attacker can construct a URL that looks safe but actually leads to a dangerous site. For example, if the blind redirect script is at http://nytimes.com/redirect.php, then the attacker sends the victim a link like http://nytimes.com/redirect.php?destination=http://spyware.malware.xxx/get_pwned and a naive user looks at the link and thinks he is going to the NYT website. (Depending on the exact nature of the script, the attacker might be able to URL encode part or all of the destination URL in order to further obfuscate it.)

A redirect script should inspect the destination URL to make sure that it is appropriate, probably through some kind of whitelisting.


How to globally enable ld.so secure-execution mode for all applications?

There is no standard way to do this. You can write/use an LSM which sets bprm->secureexec = 1 for all processes under the user you want, or you can patch the dynamic linker in a way like this:
--- a/elf/dl-support.c
+++ b/elf/dl-support.c
@@ -316,7 +316,7 @@ _dl_aux_init (ElfW(auxv_t) *av)
       }
   if (seen == 0xf)
     {
-      __libc_enable_secure = uid != 0 || gid != 0;
+      __libc_enable_secure = uid != 0 || gid != 0 || !!getenv ("LD_SECURE");
       __libc_enable_secure_decided = 1;
     }
 }

This patch adds support for a new environmental variable, LD_SECURE, which if set, causes the linker to act as if AT_SECURE was set in its auxiliary vector. I haven't tested this patch since it's so trivial, but it should do what you want. You will need to set that environmental variable for any user you want in to run in secure-execution mode. Note that this is very likely to break a lot of applications.
I do have to question the utility of doing this, though. Secure execution mode is designed to protect a process executing another process across a privilege boundary. It is not a generic security feature. You should consider your threat model and try to find out exactly what you are protecting against.


Can an attacker reuse stolen SSL private key to recreate that domain on his server

Yes, if someone steals your private key, then he can make a fake server with the same name, and users won't see anything wrong with it (provided the attacker redirects connections to his server, e.g. by altering the DNS).

No, users will not be warned.

From the point of view of both the CA and the user browser, a fake server with a stolen key is not different from a Web server being moved to another IP address, e.g. as part of a DNS-based load balancing. When you have a server and a certificate, the certificate is in no way locked to whatever IP address you presently used; browsers only check that the server name appears in the certificate (see RFC 2818, section 3.1). You are free to copy your private key and certificates to another server with another IP address, and make the DNS point to that new address. The only difference with the attack scenario you describe (key theft) is that this time you really want it. Whether you agree to the IP move or not cannot be checked by the client, and, correspondingly, the client does not check it in any way.

So protect your private key, and, if it gets stolen, report the theft to your CA which will then revoke the certificate.


How to store a WS password on Android without risk or lowering the risk?

This sounds like a re-architecture may be required.  As Crovers mentioned above, you will not be able to protect the username and password if they are stored locally on the device.  You will need some form of proxy in between the web service endpoint and the device.

Best Practice

Best practice would be to give each user his or her own credential for the proxy, and then the proxy itself would connect the the SOAP endpoint.  The Proxy would connect to the SOAP Service via SSL

A not recommended work-around

Depending on your security requirements, you may be able to get away with less stringent requirements.  If there are particular operations on the SOAP service that you do not want your users to be able to access, you can simply not expose them via the proxy application.  For example, if the SOAP service exposes an add, an edit, and a delete operation, and you don't want your end users to use the delete operation, your proxy application would not expose a delete operation to your users.  Please note that this solution will only work with vertical access control, and not horizontal access control. It will only prevent users from performing unauthorized actions, such as the delete example.  It will not prevent users from performing authorized actions against object which they should not be able to access (i.e.  If I can update my records, I can also update your records.)

I hope that helps.  Please go with the best practice if at all possible.


Directory names using extensions a security risk?

Well, renaming only the folder  is more a matter of good practice. In the case you want the user to access his template folder like: site.com/templates/mytemplate.php; I would recommend you implement "Friendly URL" (Semantic URL), so in this case you would pass the 'mytemplate.php' like a variable and not like a folder name.


Why should I care if a site uses encryption or not if I'm not exchanging any sensitive data?

The issue you're dealing with, here, is that if you decide not to encrypt a connection, you're making assumptions regarding the sensitivity of the data that goes over that connection.

Unfortunately, it is impossible to properly make that assumption because:

You might not have fully understood all the implication of the data (for instance, if Twitter didn't encrypt data, it could be used by government agencies to spot dissidents and opponents).
Data can become sensitive after they are being transmitted (for instance, answering "who was your first grade teacher" in a web chat with old school buddies could lead to a compromise of your iTunes account later on).

In the end, it is the same as dealing with sensitive paper documents: you can decide to shred what's sensitive only but all it takes for that model to crumble is a single mistake. It's much easier to simply destroy ALL documents securely and not worry about sorting.

Given the relatively low cost and of using connection security and the fact that it wards you against all the above problems (mostly), it makes a lot more sense to encrypt everything that to try to cherry-pick the "right" content to be encrypted.


If DNSSEC is so useful, why is its deployment non-existent for top domains?

It is actually unclear whether DNSSEC is "what we want".

Right now, the certification of Web site, i.e. how a Web browser makes sure that it talks to the right site (when doing HTTPS) is done with digital certificates emitted from about a hundred of Root Certification Authorities. The root CA are entities who decided to go into the certificate issuance business, and what makes the hundred-or-so special is that they made a deal with Microsoft/Apple/Mozilla/Google so as to include their public key in the "trusted" store of every browser (or operating system). The deal includes a lot of legalistic gizmos and insurances.

Though often criticized for its opacity, public cost of individual certificates, and a few well-publicized blunders (lookup "Comodo" and "DigiNotar"), the PKI system tends to work, in an economic sense: commercial sites use them, and the CA are very rarely attacked (most attacks are about inducing the gullible user into ignoring the scary warnings that the browser emits when it finds something fishy with the certificates, rather than going to the trouble of subverting an existing CA). There is then relatively little incentive to change things (that is, there are a lot of people who would prefer another system for a variety of reasons, but, ultimately, these things are decided by those who pay for it).

DNSSEC is about taking these root CA out of the loop, and instead give the certification power to the people who maintain the DNS (the mapping from server names to IP addresses), in such a way that the two structures would be bound together: domain name inheritance (with the notion of "sub-domain") would be merged with PKI inheritance (with the notion of "intermediate CA").

It is unclear whether the new tenants would be more competent at the CA business than the previous; as I said, the actual system works already quite well, and certification is not the same craft as mapping names to addresses. It is also unclear whether such concentration of powers is really a good thing. For the big players, it would not change anything: Verisign-the-CA and Verisign-the-registrar are both Verisign.

On the technical side of things, DNSSEC offers easy distribution of certificates (aka "signed bindings of identities to public keys") through the DNS system, but that's not a problem which needed to be solved: right now, any SSL/TLS server happily sends his certificate chain as part of the initial handshake, and it works well.

Thus, given the uncertainties about the goodness of DNSSEC, and the lack of flagrant issues with the existing PKI, it is no wonder that deployment is deemed non-urgent by the big companies. Let's get IPv6 working first.

As indicated by the comments below, DNSSEC has some value as itself for authenticating DNS information, which blocks DNS poisoning. DNS poisoning is the easy way to do a Man-in-the-Middle attack, but it would be wrong to believe that this solves MiTM issues; it just makes things a bit harder for the attacker (e.g. the attacker must use a WiFI-pineapple instead of simply abusing a hole in an existing WiFi hotspot). Getting guarantees about the mapping of a name to a given IP address does not get you far if you cannot know whether a given packet really comes from the IP address which is written in its header.

Either way, it does not provide much added value to the big servers, and that's sufficient to explain their reluctance.

(DNSSEC has military value, though: by preventing DNS poisoning, it helps in defending against big denial-of-service attacks that could be part of some global electronic warfare. I expect DNSSEC to be supported by governments, not by big companies -- but the days or ARPANET are long gone, and the Internet is the territory of private ventures nowadays.)


Why are non-collision-resistant hash functions considered insecure for signing self-generated information

Digital signatures are designed to do three things:

Ensure the integrity of the data that has been signed
Create some degree of non-repudiation by the signer
The purpose you mentioned, which is to authenticate the origin of the message

The biggest issue with hash functions that are susceptible to collisions is that you very quickly lose the first design goal.  If two different messages can have the same signature, then you can't know which are genuine.

So, what's the big deal if I can sign two different messages with the same signature?  You still know they both came from me and can hold me accountable, right?  Well, perhaps.  There are certainly some cases where this can be abused, but we're going to ignore them because they aren't the real issue.   The real issue is where you can craft two messages that will have the same signature and the submit one of them for someone else to sign.

The canonical example here is a x.509 (SSL/TLS) certificate request.  In this case, a poorly designed certificate signing process can be leveraged to induce a Certificate Authority to sign a certificate for one subject or with one set of properties (like an end-entity certificate), only to have the signature collide with the signature for a second certificate also generated by the attackers that would not have been issued for a subject the attackers don't control, or for a CA cert, and that rogue cert can now benefit from the perfectly valid signature associated with first, benign certificate.


As the name implies, Extended Validation certificates require a much more rigorous verification requirements than OV. While you're correct that the CA isn't guaranteeing the legality of the site, they are vouching for (11.1.1.) much more than they would be in the OV case.

  Verify Applicant’s existence and identity, including;

  (A) Verify the Applicant’s legal existence and identity (as more fully set forth in Section 11.2 herein),
  (B) Verify the Applicant’s physical existence (business presence at a physical address), and
  (C) Verify the Applicant’s operational existence (business activity).

  Verify the Applicant is a registered holder, or has control, of the Domain Name(s) to be included in the EV Certificate;
  EV Guidelines, v. 1.6.2 15
  Verify a reliable means of communication with the entity to be named as the Subject in the Certificate;
  Verify the Applicant’s authorization for the EV Certificate, including;

  (A) Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester,
  (B) Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative
  acknowledged and agreed to the Terms of Use; and
  (C) Verify that a Certificate Approver has signed or otherwise approved the EV Certificate Request

While 11.1.1.(1)(C) might seem to be a contradiction with the exclusion for the company's activity, it means that the entity was active at the time of application for the EV certificate, though the CA cannot guarantee that the entity is still currently active.

11.14.3. Specifies that the CA cannot use data older than 13 months to support issuance of certificates, and EV Certificates have a maximum lifetime of 825 days (and as of 1 March 2018 all certificates will have this maximum). Thus, an EV certificate certifies that the entity was active within 13 months of the issue date and it will be trusted for a maximum of ~27 months from that date.

Each of the verifications above is also more rigorous; for example:

  11.2.2 (4) Principal Individual: A Principal Individual associated with the Business Entity MUST be validated in a face-to-face setting.

The description of the requirements for this face-to-face validation goes on for a full page.


ssl handshake failure unable to get local issuer certificate

Some basic reading on TLS / SSL
"SSL" is the old name, I'll call it "TLS" in this post.
You should do some reading to get a basic understanding of how TLS works. Googling "How does the TLS handshake work?" should get you some good articles. We also have an overall primer post (thought it may be longer and more detailed than you want): How does SSL/TLS work?
Here is a curl-specific article about how TLS works: https://curl.haxx.se/docs/sslcerts.html

Why a CA chain?
It's normal for HTTPS certificates to have that structure with a root CA, and issuing CA, and the website cert, for example take a look at the cert for this page:

To answer your 4th question: The point of these certs is so that the server can prove to you that it is who it says it is, therefore the website keeps the private key, and you (the client) can use its public key (aka "certificate") to verify that is the authentic server. Nowhere in there is the client proving its identity to the server (that's usually accomplished by including an API key in the request).

Fixing your error
Remember that TLS is about establishing trust; validation of a server's certificate involves these steps:

Is the End-User cert valid? Who issued it and do I trust them?
Is the Intermediate CA cert valid? Who issued it and do I trust them?
Is the Root CA cert valid? Do I trust it?

So when validating, you "chain" up to the root, and then check your "trust store" (a file on your computer of root CA certs that are "trusted") to see if that root cert is in there. OSes, browsers, etc will all ship with a list of root CA certs that it trusts. in the case of curl, that's a file on disk called curl-ca-bundle.crt.
My guess is that the root CA you're dealing with is not in curl's default list, so you need to add it manually. In the curl article I linked to above, they explain how to do this in Step 4.
Good luck, and welcome to the world of TLS and certificates!


What should I be aware of when opening my home server to the internet?

First things first, assume that your server will be under attack as soon as you put it online.  Operate under that assumption and you'll avoid a lot of mistakes that people normally make.

I would start off by putting your server in a DMZ so that in the event that it does get compromised, the attack surface is limited in terms of what it can get to.  If this is not possible, it's not the end of the world but it does help keep things separated.

Next, and probably more importantly, absolutely nothing that does not need to be running should be running.  Turn off all unnecessary features (do you really need a GUI environment?) and block any ports that are not specifically required to function.  I like iptables myself, but the important thing is that something is used.

There are some tools you can use to detect malicious activity, such as scanning, brute-forcing, exploits attempts, etc.  I won't go over each in detail, but here are a few I have used over the years:

tripwire is somewhat outdated but not terribly so
ossec serves a similar role, but is more reactive
snort is very popular, has a lot of rules

More important than any specific tool is that you configure and use it correctly.  Make sure you understand what all the tool covers, what it doesn't, and what happens when it fails.

You can definitely run a home server, and it can be a good learning experience to do so, but you'll want to make sure your system is updated and kept under watch.  Don't neglect to check in on it occasionally just because it seems to be running fine.


Is TrueCrypt still safer than VeraCrypt?

VeraCrypt is a fork of the now abandoned TrueCrypt project. I really wonder where you have found the information that TrueCrypt was safer than VeraCrypt. More exactly, it may have been true in the early times of the fork, if some security patches had been implemented in TrueCrypt before being ported in VeraCrypt. But as TrueCrypt is no longer maintained, while VeraCrypt started from the same code and is actively maintained, I would now trust VeraCrypt more than the good old TrueCrypt.


Can a curl request to an arbitrary url made sufficiently safe?

SSRF could only be mitigated with a (regularly updated) white list of hosts or URL's which are known to be safe, i.e. which don't have any side effects which depend on the source IP and where access to a URL will not cause an abuse report, law suite or similar against your site (for example because someone tries to find hidden pages on a site or making bomb threats).

A black list will help but is is not sufficient.


What does it mean to have a retired CA root certificate?

All of the certificates described on the retired roots page today have 1024-bit RSA keys (except for the one which says 1025) and were self-signed with either md5WithRSAEncryption or sha1WithRSAEncryption.

The most likely interpretation is "we are not self-revoking these roots, certificates which chain to them are not inherently untrustworthy, but you need to make an application decision to trust them; however, we will not issue any further certificates which chain to these roots".


It looks like you're only looking at the file extension.  This is not effective.  For a description of why, and a list of viable protections, please refer to the OWASP article on "Unrestricted File Upload".

Excerpt:  (Some of this may not be directly applicable to your environment, but I'm not editing those out.)

  Using Black-List for Files’ Extensions

  Some web applications still use only a black-list of extensions to
  prevent from uploading a malicious file.

  It is possible to bypass this protection by using some extensions which are executable on the server but are not mentioned in the list.
  (Example: “file.php5”, “file.shtml”, “file.asa”, or “file.cer”)
  Sometimes it is possible to bypass this protection by changing some letters of extension to the capital form (example: “file.aSp” or
  “file.PHp3”).
  Using trailing spaces and/or dots at the end of the filename can sometimes cause bypassing the protection. These spaces and/or dots at
  the end of the filename will be removed when the file wants to be
  saved on the hard disk automatically. The filename can be sent to the
  server by using a local proxy or using a simple script (example:
  “file.asp ... ... . . .. ..”, “file.asp ”, or “file.asp.”).
  A web-server may use the first extension after the first dot (“.”) in the file name or use a specific priority algorithm to detect the
  file extension. Therefore, protection can be bypassed by uploading a
  file with two extensions after the dot character. The first one is
  forbidden, and the second one is permitted (example: “file.php.jpg”).
  In case of using IIS6 (or prior versions), it might be possible to bypass this protection by adding a semi-colon after the forbidden
  extension and before the permitted extension (example:
  “file.asp;.jpg”).
  In case of using IIS6 (or prior versions), it might be possible to bypass this protection by putting an executive file such as ASP with
  another extension in a folder which ends with an executive extension
  such as “.asp” (example: “folder.asp\file.txt”). Besides, it is
  possible to create a directory just by using a file uploader and ADS
  (Alternate Data Stream). In this method, filename should end with
  “::$Index_Allocation” or “:$I30:$Index_Allocation” to create a
  directory instead of a file (example:
  “newfolder.asp::$Index_Allocation” creates “newfolder.asp” as a new
  directory).
  This protection can be completely bypassed by using the e.g. control characters like Null (0x00) after the forbidden extension and
  before the permitted one. In this method, during the saving process
  all the strings after the Null character will be discarded. Putting a
  Null character in the filename can be simply done by using a local
  proxy or by using a script (example: “file.asp%00.jpg”). Besides, it
  would be perfect if the Null character is inserted directly by using
  the Hex view option of a local proxy such as Burpsuite or Webscarab in
  the right place (without using %).
  It is also possible to create a file with a forbidden extension by using NTFS alternate data stream (ADS). In this case, a “:” sign will
  be inserted after the forbidden extension and before the permitted
  one. As a result, an empty file with the forbidden extension will be
  created on the server (example: “file.asp:.jpg”). Attacker can try to
  edit this file later to execute his/her malicious codes. However, an
  empty file is not always good for an attacker. So, there is an
  invented method by the author of this paper in which an attacker can
  upload a non-empty shell file by using the ADS. In this method, a
  forbidden file can be uploaded by using this pattern:
  “file.asp::$data.”.
  In Windows Servers, it is possible to replace the files by using their short-name (8.3). (example: “web.config” can be replaced by
  uploading “web~1.con”)  Sometimes combination of the above can lead to
  bypassing the protections.

  Using White-List for Files’ Extensions

  Many web applications use a white-list to accept the files’
  extensions. Although using white-list is one of the recommendations,
  it is not enough on its own. Without having input validation, there is
  still a chance for an attacker to bypass the protections.
   - the 3rd, 4th, 5th, and 6th methods of last section apply here as well.
   - The list of permitted extensions should be reviewed as it can contain malicious extension as well. For instance, in case of having
  “.shtml” in the list, the application can be vulnerable to SSI
  attacks.


Credit card aggregation based on open standards?

Do you trust the vendors you buy from?  They are all bound by PCI-DSS and the penalties for storing it insecurely can be pretty harsh.  Older versions of Bluetooth had security problems(2.3 and prior), but if they are using current versions, there aren't known security issues, so it is possible to have a trusted pairing.

Is it as strong as having a TPM based system, no, but it also isn't as expensive or complicated to use and it isn't really any less secure than many "stored credit card" options that many consumers still use.  For many, CC transactions are only valid if they made them and disputing invalid transactions is trivially simple, with zero liability, so it simply isn't seen as a risk by many.

Also note that these devices ONLY work on magnetic stripe cards, which are inherently insecure to begin with.  You can't use them with chip based credit cards, so the markets they apply to are already not particularly worried about the security of the card data.

Using a TPM, while nice for us security nuts, is overkill compared to the existing risks in the system for the cards that these devices are designed to work with.  They already provide a comparable or better level of security than the existing system does.  Your cards could be stolen or copied, this system provides a way to know when your card is scanned and to link them all to one device (your phone) which will likely be far quicker to notice if it is stolen.  It uses an optional online backup, but many consumers already do that with vendors.

There is fairly minimal real new security risk introduced by these devices provided they are using a recent, secure version of bluetooth and particularly if they protect the credit card details with a key stored on the card itself (so that malware on the phone can't get access).


Lots of 'unidentified exploits' detected with w3af

Not sure what you're finding because your question lacks detail, but it looks like you have the audit.generic plugin enabled and you're actually seeing something like: "Possible unidentified vulnerability" or "Unidentified vulnerability".

If this is the case, what w3af is telling you is that you should look into those HTTP requests and responses because they might be potential vulnerabilities.

If you don't want to see these potential vulnerabilities anymore, simply disable audit.generic plugin. On the other side, if you're interested in knowing where they come from, please read the source code at "plugins/audit/generic.py"; but to sum up:

w3af sends 'd\'kc"z\'gj\'\"*5(((;-*`)' and an empty string to each input parameter
w3af sends something "normal" to the same parameter
If the HTTP response for those requests if very different, flag them as a potential vulnerability

PS: I wrote w3af.


Where can I find vendor neutral info and best practices on MFA using mobile?

You may want to try reading the SANS Reading Room white papers related to such topic. Many authors list different tools that focus on the objective.


What is a current best practice example of basic encryption and decryption in PHP?

I don't think there is any one line function or method for encryption and decryption.
You can try this, its pretty easy

https://github.com/CoreProc/crypto-guard

Sample:

<?php

require 'vendor/autoload.php';

use Coreproc\CryptoGuard\CryptoGuard;

// This passphrase should be consistent and will be used as your key to encrypt/decrypt
// your string

$passphrase = 'whatever-you-want';

// Instantiate the CryptoGuard class

$cryptoGuard = new CryptoGuard($passphrase);

$stringToEncrypt = 'test';

// This will spit out the encrypted text

$encryptedText = $cryptoGuard->encrypt($stringToEncrypt);

// This should give you back the string you encrypted

echo $cryptoGuard->decrypt($encryptedText);


Where to find or purchase non-SSL certificates

A certificate is basically a binding between an identity and a public key, but there are details:

The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...).
The lifecycle of the private key matters: who generates it, where it is stored, whether there are backups...
The certificate contents may activate or deactivate some usages, and you may want some control over that.

If you want to produce your own certificate, then you want to operate your own Certification Authority. There is nice opensource software for that (e.g. EJBCA). However, this course of action entails two main cost areas:

You have to operate the CA. PKI is 5% technology, 95% procedures; having the software is fine, but running it, managing physical access, renewals, audit... will be what costs the most, by far.
Certificates from your CA will be accepted by your machines only if the public key of your CA is installed in these machines as a root CA, or if your CA has been issued by another CA which is installed in your machines as a root.

Using certificates from a "commercial CA" solves the second point, but at a heavy cost. In particular, if you want to have your own CA, then it must be marked as a "CA certificate" (that's written in the Basic Constraints certificate extension). A commercial CA may accept to issue to you a CA certificate, signed by their own, but it will be expensive (think thousands of dollars, at least); and they will require that you operate your own CA within strict rules (including insurance, publication of a detailed and legally binding Certification Practice Statement, and so on).

If you just want to produce certificates for your own usages, on systems that you control, then it makes relatively little sense to rely on a commercial CA: it is much easier to simply have your own root, and install it in all relevant machines.

It is also quite possible that your problem at hand does not actually call for true "certificates". Certificates are a solution to a key distribution problem: the point of certificates is that a given system can gain knowledge a public key, and confidence in the identity of the key owner, dynamically, by virtue of seeing and validating a certificate. If, in your system, there are 8 keys altogether and you have control over all client and server, then chances are that you do not really need certificates; you just want asymmetric key pairs. Public keys are published a priori (pushed through configuration or hardcoded in relevant software).

For easy and cheap compatibility with existing protocols (e.g. SSL), it may be convenient to encode the public keys as something which looks like "certificates"; traditionally, these certificates will be "self-signed" because there is a non-optional field for a signature in the certificate format.

There is nothing intrinsically wrong with self-signed certificates if they map to your problem at hand. There is no need to invoke a PKI if your situation does not have a key distribution issue.


What's the weakness of keyed-MD5 for message authentication?

The "keyed MD5" described in RFC 1828 can be summarized as follows: for key K and data D, the MAC value is MD5(K||D||K) (in the RFC, K is first padded to a length multiple of 512 bits, but it does not substantially change things here). To my knowledge, there is no known weakness to that construction, but there is not much security analysis either.

HMAC has been designed to provide security when used with a hash function that relies on the Merkle–Damgård construction. It has been proven that IF the inner "compression function" of the hash function acts like a pseudorandom function family, then HMAC is secure. We do not know of any similar security proof for the "keyed hash" construction. In that sense, we believe more in the security of HMAC than in the security of the "keyed hash".

If hash functions were "perfect" in a sense that relates to the notion of random oracles, then the keyed hash would be "obviously" secure, like a number of other constructions, e.g. h(K||D). This latter example falls to the length extension attack when the hash function uses the MD construction (which is the case for MD5 but also SHA-1, SHA-256...); this does not directly impact the "keyed hash" from RFC 1828, but is sufficient to demonstrate that MD-based hash functions are not perfect in the sense alluded to above, and thus security of any MAC construction cannot be simply assumed. We need some more details, and with HMAC we have these details.

Some extra notes:

The "length extension attack" does not contradict the classical security of the hash function, namely resistance to preimages, second preimages and collisions. In particular, SHA-256 and SHA-512 are "believed secure" and yet fall under the scope of the length extension attack.
Collisions are not an issue here, and, more generally, are not an issue in constructions that use inputs unknown to the attacker (as is customary for MAC, because of the key). We know how to produce collisions for MD5 very efficiently; but we do not know how to attack HMAC/MD5 or even the "keyed MD5". (It is possible to design a contrived MAC that uses MD5 and is weak because of MD5 collisions, but that's not the case for HMAC nor for the "keyed MD5" we are discussing here.)
Conversely, while collisions do not apply to HMAC, the mere existence of efficient methods to compute MD5 collisions demonstrates that the inner compression function of MD5 is not a PRF, and thus the HMAC security proof does not apply to HMAC/MD5. This is a pity since the whole point of using HMAC and not the "keyed hash" is to benefit from the security proof. Take care to note, though, that lack of security proof does not mean that attacks are possible; only that if an attack is found, then it would not contradict the generic HMAC security proof.


Why is it a bad idea for management to have constant access to every employee's inbox?

So many reasons:

Security Risk
Legal Liability
No Plausible Deniability
Not Scalable
Memory and System Requirements
Unnecessary and Redundant
Unproductive use of his time
There are better ways to monitor employees
Et cetera.

The biggest reason is the security risk. If someone stole his computer, or hacked into it, they would not only get his email, they would get all the email of the entire company, including any trade secrets and confidential information they may contain. Sure, all that information is on the mail server, but the mail server usually has much better security attached to it.

The second is that it is redundant. If he needs access to an employee's email, he can get access to it through IT. He doesn't need it popping up on his computer in real time as well.

And if he is looking at everything, he is focusing on nothing. There is no way he can keep up with emails everyone in the organization sends and received. If he has specific concerns about particular employees, then look at those email accounts. It's more focused and a more productive use of his time.

If he is concerned about certain types of emails, a system can be put into place that flags emails and employees that might need to be reviewed.

Another issue is memory usage. Is his computer actually going to be able to handle 100,000 to 1 million emails in Outlook (or whatever mail client he is using). Probably not.

Besides all of this, such an invasion of people's privacy could cause a hostile working environment, and harm productivity.

Then you have the legal liability. If the CEO gets a copy of every email, and he does not read all of them, and one of the employees does something bad that the CEO does not catch, the CEO could be accused of approving the conduct or casting a blind eye. Instead of the CEO having plausible deniability, prosecutors might accuse him in being complicit in a crime, simply because he did not read every single email the organization sends or receives.

And, this is not scalable either. The more employees he has, the less he will be able to review all the emails. The bigger the organization, the more likely he will be held accountable for an email he didn't have time to read.

There are much better ways to monitor employees than this.

For example, if he really needs that much control over what employees say and don't say, then create a compliance department that spot checks employees, or implement a ticket system which tracks all emails in and out of the system that can be logged into and spot checked from time to time.

Many systems work with email that give advanced functionality, such as:

ticket systems
project management systems
team collaboration systems
etc.

In fact, such a system, that he can log into anytime, might be a much better solution, and give him the access and sense of security he is looking for.

Setting up his computer to access everyone's email account is too risky.


How to harvest plaintext passwords from emails

The problem for you finding an example is that it is not going to be malware. Malware will help gain access to emails, but once you gain access, you just need a simple script to look for keywords. Or, the search function of the email client.

So, you will end up with tools (not malware) like this:

https://github.com/dafthack/MailSniper


MQTT over TLS - ca certificate on client

Lets start with TLS.

Certs to do two things Encrypt a connection and Validate authenticity of both sides of the connection.  All major web browsers have a list of Certificate Authorities included by default (ex Firefox).  These CAs are used to check all certs you generally come accost on the web. Likewise you also have a client side cert in your browser that is unique to you (unique to your session?), however, it is not signed by any type of CA and thus you have no way of proving to the HTTPS server that you are who you say you are.

It is possible to Verify the Identity of both sides of the TLS connection.  In order to do this a HTTPS server has to be configured with a list of client side certs to trust ... or a "Root" cert that all client side certs are signed with (think internal network https for a company).

Node.js is based on chrome and like chrome it uses a list of Certificate Authorities ref ... from a brief skim of my google search this list is configurable within node.js itself.

When I have configured MQTT for TLS in the past I have always done self signed certs for encryption not caring too much about verification of identity ... I would assume that you can configure a list of Certificate Authorities or a Root Certificate, but it is a guess at best.


Firefox vs. Chrome extensions: Which are---ceteris paribus---more secure?

Your assumption is incorrect, Firefox addons are not inherently more secure than Chrome extensions (though in terms of security, I attach more value to Firefox's official addon gallery (AMO) than the Chrome Web Store because all addons on AMO are manually reviewed).

Addons in Firefox are trusted by design; they can do anything that is allowed by the Firefox process.
The worst-case scenario for installing a malicious Firefox addon is a re-install of your operating system to clean up the mess.

The Chrome extension APIs are very constrained, because the Chrome browser does not fully trust extensions (unlike Firefox). Chromium extensions can typically not access any resources outside Chrome's sandbox without the user's approval. The worst-case scenario in Chrome is less severe than Firefox' (and also applicable to Firefox): All of your web browsing activities can be considered compromised.

Since most of us increasingly spend more time in the web browser than in native applications (e.g. internet banking, e-mail), it is a stupid act to install extensions that you cannot trust. Considering this view, then Chrome extensions could be more secure because you have to consent to the every newly requested permissions upon installation/update. Firefox has not implemented any addon permission warnings, so when you install a Firefox addon, you should always mentally add a "This addon could access all data on your computer and the websites you visit" warning to the installation dialog.

On the other hand, because Firefox addons are more powerful, they can also integrate security features in a much better way than Chrome extensions. For example, to date it is not possible to create a NoScript equivalent in Chrome because of the limited extension API.

If you want to know more about Chrome's extension security design, I suggest to read:

Barth, Adam, et al. "Protecting Browsers from Extension Vulnerabilities." NDSS. 2010., available at http://www.adambarth.com/papers/2010/barth-felt-saxena-boodman.pdf
The security foundations/design of the Chrome extension platform.
Carlini, Nicholas, Adrienne Porter Felt, and David Wagner. "An Evaluation of the Google Chrome Extension Security Architecture." USENIX Security Symposium. 2012., available at https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final177_0.pdf
An evaluation of the effectiveness of the Chrome extension security architecture.
CRX API Security Checklist
Security checklist for developers of Chrome extension APIs.


What is a good way of embedding rsa encryption into a messaging app

You should obviously generate keys locally at the device. Otherwise, a compromised server could leak every single key.
Further, why use a key-pair per conversation? That means a lot of keys. One of the public key crypto systems is that you have a public and private key. The public key is used for encryption, and private for decryption. Thus one public key per client would be enough.
There's no need to keep the public keys secret. Send them to the other party in the conversation. You obviously need to control the integrity of them.
You should also look into topics such as forward secrecy, and how to achieve this.
In short: don't implement this yourself. You will mess it up. Use an encryption library and established protocols, such as Signal (for instant messaging), PGP or similar. You will avoid a lot of pitfalls by using well-tested algorithms and protocols.


Why is there a list of known WiFi networks in my airodrop-ng output?

This is called "Probe Request" and it is a special frame sent by a client station requesting information from either a specific access point, specified by SSID, or all access points in the area, specified with the broadcast SSID.

You can read more information about this here.

  How/where does it get this list of networks the computer has connected
  to?

It's a list with all known networks your device has successfully connected and marked as "Auto-Connect" by your system.

  is this a problem security wise?

Yes, because an attacker could reply to the probe request with a fake AP, created only to sniff your data. It's possible to perform this with a lot of tools, even with your own OS, creating a hotspot with the same name as the network your computer is probing.

I recommend you reading this and taking a look at WifiPhiser.

And no, you cannot disable this, because it's essential to inter-AP roaming.


Find out who has hacked your gmail account

You could do a whois lookup. On linux or OSX it's a command line tool. You can also find websites that provide that functionality.

However, most certainly the attacker just used this IP as a proxy or vpn endpoint to disguise his real ip. I would say it's almost certain that this is rather another victim's IP than the one of the attacker unless he's a complete noob.

So i would advise you to be careful with that IP. You might contact the abuse email address that is usually provided within the whois lookup and advise them that you are being attacked by this IP. They may inform the owner of that IP or the may just not respond at all, as this is often the case in my experience.

hth


What should I consider as a security opt-in?

I would provide a user-side configuration option to control what to do, with three possible settings:

Check only if a signature field is present.  This option should be the default, and lets the user defer to the publisher as to whether or not to check the signature if present.
Always check, and issue an error if there is no signature field. This option is for those users who want (or need) to ensure code integrity, and don't trust the publisher to require it.
Never check.  This option is mostly for developers or internal usage, and should probably have a big warning on it.

Most users will leave things at the default, and therefore will get checking if the update provides a signature, and none if it doesn't, while those who need to force enable or disable checking can do so.

You might additionally consider providing something equivalent to the Strict-Transport-Security header in HTTP.  Essentially, if some flag is set in an update that's been signed, future updates for that same piece of data must also be signed or they won't be accepted, even if they don't have a valid signature field.


Key pairs are generated in a number of ways, but I am going to refer to the specific example of OpenSSL, which is a very popular and easy way of creating RSA keys for many uses.

The command for creating a key used to be[1]

openssl genrsa -cipher_name -out file_name_in_pem_format key_length

Where cipher_name can be a number of symmetric encryption methods like AES, Camellia, Des3 or IDEA.

genrsa has actually been superseded by genpkey, but the same cipher options remain.

This actually answers your follow-up question. Yes, the ciphers are symmetrical so that a single password can encrypt/decrypt the key.

Finally, yes, the password is a security measure in case your private keys fall into the wrong hands. The bad guys would have to crack one more password before being able to impersonate you or your server. It might just buy you enough time to revoke the keys.

[1] https://www.openssl.org/docs/HOWTO/keys.txt


How dangerous are SWEET32 and LUCKY13 vulnerabilities?

Lucky13 and Sweet32 are both attacks on SSL/TLS, i.e. these attacks can be used to intercept the encrypted connection between the client and the server.  In the case of a server that is vulnerably to Lucky13, an active attacker may be able to launch a MITM attack by exploiting this vulnerability.  The same applies to Sweet32, but even a passive attacker may be able to decrypt the encrypted data if they are able to collect enough data.  However, neither attack can be used to gain access to the server.


What exactly does `ssh -T user@domain verify` do?

Disable pseudo-terminal allocation

This means that the command verify is run directly on the other side and the standard input/output/error are connected directly to your local terminal.

For commands, there is usually no difference, but it is difference if you want to run interactive scripts (shell). In that point, your output would not be handled by remote terminal, but with your own and the output would not be so pretty. You can try with ssh -T other_host, where you have terminal access (you don't have on github). On github, it is also one of the resources-saving task, since TTY allocation is "not for free" if you have 31 million users (October 2018).


Is a lockscreen a deterrent to a USB Rubber Ducky style of attack?

Yes, you understand it correctly. USB Rubber Ducky cannot bypass the login screen or the lock screen (in a way other than providing the correct password).

It can contain payload brute-forcing the password for the user, but it cannot bypass it otherwise.


Should I expose HTTP status code 500 on a REST application?

An error 500 indicates that the server had an internal error. It normally means one of two possibilities:

either a component is down - ok, the error will disappear as soon as it is up again
or an exceptional condition is not correctly processed by the application

The occurence of an error 500 should always be followed by an action: if a component was down, it must be repaired or restarted, and if an exceptional condition was not filtered, the application needs a fix.

A problem occurs with applications that do not process exceptional conditions, and are poorly supervised and maintained. If an attacker sees an error 500 that consistently happens in certain requests, it is an indication that the application could not process it, and did not process the error condition either. Maybe a slight variation could make bad things happen...

But simply replacing the 500 code with say a 400 is not a true solution: it only hides the real problem. If I was doing a black box penetration test (with no access to code), I just would not rely on the value of the error code and try all known weaknesses, so hiding an internal 500 with a 400 would not protect the application. And I really believe that serious hackers will think the same...

In a professional world, the 500 errors should be analyzed, and when caused by an non processed exceptional condition, a ticket should be filled to the developper team. For an internal application, an error 500 should mean (explicitely or implicitely) this is an unexpected error, please contact support


openVAS: uninitialized constant OpenVASOMP::OMPConnectionError

So the answer for this is to reinstall the whole configuration and start over again due to missing dependencies:

root@kali:~# apt-get --purge autoremove openvas
root@kali:~# apt-get update
root@kali:~# apt-get dist-upgrade

root@kali:~# apt-get install openvas
root@kali:~# openvas-setup

Once openvas-setup completes its installation process, make sure that OpenVAS manager, scanner, and redis-server services should be running.

root@kali:~# /etc/init.d/openvas-manager status
root@kali:~# /etc/init.d/openvas-scanner status
root@kali:~# /etc/init.d/redis-server status

Then you can simply start all the necessary services by running openvas-start. Then run your browser to https://127.0.0.1:9392, and accept the self signed SSL certificate and plugin the credentials for the admin user


How can I obliterate information on a defunct device, and should I?

Degaussing only works for magnetic media, not solid state.
Bashing everything to bits with a large hammer is probably the most practical. True, some of the tiny memory modules could in theory survive sufficiently intact to be reconstructed, but unless you're concern is high end Law Enforcement or a Nation-State that's pretty unlikely.
If you're still concerned, you could also Microwave the pieces but this would be a significant risk of unexpected fire. It would be safer simply to burn it.
If you burn it, be careful of toxic fumes.
A handy wood chipper would be useful.


pros and cons of a bootable BackTrack instance vs installed

Generally depends what you are doing.

If you are planning on learning first, on a legal enviorment, I would recommend to install backtrack (dual boot, usb or virtually).

installing it:

Runs Faster
No need to do a large update over & over.
Allows you to add your own tools, and save files.
Allows you to save preferences.

At this point it seems that installed backtrack is the best option, but live backtrack gives you something that the installed backtrack dosn't.
It will always be in a clean state.

Just the fact that it is in a clean state, might be more important than all of the other points for a pen-tester, esepcially for a black hat. That is why another option is customizing the the live version.

It all boils down to what exactly are you looking for (as well what you prefer)? Learning -> Installed, Work -> Installed/Modified Live, Black-Hat Pen-Test -> Live/Modified Live.

Further explanation:

Backtrack is built on ubuntu, updates  are done the same way.

sudo apt-get update & upgrade

If you install it or use live cd you will have to update it, but
take in account that with the live cd you will need to do a large
update that may take from 15-25min, instead of small updates from
the installed OS.
Running backtrack from harddrive/ssd is faster, than accessing the
OS from a externall usb/cd. In my case performance difference has
been minimum.
If you build your own tools, or have found some tools that are not
included with Backtrack 5 can be added to the installed OS, if you
use the live version you will have to reinstall them.
When you boot into backtrack, your user is root and the password is
toor. You also have to start network by running

  $ /etc/init.d/networking start

Some want their own password, wallpaper, have no need for stealthy
boot, and so on. So they modify it on their installed OS.