Observable password inputs An obvious problem with passwords is that if an observer sees a user enter it, then the user has lost the password secrecy. Some systems try to defend against this with dark screens or with shields around button inputs.

I was wondering if there are any implementations or research into "complete knowledge" password systems. In other words, an observer can observe and record all the things observable to the user, such as screen and keyboard and sounds, and still not be able to enter a valid password.

For example, the screen could display X, and the user could mentally compute Y = f(X), and input Y. F is a function known only to the user; it could be a number of things like word games or graphical transforms or mathematical or a combination of all of them.

A few problems I see with this: if f is too complex, the user won't be remember or compute it. If it is too simple, the observer will be able to guess it. Also, it seems like a lot more work than physically obscuring the view.

Still I wonder if anyone does research into this subject, and if there is any terminology for it. Thanks~

PS I apologize if this question has been asked before, I'm not sure what the common terms are for this subject to search for.  Also, I have migrated this question from the UX stackexchange, from https://ux.stackexchange.com/q/89185/78288

I don't recall hearing about a proposed authentication scheme where the user has to compute, essentially, a one-time password in their head.  I agree with you that most users would probably not be accepting of such a system, especially if it were designed with enough security to resist being easily reverse engineered by an attacker that can observe the challenge prompts and responses.  Here's one paper that proposes a slightly different system for entering PINs: How to Fend Off Shoulder Surfers.

You also mention graphical passwords, and I do know that there has been sustained work in this area to combat 'shoulder surfing'.  But I believe even they don't claim to be impervious to attackers who have prolonged observation capabilities, just more resistant than other authentication systems.  I can point you to a few related papers if you care to delve further into the subject:

You Only Live Twice or "The Years We Wasted Caring About Shoulder-Surfing"
Shoulder Surfing Defence for Recall-Based Graphical Passwords
Shoulder-Surfing Resistance with Eye-Gaze Entry in Cued-Recall Graphical Passwords
A Comparison of Perceived and Real Shoulder-Surfing Risks Between Alphanumeric and Graphical Passwords

For situations where all visual and audio data are susceptible to observation we typically rely on an authentication system where there is no observable data leaked.  This can be something like RFID cards, smart cards, certain types of biometrics, etc.  When these options aren't available, or are combined with knowledge like an ATM PIN, we typically try to implement the controls you mentioned to reduce the possibility of illicit observation.


OWASP: Insufficient Logging & Monitoring - open source tools Being new to the security and logging and after reading a lot about the terms used, I am pretty sure I neither need an IDS/IPS nor a WAF.

I am mostly interested in automating the "monitoring" of my application logs and enforcing some things whem certain events under certain conditions take place. Is there any open source tool that can help with this kind of detection and automation (some powerful rules/condition engine with alerting to call a script or http point) or should I build it on top of the logging management platform?

Maybe this thing I am describing is called SIEM but I am not sure, or it is already doable using ELK or Graylog etc.

Thanks

Graylog allows you to define alert triggers/Conditions and Actions/Notifications.

Out of the box it can do an HTTP POST to a nominated URL. I am not sure if parameterisation is available, but this might be enough to do what you need. The graylog marketplace (https://marketplace.graylog.org/) will have some more options which may allow more complex actions - so something may already be available.*

*(Depending on how much hair you have on your chest you can develop your own alert/notification plugin)

I am 99% sure ELK would offer this and even more than Graylog. My ELK experience is limited, but I suspect that Graylog is closest to the Logstash service in the ELK stack. Both use Elasticsearch, but Kibana provides a lot of features not really available in Graylog.

SIEM may also be able to do this, but SIEM's include a lot of pre-defined rule-sets to track anomalies across various sources and correlate and automatically raise security alerts. They generally allow extension of existing rule-sets and/or creating your own. They are almost always goliath systems with a strong learning curve. From what you're saying it seems like overkill.

If you go with SIEM or Centralised Logging - these things need a lot of "juice" (CPU, RAM and IO). If you simply want to deploy application logging, monitoring and alerting, Graylog would likely be the best option. Grab the OVA from the graylog site and have a play, move on to ELK if Graylog falls short and then look at the SIEM options.


Why has the NSA had a hand in deciding on encryption standards? The NSA has had a large hand in the design of at least two significant encryption standards: the Digital Encryption Standard, and its successor, the Advanced Encryption Standard.

Because of their involvement, there is much speculation of backdoors. Setting aside our tinfoil hats for a moment, have there been any official statements by the NSA or other involved organizations as to why the NSA have had a part in the encryption standards?

Why it is in their interest to support the encryption of data? Especially when the usage of the encryption standards can't be enforced; the algorithms can be (and are) used by countries and corporations outside of the United States.

The NSA is a composite organization, that comprises several sub-entities called "directorates" with various scopes and goals. The NSA, as a whole, is supposed to have a multitude of roles; its signal intelligence role (often abbreviated as SIGINT, i.e. spying) is the one most people talk about, and is supposed to be handled by the SID (as "Signal Intelligence Directorate"). However, NSA is also supposed to ensure the information safety of US interests, and as such should help federal organizations and also big US private companies apply proper encryption, where encryption is needed. This defensive role falls largely within the scope of the IAD (Information Assurance Directorate).

It is true that within the NSA, the balance of power substantially shifted towards SID after September 2001, but they still maintain a non-negligible defensive role. In any case, both DES and AES were standardized before that date.

In the USA, federal standards are edited and published by a specific agency called NIST. NIST is not the NSA. However, when the NIST people deal with some cryptographic algorithms, they like to get inputs from the NSA because that's where the US government keeps its crypto-aware thinkers. The NSA itself likes to be consulted by NIST because they want to keep track of published cryptographic algorithms, both for attacking and defending (they want to know what algorithms they will be faced with when trying to eavesdrop, and they also want to know what algorithms they should advise big US companies to use to thwart foreign evildoers).

On that subject, you may want to read this article which is about elliptic curves and "post-quantum crypto", and what the NSA says and thinks about it. It highlights that NSA is, first and foremost, a big governmental organization, and thus tends to behave like big governmental organizations do; in particular, some or even most of its actions are related to its own internal politics.

There is quite a gap between "being involved" and "having a part". According to Don Coppersmith (one of the DES designers), the NSA, at some point, interacted with the IBM team, under the avowed goal to strengthen the algorithm. The NSA, at that time, still employed a substantial proportion of available cryptographers (this is no longer true), and had some knowledge of an as yet unpublished attack method, namely differential cryptanalysis. The NSA wanted to make sure that the new algorithm would resist such attacks. It turned out that the IBM team had also conceived the idea of differential cryptanalysis, and had already strengthened their design against it. So the NSA involvement reduced to asking the IBM researchers not to publish their findings.

(As Leibniz would have put it, scientific discoveries are floating in the air, and when you have a new idea, chances are that several other people have the same idea at the same time. It is thus pretty hard to keep ahead of the rest of the World in scientific areas.)

For the AES standardization process, NIST deliberately organized the whole competition as being very open; submitters were encouraged and even requested to publish all design criteria of their candidates. While one cannot logically preclude the possibility of bribery to inject a backdoor in one candidate, because it is very hard to prove a negative (that's the point about conspiracy theories: they cannot be rationally denied because they are beyond logic), most candidates, including the one finally chosen (Rijndael), had all their design elements fully explained, with no undisclosed dark area. Thus, NSA input in that matter was mostly a statement that they found nothing wrong with any candidate.

(Cryptographers are also human beings and, as such, may occasionally indulge in gossip. At that time, the gut feeling of most of them was that if there was an NSA-sponsored candidate, then it was MARS, mostly because that was Don Coppersmith and IBM again. In any case, that algorithm was not very popular because it was overly complex and hard to fathom. Rijndael's structure was a lot more simpler.)


What are the risks of not patching a workstation OS for Meltdown? Assume the following:

macOS (but not sure that matters that much)
workstation, mostly gets new executables from the app store or open source repos through macports homebrew
fair bit of loading JS, Python and Ruby scripts, again from repos.  (the Python and JS repos are NOT very well vetted but neither are they very good candidates for low-level hacks from this vuln as far as I understand)
assuming also online Javascript can't be leveraged to exploit this.
6 yr old CPU, so assuming on the higher end of the KPTI workaround loss of 30% and no vendor warranty.

I totally get that being able to bypass the ASLR and the like is bad news.  And maybe a privilege escalation if a rogue program is capable of escalating itself.

But...

If I am careful downloading programs from mostly trusted sources

Can I avoid taking that 30% hit, by not patching, at not too great a risk?  If I have a rogue malware running on my system, that's already most of the security gone, regardless of this particular vuln.

Things would look very different from the POV of a cloud service provider who by definition runs all sorts of unknown programs. Or to someone running arbitrary code in VMs and relying on their protection.

I also realize that, once the OS vendor patches this, then I will have to patch Meltdown anyway to access future vendor patches, so reasoning on the basis of solely Meltdown is short-sighted.

Which means I suspect the answer will be No, you'll have to patch sooner or later.

No, you'll have to patch sooner or later.

More seriously, for a workstation-style machine, Meltdown is mostly a concern in the case of malware or existing compromise.  (In that it will allow reading kernel memory and consequent privilege escalation.)  The media have made a lot of noise about Meltdown (somewhat rightly so: for hosting companies, virtual machine hosting, etc., it's quite a big deal) but your average user is unlikely to be affected by meltdown on their workstation.

That being said -- you're unlikely to see a 30% hit.  Most benchmarks of typical workloads show more like a few percentage.  As you point out, you'll either have to never get any more updates or eventually accept the performance hit.  (Unless OS X adds a flag like the Linux kernel has to turn KPTI off.)


How to secure wireless (Wi-Fi) home network What are the countermeasures to make home wireless network secure, which will both prevent others from stealing internet and will also prevent hackers from taking control of computers through your own wireless network.

1) Set a strong password.

Yeah, this may seem common knowledge, but I actually stick with something unique, alphanumeric, and not the default router password.

2) Hope that whoever wants into your network doesn't have something like Aircrack-ng.

Aircrack is a network software suite consisting of a detector, packet sniffer, WPA/WPA-2-PSK and WEP cracker and analysis tool for 802.11 wireless LANs.

I've had friends in college that got good with this software, and you can get access to pretty much anyone's Wi-Fi network. All you need is to sniff the right packets (i.e. the password) and you're good to go.

4) Restart your router & change your password regularly.

Just restarting your router can terminate sessions from un-authorized users, then if you are paranoid, just go into the router and change the password. Doing this every 90 days or so is just healthy, much like your PC or any other device.

5) Limit physical access to your router / APs.

If you have physical access to an AP or router, it can be easier to get into your network. So goes the phrase - if I can touch it, it's mine. Keep it behind a lock and key if you can. I can't tell you how many times I have gone to a Wi-Fi AP and the password (key) is printed on a label on the bottom. (NOTE: you don't need to worry about this if you change the default password.)

6) Change your router's Administrator password.

Once you are in your router (via browser - normally 192.168.0.1) you need to change the default password for admin access. This will keep others on your network out of your router, and can ensure that you remain in control of your network. Keep this password unique from the other password(s) on your network, and change it every once in a while - if you want.

7) Realize that no network (even more so a WLAN) can be secure.

If you are using Wi-Fi, you need to accept the fact that it is far less secure than a wired Ethernet connection, and there is no such thing as a secure network - anywhere.


Why is it important to apply security best practices when the risk they protect against is very low? Sometimes, security best practices protect you against attacks that are very improbable. In these scenarios, how do you defend the implementation of such security measures?

For example, password-protecting access to the BIOS of a thinclient. A BIOS without a password is a risk because an attacker with physical access can change BIOS configuration in order to boot from USB and access the data of the system without authentication. In this case, the attacker needs physical access, the thinclient does not store too much important information, etc. The risk is very low.

Other examples may be related to some measures when you harden systems.

In this case, is it better to not enforce this security measure to be reasonable with the rest of the company or you are opening little holes that will punch you in the face in the future?

The potential impact of this is not low, regardless of how much information the thin client stores.

Specifically the risk is that an attacker installs something like a rootkit or software keylogger in the operating system of the thin client, which you are unlikely to be able to discover by inspection. (This is a variant of the Evil Maid attack).

Should any administrator ever use that client in the future, it will be game over for the network. The thin client can also be used as a beachhead to launch further attacks against the network, or to conduct reconnaisance.

Protecting the BIOS prevents this from happening, by protecting the integrity of the thin client OS.

The wider lesson here: Best practice saves you the expense and difficulty of assessing every risk, which as this question demonstrates, is hard to do.


Is it possible to browse/access the files on a computer's hard drive by booting from an OS installed in a flash drive? I have installed Tails in an USB flashdrive and then booted my macbook with it. I noticed that Tails was capable of seeing my macbook's hard drive. Out of curiosity I tried to browse it.

Interestingly, I was capable to entering /Users/myName and access all files within. Except for a handful of folders: Desktop and Documents. Tails prompted me saying that I didn't have permission for that.

Makes sense: I could very well be a random stranger trying to steal the files out of this computer. But it got me thinking: what exactly is stopping me from accessing such files?

As far as I am concerned, the Desktop and Documents folders or any other file in my macbook's hard drive are not encrypted in any way. I'm no expert, but I doubt there is any sort of encryption protecting such files.

So I guess it is Tails itself. Is Tails deliberately thinking "oh boy this guy could be a random stranger, I better stop him", or is Tails actually trying to access such files but something is stopping it? If that is the case, what is it?

Naturally, the above bears the next question: is it possible to browse/access the files on a computer's hard drive by booting from an OS installed in a flash drive, such as Tails, effectively bypassing any sort of authentication?

In general, yes, booting from a flash drive gives you access to anything that's not encrypted.

In this specific case, Tails itself is stopping you. It's voluntarily respecting the permissions declared by the filesystem on the hard disk. This isn't intended to prevent you accessing private files though - it's simply a side effect of the fact that Tails, for security reasons, doesn't give you root access by default. You can lift this restriction by setting an administration password in the Tails startup dialog, then you should be able to access those files as root.


Is IP whitelisting safe enough for a HTTP Basic protected service available on the internet? We are discussing about making available through the internet one of our microservices deployed on a public cloud on Kubernetes. This ms offers some sensitive information to the clients.

This microservices will be protected by HTTP Basic security and be exposed with TLS.

In addition we intend to add IP whitelisting to limit the range of IPs that can access it, so only our corporate network computers will be allowed to access it.

Is IP whitelisting safe enough, is it hackeable in some way?

Any recommendation to improve this approach or directly avoid it?

Just some clarifications/assumptions on my part based on your question. You would like to expose a micro-service API running on Kubernetes to the internet. The API in question is running on top of an HTTPS server which allows for TLS encrypted communication. What you want to know is if white listing is sufficient for protecting your API. Let me know if I missed any thing.

My initial answer is no, this is not secure. Or rather, it's not as secure as I think it should be. You have not made any mention of securing the API in anyway other than IP listing. Is this an open API that allows access to sensitive information? How else are you going to establish trust with your remote systems and users? Are you sure that your remote systems will always come from the same IPs? What happens if one of the IPs is compromised?

Going beyond my initial barrage of questions, I think we should look at a couple of key principles that I rely on when trying to design security solutions for companies.

First, I never trust the network unless I absolutely have to. Any chance I can implement a solution that performs verification, I do that. Whitelisted IPs do not pass this measure because an IP address is not a form of identity. IPv6 does have some capability to perform identity through an address, but it's not widely adopted and I don't think the standards are mature enough yet.

Second, identity is the biggest factor to your security. An attacker can come from anywhere, and in some industries the biggest risk for attack is actually from within your own company. Healthcare has the largest internal risk with a whipping 65% chance of being compromised from within. You mustknow who had access, when, and whether or not they should have access. You should know the machine they had access with and whether or not it's known. And if you can afford it, having the behavioral history of actions to check the traffic is a major benefit too. All of these identifiers are what will protect your API.

Third, once you have an identity management system in place, you need to ensure that you can properly authorize and audit user access.

Now, if you have all of these things built into your API already, then all the best to you. Overtime, you may find it beneficial to migrate from a white list to a blacklist which allows you to block the trouble makers. You can even automate this with the right types of scripts/automation and reduce the chance of blocking your clients. This will help to reduce your operational burden and reduce the potential impact to your clients, a win win.


Second order SQL injection protection Normal SQL injections are no problem since I always use prepared statements, but how to protect oneself from second order SQL injections?

A second order SQL injection is an injection where the payload is already stored in the database (instead of say being delivered in a GET parameter). In that sense it is somewhat similar to stored XSS (and ordinary "first order" SQL injection would be analogous to reflected XSS).

How does it work? Lets say you let users pick any username. So an attacker could choose the name '; DROP TABLE Users; --. If you naively concatenate this username into your SQL query to retrieve information about that user you have a problem:

sql = "SELECT * FROM Users WHERE UserName = '" + $username + "'";

So, how do you deal with this?

Always use parametrized querires, always, always, always. Treat all variables as untrusted user data even if they originate from the database. Just pretend everything is GET parameters, and behave accordingly by binding them as parameters.

You can also sanitize and limit the input (e.g. only allow alphanumeric usernames) before it is stored in the database as well as after it is retrieved from the database. But I would not rely on that as my only line of defence, so use parametrized queries as well.


What personal data should be encrypted in a database? I am having trouble answering what seems like a simple question. I was hoping to find a Yep/Nope style list somewhere, but can't seem to find one.
What data should be encrypted in a cloud (e.g. AWS/Azure) database?
I have researched ICO as well as Stack Exchange Posts, but can't find a direct answer.
Obviously passwords should be hashed and bank card details encrypted, but what about information such as the following?

Name

Address

Telephone Number

Passport Number

National ID

Bank Account Number

These details are sensitive, but do they need encrypting?

There is no definitive list of PII that should be encrypted.
Encryption is a security control that mitigates risk. There are many other controls than can achieve the same result.
So, you need to perform a risk assessment to determine what stakeholders require, what regulatory/legal obligations you have and what risks you face that could be mitigated with encryption.
Encryption is often a Good Idea™, but regulations tend not to specify it because encryption is not a "tick the box" exercise and the regulations don't want to get into the technical details of how to do it correctly. They just specify an outcome they expect.
So, to answer your question, the data that should be encrypted is the data that you have determined should be encrypted.


Can a computer get infected with malware by viewing a PDF online? Is it possible for a computer to be infected by viewing the link to a PDF file without downloading it?
For example, if I opened a link on a website such as www.wordpress.com/somepdfFile.pdf (not a real site), are there current malware that can infect my computer just from viewing the link?.
John Doe owns a website, www.doejohn.com. He decides to share a pdf document with his subscribers. He, however, doesn't know the pdf contains a malicious payload. The pdf can be found at www.doejohn.com/file123.pdf.
Jane Doe navigates the link above and views the file WITHOUT downloading it. Does the malicious payload infect Jane's computer or not?

Obviously if you are viewing the PDF in your browser, you could get attacked.  Browsers are imperfect, and the PDF format is filled with vulnerabilities (that continue to be found.)

However, it's very highly unlikely that simply viewing a page with a link to a malware file would cause an infection, but we can't definitively say no.  Historic attacks have stepped along paths that once upon a time could have led to infection, but those were ancient exploits that happened back in the early 2000s.  Browser and OS security have improved greatly since then.

For performance reasons, some browsers performed prefetching of links, with the idea that while you were looking at page A, you will probably click to page B.  The browser would therefore download the pages to your cache, even if you didn't click the link.  (Note the referenced page is from 2003.)

There are also exploits that have taken advantage of disk indexing.  When a file lands on your file system, the indexer would scan it and add the data to your computer's search database.  Different types of files have been susceptible to these attacks, including JPG and TTF.

Theoretically, a browser could prefetch a malware file, and then infect you while the filesystem indexes it.

However, I don't know of any browsers that are still doing prefetching; most pages have hundreds of links, and a browser would have no way of knowing which links you might click on.  Furthermore, most indexing systems have been reworked so they aren't as vulnerable as they once were.

It's not a vector that you should lose sleep worrying about.


Ids/ips configuration audit Is anyone familiar with a tool that can audit the configuration of an intrusion detection/ intrusion prevention tool? I'm looking for a tool that can check for best practices, and non standard configurations.  I have googled just about everything and I only come up with white papers.

Does it work? IPS and IDS are very specific configurations. Plus, the general behavior of each provider is different. Some fail-open, some fail-closed and some just fail.

The best way to audit is to:

Identify what assets/resources are being protected by the ((IP|ID)S).
Document the current configurations. (You need to know exactly what polices are being applied to each protected asset/resource). Literally, map asset/resources to policy.
Determine what tools and test need to be run against the assets/resources.
Run the sets and interpret the results.
Tune the device as needed.
Realize that you will get false(neg|positive)results.
Realize that the application is the right place to fix vulnerabilities.
Repeat 3-7 until confidence rating is high or completely shot.
If confidence rating is completely shot or you don't want to have all this weight on your shoulders and massive ramp up, get experts on the problem.


IMEI.info knows my phone before I put sim Recently I brought a Moto G3 turbo phone, which I suspect is a factory reset by a seller from other customer, and dispatched to me.

I search net for getting in if its factory reset, but non tricks worked,
eg: ##786#, ##786#8#* for getting refurbished information as mentioned in this answer

I want to know, how does www.IMEI.info knows my IMEI number even though I have not put any sim in phone yet, I must add I am connected to wifi.

So how does www.IMEI.info works, or is my phone used previously.

Have a look at the IMEI article on Wikipedia and you will find out that the IMEI:

  ... includes information on the origin, model, and serial number of the device.

So no there is magic there and it has nothing to do if the device is resold are not, because the information are all contained in the IMEI itself. The IMEI is generated by the manufacturer  of the device and relates to the hardware. It does not depend on registering the device, carrier, selling, phone number, SIM card or similar.


How to securely store API keys I need to store API keys for my users. These keys are extremely valuable as they are used to buy and sell things. Some users won't want to give  these keys to anyone, and I'm trying to figure out a better solution than simply storing them in a database.

It would be nice to some keep control of the key with the user. I consider making an open source script that they can deploy on a server and my app call or similar.

Somone suggested it might be possible to configure a proxy to do something without any code, but this is all beyond my expertise.

Does anyone have any other ideas?

edit: for further clarification

My system is a web app. Each user gives my system their api key, which allows the web app to trade on their behalf (buy and sell things). The essence of the system is that under certain automated circumstances the system will want to trade on the user's behalf.

I am considering a manual intervention with 2FA, which will likely be strong enough in my opinion, but is sub-optimal in that the user won't be able to react fast enough all of the time.

I consider creating some light-weight, open source, partner code that the user can deploy on their own server somewhere. The idea being that it can be independently verified as un-malicious and the user can store the keys themself.

I'm not sure if anything is gained by that approach besides a hacker having to find out the location of script, and even then if my server is compromised they can simply send trades using my system to this script in the same way as if everything was on my server.

I guess the idea of a proxy server would be something like the above, but something at a lower level than an app running on the server. I'm afraid I don't have enough server admin knowledge to speculate on how that might work.

Great question, and one that comes up frequently (though always with different nuances, so there's no good general answer). A quick search found some related questions:

Is it possible to automate use of passphrase-encrypted private keys?
automated decryption
How do automated systems store their keys securely?

In general, you need to decide which use-category your keys fall into, which will tell you what options you have available:

1. Manual access

By this I mean that they key is only needed when there is a human at the keyboard. This scenario is fairly easy to solve: for example you could encrypt the key with a user-entered password. You still need to think about enforcing strong passwords mitigating brute-force attacks, but it's fairly standard; see how SSH password-protects ssh keys to get inspiration.

2. Automated access

If the sensitive keys need to be stored in such a way that they can be used by an automated process with no human at the keyboard, then you're looking at a very difficult problem because of the conflicting requirements that the machine should have access, but an attacker who compromises the machine should not have access.

The standard solutions to this problem include:

Attaching a USB smart-card to the server or issuing one to each user.
Storing the keys server-side in a secure vault that will use the keys on the user's behalf, and requires users to authenticate using strong two-factor auth.
If applicable, Hardware Security Modules.

Clearly the applicable solution depends a lot on the architecture of your environment.


What do I need to configure, to make sure my software uses /dev/urandom? When setting up a server, what configuration changes do I need to make sure that all of the software uses /dev/urandom instead of /dev/random?

Some servers don't have much entropy in the entropy pool (e.g., VPSs).  If a software component uses /dev/random, then it may block and cause the server to become mysteriously slower.  Is there any software that comes out-of-the-box using /dev/random by default?  If so, how can I configure it to force it to use /dev/urandom?  It'd be nice to have a checklist of configuration settings to set, when setting up a new VPS environment.

General advice

Any program written in Java

Add

-Djava.security.egd=file:///dev/urandom switch

or

-Djava.security.egd=file:/dev/./urandom

to the command line invocation used to start the Java process.  (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.)

Alternatively, in the $JAVA_HOME/jre/lib/security/java.security configuration file, add the line

securerandom.source=file:/dev/./urandom

Footnote: In the above examples, you need the crazy-looking filename, e.g., the extra /./, to trick Java into accepting your filename.  If you just use /dev/urandom, Java decides you didn't really mean it and replaces what you wrote with /dev/random.  Craziness!

Chroot

If you are starting some service in a chroot environment, don't forget to create the /dev/urandom device inside your chroot directory.

Specific software

Apache mod_ssl

Use

SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512

in the mod_ssl configuration file.  Avoid using file:/dev/random with SSLRandomSeed.

Cyrus POP3, IMAPD, and SASL

Compile Cyrus SASL (libsasl) with the configuration flag  --with-devrandom=/dev/urandom.

By default, Cyrus POP3 reads from /dev/random.  I couldn't find any configuration setting to change this, short of recompiling.

OpenLDAP

Add

TLSRandFile /dev/urandom

to the slapd.conf configuration file.  (This hopefully should be the default, but some guides misleadingly suggest using /dev/random, so you might want to double-check.)

Postfix

Use

tls_random_source = dev:/dev/urandom

in the main.cf configuration file, or

sudo postconf -e 'tls_random_source = dev:/dev/urandom'

from the command line.


How authentication tag is calculated in AES-GCM-256 I have a sample code,which encrypt and decrypt a string using AES-GCM-256.

I am unable to understand,how authentication tag is being generated on encrypter side and how is that being used on decrypter side.

Actually here i am not generating authentication tag either on encrypter side nor validating decrypter side,so is it being done internally by library itself.

private static String encrypt(String s, byte[] k) throws Exception {
        SecureRandom r = SecureRandom.getInstance("SHA1PRNG");
        // Generate 128 bit IV for Encryption
        byte[] iv = new byte[12]; r.nextBytes(iv);

        SecretKeySpec eks = new SecretKeySpec(k, "AES");
        Cipher c = Cipher.getInstance("AES/GCM/NoPadding");

        // Generated Authentication Tag should be 128 bits
        c.init(Cipher.ENCRYPT_MODE, eks, new GCMParameterSpec(128, iv));
        byte[] es = c.doFinal(s.getBytes(StandardCharsets.UTF_8));

        // Construct Output as "IV + CIPHERTEXT"
        byte[] os = new byte[12 + es.length];
        System.arraycopy(iv, 0, os, 0, 12);
        System.arraycopy(es, 0, os, 12, es.length);

        // Return a Base64 Encoded String
        return Base64.getEncoder().encodeToString(os);

    }

    private static String decrypt(String eos, byte[] k) throws Exception {
        // Recover our Byte Array by Base64 Decoding
        byte[] os = Base64.getDecoder().decode(eos);

        // Check Minimum Length (IV (12) + TAG (16))
        if (os.length > 28) {
            byte[] iv = Arrays.copyOfRange(os, 0, 12);
            byte[] es = Arrays.copyOfRange(os, 12, os.length);

            // Perform Decryption
            SecretKeySpec dks = new SecretKeySpec(k, "AES");
            Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
            c.init(Cipher.DECRYPT_MODE, dks, new GCMParameterSpec(128, iv));

            // Return our Decrypted String
            return new String(c.doFinal(es), StandardCharsets.UTF_8);
        }
        throw new Exception();
    }

Yes, it is internally being done by the doFinal method. According to the Javadoc for Cipher class:

  doFinal(byte[] input)

  If an AEAD mode such as GCM/CCM is being used, the authentication tag
  is appended in the case of encryption, or verified in the case of
  decryption.

So, you don't have to explicitly append/verify the auth tag during the encryption/decryption process.


Hydra returning incorrect passwords I'm trying to bruteforce my own HTTPS website account through Hydra. Therefore, it is 100% legal. Hydra keeps producing tons of incorrect passwords.
This is the code I use:
hydra -v -V -l XXXXXX -x 6:6:a1 -f -v example.com http-get /user/login.php
Can anyone help?

I'm guessing you are trying to brute force a login form, sometimes with hydra cli you have to play with it editing number of threads, etc. Here is a good tutorial which explains all the GET/POST methods as well as using hydra on brute forcing and launching a dictionary attack.

Also you need to supply good password / bad password condition which are called tokens like ^USER^ and ^PASS^ in the URL where they are to be replaced by the usernames and passwords under test. The second is done by hydra by string matching against the returned page. You can either test for a failure condition, such as "Bad password", or a success condition, such as "logged in". If you don't supply the conditions how does hydra know what username:password combination is the correct one? You need to let hydra know what it means to login successfully and unsuccessfully, each website is different like "Bad Password" "Login Incorrect "Please Try Again".
Here's a very simple command line example:

hydra 127.0.0.1 http-form-get '/login.php?username=^USER^&password=^PASS^:Bad password'

Hydra Guide

PS: Also sometimes due to high number of threads the page doesn't have time to load giving you false positives always try to decrease thread count.


Are commercial VPNs useful for privacy, or do they just add another party to be worried about? A common suggestion I see for people who want to protect their privacy is to use a VPN. Now, I don't own a data center in Switzerland, so if I were to use a VPN it would probably be from one of the first ones that I can find on Google (ExpressVPN, NordVPN, ProtonVPN, etc). But now, rather than my local ISP gaining some information about my internet usage, both my ISP and VPN gain information about my internet usage.

How is that helpful?

Commercial VPN don't add a party to worry about but replace a party. If you worry that your ISP or the public hotspot you use might sniff or even modify the traffic, then you can use a VPN - in which case you have to worry that the VPN provider is doing such stuff instead.

It is thus mainly a question of who you trust more. If you already know that your ISP is sniffing data or even injecting ads into the traffic then it might be easy to trust the VPN provider more. But if both claim that they will protect your privacy and you have no real arguments to believe one more than the other then it is hard to tell what you should more be worried about.


Concatenating secure and reused passwords Would concatenating (i.e. joining together into one string of text) a secure (i.e. Diceware) password and other, much less random, passwords be a good idea? This new password would be used as master password for my password manager, and, since it would replace all my passwords, why not concatenate all of them into one and append a secure one? Obviously, each service would use a new password generated by the password manager.
Intuitively, it would be more secure since the password is longer. The disadvantage, of course, would be that I'd have to type more.
Are there any downsides I'm not aware of?

This new password would be used as master password for my password manager

I am against this. The thing about using passwords that are similar or have a part to play in other password would be considered a bad idea.
Which in your case would be, having phrases from other passwords to make up the master password. The moment any on your passwords are compromised, it places your master password at a higher risk than it should be. Password Cracking techniques have exponentially gotten better, faster & smarter.
Depending on the type of attack, any newly added information would contribute in the time taken to crack your passwords, let's not contribute to that.


RC4 encrypt many messages with same password I would like to ask if it's insecure to encrypt many different messages sent over the Internet encrypted by RC4 with the same password.

If it is insecure, then if I encrypt the first message with the password 100, second message with the password 101, third message with the password 102 and so on, would that make it secure?

RC4 is not considered as secure anymore, since there are several security vulnerabilities found in it. More about RC4 on Wikipedia ...

Using the same password for all messages is also insecure, since if the password was discovered, all messages are compromised. Using pattern like 100, 101, 102 will not add much security to it, since attacker can guess what will be the next and previous password.


What are the considerations when migrating from Bitlocker to Veracrypt? We are currently evaluating migrating from BitLocker to VeraCrypt. Based on the most recent update to VeraCrypt, there appears to be support for UEFI/GPT. Additionally, it seems that decryption isn't required when updating Windows 10.

The reasons for migrating from BitLocker to VeraCrypt include:

Not all devices support TPM
Limited supported for BitLocker as a number of devices are deployed with Windows 10 Home

Assuming that there is the ability to adopt VeraCrypt, I imagine the natural progression would be to decrypt the devices currently using BitLocker first. If yes, what risks does this present to the data on the disks?

For example, will the be exposed such as if there are attempts to perform data recovery after the drives have been encrypted with VeraCrypt, these could be discovered?

Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?

As the devices that currently use BitLocker store sensitive information such as personally identifiable data, financial statements, etc, I would like to limit the risk of data leakage.

To begin with, VeraCrypt is open source. So, you can ensure the code does not contain backdoors. While BitLocker is closed source and hence not open to inspection. For this reason posts like, Can the NSA Break Microsoft's BitLocker have come about. While Microsoft Opens Windows Source Code to EU Governments is good news, it still allows me to make the statement BitLocker is as trustworthy as Apple's FileVault, because the source code is not public, until that date, this statement remains true.
To my understanding, VeraCrypt's hidden partitions work similar to the discontinued TrueCrypt. The hidden partitions work very nicely,

It may happen that you are forced by somebody to reveal the password to an encrypted volume. There are many situations where you cannot refuse to reveal the password (for example, due to extortion). Using a so-called hidden volume allows you to solve such situations without revealing the password to your volume.

The principle is that a VeraCrypt volume is created within another
VeraCrypt volume (within the free space on the volume). Even when the
outer volume is mounted, it should be impossible to prove whether
there is a hidden volume within it or not*, because free space on any
VeraCrypt volume is always filled with random data when the volume is
created** and no part of the (dismounted) hidden volume can be
distinguished from random data. Note that VeraCrypt does not modify
the file system (information about free space, etc.) within the outer
volume in any way.
The password for the hidden volume must be substantially different
from the password for the outer volume. To the outer volume, (before
creating the hidden volume within it) you should copy some
sensitive-looking files that you actually do NOT want to hide. These
files will be there for anyone who would force you to hand over the
password. You will reveal only the password for the outer volume, not
for the hidden one. Files that really are sensitive will be stored on
the hidden volume. - Source

VeraCrypt has cross-platform support. Such that you can access VeraCrypt volumes on FreeBSD, Linux, Mac OS X and Windows. However, BitLocker volumes can only officially be supported, as of writing, on Microsoft Windows. Furthermore, Cryptsetup can decrypt and open VeraCrypt volumes cryptsetup --tcrypt-hidden open --type tcrypt [volume] [name].
If looking for aspects of BitLocker which are less secure, it should be noted that TPM does not aid security when compared with using a removable USB key, as this can be taken with you more easily, while the TPM cannot. Furthermore, BitLocker does support password decryption, similar to that of LUKS. So, BitLocker provides three options for where to store the decryption key: TPM, USB key or password (which you remember).

Assuming that there is the ability to adopt Veracrypt, I imagine the natural progression would be to decrypt the devices currently using Bitlocker first. If yes, what risks does this present to the data on the disks?

Storing any sensitive data on a decrypted drive presents a considerable risk. As once done, you have to properly overwrite the data after, which on SSDs can become considerably more tedious.

Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?
As the devices that currently use Bitlocker store sensitive information such as personally identifiable data, financial statements, etc, i would like to limit the risk of data leakage.

Copy the sensitive data directly from the BitLocker encrypted directly onto the VeraCrypt encrypted partition, this mitigates data leakage. Alternatively, if this is not viable archive the data into a 7z archive and encrypt that using AES256 with a strong random password. Then extract that archive onto the VeraCrypt partition. Then discard the password and overwrite the 7z archive, the overwrite part is optional.


How do I know which padding was used in a cipher suite? I am trying to write a java program that decrypts tls packets. I want to use the Cipher class. From the Handshake I know that e.g. my CipherSuite is 0x00 0x2f which is TLS_RSA_WITH_AES_128_CBC_SHA. So when I call Cipher.getInstance(); I know to put in "AES/CBC/????" but what’s the padding?

I read in How does SSL/TLS work?, that:

  ...then some padding (depending on the encryption algorithm)...

And from Using Padding in Encryption on www.di-mgt.com.au I know there are at least 5 methods of padding.

So to my understanding there is more than one possibility for one encryption algorithm.

So how do I know which one was used? Or can I get that maybe out of the handshake?

Padding in TLS is almost the same as the PKCS#7 padding, but with some subtle differences.

When using CBC encryption, in TLS, things go the following way:

The MAC is computed over the plaintext, and appended to the plaintext. In the case of TLS_RSA_WITH_AES_128_CBC_SHA, that's HMAC/SHA-1, so 20 extra bytes.
What will be encrypted is the concatenation of the plaintext, the MAC and the padding. The total length must be a multiple of the block cipher size, i.e. 16 in the case of AES. The padding consists in appending n+1 bytes, such that 0 ≤ n ≤ 255. So there is at least 1 extra byte, at most 256, all have the same value, and that value is one less than the padding length.

(In true PKCS#7 padding, there would be n+1 bytes who all have value n+1, not n.)
Upon decryption, the contents of the padding bytes MUST be verified, as well as the MAC. Doing so securely is hard to do but if you are writing an inspection tool, then you are the attacker, and thus can afford to do things most insecurely.

In the older SSL 3.0 version, only the last padding byte had to have value n, the other bytes being random (and this is a weakness in the protocol). Conversely, in SSL 3.0, the total padding length was not allowed to exceed the block cipher length, whereas in TLS it can be longer (up to 256 bytes), as long as the total padded message length is a multiple of the block length.

For an inspection tool, the simplest implementation method would be to decrypt with padding "none", and then inspect and remove the padding and the MAC with explicit code that you write yourself. There is no "standard" padding method implemented in Java that would match the variant used in TLS.

If you are interested in decrypting SSL/TLS handshake, it might be a good idea to first write your own SSL/TLS library -- not for production use (these things are very hard to get right with regards to side-channel attacks), but more to gain experience in the fine details of the protocol. When your own library succeeds at completing a handshake, you know that you got all of them properly. Also, the code elements will be reusable for your inspection tool. Thus, writing your own library is a good pedagogical investment (as long as you remember the condition: not for production use !).

You may want to read this answer as an introduction to the protocol.


limit client certificate to domain name If i want to use client certificates for authentication to a certain part of my website, is it possible to make the client certificate only work on a certain domain name?

I know when requesting the client certificate you can request the CA.
But i want it so if my site is domain.com and the client visits a fake website domainn.com then when the client certificate is requested on that fake website it will be impossible for the real client certificate to be used as it wont match to the correct domain.

You can't regulate where the cert goes as it's handled by the client (browser in your case). There's nothing in a client cert to restrict it to specific domains. The browser is free to send it wherever it wishes. There are settings in the browser that lets users control where the certs go, but that too is out of your control.

That said, I'm not sure why you care who gets the cert. If you're using client certs, there's no chance of phishing or MiTMing.


Is physical security less important with disks on a server being encrypted? If you could get physical access to a server, you could change the root/admin password even if you did not know the current password.

However with encrypted disks, I don't think this is possible (or is it?).

So, does this mean physically securing your server has become less important - it's still needed for other reasons - but is this reason no longer there?

Physical access, in many, likely most, situations means a total loss of security - for a variety of reasons (this all assumes encrypted disks):

Theft - An attacker could steal the server or disks, to attack at their pace. This allows an attacker to take their time, and you have no idea if they've actually gained access to data.
Physical Modification - If I can access a server, I could add hardware, this could be anything from USB or keyboard logging to adding a wireless interface to allow remote access.
Cold Boot Attack - There are attacks that can be used to extract encryption keys, allowing decryption of the disks.
etc.

There are others of course, but this is just a sample of what can happen if an attacker has physical access. There are possible attacks that are still somewhat theoretical, such as applying backdoored UEFI images and the like.

Possibly the worst part of a physical attack, is that you may not even know what exactly was done, so there's a real problem with being able to trust the hardware afterwards.


smart AND secure cloud document archive I am thinking of creating a cloud-based document archive. The intention is to make it impossible for the system to read the users' files, and be more than just a storage provider.

Looking at this question, there are some ways to do this, but effectively this limits the archive system to be just a "dumb" storage provider: Only on your own machine will the data make sense after decryption.

For trusting that the storage provider will not laugh at your embarrassing holiday pictures, this approach is rock solid. But the problem is that you won't have the convenience of a less secure system like dropbox, google drive or neat.com.
These systems (let's call them "smart") index your data for search, have handy in-browser document viewers, etc, which I want for my system.

But providing a web-interface to users' data means that the web server must be able to serve unencrypted files (or thumbnails).

For storage, I was thinking of using asymmetric (RSA) encryption of symmetric encrption (AES?) secrets on the central server. Each file is symmetrically encrypted with a per-file secret. Those secrets are encrypted using the public key. The private key needed for decrypting a file's secret (and thus decrypting the file) is encrypted using a secret based on the user's password.

This means that files can only be read by the server if the decrypted private key is kept in its decrypted form for the duration of a users session. Similary, indexing and generating thumbnails for stored files/documents can only be happen while the private key is "unlocked". This design is easily expandable to accommodate application-specific passwords (create an encrypted private key per password), in case I ever want to develop apps besides the web interface.

My question is: How fundamentally (in)secure is this design?

If the (web) server can decrypt files when users are logged in, this obviously begs a question of "how trustworthy and responsible with users' data and encryption secrets am I?" Is there a way to formally(/by design) answer this question with "very"?
Moreover, how eager are the system administrators at my cloud provider to MITM my running system? (If e.g. pressured by some government.)
And finally: In case of someone seizing my servers, are the users' data/encryption secrets safe from prying eyes?

I'm not sure if I understand your problem.  There seems to be a contradiction in your goals vs. solution.

You don't trust the server to not evesdrop
You're providing the server your decryption keys during login so that it can scan the files and generate metadata
You're trusting the server to forget the keys and the plaintext when the user logs out

You'd be better off generating the metadata at the time of encryption on the user's workstation.  Then upload the metadata plaintext along with the encrypted data.  It's not future-proof, so choose your metadata carefully.

To share the file, encrypt the keyfile with the recipient's public key and upload it.

Never give the plaintext keyfile to the server.


What happens if my VPN drops momentarily while using an SSL connection? The Situation
I am in an office with a connection that is routed through a BigIP firewall, with SSL interception; our computers have a root certificate to permit the intercept certs. If I browse to a site such as https://www.google.com/ and view the security certificate, I see the certificate issued by the firewall, but browsers merrily accept it because it maps to a root cert on the computer.
I have a VPN connection that is tunneled around the firewall; the certificate used in the VPN negotiation is the expected VPN server certificate, indicating that the firewall is not intercepting this connection. When connected, all my traffic is routed over the VPN, and HTTPS traffic displays the proper site certificates instead of the firewall certificate, indicating that my HTTPS traffic is no longer being intercepted.
The Confusion
Every so often, the VPN server momentarily drops connection (OpenVPN shows that it's renegotiating the connection, then reconnects within 3-5 seconds). What happens to any AJAX/other background HTTPS requests that run while this is happening? The connection never seems to miss a beat (updated data continues to refresh on the page), suggesting that traffic continues flowing even while the VPN connection is down.
Does the browser renegotiate the HTTPS connection momentarily (and transparently) using the firewall certificate while the VPN connection is down? Or does the firewall somehow see that the data is part of an existing connection and pass the data without MITMing it? Or do the AJAX calls actually get rejected because of the certificate change-up, and the page is just continuing to refresh stuff it picked up before the drop so it only feels continuous to me?
The Specifics

Platform: Windows 7
Tunnel: OpenVPN server, with OpenVPN GUI client
Browser: Google Chrome (and sometimes Mozilla Firefox)
Firewall: f5 BigIP, possibly AFM

This is not a question about whether bypassing a firewall with a VPN is (moral, ethical, legal, etc); this is a question about what happens to data when the VPN drops momentarily, and whether it may be subject to interception. I have authorization to do this specifically because of legal implications.

The "tcp" in your network stack will happily compensate for an outage less than the the tcp timeout, asking the server to resend any packets it has missed. The existing socket connection will not be switched across a different route (this is often done on routers but not on endpoint devices). Since the tcp network stack is very good at this, there is no capability within the browser to handle such events.

I don't see how content could be delivered without any network connection. Note that rendering and javascript execution occur asynchronously from the content retrieval (both from servers and local cache) hence the screen may change without data packets being exchanged.


How can I use my HSM to turn a CSR into a certificate? I create a CSR using OpenSSL, so I have public and private keys. Now I want to sign this CSR and convert it into an X.509 certificate.

The only problem is, my signer is a custom HSM. I can send bytes and it signs them for me using SHA1. (The full algorithm is called: SHA1-RSA-PKCS.)

How can I manually extract the bytes that need to be signed, get them signed and then feed that signature to OpenSSL?

I had an idea of signing my CSR with a fake CSR, then replace signature bits. I tried some openssl stuff, but I wasn't able to do it (I learned mostly from this question: What part of the CSR is hashed in order to create its signature?) Any suggestions?

Creating a certificate is NOT signing the CSR, or even the CSR body. You need to create a cert body containing data that is partly the same as the CSR and partly different, and sign that.

First, do you have a CA cert (root or otherwise) matching the key in your HSM? If not, any cert(s) you do manage to create with that key won't be useful because software has no reason to trust it(them).

OpenSSL has an ENGINE API to allow HSMs or other "external" components to handle some crypto operations, including RSA.
This API is intended to be simple enough that new engines can easily be added. If there is an engine module already compatible with your HSM or you can get one, you can just use the same
openssl commandline operations openssl ca or openssl x509 -req -CA* with explicit -engine option or the equivalent in your config file. If your HSM supports a PKCS#11 interface,
there is a generic but thirdparty pkcs11 engine for OpenSSL, see https://stackoverflow.com/questions/19456555/openssl-engine-pkcs11-libp11-opensc .

Or you can as @Z.T. comments write a program that calls libcrypto to do most of the same things the commandline apps do, except using your HSM to do the signature.
I suggest looking at the reqfile case in apps/x509.c as a starting point; ca.c has so many more options it's a bit harder to extract what you actually need. You'll also need to replace X509_sign, which is really just ASN1_item_sign with X509_CINF as the encoded type, with an explicit encoding step i2d_x509_CINF(x->cert_info,...) followed by digest, encode/pad, and sign as per PKCS#1/rfc3447 (and rfc3279).

As a last resort you could:

create a fake issuer keypair with the same algorithm (RSA) and size, and fake issuer cert for that keypair but with the same names, and keyid if used, as the real CA cert; the keyid won't match the key as openssl sets automatically so you'll have to encode the explicit value
use openssl commandline as-is to process your CSR and issue a bastard cert under the fake issuer keypair and cert (add) with right hash, so it has all the correct data in the cert body (add) and algids but a wrong signature
split the DER encoded cert into the outer wrapper, "to-be-signed" body, algid, and wrong signature
have your HSM sign the encoded/padded digest of body with the real CA key giving a good signature
recombine the outer wrapper, body, and algid with the good signature

Expanded third option per comment. I realized x509 can copy an existing subjectkeyid without computing it on the actual (new) key, so that part is easier; note this feature requires the fairly-recent version 1.0.2 of OpenSSL.

Also on going through the steps I realized your device is signing with SHA-1. Because MD5 was broken several years ago for collision, and thus signature at least in a potentially adversarial situation like cert issuance, and the consensus of cryptography experts is that essentially the same techniques will work soon against SHA-1, cert signature using SHA-1 has been officially disapproved since 2013 by NIST, and prohibited by CA/Browser Forum for certs lasting beyond next year (2016) and some people are actively pushing to make it sooner. There are already dozens of questions here and some other SEs about this: "Why does Chrome warn my cert is about to be insecure?" "SHA-1 is obsolete, you need to get a new one." "How can I shut off all the warnings clogging my Firefox console about SHA-1 certs?" "You can't, that's a feature." Browsers may, with sufficient manual overrides, continue to accept SHA1 signatures from private in-house CAs like yours, where the collision risk is mitigated, but it may become more difficult, especially if the users of your system(s) are not crypto experts.

Those said, here's a worked example on Windows, which is the slightly harder case:

:: contents of conf.txt

[req]
# to generate CSR (and also fake HSM)
distinguished_name = reqdn
[reqdn]
# dummy, actual values on commandline

[myca]
# to issue "bastard" cert which will be patched
private_key = fakekey.pem
certificate = fakecert.pem
default_days = 365
database = index.txt
serial = serial
new_certs_dir = .
policy = policy_anything
x509_extensions = user
[ policy_anything ]
countryName     = optional
stateOrProvinceName = optional
localityName        = optional
organizationName    = optional
organizationalUnitName  = optional
commonName      = supplied
emailAddress        = optional

[HSMCA]
# to fake HSM only
basicConstraints=CA:true
keyUsage = keyCertSign
subjectKeyIdentifier = hash
#authorityKeyIdentifer not needed

[user]
# for issued certs
keyUsage = digitalSignature, keyEncipherment
authorityKeyIdentifier = keyid
# could be omitted or 'issuer' additionally or instead
subjectAltName=DNS:example.com,DNS:*.example.com
# canned value for example, reality should be copy-from-req or dynamic

:: simulate for example "real" (HSM) key and CA cert for it

C:\temp>openssl req -newkey rsa:2048 -x509 -subj "/C=QQ/O=McKean/OU=HSMCA" -days 3650 ^
-config conf.txt -extensions HSMCA -nodes -keyout hsmkey.pem -out hsmcert.pem
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
..........................+++
..........................+++
unable to write 'random state'
writing new private key to 'hsmkey.pem'

C:\temp>openssl x509 <hsmcert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            c3:1e:19:f6:87:e0:8e:90
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 02:38:16 2015 GMT
            Not After : Oct 13 02:38:16 2025 GMT
        Subject: C=QQ, O=McKean, OU=HSMCA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ba:f1:da:4a:2b:24:8c:de:1b:cc:b8:e4:30:a5:
                    17:bc:d2:a9:93:8c:cc:ee:91:98:99:83:ee:81:d3:
                    80:e5:9c:ec:5d:97:c3:2f:8e:e6:db:52:e0:af:a1:
                    c6:f4:6e:78:90:32:3a:8c:09:a5:78:34:76:44:98:
                    04:83:03:41:59:f0:0b:7e:13:02:20:a0:70:cb:eb:
                    32:52:c8:62:ee:1c:97:a3:c9:64:14:0a:73:85:9d:
                    e3:16:90:96:3d:e1:e7:3a:39:a8:95:64:68:8f:e4:
                    eb:29:62:36:ff:e6:e7:89:d6:5a:8f:b0:03:cb:38:
                    e4:dc:6a:9d:5b:9c:5d:1a:4e:13:5c:22:5a:cf:e6:
                    92:a5:42:82:44:c7:07:46:f4:db:57:97:04:e6:b3:
                    7b:88:3b:14:ff:c7:dd:87:7a:e3:14:f6:84:ef:09:
                    9e:44:7b:e1:81:a9:3d:c6:a6:5f:77:ee:02:6e:74:
                    a6:b8:d9:30:88:8e:b4:48:b3:f0:ab:c9:87:5c:db:
                    5d:df:05:28:b1:34:b7:20:32:be:b7:a2:77:7d:bf:
                    7f:62:57:88:c3:c9:4c:4d:29:63:cc:a3:dc:b2:b3:
                    00:8c:69:17:f9:d1:6c:02:31:9d:ca:03:6f:c2:a0:
                    ef:61:14:66:07:57:e6:9c:44:7d:ed:22:e4:e9:f8:
                    7f:83
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign
            X509v3 Subject Key Identifier:
                F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC
    Signature Algorithm: sha256WithRSAEncryption
         1c:78:16:42:f4:29:7c:1e:a9:fb:b6:7f:15:12:8e:d1:e6:c6:
         c3:11:dc:f2:fe:6b:3d:05:4b:0b:bc:cc:f8:29:ce:29:c1:a4:
         11:8d:c1:c1:83:b7:4c:6e:f6:51:86:3a:08:2b:e5:a2:2e:ca:
         23:09:d5:13:6d:c9:fe:b9:af:c4:ed:6f:75:d5:ef:a7:3e:4b:
         7d:09:5b:ad:0d:3b:85:c4:fb:99:dd:a3:b1:e6:f7:34:25:f9:
         c7:8e:37:fd:0d:20:85:cd:04:80:4b:b0:fc:46:4e:5b:a1:3a:
         4c:ce:a3:17:a0:f9:41:f1:64:2e:ac:96:5a:f1:72:5b:9d:57:
         0c:32:8e:cf:9b:ed:50:bf:88:28:c1:b2:bc:e1:87:3e:7b:ac:
         f1:f0:3c:c7:5c:25:0d:da:38:f0:33:e0:25:03:88:f8:97:2c:
         8c:a6:54:92:11:4d:36:9c:9f:3c:40:bb:3c:09:50:4b:f5:6e:
         85:10:bb:dc:d9:67:8f:40:03:d1:95:a5:85:05:c2:65:f5:52:
         18:a2:4d:59:7d:3f:5e:7a:f9:8c:e1:ca:ec:f8:05:4c:5c:74:
         b6:04:f0:18:27:c5:a5:c6:d4:55:56:f9:80:1a:01:78:ab:51:
         8c:c0:69:64:eb:09:ee:d8:f0:62:b9:f9:04:3c:d7:50:67:9e:
         23:a6:69:ea

:: create "fake" RSA key of same size, and fake CA cert for it
:: with same subject, issuer/serial and keyid as the HSM cert
:: (validity period differs, but that doesn't matter)

C:\temp>openssl genrsa 2048 -nodes >fakekey.pem
Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
.....................................+++
..........................................................................+++
unable to write 'random state'
e is 65537 (0x10001)

C:\temp>openssl rsa <fakekey.pem -noout -text
Private-Key: (2048 bit)
modulus:
    00:98:07:94:79:39:14:c5:c7:64:8b:51:d3:9b:e1:
[remainder snipped]

C:\temp>openssl rsa <fakekey.pem -pubout >fakepub.pem
writing RSA key

C:\temp>openssl x509 <hsmcert.pem -force_pubkey fakepub.pem -signkey fakekey.pem >fakecert.pem
Loading 'screen' into random state - done
Getting Private key
unable to write 'random state'

C:\temp>openssl x509 <fakecert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            c3:1e:19:f6:87:e0:8e:90
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 02:53:15 2015 GMT
            Not After : Nov 15 02:53:15 2015 GMT
        Subject: C=QQ, O=McKean, OU=HSMCA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:98:07:94:79:39:14:c5:c7:64:8b:51:d3:9b:e1:
                    1b:0c:e7:f8:10:15:c6:95:b2:7d:81:66:2b:0a:ac:
                    82:2d:d2:86:72:84:f2:8c:d3:09:8a:d6:01:f4:d5:
                    73:cc:4b:6a:8a:3f:4c:e0:78:41:98:74:26:ab:07:
                    db:06:66:eb:63:23:27:f6:fa:d8:cf:7f:93:c6:65:
                    72:61:3d:c8:f5:db:5d:45:ac:4f:4e:a9:91:9b:af:
                    5e:4b:d1:61:9a:6c:42:de:87:56:ec:11:d0:64:12:
                    23:24:6a:8b:4c:b9:b2:68:97:8e:43:2e:9b:ad:1c:
                    1e:f5:f9:fa:69:6a:99:d7:ab:db:3f:7b:a9:dc:44:
                    b4:49:4c:95:7a:9b:ad:a1:69:84:b5:bc:fb:66:be:
                    58:0a:df:2c:8a:01:a6:7c:38:a6:10:e7:48:ed:72:
                    37:09:ea:fc:bf:1b:9c:27:49:8b:43:32:01:9a:1d:
                    aa:00:ba:88:2e:d0:1b:14:93:9e:5b:33:f9:12:03:
                    08:9e:9f:22:06:be:c7:85:3f:39:ae:41:f8:63:0e:
                    92:08:55:9b:82:6f:a7:b1:d2:df:f6:3a:2f:97:88:
                    9f:be:17:df:40:f0:89:de:1a:94:dd:63:10:75:3c:
                    dc:a1:c4:15:ca:e9:3b:26:81:6e:7b:58:52:79:72:
                    09:47
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign
            X509v3 Subject Key Identifier:
                F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC
    Signature Algorithm: sha256WithRSAEncryption
         97:5b:8b:4b:e4:e0:04:b0:b5:bd:68:09:a1:18:f2:19:68:76:
         ea:be:e8:01:42:04:0a:c1:4c:a9:4f:4f:54:31:46:6c:cd:d2:
         5a:4c:9d:af:9d:f3:99:8b:a5:ec:c3:38:7e:24:3a:6c:a0:4e:
         7b:96:c2:88:9f:31:fc:93:47:57:fa:7c:4e:79:40:e6:ed:89:
         b4:f5:42:17:d8:37:20:79:a6:2a:30:ce:f9:18:51:f0:a2:02:
         7b:cb:8b:b5:41:92:79:4f:ce:ec:99:e1:a5:82:24:ec:e5:3d:
         a1:ec:d1:6c:63:75:41:90:b6:af:15:17:f4:a1:8b:f7:8b:a5:
         09:99:f9:aa:57:f7:98:ae:bc:ef:39:aa:6c:96:66:66:8b:65:
         3a:b5:11:1f:d2:d6:b3:4d:95:0a:22:e7:3d:88:1f:ce:1c:3a:
         04:c3:4f:33:e3:53:27:1d:94:10:98:4b:f6:70:ed:48:f1:ac:
         ac:91:1a:5e:4a:37:9a:eb:58:39:69:89:d0:0e:1e:e5:7b:be:
         51:bc:54:ae:09:dd:e5:8f:1f:41:0e:11:b7:e0:87:94:ba:9e:
         d3:9b:69:04:02:fa:55:94:b0:43:bb:e9:15:ac:5c:a9:78:0d:
         ae:1c:34:b1:ca:a7:d0:d4:78:5b:ec:35:1a:07:95:68:48:58:
         fe:22:82:49

:: create user key and CSR for it, then issue bastard cert under fake key (with SHA1)

C:\temp>openssl req -newkey rsa:2048 -subj "/C=QQ/O=McKean/OU=server/CN=example.com" ^
-config conf.txt -nodes -keyout userkey.pem -out userreq.pem
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
................................................................................
.................................................................+++
...............+++
unable to write 'random state'
writing new private key to 'userkey.pem'
-----

C:\temp>echo 01 >serial

C:\temp>echo |set/p x= >index.txt

C:\temp>openssl ca -config conf.txt -name myca -in userreq.pem -md sha1 -notext -out bastard.pem
Using configuration from conf.txt
Loading 'screen' into random state - done
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'QQ'
organizationName      :ASN.1 12:'McKean'
organizationalUnitName:ASN.1 12:'server'
commonName            :ASN.1 12:'example.com'
Certificate is to be certified until Oct 15 03:52:16 2016 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
unable to write 'random state'

C:\temp>openssl x509 <bastard.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=QQ, O=McKean, OU=HSMCA
        Validity
            Not Before: Oct 16 03:52:16 2015 GMT
            Not After : Oct 15 03:52:16 2016 GMT
        Subject: C=QQ, O=McKean, OU=server, CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:9b:ea:c9:f1:fa:80:b6:9f:b4:6e:47:aa:9b:
                    f7:32:cf:2b:b9:44:f2:41:f3:42:10:dc:0a:58:6f:
                    8a:6b:71:2b:5d:93:a3:74:72:20:95:1a:db:9e:9c:
                    ae:d0:af:b7:da:11:f7:26:af:36:13:54:8f:b9:45:
                    d8:dd:5c:1c:a7:c7:c8:8f:b9:4d:09:f5:30:c3:2b:
                    d7:2c:c1:fa:25:78:91:51:22:61:aa:eb:8c:f4:d3:
                    47:80:7e:33:c0:9c:91:14:7d:97:fa:4c:72:28:73:
                    b5:41:7a:cc:5c:4f:da:4f:4d:6c:72:1e:65:b4:47:
                    1a:31:ff:1f:b9:e2:55:c5:c4:2c:d0:28:c9:e1:0c:
                    60:87:2c:0a:0b:21:9c:23:ee:86:a1:57:06:62:68:
                    8b:46:3b:07:2a:08:5c:6f:42:74:5b:53:a6:3e:ba:
                    ed:16:4d:64:c5:17:4a:8b:45:7e:fb:23:e7:63:94:
                    01:b1:c0:45:0d:7d:45:d0:fe:2d:1e:b0:d6:14:25:
                    45:2a:f7:3a:28:14:fe:67:0b:9b:7e:67:90:a2:84:
                    90:f5:de:55:3a:94:ad:4f:fc:80:e4:60:6d:7a:7c:
                    06:7f:aa:69:e2:22:39:e3:13:ae:20:f8:14:f8:55:
                    bd:3a:e7:6b:23:a0:b1:54:9f:bf:af:56:cc:77:32:
                    7e:27
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Authority Key Identifier:
                keyid:F7:A0:68:EB:7F:28:BC:4C:80:03:CA:57:C7:F0:61:7B:D6:14:C3:EC

            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:*.example.com
    Signature Algorithm: sha1WithRSAEncryption
         24:4c:01:bf:b3:73:8f:16:03:d5:fd:34:55:e8:7c:de:be:1f:
         99:92:88:b7:df:97:a3:a3:9e:2e:31:78:22:b8:ea:12:ff:3b:
         10:ff:d3:56:4f:5d:77:8c:21:d4:65:87:56:42:e5:91:e6:d7:
         68:b6:09:2e:22:b6:2e:d2:d7:6c:a4:3f:fa:98:57:f9:e3:61:
         fd:49:90:e7:9c:3d:42:36:19:68:8e:be:a3:77:3d:94:41:54:
         81:46:e4:bd:0b:5a:96:6e:de:28:00:36:39:a1:27:0a:84:2d:
         19:b2:3d:19:d7:97:c9:a7:3f:f2:0a:71:d8:21:4a:64:6b:25:
         85:c2:1e:f4:bf:e1:01:1c:96:64:6f:33:d6:8d:46:c2:85:3c:
         e7:fb:15:95:75:bb:cf:0c:a5:8f:6d:a3:a8:51:3b:fe:8d:cc:
         27:d1:b7:13:c8:90:60:6a:fa:ba:7e:47:53:51:f5:89:bc:f0:
         55:e7:bd:fc:29:59:0f:6e:99:e6:53:bc:87:9f:a1:23:6f:cb:
         8f:d3:58:53:a3:05:40:54:38:6e:df:34:83:86:34:9d:5d:21:
         9f:26:e9:53:e3:f1:fd:a9:8e:be:b8:64:48:d7:8d:80:a2:de:
         4a:86:fc:99:a0:08:b3:62:2b:ed:9d:38:05:ae:2a:88:75:71:
         cd:3c:89:c1

:: find parts of cert

C:\temp>openssl asn1parse -i <bastard.pem
    0:d=0  hl=4 l= 837 cons: SEQUENCE
    4:d=1  hl=4 l= 557 cons:  SEQUENCE
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]
   10:d=3  hl=2 l=   1 prim:    INTEGER           :02
   13:d=2  hl=2 l=   1 prim:   INTEGER           :01
   16:d=2  hl=2 l=  13 cons:   SEQUENCE
   18:d=3  hl=2 l=   9 prim:    OBJECT            :sha1WithRSAEncryption
   29:d=3  hl=2 l=   0 prim:    NULL
   31:d=2  hl=2 l=  46 cons:   SEQUENCE
   33:d=3  hl=2 l=  11 cons:    SET
   35:d=4  hl=2 l=   9 cons:     SEQUENCE
   37:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   42:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :QQ
   46:d=3  hl=2 l=  15 cons:    SET
   48:d=4  hl=2 l=  13 cons:     SEQUENCE
   50:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   55:d=5  hl=2 l=   6 prim:      UTF8STRING        :McKean
   63:d=3  hl=2 l=  14 cons:    SET
   65:d=4  hl=2 l=  12 cons:     SEQUENCE
   67:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
   72:d=5  hl=2 l=   5 prim:      UTF8STRING        :HSMCA
   79:d=2  hl=2 l=  30 cons:   SEQUENCE
   81:d=3  hl=2 l=  13 prim:    UTCTIME           :151016035216Z
   96:d=3  hl=2 l=  13 prim:    UTCTIME           :161015035216Z
  111:d=2  hl=2 l=  69 cons:   SEQUENCE
  113:d=3  hl=2 l=  11 cons:    SET
  115:d=4  hl=2 l=   9 cons:     SEQUENCE
  117:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
  122:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :QQ
  126:d=3  hl=2 l=  15 cons:    SET
  128:d=4  hl=2 l=  13 cons:     SEQUENCE
  130:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
  135:d=5  hl=2 l=   6 prim:      UTF8STRING        :McKean
  143:d=3  hl=2 l=  15 cons:    SET
  145:d=4  hl=2 l=  13 cons:     SEQUENCE
  147:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
  152:d=5  hl=2 l=   6 prim:      UTF8STRING        :server
  160:d=3  hl=2 l=  20 cons:    SET
  162:d=4  hl=2 l=  18 cons:     SEQUENCE
  164:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  169:d=5  hl=2 l=  11 prim:      UTF8STRING        :example.com
  182:d=2  hl=4 l= 290 cons:   SEQUENCE
  186:d=3  hl=2 l=  13 cons:    SEQUENCE
  188:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  199:d=4  hl=2 l=   0 prim:     NULL
  201:d=3  hl=4 l= 271 prim:    BIT STRING
  476:d=2  hl=2 l=  87 cons:   cont [ 3 ]
  478:d=3  hl=2 l=  85 cons:    SEQUENCE
  480:d=4  hl=2 l=  11 cons:     SEQUENCE
  482:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Key Usage
  487:d=5  hl=2 l=   4 prim:      OCTET STRING      [HEX DUMP]:030205A0
  493:d=4  hl=2 l=  31 cons:     SEQUENCE
  495:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority Key Identfier
  500:d=5  hl=2 l=  24 prim:      OCTET STRING      [HEX DUMP]:30168014F7A068EBF28BC4C8003CA57C7F0617BD614C3EC
  526:d=4  hl=2 l=  37 cons:     SEQUENCE
  528:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject AlternativeName
  533:d=5  hl=2 l=  30 prim:      OCTET STRING      [HEX DUMP]:301C820B6578616D06C652E636F6D820D2A2E6578616D706C652E636F6D
  565:d=1  hl=2 l=  13 cons:  SEQUENCE
  567:d=2  hl=2 l=   9 prim:   OBJECT            :sha1WithRSAEncryption
  578:d=2  hl=2 l=   0 prim:   NULL
  580:d=1  hl=4 l= 257 prim:  BIT STRING

:: For this cert: outer TL is 0 to 4, body is 4 to 565, algid is 565 to 580,
:: BITSTRING TL+unused is 580 to 585, and actual signature is 585 to 841

:: separate the pieces; on Unix could use a bunch of dd,
:: but perl is easier and (nearly) the same on Windows

C:\temp>openssl x509 <bastard.pem >bastard.der -outform der

C:\temp>type bastard.pl
open F, '<bastard.der' or die $!; binmode F;
my $b; my $i=0; foreach my $n (@ARGV){
  ($n-=tell(F)) > 0 or die "out of order";
  open G, '>bastard.'.(++$i) or die $!; binmode G;
  read F,$b,$n; print G $b; close(G); }

C:\temp>perl bastard.pl 4 565 580 999

C:\temp>dir bastard.?
[skip]
2015-10-16  00:48                 4 bastard.1
2015-10-16  00:48               561 bastard.2
2015-10-16  00:48                20 bastard.3
2015-10-16  00:48               256 bastard.4
[skip]

:: simulate HSM signature on body with SHA1,RSASSA-PKCS1v1.5
:: doing this on the real HSM remains your problem,
:: and if you (need to) write a program
:: it might easily handle the split and recombine too

C:\temp>openssl dgst -sha1 <bastard.2 -sign hsmkey.pem >bastard.x

C:\temp>dir bastard.x
[skip]
2015-10-16  00:52               256 bastard.x
[skip]

:: recombine substituting HSM signature (on Unix just cat)

C:\temp>copy /b bastard.1+bastard.2+bastard.3+bastard.x fixed.der

:: convert back to PEM and check result

C:\temp>openssl x509 <fixed.der -inform der >fixed.pem

C:\temp>openssl verify -CAfile hsmcert.pem fixed.pem
fixed.pem: OK


benefits of xinetd for a web server What are the pros and cons of using xinetd for a web server running on a VPS. Assume the following measures have already been taken to secure the system:

system hardening, latest updates, minimal packages
strick iptables firewall
controlled/limited use of admin privileges
properly configured services
hardened web application
web application firewall
continuous vulnerability assessments
log monitoring

Putting an xinetd server in front of your web server will reduce security: in addition to any security holes in the web server, you now also are vulnerable to any security holes in xinetd.  Any security measures you can apply through xinetd, you can apply instead through the firewall or the web server.


Is there a reason for the assumed ISIS video's OpenPGP encryption key ID being outside base-16? I was reading an article earlier today about Edward Snowden and ISIS. According to him they faked an encrypted message. He uses the fact that they have an encryption key outside of base-16 as his proof. He also points out that the date of encryption is days later than the message. Here is a link to the twitter post by him:

https://twitter.com/Snowden/status/691396009587556353

I have a couple of questions though. Is it possible in PGP to change the settings to allow an encryption key outside of base-16? Are there settings that will allow a key of any thing you like? Is there a way to delay encryption that would explain the date differences?

Is it possible in PGP to change the settings to allow an encryption key outside of base-16? Are there settings that will allow a key of any thing you like?

No. That piece of output is shown in base 16 (hexadecimal) just because it's a good way to show binary data (in this case a hashsum).

In this case it's as if they had codified a message in morse code, and the output, in addition of dots and dashes, had commas and semicolons. The underlying "message" may have anything, but if you are showing it in morse (eg. for radio transmission) you wouldn't have commas.

  It there a way to delay encryption that would explain the date differences?

It's not that the encryption is delayed, but that the message is encrypted 3 days before the encryption key was created.

As if there could be plausible explanation, they could have generated the key in one computer, then used it in a different one, with one of them (or both) with the date set wrong. Most probably though, they were two pieces recorded recently, with the dates set manually in the past, and nobody smart enough to notice that the generated dates were inconsistent.


Bruteforcing a windows mapped network drive with half of the digits known How do you bruteforce a windows mapped network drive on lan? I know half of the password already and have created a wordlist with crunch. I am not sure how to bruteforce it using hydra or any other script available on kali linux. My question is how do i direct hydra to the mapped drive, for ex //192.168.2.9

You need to attack the SMB protocol with your brute username / password lists.

Hydra has the smb switch can be used
nmap has a smb-brute script which can be used

Remember that if you're attacking a network user you'll want to account for the domain in the username, and bear in mind that dictionary attacks are very noisy.


How can I download an exposed mercurial directory? I have a client with an open .hg directory. For example, the URL http://example.com/.hg/dirstate shows a plain text config file. They have not enabled directory listing, so http://example.com/.hg/ gives a 403 Forbidden page.

I want to download the repository in order to obtain the source code. How can I download the contents of the .hg directory?

I have made a tool that performs some of the following steps:

First, download the changelog and manifest files as described in the repo structure documentation.
Run hg --debug manifest to get a file list. Download the index for all these files.
Fix the repo using the convert extension
Run hg update -C to restore all files.

Now you have the source code.

Edit: more information in my blog post about this.


Installing Development Tools on Production Server? Security Risk? I am using an Amazon Linux EC2 instance as a web server. My web app uses ImageMagick. Because the Amazon Linux (CentOS) repository doesn't include an up-to-date version of ImageMagick, I am compiling it from source. To do this I run:

yum groupinstall 'Development Tools'

Does installing development tools on a production serve pose a security risk? If so, how do I go about safely removing what I shouldn't have installed?

In addition to @Karrax's correct answer, regarding increased attack surface, possible exploits, and easier attack environment for a potential hacker, I wanted to point out one more issue that should be obvious, but is often painfully not.

These are development tools. On a production server.
I infer from that, that not only do the developers have access to the production server, they apparently intend on developing on it.
This by itself has a whole bunch of risks associated with it, namely:

Unauthorized access to production data
No Least Privilege possible
No Segregation of Duties (SoD)
Highly probably there are lots of old, test, and unused code files
Highly probably there are lots of old, test, and unused configuration files - e.g. with a .bak filetype, allowing any user to download and steal passwords etc
No security testing before deployment
Easy to pop in hidden backdoors, because of the previous
Obviously, there is no SDL (security development lifecycle) in place
And more.

My point is that the problem isn't just installing the development tools, its the bigger problem is the process and environment around it that would cause such a plan in the first place.


TLS Authentication/OpenVPN/MITM Attacks on Public Wifi My question is about how an SSL VPN connection such as OpenVPN is protected against MITM/Spoofing attacks on a public Wifi.

For example, if somebody has a 'pineapple' or router setup as a honeypot gateway acting as a proxy does the act of authentication between the client and OpenVPN server protect it from spoofing or MITM. Does the initial authentication using TLS and the exchange of server public key (certificate) and comparison between that and the CA certificate already stored on the clients device identify whether the OpenVPN server is who it actually says it is?

If I have got that wrong can somebody explain the process and if it is correct is there any other point along the handshake that is susceptible to MITM attacks?

Thank you all

In the case of OpenVPN the certificate is already known to the client, there is no exchange at that point, so MiTM is mitigated based on the idea that they would have to compromise the server cert in order to mislead the client into communicating with the middle device.

If the MiTM presented an alternate cert for communication, the client would reject it, likewise the best the middle attacker could do is present authentication for the client, which would result in a communication they couldn't read because they lack the private key material to decode the stream.

Compromise of something like OpenVPN is notoriously hard, provided the OpenVPN server is configured adequately. The security model of that product is based on layers of security, requiring an attacker to accomplish multiple attacks on unrelated code trees simultaneously. (I'm assuming best case scenario here using tls-auth is properly implemented etc)

The CVE list is small http://www.cvedetails.com/vulnerability-list/vendor_id-3278/Openvpn.html with most falling in the range of DoS as opposed to actual integrity leaks. To my knowledge, there hasn't been any compellingly successful MiTM attacks against the product.

There might be some alphabet organizations out there capable, but the average pineapple user isn't going to be able to do much here.


Can an ampersand (&) be used in SQL injection? With SQL Server, does the ampersand pose as a threat related to SQL injection? I'm working on a project that includes this as a blacklisted character. I'm aware that there's a threat related to Oracle (SQL*Plus) but cannot seem to find an issue with the ampersand. I've referenced multiple cheat sheets and articles, and cannot find a reference to it (other than Oracle).

Technically yes, but no more so than any other T-SQL syntax.  The & is used for bitwise actions, and if there is an applicable SQL injection vulnerability found, an attacker could use it to probe for more information about the structure of the query/data, but it's a very specialized scenario, and, in my opinion, a very low priority.  I can think of many more reasons to whitelist an ampersand than I can to blacklist it.

See the link below for more documentation about the operator.
https://docs.microsoft.com/en-us/sql/t-sql/language-elements/bitwise-and-transact-sql?view=sql-server-2017


Is using a dedicated IP for AWS dev access secure enough? I'm about to launch my first ever SaaS product on AWS and am thinking through security.
I have my main server, which is obviously public on :80 and :443, and then I have a bunch of other infra that I need access to as a developer (typically on :22) but that I don't want to be fully public.
I was thinking I would rent a dedicated IP through one of the VPN companies and then set AWS security groups to only allow traffic from that IP for those kinds of services.
How secure is this approach? Is there a better way I'm not thinking about?

That approach would work. So you would have your dedicated VPN IP that is the only IP address whitelisted ("nnn.nnn.nnn.nnn/32") in AWS for port 22. This is best if you need to access your AWS resources from several different networks (home, office, coffee shop, etc.). If you only needed to access AWS from a fixed office, you could whitelist the address block for your office's ISP. Anyone from within that ISP could talk to your SSH service so it is not at tight as it could be. A quick search tells me that dedicated IP VPNs are $10-$20/month. You just have to decide if that added security worth the added cost to you.
Obviously it makes securing your VPN credentials the most important part of your setup. Make sure to enable MFA for the VPN access. And I would still recommend SSH key-based auth where the private key uses a different password from the VPN password.


What are Non-linear/backward overwrites? I read some slides from the Black Hat USA 2012 conference, and I stumbled across the term
non-linear/backward overwrite, mentioned on slide 5 of the Exploit Mitigation Improvements in Windows 8 by Ken Johnson and Matt Miller, Microsoft Security Engineering Center (MSEC) (PDF) presentation:

            Image attribution: Ken Johnson, Matt Miller, Microsoft Security Engineering Center (MSEC)

According to this image, in Windows 7 there is no mitigation for this kind of overwrite, yet.

Has anyone a clue what this non-linear/backward overwrite is, and can give me some additional information about this exploitation technique?

First of all, a "linear overwrite" is the most common type of buffer overflow.  This is the example given in the slide.   Where by starting at some base address you write in a linear fashion and eventually you overwrite the return address:

void function(LPCSTR input){
    char buffer[256];
    strcpy(buffer, input);
}

An example of a non-linear overwrite is this GroupWise ActiveX control exploit written by rGod.  This ActiveX component has a method call where one of the parameters is a memory address, which allows an attacker to write to an arbitrary location in memory.  If the return address was protected by a canary the attacker could just point directly to the return address and overwrite it without corrupting the canary. Dangling pointers can also produce a condition where by the attacker can control a specific address in which to  read, write, or execute in a non-linear fashion.


How do I ensure data encryption on Samba transmission on *NIX systems? I have a heterogeneous system (both MS and *nix) that communicates with CIFS/SMB. How can I ensure proper data encryption at the application layer?

Use Samba 3.3.x+ and set server signing = [auto|mandatory|disabled] in the Global section (disabled by default). Share level SMB encryption is auto by default. This has been tested with WinXP/Win7 and AIX 5.3 running Samba 3.6.7. SMB encryption became available in Samba 3.2 but server signing did not appear until 3.3. These are required for Win7 clients configured to Microsoft's security recommendations (NTLMv2 and 128 bit encryption).

See: http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html


Django, ajax and HttpOnly cookies While reading "Tangled web" I came across description of http only cookies and I wanted to try it out in my project, so I've added these settings according according to docs:

CSRF_COOKIE_HTTPONLY = True
SESSION_COOKIE_HTTPONLY = True

And went to console to dive into it. As expected no csrf token or session cookie showed up when I executed some JS:

> document.cookie
"djdt=hide"

However, I have AJAX running in background polling some data from the server beginning with:

function doPoll() {
    $.get(predefinedUrl){
        (...)

And it seems that somehow it has access to this data:
.

My questions are: how is this data accessible? Is it enough that this script makes request to my site and browser handles the rest (like it does in "regular" cases)? Does it mean I should be able to securely switch on this http only flag by default and not worry that frontend scripts will not be able to make requests? Is there anything I should pay attention for?

how is this data accessible?

It's not. If your browser issues a request, including AJAX requests, it will include all cookies for the target domain in the Cookie header, even httpOnly cookies.1 However, your script can't access them since the headers Set-Cookie and Cookie are forbidden headers per specification and you can't extract them with, say, XMLHttpRequest.getResponseHeader('Set-Cookie').

  Does it mean I should be able to securely switch on this http only flag by default and not worry that frontend scripts will not be able to make requests?

With httpOnly cookies your script can still make authenticated requests, it just can't read the values of the httpOnly cookies which are sent along. Turning on httpOnly only breaks functionality if you explicitly handle the cookies on the client side.

1 sameSite cookies can be an exception.


PCI DSS compliance for storing PAN and PII in multi-tenant environment I wanted to know if I can still be PCI compliant if I store card holder and PII information for multiple tenants in the same database? I.e., have an identifier on the table level to identify the tenant?

The PCI DSS standard does not directly prohibit shared tenant information, so the simplest answer is "yes, that's PCI compliant."  The real answer is "...provided you have sufficient logical controls to prevent tenants from accessing information that isn't theirs."  Do you have an application pen test which demonstrates the table-level identifier information is successfully used to partition access?

This is most closely spelled out in Appendix A "Additional PCI DSS Requirements for Shared Hosting Providers":

A.1 Protect each entity’s (that is merchant, service provider, or
other entity) hosted environment and data

This is just making explicitly clear that the DSS restricts your ability to share PCI info.  It's just as true if you have two tenants in a database as if you have two merchants in a shared hosting facility, but they didn't bother to spell out each shade of grey in detail.

In my experience, PCI cares that controls are in place.  The only people who ask for complete separation from other tenants are... tenants.  Usually big ones, who feel that you exist to provide an application for them.  They would rather ask you to spin up separate infrastructure than trust your ability to create valid logical controls.  It's like a knee-jerk thing with certain large companies.


Repairing corrupt TrueCrypt volumes/disks? (I'm asking this for a friend of mine as I'm trying to help him with this problem over remote desktop, so if any details are needed, just ask and I will get them). Two entire hard disks were encrypted with TrueCrypt, and then decrypted with a recovery CD created on a different computer, but with the same password. Windows then detected the disks as "RAW", instead of the filesystem it was supposed to be (FAT or NTFS, not sure). fdisk on an Ubuntu virtual machine shows one FAT16 partition spanning one entire drive. Various partition recovery programs such as TestDisk were run on the drives with no success. I think the file data itself is still there, but the partition or filetables are corrupt or missing. We've tried altering the partition tables on the drives with no success. Any help would be very, very greatly appreciated.

Currently, we are running TestDisk on one mounted virtual drive in Windows. The other hard disk will not mount, but this one does. The hard disk seems to still be encrypted, and TestDisk found a few NTFS partitions, and is still scanning currently. I'll update this as the situation changes.

First a bit of background; Truecrypt uses a classic 2-stage approach:

There is a small volume header, which the end user can decrypt with his password.
Inside this header there is a master encryption key, which is the one Truecrypt uses to encrypt and decrypt the main user data volume.

So your task right now is to recover or re-create the original volume header, with the original master encryption key used to create the volume.

I hope your recovery CD is a Truecrypt Rescue Disk, as described here. If it's a recovery CD from Microsoft Windows or partition tool (like Norton Ghost), then you are probably out of luck. These will very likely not contain a copy of the original Truecrypt volume header, or contain a damaged header, and thus be of no use.

If your recovery CD is made on another computer, for another Truecrypt volume, then it is of no use. It contains a copy of a volume header with a master encryption key -- but the master encryption key is for the other computer's volume, not for your friend's volume.

Assuming that you're not stuck due to the above problems, then here is what I would do to recover data:

Make a bit-by-bit copy of the harddisks to empty harddisks of the same or larger size. You could do this using fx Norton Ghost, Acronis Trueimage, or Linux tools like G4L or Clonezilla Live. Then put the original disks away. (The purpose of this step is to keep the original disks safe, in case I accidentally make an irreversible mistake while working with the volumes.)
Put the volume copies into a known good computer.
And now it should (hopefully) be a case of booting from the Truecrypt Rescue Disk (CD), and follow Truecrypt's instructions.