Are there standards for software disk image acquisition in forensics?

The overall question would be: is using a software-only solution to
  acquire a hard drive image sufficient from a forensics perspective?

It depends on the purpose. If you are responding to an incident and you have a need to image the drive without disturbing the machine, then if could be appropriate to use software write-blocking.

However, if you think the results are going to be used in court, I'd say please just use a hardware write-blocker. If only because the preservation/protection of the data is more manifestly apparent... and appearances mean a lot in some cases.


Can Solaris' shadow hashes be created by better algorithms than the default DES-based hash?

You can choose the algorithm used between one of these (older Solaris releases might not have all of them available):

Traditional Unix crypt
BSD/Linux compatible md5
Blowfish
SHA256
SHA512

To change the algorithms accepted for existing passwords and used for new ones, modify the CRYPT_ALGORITHMS_ALLOW and CRYPT_DEFAULT variables in /etc/security/policy.conf file.

This is based on plugins so should you want custom encryption methods, you can install third party ones or develop your own.


Is there any reason to disable copy/paste in a website?

Is there any real security implication about allowing doing this?

No.

Lets look at each of these things:

disabling right click

There is no security benefit to this at all, as there is no dangerous action that is performed with a right click.

Some websites disable right click so that users can't copy or save images easily, but this can of course be easily bypassed.

It's very difficult to even come up with a contrived example of the dangers of right click. Some corner-case clickjacking attack may exist, but the defense against that would of course not be to disable right click, but to not allow clickjacking in general.

disabling copying

See above. There is no reason for this at all. Any contrived clickjacking attack should be mitigated by proper clickjacking defenses.

disabling pasting

This is the only functionality that some would argue provides a security benefit, as it disallows the pasting of passwords. They would be wrong.


Theres a few sites you can use - I'll link a few below:
News
Krebs On Security
Kaspersky
Erata Security
Packet Storm
Hacker News
We Live Security
Vulnerabilities
CVEDetails
OWASP
EDIT: I'll update this list with more links shortly!
Updated the list to reflect @Nomad 's comment


Is there a way to prove that HTTPS is encrypting the communication with my site?

My boss is asking me to prove that HTTPS really encrypts the information. How can I do that?

On a basic level, you can use a packet inspector or simple port forwarding proxy. Perhaps Wireshark will inspect the packets easily enough.

You should quickly be able to find that the HTTP traffic is plain text, while the HTTPS is binary gibberish. (with the exception of the hostname)

However, this only proves that the connection is obfuscated. It does not prove encryption or security. Specifically it does nothing to show immunity to MiTM.

Fortunately, the browser does all this for you. If a modern browser tries to connect to an HTTPS web page, it will verify the following:

Strong enough hash algorithms for the certificates involved.
Strong enough encryption algorithms. (i.e. it is actually encrypted)
Certificate chain issued by trusted Certificate Authority(s) (i.e. CA who verifies domain ownership prior to issuing their certificates)
Non-expiry of the certificates.
Matching hash values means there will be no MiTM.

While your boss may like to see the wireshark gibberish comparing HTTP to HTTPS, a stronger test is to quite simply visit the HTTPS site with a modern browser.

Be sure the browser has not been pre-configured to ignore the warning. (i.e. test from multiple computers and smartphones)

If you plan to continue HTTPS permanently (which you should), a wise precaution would be to force redirect all HTTP visits to the HTTPS site, because you cannot guarantee that all visitors will include the https:// prefix when visiting your site.


The signature can be used to verify a download, only if you have the corresponding public key to verify against.

In order to verify that something was signed by who you think it was, you should import their public key into Kleopatra. Then you should be able to verify the signature from there.

Note: I took a short, cursory look over the website, and couldn't find the public key posted anywhere. You might be able to email the author and ask.


is having a `set-cookie: sessionid=xxxxxxx` in every response considered bad practice?

The Django default is secure.

Changing the way Django sessions work in a way that is not through a supported setting would be less secure, because if you replace django sessions with your own sessions module (or monkeypatch some code in Django's session module) you rely on yourself for security instead of relying on the Django community for security.

Your site should also be HTTPS-only and if so set SESSION_COOKIE_SECURE to True.


Remove wp-config.txt, wp-config.php.original, etc. (but not wp-config.php!)

If those files don't exist, then it's a bug in the scanner. If the file contains passwords (like a database password), change them immediately.

How your Wordpress got hacked and how those files were created is anyone's guess. Each installed Wordpress plugin can be vulnerable, as can Wordpress itself. Or you may have a weak password for ftp, the Wordpress admin panel, or something else. Even your hosting may be hacked.

Make sure your Wordpress installation and all plugins are up to date, and don't install untrusted plugins (like ones that have few or no reviews).


Monitor HTTP requests in a TLS transaction

HTTP/1.x traffic consists of a single request followed by a single response inside a TCP or TLS connection. There can be multiple requests and matching responses inside the same connection but typically a new request is only sent once the response is received fully. With this in mind you can do a flow analysis, i.e. look at records of type application_data and analyse in which direction they are sent (i.e. request or response) and how many bytes they transport. From this you can easily distinguish requests and responses even if the traffic is encrypted. You will also get the size of requests and response, although not the exact number of bytes but a close value.

While this described typical HTTP/1.x traffic there can be some less common behavior. Some clients use HTTP pipelining where request are already send before the previous response is received. Due to this message boundaries (i.e. end of request and response) are harder or impossible to detect. This is also true with HTTP/2 traffic where multiple requests and responses are interleaved inside the same TLS connection. And then there are Websockets which provide a bidirectional data exchange after the initial request and response pair. Depending on the kind of data exchange this might look similar to request and response or to be completely different.


PCI compliant RSA key generation and getting value of private exponent

Your question asks that the RSA key pair be created on a token. If that token contains an approved RNG, you should be OK. Otherwise, not so good.

Your private key encrypted with an AES key will be imported onto a trusted desktop computer? Your private key should only be used for signing or for decryption. If your private key is for application signing it will likely be on a token. If used for decryption as part of a PKI within a P2PE solution, it should be on a SCD (HSM, KLD, POI).

You're not supposed to be able to get the keys in the clear within P2PE. The following is from 6F-1.1 of the P2PE draft version 2.0. Keys can only exist in one of the following forms:

• At least two separate key shares or full-length components

• Encrypted with a key of equal or greater strength as delineated in Annex C

• Contained within a secure cryptographic device

Note for hybrid decryption solutions: Clear-text Data Decryption Keys (DDKs) may temporarily be retained by the Host System in volatile memory for the purpose of
decrypting account data.


Crack hashed passwords using a known password

Short answer:

You can not decrypt the hash. You will have to use other means to recover it.

Explanation:

The result of a hash isn't an encrypted version of the password. It can not be decrypted, any more than you can take hashbrowns and rebuild a full potato.  The result of a cryptographic hash is a scrambled up version of the data, with much of the original data lost.  You can guess what the lost data might have been, but you'll probably be wrong, and with cryptographic hash functions, being a little wrong at any one point will make the calculated data vastly different from the original data.

However, you can recover that default password using different means, assuming that you have access to the old system's source code. Here are three possibilities:

Since it is a default password, and this password is identical for everyone, the original developers didn't put much thought into password security.  Check the source code around user creation; the password may be stored in plaintext.
The default password has to be communicated to the new user somehow.  Create a new account, ask your IT admin, or ask the HR rep who gives the password to new employees.
(Somewhat shady) You can also just copy the passwords over wholesale from the old system to your new system and, when a user logs in using the default password, you'll have it in plaintext for a brief moment while the authentication system verifies that the password matches the stored hash.  Use this as an opportunity to switch everyone's password to a key-stretching algorithm such as PBKDF2, bcrypt, scrypt, or Argon2id.

And, if all of that fails, get the user on the phone, explain the situation, and schedule a time where they can watch you work and reset their password immediately afterwards.  (I'm only putting this as the last option, because it was mentioned in comments that this is the situation that you want to avoid.)

In all cases, you should expire the password immediately (because you just compromised it). However, the use of a default password hints that the application probably doesn't have a password expiration feature in it, so this is likely a moot point.

And while you're working on authentication systems, head over to the NIST Digital Identity Guidelines, browse the whole thing, and pay special attention to SP 800-63B.


The problem is independent of what technique you use to obtain your JS libraries. It doesn't matter if you use NPM packages, web-pack or manually copy&paste a folder of .js files. The problem is with using 3rd party code from untrustworthy sources and putting them into your web application without making sure they don't contain any malicious functionality.

When you decide to use 3rd party libraries in your web application, make sure that:

It's a trustworthy project with a good reputation. Is jQuery trustworthy? Is Angular trustworthy? Is PhilippsSuperReliableCreditCardValidator.js trustworthy? Which projects seem trustworthy to you and which don't is a decision you need to make for yourself.
You download the files from the official server via an authenticated and encrypted connection (which tool you use for that purpose is secondary)
You keep the copies of the libraries on your own server. Don't download libraries from an offsite source on page-load.


Server secured with a Certificate from a Custom CA Root: OK on Firefox but KO on Chrome?

Chrome requires SAN present in the certificate.


Google track this activity?

Yes. They track it.

Below, you can see:

I'm in incognito mode
I made a random image search
I clicked on a random image.

The click generated an imgevent JS method / function to be executed which made an ajax call and tracked the terms and image that was clicked on. It even tracked how much scroll I did before I clicked on something and a few other variables.

Whether or not this is directly associated with you is "black box" as far as Google is concerned. However, They know your IP, they know your timezone, and a lot of other information that incognito mode doesn't hide.

If you don't really want to be tracked for something:

Use Tails
With the tor browser
Over a VPN
From a public location
to search DuckDuckGo via their Onion address. http://3g2upl4pq6kufc4m.onion/


Mobile application authentication using UUID

I have one main concern with your setup: You should hash the UUID tokens! Otherwise, if your database leaks all accounts will be exposed. Given the amount of entropy in a securely generated UUID, a simple hash function as SHA-256 will do the job.

A few minor points.

Using a UUID as an authentication is not wrong from a security perspective, as long as you are 100% sure that it uses a secure random source (and the Javadoc seems to agree with you on that). To make the code more explicit, personally I would generate the token directly from the random source without mixing in any UUID. But that is mostly to make the code cleaner.

Make sure that you are using a version 4 UUID. The other versions are not random!

Also, I would keep the tokens in a separate table and not in the users table. But that is more about database normalisation than it is about security.

You should think about when you expire tokens. If you have some kind of log out feature, the token should expire when the user log out. In the same way, if the user is logged out when the app is closed, the token should expire when the app is closed.


Why do Invalid Host header errors exist, what are attackers trying to achieve?

Using a proxy isn't necessary. I wrote a PowerShell module SocketHttpRequest which allows one to submit a custom HTTP request to a destination. It was created to test applications without having to modify DNS or the local hosts file.

netcat is another option: How to make an HTTP GET request manually with netcat?

In terms of what they're trying to achieve:

1) IP Address

Many internet scanners just scan IP address ranges looking for vulnerable web servers. When a web server is found, they send it a request using the destination IP address as the host header value (e.g. Host: 1.1.1.1). No additional steps are taken to determine what website is actually being hosted (e.g. reverse dns lookup).

2) Alternative Host Values

Occasionally a request for an unknown host header value will be submitted. This is to see if the web server will respond with the "default" website; which allows any host header value and should be avoided. This is of greatest concern for web applications and Content Management Systems (CMS) that may rely on the host header value for generating links and other tasks.

  Example: Suppose your website is configured to allow any host header
  value and all links are dynamically generated based on that value.
  I register a domain bad.com to your web server IP address.
  Upon visiting bad.com, your website is displayed with all the links
  resolving to bad.com.

3) Security Filtering

In some cases, modifying the Host: value is an attempt to bypass or enumerate any security filtering in place. This could be a Web Application Firewall (WAF), load balancer, web server, or modules within the application itself.

Fix

The best fix for this is two-fold.

Websites should only respond to requests for the host header values registered in DNS. "Default" websites should be avoided.
Applications should use Host values from configuration files and not rely on the server providing this value. This defense in depth mitigates the risk of a misconfiguration.


It would not violate PCI-DSS if normal rules are taken into consideration. In fact, it's common practice by PCI-DSS recommendations.

The thing is it would be good to implement two-factor authentication on these with e.g. token and also timeout unused connections and use these connections only when needed.

Basically to see what's going on the RDP connection when it's being used and require token when establishing new connection.


I hate to say it, but it sounds like you got tricked. It's a common scam for a pop-up to claim you have malware or viruses and "offer" you a to fix it for some fee. In reality you are usually paying for the privilege of giving hackers full control over your computer (if you installed software for them, that is).
Second, limi1.com doesn't appear to have anything on it, at least nothing that makes it past my script blockers (and I'm not willing to turn them off to check). That's not a good sign. A whois on limi1.com shows:

Registrant Name: Oliver Hoger
Registrant Organization: Virtual Real Estate Limited
Registrant Street: Suite 4, 4 Giros Passage
Registrant City: Gibraltar
Registrant State/Province: Gibraltar
Registrant Postal Code: GX11 1AA
Registrant Country: Gibraltar
Registrant Phone: +1.8553653669
Registrant Email: seek99com@yahoo.com

The admin and tech entries are identical to this registrant entry. This seems awefuly suspicious for a company selling software services.
Cancel all your cards, payment accounts, change all your passwords, and get a proper anti-virus
Those charges are terrifying. You should assume that the "company" you were dealing with was a bunch of criminals. You should think carefully about what information you gave them directly, and what information was on your computer that they might have copied. As a general rule, you should cancel all your cards and change ALL your passwords (unless you are 100% sure that for a given card / account that information has never been anywhere near your computer).
You may be able to get some of that money back from your credit card company by saying that you only authorized $29.97 and the rest was fraud.
As for your computer, you should assume that these criminals have full control of it, best option is to put your important documents onto a USB stick, wipe the drive, and reinstall Windows (or take it to a tech shop to do the same). The second-best option would be to install a legitimate anti-virus (Symantec, McAfee, AVG, or the likes) and see what it finds in the way of malware.


Windows task manager can see all processes as non administrator without permission

In terms of Windows system calls, getting process information can be done via NtQuerySystemInformation() with SYSTEM_PROCESS_INFORMATION as a parameter.

However, the true clue to this behaviour lies with GetProcessMemoryInfo() which mentions a permission called PROCESS_QUERY_LIMITED_INFORMATION discussed in Process Security and Access Rights. Specifically:

  [With Windows Vista] The PROCESS_QUERY_LIMITED_INFORMATION right was introduced to provide access to a subset of the information available through PROCESS_QUERY_INFORMATION.

This exists because (if you keep reading that page) PROCESS_QUERY_INFORMATION is denied on some processes in Vista, particularly those with DRM. So in order to provide you with some information about the process you're running, you get this cut down version.

I'm not at a Windows box to verify this yet, but I believe that all users have at least PROCESS_QUERY_LIMITED_INFORMATION on any given processes so you are able to query limited information even on processes that do not belong to you. Their existence is one such property, although as SteveS notes in the comments, the detail is limited.


How attacker can access victim's account without knowing its credentials?

Not speaking for Facebook specifically, but in any decently configured Web server, the cookies sent over HTTPS are marked "secure" and the browser will not send them back to the server if not using HTTPS (from the browser point of view, if the name is the same but not the protocol, then it is not the same server).

Of course, a user who crazily clicks without paying attention... that's the root of all vulnerabilities.


Encrypted cookie to prevent csrf attacks

For preventing CSRF attacks does creating an encrypted cookie with a nonce prevent a CSRF attack?

No, requiring certain cookies would not defend against Cross Site Request Forgery, because the browser will still send the cookies, regardless of whether the request was Cross-Site or Same-Site.

  In addition, to that checking the referrer against the target origin. I cannot change 1000s of pages to embed the token in each submit and I do not have session state.

Read the OWSAP CSRF Prevention Cheat Sheet for recommended methods to prevent CSRF. Specifically look at the Verifying Same Origin techniques which are more easy to implement than tokens. Also look for OWSAP's description of this technique's limitations, if any.

If I remember correctly, checking the Origin is an effective countermeasure against CSRF for most (if not all) 'major' clients.


Can SMS messages be traced to a specific phone after one month time has passed?

Caller ID (which includes the SMS sender field) is spoofable by design. I'm fairly certain the numbers you have are innocent people's numbers chosen at random, and the offensive texts were actually sent through an online SMS service.

In any case, your mobile carrier may still have the logs containing which carrier the texts really originated. It may end up nowhere (if the far-end carrier is an online SMS gateway and the attackers used Tor, proxies or compromised computers to conceal their identity) but it's worth a try.

Get in touch with the police, they will obtain the logs from your phone's carrier and investigate based on that, and they may be able to locate the attackers, but as I said, if the attackers did their job right, the chances of them being brought to justice are unfortunately close to zero. Your best bet is to ignore them, possibly change phone numbers & e-mail addresses and making sure none of your new information leaks out (don't reveal too much on social networks, etc). Google your name and your relatives and see what comes up. Try to get any personal information taken down or change it so whatever data is published is no longer valid. I suggest you read this : After getting doxxed, how can one protect personally identifiable information?

I doubt your iPhone was compromised, especially if it's up to date. iOS exploits retail for millions on the black market and I do not think someone would waste valuable exploits just to bully someone. Your computer, on the other hand, may have been compromised. I suggest you reinstall it and change your passwords.


It's entirely likely that these aren't scams but rather just spam for a semi-legitimate service. Either way, they could take your money and either do some amount real SEO work or do nothing (in which case it would be a scam) and it'd be hard to judge whether or not work was actually done since SEO simply attempts to increase traffic to your site, thus using SEO techniques may not always work and likewise traffic may increase after SEO for a completely different reason. It's also possible they could use click-farming to make it seem like the "SEO" was effective in the short-term (whether or not they actually did anything).

Another possibility here is that they will ask for credentials to access your site to "do the SEO" and start using it to host phishing pages and malware, but I doubt this is likely. I'd imagine it's merely spam along the same lines of online pharmacies or "green coffee"-like miracle products: there is an actual product being sold in most cases, but the business and advertising practices are wrong.


Is it secure to transfer an RSA public key by email?

The public key is public, meaning that everybody can know it without endangering security. No problem in putting it in an email, then.

The potential issue would be an active attacker modifying the email while in transit, to replace your public key with his public key. To guard yourself against such attacks, compute a fingerprint of the file you are about to send by email (use the ubiquitous md5sum utility on it), and write the hash value on a piece of paper (which you keep in your wallet). When you are back at home, recompute the hash over the received file, and compare it with the value on the paper. If they match, then everything is fine.


By dictionary definition, an artefact (UK) or an artifact (US) is

  an object made by a human being, typically one of cultural or historical interest. "gold and silver artefacts"
  something observed in a scientific investigation or experiment that is not naturally present but occurs as a result of the
  preparative or investigative procedure. "the curvature of the surface
  is an artefact of the wide-angle view"

Your supervisor probably has a design science methodology background and expects your work will be build on this methodology, too.  An IT artifact is a design artifact in the field of information systems (research).

The term  is widely used in information systems research. Reading through e.g. Hevner, A., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems Research. MIS quarterly, 28(1), 75-105. should give you a good grounding on the subject. Here, an IT artifact could be many different things:

  The realm of IS research is at the confluence of people,
  organizations, and technology (Davis and Olson 1985; Lee 1999). IT
  artifacts are broadly defined as constructs (vocabulary and symbols),
  models (abstractions and representations), methods (algorithms and
  practices), and instantiations  (implemented  and  prototype
  systems). These are concrete  prescriptions  that enable  IT
  researchers and practitioners to understand and address the problems
  inherent in developing and successfully  implementing  information
  systems within  organizations  (March  and  Smith  1995; Nunamaker et
  al. 1991a). - -

  Design  science,  as  the  other  side  of  the  IS research cycle,
  creates and evaluates IT artifacts intended  to  solve  identified
  organizational  problems.  Such artifacts are represented in a
  structured  form  that  may  vary  from  software,  formal logic,
  and rigorous   mathematics   to   informal natural  language
  descriptions.    A  mathematical basis for design allows many types of
  quantitative evaluations of an IT artifact, including
  optimization proofs,  analytical  simulation,  and
  quantitative comparisons with alternative designs.  The
  further evaluation  of  a  new  artifact  in  a  given  organizational
  context  affords  the  opportunity  to  apply empirical  and
  qualitative  methods.


The short answer is no.

That error means that there is a problem on Openmailbox's end of things and changing how you connect to it will not resolve the problem on their server. You should contact their support, and let them know their SSL is not validating properly, then wait until they fix it before trying to connect to your inbox again.


Where can I find some "real time" discussion forums for security issues?

You can try in our chatroom, at http://chat.stackexchange.com/rooms/151/it-security.
Depending on hour of day / day of week, you may not find many people there... as it is, the regulars are not a huge crowd... but hopefully that will grow, along with the site.


Is there a brute-force attack similar to what they demonstrate in movies

What you see in the movies is a plot device to ratchet up tension, every time a character is determined it gives the audience a kick. Reality is a bit different.

Brute-force attacks do exist, however it's all or nothing - you either get the whole passcode right or wrong. There's no way to know whether you have guessed a correct character. Passcodes are typically hashed, where changing a single digit will return a completely different cryptographic result. You could get all but a single character right and you wouldn't have any indication you came close.

So real password cracking might be a bit boring from a movie point of view, where you need to show progression to maintain audience interest. What they could do is show a progression bar for the calculation of all possible permutations of a hash, but it wouldn't have a predictable end time - you could get lucky and hit it right away, or get it towards the end of your brute force range. Not necessarily good for a movie but a good director could pull it off.


If the local user has the same password as the domain account by the same name, yes you will automatically be recognized on the remote servers as the same user, and thus have the elevated privileges.

This is known as "pass through authentication". The reason this works is because the security token is issued based on knowledge of the account's username and password - the domain is not regarded in this context (but obviously it is used as the authenticating source).
Still secure, though, since you obviously know the password...


Is it a security risk to allow index listing of the .well-known/acme-challenge directory?

Exposing your ACME challenges is not a security concern. These unique tokens are given to you to aid automatic domain ownership verification. They should be unique in path and content.

Since your site has no certificate when the challenge phase happens your tokens are exposed via a plaintext HTTP connection anyway.

The tokens are not secret, they just have to be sufficiently random to prevent anyone from obtaining certificates for domains one has no control over. If they were not so, one might be able to find a file on the server that matches the challenge and receive certificates for domains he does not own.

  If my acme-challenge tokens have been visible in this manner, are my SSL certs compromised?

They are definitely not. Certificate issuance is a completely separate process. Once the domain ownership is verified the ACME challenges are not used.


(Original question)

  What are the security issues for generating a RSA private key that is 1 bits in size?

You can't have a 1-bit key.

The key size of an RSA key denotes the size of the RSA modulus. This modulus is a product of two distinct prime numbers. So the smallest possible value would be 6 = 2 * 3 which fits into 3 bits (6 = 0b110).

It is similarly ridiculous to choose the public key exponent to be 1, because then the private key exponent must also be 1 (the only possible multiplicative inverse). This means that the ciphertext looks exactly like the plaintext. Consequently, this also violates the RSA specification.

  What are the security issues for generating a RSA private key that is 3 bits in size?

For your private key to be secure, the distinct primes that build the RSA modulus have to be much larger since RSA relies on the assumption that there is no efficient algorithm for integer factorization (the task of retrieving the primes from the modulus). For small values however, you don't need an efficient algorithm as it's trivial to obtain the prime factors by brute force. And once you got the primes p and q for modulus m, you can calculate φ(m) = (p-1)*(q-1) (Euler's totient function) and then proceed the same way as in the initial key creation process. You simply calculate the private key exponent d for the known public exponent e by solving e*d ≡ 1 (mod φ(m)). See the key generation algorithm for details.


How to specify virtual web hosts in Nessus (host header/SNI)

It appears you may have the format reversed.  According to this post by the creator of Nessus, the format should be

example.com[x.x.x.x]


Remote Buffer Overflow w/out Memory Leak

In the end, it turns out that I was making an elementary mistake. Prefixing my shellcode with a NOP sled ended up successfully exploiting the remote instance of the vulnerable application.


ARP Spoofing - Not Receiving Internal Traffic

Since you want to capture data between two devices that exist on the same network range
'i.e. 10.0.0.0', you don't need to spoof the router.

Your Mitm attack should take place between the two devices because the data flows directly from one device to another when you're on the same network
 and doesn't go to the router (of course there are few exceptions).

So, you need to modify your commands to the following:

echo 1 > /proc/sys/net/ipv4/ip_forward
sudo arpspoof -i wlan0 -t 10.0.0.54 10.0.0.55
sudo arpspoof -i wlan0 -t 10.0.0.55 10.0.0.54

if you have further issues, please update your question.


How can a server recover from its secret key stolen?

The key needs to be revoked, the server nuked from orbit, and a new system with a new key put into place.

To go further, this is why you want your master signing key to be offline and trust in your servers' certs based on that chain.


What is the point of using an open source and secure OS if you are running it on a machine with closed source firmware?

Historically, the open source movement is not about security but about freedom. Basically, Richard Stallman was very dismayed at not being able to fiddle with his printer because the driver source was unavailable.

OpenBSD's stance on being "secure" does not come from it being open source, but on an avowed goal and pledge to do things properly with regards to security (still historically, OpenBSD came into existence because some developers in NetBSD were much better at programming than at managing human-to-human peaceful relations).

The association between security and open source is more recent. In fact, right from the start, it was explained as being an incomplete concept (see Ken Thompson's famous Reflections on Trusting Trust). One element in the discussion is Linus's Law that says:

  given enough eyeballs, all bugs are shallow

The core idea is that, with sufficiently many reviewers, bugs will be found, and this extends to security-related bugs. This holds, however, only on the premise that there are reviewers. Open-source software makes external reviews easier, but that does not mean that external reviews actually happen. When was the last time you went through existing source code ?

Case in point: OpenSSL. After yet another vulnerability was found in the code base, a fork was made, called LibreSSL, and they started an explicit reviewing effort, that found several serious issues in the code base. These issues had been there for years, right in the middle of a library which can be said to be one of the most crucial security-related libraries in the Linux ecosystem. So this was open source, and yet not sufficient (at all) to achieve proper vulnerability detection.

So of course open-sourceness helps with security, but not as much as can be hoped for.

What open source really brings is a much increased risk for people who want to willingly plant backdoors. It is hard to make code that looks innocuous to reviewers and still does bad things (there is a contest for such code).


Getting spam calls from numbers similar to my own

The telephone system has been designed so that a caller can replace their phone number with a fake, and some unscrupulous companies use this to change their number to appear to be local to the person they are calling. They aren't using specific numbers of people you know, just something picked at random. The thinking is that a person is more likely to pick up if they think it's a local call.

It is illegal to spoof your number with intent to defraud in the US and Canada, so what they are doing is probably against the law. You could report this to the phone company and they may look into it. Other than that you can't do much about this unless your phone company offers an add-on service to prevent it.


This problem has challenged me for a while but did find a way through it.
Typically it manifests as Windows Update Error 80245006 or 803D000A

I wrote a tool called SuperPhishers DetermineSubCAIdentity.py in March 2015 that will allow you to bypass the windows internal check that the certificates are really truly from Microsoft.
The name is a play on the SuperFish Lenovo controversy at time.

The easy part is having your SSL proxy generate something modern:
like RSA>=2048 and SHA256RSA, etc. I used sslsplit and modified it to generate SHA256 digests. Windows requires SHA256 on its update and store certificates or it fails with 0x803D000

The hard part is bypassing Windows checks that the CA Cert is Microsoft:

Basically there are two functions that implement a checks that the CA cert is legit. They are both called DetermineSubCAIdentity in wuaueng.dll and storewuauth.dll
Using Nektra Deviare2, the function DetermineSubCAIdentity was hooked so that it always completed leaving EAX=3.
This allows the Microsoft check to pass and the update or store function continues as normal.

If you patch this function in both dll's it allows interception of Windows Store traffic.
Review your intercepted traffic or run through ICAP to rewrite fun.

I made a video here: https://www.youtube.com/watch?v=EyDaTkU2sKY

The code and technical write up is here: https://github.com/MiWCryptAnalytics/DetermineSubCAIdentity

Thomas Pornin is correct in that you need to modify dll's -- When I modified the dll's on disk, SFC did replace them with good ones.
However doing it in memory with Deviare2 injected into a SYSTEM process, Windows 8.1 didn't seem to care.

Hope this helps and it was enjoyable to see that Windows Update traffic in the clear for the first time.


I googled the first onion address and found this: https://blog.cyren.com/articles/wannacrypt-ransomware-spreads-via-nsa-exploit

Those are WannaCry command and control servers. It appears that some protection technology is blocking WannaCry from downloading to your computer (by setting 0.0.0.0 as the destination).


Why should we prevent users from saving their passwords in their password manager?

DON'T.

Unique passwords is one of the most important aspect of password security, as a breach in a different site will not affect other sites for the same user.

Unique passwords per site is almost impossible without password managers. In addition, password managers enable longer password. For instance, most of my passwords are unique, 60-character, containing special characters. This is way more secure than the previous ten-character passwords I employed previously - with lot's of password reuse.

In short; your idea will likely lead to worse safety. And it will seriously piss off security conscious users. Instead, follow NIST Guidelines, and don't try to control how users enter the password.

In addition such attempts at controlling input may impair users with disabilities. Screen readers and alternate input methods may not play well with custom scripted input options.


"Strong Authentication" - Multi-factor authentication vs multiple of the same factor authentication

If the contract calls for "strong authentication" I think that's open to interpretation. It also depends on the type of information you're protecting and how that information is being accessed. My bank for instance, doesn't require two factor authentication to access my money, only a strong password.

To answer your question, I don't think requiring two sets of usernames and passwords is any more secure than just one. The benefit of true two factor authentication is that if one factor is compromised, the other most likely isn't. Having two usernames and passwords is pointless if a users desktop is compromised.


Is it possible for unprivileged user to modify/inject into other user's (root) process?

This is far from being a simple task thanks to memory protection techniques.

In the old times of MS-DOS, Windows 9x and equivalent home computing systems, the memory was indeed equally shared amongst all the running process. In such conditions your feeling is right: any user process can access and modify memory from other processes, even the operating system kernel has no mean to fully shield itself.

But this is old story now. As an inheritance from mainframe computers (big bulky fridge-looking units used for highly sensitive and parallel tasks), home computers OS and processor architectures received real memory protection techniques.

At the basis of this technique there is a map allowing to match a memory segment with its owning process. Thanks to this, a process is not allowed anymore to access anything outside of its own memory. If a process attempts to break this rule (most often as the result of a bug) the operating system mercilessly kills it (this is dreaded segmentation fault, or "segfault" for the intimates).

Does this means that the threat you are describing can never happen anymore? In security, never say "never": every system as secure as it may seem has its flaw:

The whole thing is controlled by the operating system kernel, so a flaw in the kernel may lead to bypass this security and obtain access to whole memory like in the good old days. An example on Linux could be the ptrace system call, designed to allow to trace (debug) a process. Vulnerabilities are found from time to time allowing an unprivileged process to abuse this function into getting such ability.
On the other side of the chain, you may also want to bypass the operating system completely and directly attack the physical RAM storage. The most well known attack in this category is the Row Hammer: it has been found that on a lot of RAM modules the fact of quickly and repeatedly changing the value stored at a location may, due to some electronic weakness, affect and possibly change a value stored at a nearby location.

Where your nightmare may come true regarding your "fairly simple" scripting language is that there is for instance a working JavaScript implementation of the Row Hammer attack. So definitively yes, it is possible for an unprivileged JavaScript program to inject some code in a root process. However, this is not a simple thing, and as new ways to do this get discovered, new protection techniques gets developed: the endless story of IT security ;) !


Hiring a Third Party Developer, what config files & certificates are ok to share?

Sounds like you're a small operation but you should still tried to seperate production from development and seperation of duties. A developer  NEVER needs to have access to any signing key or account related to production and hiring an external always adds a risk factor.

You should have spun him up an environment that you could throw away after his work and retain control of those you intended to use in production.


The only relation I see is that the server might abort if the CSRF token is invalid before running any SQL, so you would need to have the CSRF token to exploit an SQL injection vulnerability.

Of course this would only apply to requests that include CSRF validation, which is generally limited to POST requests, and if there's an SQL injection vulnerability in a POST request there's probably one in a GET request somewhere too.


What can my university see by installing a CA root certificate on my computer, even when I'm using a VPN?

From your description, you don't seem to have installed a new CA at all; you accepted a certificate to authenticate the wireless network, or accepted an already-installed CA to verify certificates to authenticate that network. This is not a security risk; it's fairly normal, does not let the university sign their own certificates, and does not let them impersonate websites. All it does is verify the identity of the server that processes your credentials that you used to log on to the wireless network.

Some background: Many universities use WPA/WPA2 Enterprise security, which involves logging in to the wifi network with your university username and password (entered into the wifi client, not a web browser). In such cases, the authentication server (called a RADIUS server) needs to verify its identity, which it does with a certificate, just like for websites.

For websites, a CA can verify a certificate for a particular domain. However, there's no good way to do that for RADIUS servers; I might have a legitimate certificate for radius.cpast.com, but that doesn't mean you should trust my RADIUS server when connecting to SchoolWifi. So, it's pretty common to be prompted to manually accept the certificate for the wireless network. This is not a security risk; you aren't accepting a university-controlled CA, you're accepting a particular certificate for that specific wifi network.

(Windows does it a bit differently: you do accept a (already-installed) CA for the wireless network, but it also remembers the RADIUS server's domain, so trying to pass off radius.cpast.com for SchoolWifi wouldn't work because Windows would only accept certificates for radius.school.edu and from a particular CA that the user accepted when first connecting).

So it's not unusual to get a certificate prompt, and it's not generally a security risk to accept it.

EDIT: With your comments, it's even clearer that this is what's happening. Thawte is a generally trusted CA; common browsers and OSs already trust it to verify a website. It comes preinstalled on your computer, because Apple trusts them. However, it is not trusted to verify a RADIUS server by default, so you're manually accepting the school's certificate.


If it opened without a key, it wasn't encrypted. It was probably signed by the sender, and if you have the sender's public key (out of band) then you can verify the signature.

The point of S/MIME is the same as PGP, but geared for corporate use. It's not good, and people should use Signal instead, but when used for encryption it does provide encryption.

The people who downvote this answer because they don't like me saying PGP and S/MIME are not good and should not be used, should read the "Johnny-You-Are-Fired" paper about PGP and S/MIME signatures.

My reply to a comment got too long so I post it here:

@martijnbrinkers in practice you are wrong.

A standard for doing something between you and another person is only good and useful if there is a high chance the other person will (1) have an implementation and (2) that the implementation they have is good.
If no one uses the standard (e.g. too hard to implement or expensive) then it's no good.
If the major implementations are not good then it's no good.

Take for example TLS. If only an implementation you never heard about had the bug we would agree the bug doesn't mean anything about TLS. But if every major implementation had the bug, like poodle and lucky13 variants, we say TLS was a bad standard (fixed in TLS 1.3).

Back to secure mail, Thunderbird, Outlook, Apple mail all fell? Interoperability with a random implementation used by other side is likely insecure? The standard is bad.

If it's only secure to use if you are sure the counterparty verifies signatures and decrypts using gpg command line outside their mail client, it's not good.

And even when all these bugs are fixed, it's not using authenticated encryption, there is no forward secrecy, the non repudiation is too strong, the metadata is problematic, etc. etc.


How to protect Time Machine backups from Ransomware?

Probably the best low-impact solution is to use multiple disks. OSX supports it already.

You could keep a regular disk plugged in, and use the second disk on a weekly basis (keeping it unplugged and in a safe location). If your backup gets compromised you only risk losing a week's worth of work.

Also, keep your backups encrypted!


Does anything stop applications from reading your saved passwords and cookies from your browser's AppData folder?

This can very well be a concern. Different browsers handle it different ways. Chrome passwords on Windows are not stored in some file in AppData; they're stored using Windows's DPAPI, which means that they're encrypted with a key derived from your Windows password, so they're secure if someone doesn't have access to your Windows account. However, while it's not necessarily trivial for other programs running under your user account to access the passwords, it's by no means impossible to do so. The basic principle seems to have been "there actually is no secure way to have the passwords stored in memory (not on disk) and keep other programs from accessing them, so let's not pretend there is" -- thus, for a long time, it didn't prompt you for a master password at all (you were logged in, and that's your master password. Nowadays, they have implemented a Windows password prompt to view stored passwords; there's no technical benefit, but it's much harder to casually view someone else's passwords.

Firefox instead implemented its own crypto modules from scratch, starting from Netscape days (other browsers tend to use OS functions for crypto). Its passwords are encrypted by Firefox, with an optional master password that the user must enter before it will autofill passwords (and again each time you want to show all passwords). This is probably more secure when Firefox is not running -- the Chrome password DB is open to all programs running as your user, but the Firefox one is only open when Firefox is actually running.

However, when Firefox is running, any program running as you can see what it has in memory. Because it doesn't prompt for a master password each and every time you need a password filled, other programs can then read the password DB because you decrypted it for Firefox. They can do this until Firefox is closed.


Reference for Insecure password by email

well I'd have recommended plaintextoffenders but @razethestray has already done that :)

As to DPA, I'd say that the obvious place where this practice might not match up with its requirements is that principle 7 requires that

  Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Unfortunately the DPA doesn't provide any additional information about what appropriate means, which is (IMHO) a bit useless!

One other one is, if they're processing debit or credit cards they'd be in breach of PCI DSS requirements on storage and processing of passwords.


If you are asking about an academic peer-reviewed conference on web security, I have some thoughts for you.

First, the four most prestigious peer-reviewed conferences in computer security are generally considered to be IEEE Security & Privacy ("Oakland"), Usenix Security, ACM Computer and Communication Security (CCS), and ISOC Network and Distributed System Security (NDSS).  Folks will debate the order, but most people will probably say that Oakland is the most prestigious of these and NDSS the least.  All of those conferences will accept web security papers, if they are strong enough.  Usenix Security and NDSS probably are the conferences that are most closely aligned with web security.  Papers have to have an exceptionally strong contribution to be accepted at these top-four research conferences.  If you are active in the computer security research community, you probably already know about these four.

Second, there are other peer-reviewed conferences and workshops that focus specifically on web security.  W2SP is a fantastic workshop that accepts many strong research papers on web security each year.  You could also look at WWW and Usenix WebApps; their focus is on web technology in general, but they tend to accept several security papers each year.  If you are active in the computer security research community, you should already know about these conferences, I'd hope.

Finally, there are many other peer-reviewed security and web conferences that accept good web security papers.  For example, you might look at ones like ESORICS, ACSAC, DIMVA, RAID, and too many others to list.

One last piece of advice: Before submitting to any of these conferences, you must first become an expert on the published peer-reviewed literature on this topic.  Read through the proceedings of the last few years of the conference.  Also, read the other published work that is related to your own research.  There is a tremendous amount of prior work on web security; it is important that you be familiar with it and able to articulate how your work fits into the past work and how it advances the state of the art.  If you are not familiar with the related work, and not familiar with the standards of the conference, it is not likely that your paper will be accepted by the conference's program committee.


The problem is not in doing a renegotiation; it is in believing in security characteristics that the renegotiation does not provide.
Renegotiation is making a new handshake while in the middle of a SSL/TLS connection. This is described in the standard, albeit not in very clear terms, especially when it comes to defining what guarantees renegotiation offer.
Renegotiation is very common when used with client certificates, especially with IIS. Things go like this:

Server receives a connection request on port 443; it begins a handshake. The server does not ask for a client certificate.
Once the handshake is completed, the client sends the actual target URL as a HTTP request in the SSL tunnel. Up to that point, the server did not know which page was targeted; he only knew, at best, the intended server name (through the Server Name Indication). Now that the server knows which page is targeted, he knows which "site" (i.e. part of the server, in IIS terminology) is to be used.
If the specific site requires or at least demands certificate-based client authentication, the server triggers a new handshake, this time with a CertificateRequest message.

The security issue here is a question of layers. Handshake messages appear "under the cover" as administrative out-of-band administrative interactions, around the main "application data" traffic, which is just HTTP. Once the new handshake has been performed, any subsequently sent application data is covered by the authentication umbrella of SSL. However, what of the application data which was sent before the second handshake, in particular the initial HTTP request which decided the server to perform a second handshake, or, crucially, other HTTP requests pipelined after it (but before the new handshake) ?
It so happens that Web servers tended to just assume that whatever authentication was just performed in the second handshake could be "transported" to previous data, retroactively. It so happens that it is not true. That's never clearly said in the SSL/TLS standard, but such authentication only acts in a forward way: no time travel. The important word in the previous paragraph is "subsequently". This allowed an actual attack (see this page for pointers to extensive explanations).
A crucial point for the practical attack is that the second handshake messages are indistinguishable from the handshake messages for a new connection (i.e. a "first handshake"). RFC 5746 describes the patch, which has been implemented in major browsers and servers (which we assume to be up-to-date with security fixes; otherwise, you are in big trouble anyway). This is also what OpenSSL reports as "Secure Renegotiation". Note that the RFC candidly says that:

While this extension mitigates the man-in-the-middle attack described
in the overview, it does not resolve all possible problems an
application may face if it is unaware of renegotiation.

In other terms, this is a patch to fix a demonstrated issue, but it does not claim to cover all grounds. What renegotiation really offers is still not clearly defined anywhere. If your clients and server support "Secure Renegotiation" then things are fine for now (it prevents all currently known attacks). The whole concept of renegotiation and interleaved handshakes is still sorely in need of a more formal analysis.


Publishing an exploit after vendor contact and patching

Is the next correct step to ask and get a CVE identification number for each exploit and then publish my paper linking to those CVEs?

As a courtesy, I would inform the vendor that you plan on publishing. They may want to first send out private notices to their customers to give them time to update. Normally, you would mention this when first contacting the vendor, but if you didn't, better late than never.

If you can get a CVE via the process described below, then yes, you would link each vulnerability to its CVE. You may also want to publish your report to a mailing list.

Is a CVE Needed?

  Can I just release this paper or do I need to get a CV Number as well

You don't need a CVE to disclose, but it's recommended, if you can get one (your vulnerability may not be eligible for a CVE, for example if it is in closed sourced software that isn't listed by MITRE, or MITRE may not be able to assign you a CVE in a timely manner).

The idea behind CVEs is to have a centralized way to identify security vulnerabilities, which makes it easier to distinguish between different issues across different tools or vulnerability databases.

So if you can, it would be best to acquire a CVE before publishing, so others can easily identify your vulnerability and to avoid duplicate assignments.

How to get a CVE (in 2016+)

In August 2016, MITRE changed their email-based CVE request process to a webform-based process. In the process, they also changed the rules about what vulnerabilities can request CVEs from them directly.

As far as I understand based on this document, it works like this:

if the affected product is assigned to a CNA, a CVE should be requested from that CNA at the same time as the vulnerability is reported.
if not, you can contact CERT/CC (I assume before disclosing), or a mailing list (while disclosing).
if the affected product is in a seemingly arbitrary list of software, the CVE should be requested after it was reported to the vendor, but before publishing the vulnerability. This request should happen via the MITRE CVE webform.
if the affected product is not in the list, and it is open source, then the CVE should be requested after it was published, via this google docs form (if you disclose via a mailing list, I would make sure to include a link to avoid duplicate CVE assignment)

For your case, point 1. doesn't seem to be the case. You may send your disclosure to a mailing list (point 2.), but I wouldn't expect to get a CVE. If the vendor is in 3., you may use the webform to request a CVE. 4. doesn't apply, so if none of the previous points applied (eg if it is closed software not in the list of covered products), you may not get a CVE.


What unique device fingerprinting information can an iOS9 app collect?

https://panopticlick.eff.org

EFF released a tool to check the uniqueness of a browser through things like canvas etc.

curiously i had never actually run this on iOS, but i just tried it on a device running default browser settings, and it found my browser settings were unique among 175000 tested. apple does not allow non-apple browsers to be based on anything other than their webkit engine. lastly, i am under the impression that all apps have full access to the webkit browser.

there is also a little bit of non-technical info here:
https://support.apple.com/en-us/HT205223


Interpreting CVE ratings: Buffer Overflow vs. Denial of Service vs. Remote Code Executing (RCE)

You should interpret it as such, an untrusted input is able to write to section in memory that it isn't supposed to write because application fails to check its size.

I think you are in the mindset of always categorising RCE as extension of buffer overflow when they could be different issues altogether. Take for instance RCE due to remote file inclusion, or flaws in web applications that utilise eval in scripting languages or take untrusted input to run an OS command. These are RCEs but not necessarily BOF.

I guess what I'm saying is, a buffer overflow can be treated as its own category that describes what a vulnerability is and how it happens. It could potentially be extended to RCE or DoS, but overflow is quite perfect to understand it.

When you see an overflow vulnerability, you can always check associated publicly released exploit code and read more about it to see if there's DoS or RCE. Most (if not all) BOFs are at a minimum already DoS. Also, it is possible to read that an overflow leads to RCE, but you can't find any public exploit. This is common, especially in software that are proprietary. This doesn't mean that it's unconfirmed, its just that the researcher(s) never released to the public and may be part of proprietary security tools.


How did the "Blaster" worm trigger buffer overflows?

If you have control over pwszPath then you can pass a very large string to exceed the buffer.

I'm not sure what else to say.


It uses browser extensions. According to MalwareTips.com

  Integrates into the web browser via the Sonic Train browser extension

How-to-remove.com has images of the extension installed in IE and Firefox. Fixyourbrowser.com also says it is done by browser extension.


How to ignore request-response pairs with a 304 status code in Burp?

I would try playing with the filter settings in the HTTP History tab:
Filter out 3xx response codes:

Or filter out the text "Not Modified", assuming you don't need to text search for anything else:


Huge amount of hidden porn backlinks from legit WordPress sites, why they did it?

How was the hacking done?

Wordpress and its plugins have a long history of security vulnerabilities. These vulnerabilities usually get fixed rather quickly through updates, but many people don't update their wordpress installs. The web is full of Wordpress instances some people set up and then forgot about. These are a prime target for black hat hackers who run bots to find these sites, exploit the vulnerabilities and insert the content the hacker wants.

But why associate non-porn websites with pornographic keywords?

We can not read the minds of the hackers or their customers, so this is pure speculation. Possible motives could be:

Harm the linked websites by getting search engines to flag them as porn and thus hide them from safe search. They might do that to benefit the competitors of these websites or to blackmail them.
As suggested in a comment by CodesInChaos: It could be an attempt at Bayesian poisoning. The spammers want to confuse the porn detection algorithms of search engines and filter software to make them less reliable. The motive could be to get some of their own sites reclassified as safe for work without deassociating them with explicit porn keywords.
They might want to exploit some halo-effect in search engine algorithms. They hope the search engine will reason: Popular site is about porn. Spammers site is also about porn. Therefor, any user who likes popular site might also like spammers site.
For Science! It's just an experiment. They want to know how search engines will react to this attack to figure out more about their algorithms. The algorithms of search engines are closely guarded secrets and the business of tricking them is a multi-billion dollar industry. The more you know about them, the better you will be at SEO.


It's still possible to email spoofing to Google

It will depend on whether the spoofed domain has an SPF policy and other factors internal to Gmail spam filters.

With a strict SPF policy on the domain it shouldn't be possible at all.

With strict DKIM it shouldn't be possible either.

With neither, it might still get filtered by Gmail (or other providers) depending on the originating host address, its configuration and probably other factors the big providers weigh in.

Getting filtered could mean it will land in the user's spam folder, it will be silently dropped, or it will be rejected during the SMTP session with the sender host.


How can granting access to the Apache log directory to a non-root user allow that user to gain root access?

It is not saying non-root user can perform any kind of direct privilege escalation as a result of this, what it is saying is the log dir should be restricted as their is potential to perform a PE.

Apache is spawned by the root process (needed to bind to port 80) so the logging dir is owned by root. You could theoretically use a public or non-root owned log file as a potential avenue for privilege escalation, e.g non-root user writing files that root would consume, but their are a number of steps needed to do this.

The Apache logs, like any other kind of logs will contain all sorts of juicy information that you definitely do not want to be public.

  Does this mean that a security issue would result if I were to chmod /var/log/httpd to 777?

Yes. For the reasons mentioned above.

I have no idea what kind of logs you are creating, their are options around all of this (custom log dirs, new users/groups etc) but it all depends on context.

Definitely do not make them public.


Attacking an HTTPS site from an HTTP site in the same browser

Most cross-site web app vulns can be exploited from an HTTP page, even against HTTPS pages. This includes XSS, CSRF, clickjacking ("mixed content" blocking usually prevents hosting insecure content in a secure parent, not the other way around), Rosetta Flash (JSONP reflection attack), and so on.

Some attacks against TLS and especially HTTPS also require the victim to visit a HTTP site while signed into the target HTTPS site. For example, the weaknesses in SSL3's handling of CBC-mode ciphers (POODLE attack), RC4 bias attacks, compression-related attacks such as BREACH and CRIME, and probably some other attacks all require that the attacker run a script on the victim's browser that programmatically makes thousands of customized requests - typically cross-domain, and often though not always originating on an HTTP origin - to the vulnerable HTTPS site.


Best practice advice - folder security (windows environment)

You're on the right track for the most part, though I disagree about the Domain Admins.

Since you mention best practice, I'll start off with stating that you should only use security groups in assigning permissions and privileges, even if there is only one member in the security group.  Think role based rather than individual user based.  In a smaller organization this is less important...but best practices and all.

Administrators might mean local, Domain Admins, Enterprise, or whatever is applicable to your environment...

In most cases, it would be appropriate to break inheritance as you suggest and grant access only to the user/group needing access and SYSTEM. Depending on the content and environment, many admins would also leave Administrators. The user(s) should be informed that they can lock themselves out, etc. since they are the sole owner, etc.

Special consideration should be given to backup and restore.  Should this directory/share be backed up?  Does your backup protect ACLs on backup/restore?  Does your backup solution use the SeBackupPrivilege, which allows backups in spite of ACLs (most do, but some simple ones do not)? Security should be maintained not only in production, but through backup and restore also...  This is particularly important in an environment under regulatory compliance such as SOX, HIPAA, or PCI.

Keep in mind that as an Administrator you can change ownership of the file or directory object and then change permissions to fix anything if need be.  This is why Administrators is often removed from the ACL.  This is generally appropriate because such activity would be logged or audited.  If you only gain access by changing ownership you can't be accused of accessing sensitive data without proof ;-)


Is this way of encoding cryptographic hashes safe?

This is almost a perfectly fine practice, but it has a bit of a flaw.

In general, a hash is just a numeric value, and you can express it in whatever base you please. For example, you could convert your hash to binary and express it as base64:

   2   6   b   a  ...
   |   |   |   |
0010011010111010  ...
      |      |
      T      u

However, the serious problem with your approach here is the clustering of the output. Three hex digits may transform into either one, two, or three base62 digits. There is no reliable way to decide how to cluster the base62 values. If you had leading zeros (i.e., you transformed three hex digits into three base62 digits) and/or used a larger base (e.g., three hex digits could map onto exactly two base128 digits with leading zeroes), you could avoid this problem.

To see a practical example of this, consider that hex f43 maps to base62 111 and 03f maps onto base62 11. Consider the impossibility of distingusinging between the base62-forms of the following hashes:

f43f43f43f43f43f43f43f43f43f4303f03f03f03f03f03f03f03f03f03f9991
03f03f03f03f03f03f03f03f03f03ff43f43f43f43f43f43f43f43f43f439991
03ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff4303ff439991

All of these hashes transform into

11111111111111111111111111111111111111111111111111CC1

There is no way to know which 1s are part of a three-character group and which are part of a two character group. Obviously, this is an extreme example, but the problem will arise any time a group has a leading 1 that is ambiguous.

However, three- and one-digit output groups only happen for 314 out of the possible 4096 values that group can be, and there will only be ambiguity for a fraction of those cases. A comment from Gilles, below, estimates the resultant truncated value will preserve 254 bits:

  As far as we know, the bits of a SHA-2 hash are independent. This truncation doesn't exactly strip bits, but it's close enough that it should be independent too. The non-uniqueness concerns only about lg(12³-62²)≈0.1 bit per 3 hex digits, so the result should have roughly the strength of a 254-bit hash.

The loss of two bits is obviously not optimal, but it's far from a devastating loss.


Is refreshing an expired JWT token a good strategy?

Refreshing a token is done to confirm with the authentication service that the holder of the token still has access rights. This is needed because validation of the token happens via cryptographic means, without the need to contact the authentication service. This makes the evaluation of the tokens more efficient, but makes it impossible to retract access rights for the life of a token.

Without frequent refreshing, it is very difficult to remove access rights once they've been granted to a token. If you make the lifetime of a token a week, you will likely need to implement another means to handle, for example, the deletion of a user account, changing of a password (or other event requiring relogin), and a change in access permissions for the user.

So stick with the frequent refresh intervals. Once every 15-minutes shouldn't be enough to hurt your authentication service's performance.

Edit 18 November 2019: Per @Rishabh Poddar's comment, you should generate a new refresh token every time the old one is used. See this in-depth discussion of session management for details.


It looks like a possible SQL Injection. ' is used to limit strings in SQL, hence with your ' you delimit it.

It seems like the FLAG string was not properly escaped, so the flag gets returned when you add the character delimiter.

It's a common technique for people testing SQLi vulnerabilities. Web CTF has a lot of guessing in it, so be prepared to keep guessing.


... leads to the injection

The flaw does not lead to the injection but it allows an attacker to inject data. I.e no inadvertently data corruption but a targeted modification by an attacker.

  How does the attack vector work?

Since you've referenced the paper I would expect that you've read it. Which parts you did not understand exactly? But to summarize it a bit:

The hard part of taking over a TCP connection is to guess the source port of the client and the current sequence number
The global rate limit for sending Challenge ACK's (100/s in Linux) introduced together with Challenge ACK (RFC5961) makes it possible in the first step to guess a source port used by the clients connection and in the next step to guess the sequence number. The main idea is to open a connection to the server and send with the source of the attacker as much RST packets with the wrong sequence mixed with a few spoofed packets. By counting how much Challenge ACK get returned to the attacker and by knowing the rate limit one can infer how much of the spoofed packets resulted in a Challenge ACK to the spoofed client and thus how many of the guesses where correct. This way can can quickly narrow down which values of port and sequence are correct. This attack can be done within a few seconds.
And of course the attacker need to be able to spoof the IP address of the client which is not true in all environments. It might be possible in local networks (depending on the security measures) but ISP will often block IP spoofing when done from the usual DSL/cable/mobile accounts.

But to really understand the attack you need to understand what Challenge ACK's are used (defend against off-path TCP RST) and how they work. Thus it might be useful to read the RFC 5961 too.

  randomizing the value in /proc/sys/net/ipv4/tcp_challenge_ack_limit .. Is it true?

Setting it to a random value and keeping it there will probably not help because the attack can figure out the new static limit. Changing the value every few seconds will help to confuse the attack. Setting the value to a very large value will also make the attack impossible.


SYN scan, determining scan vs large file upload

When you're performing a syn scan, most ports are going to have one of two results.  If the port is firewalled and configured to silently drop, no packets will be returned for most ports, so you'll see very close to 0/t packets returned.  If you aren't silently dropping you will see 1 RST packet for every SYN.  You will have very close to a 1:1 ratio of sent to received.

If you do a large file upload via TCP, the connection will be ACKd every w packets, where w is the size of the tcp window, so you will have very close to a 1/w sent to received packet ratio, where normally w << t.


Is it possible to make a login safe without a TLS certificate?

If you control the client and server software completely, you can re-implement enough of TLS for security without bothering with public key infrastructure (PKI) - the certs and such - by hard-coding the trusted public key(s) into your client. This is a terrible idea, though; TLS is really, really hard to get right (witness the constant stream of bugs in libraries like OpenSSL) and contains a lot of stuff learned in decades of trying to perfect transport-level security (SSL 1 was so insecure it was never published, SSL 2 was found to be insecure pretty shortly after publishing, SSL 3 was found to be insecure a few years ago and is deprecated, TLS 1 - essentially SSL 3.1 - has in turn been deprecated by newer versions, etc.).

Trying to do authentication without TLS or something like it is not going to be secure. Technically there exists a protocol, Secure Remote Password, for authenticating securely over an untrusted network, but it doesn't support registration (you need to have some other secure way to tell the server the user's credentials) so it is probably unsuitable for this. There exist ways to be secure against a passive eavesdropper, such as HTTP Digest authentication, but an active man-in-the-middle - which is easier to get than you might think - can still compromise such schemes.

If your hosting provider genuinely won't permit HTTPS (and dear $DEITY what is wrong with them?), find a different one. For hobby projects or small-scale prototypes, there are tons of free providers. While you're at it, have a care for how you store and look up passwords; simple hashing (even with a salt) is insufficient, and beware of issues like SQL injection. Additionally, if the server and client exchange any information other than the login request and response, make sure the other endpoints have adequate security (HTTPS or similar, but also proper authorization checks, no XML attacks, deserialization attacks, etc.; web services are easier to secure than web sites, but there's still a ton that can go wrong).


Is there such a thing as a "Black Box" that decrypts Internet traffic?

Yes. It's called a Man-in-the-Middle attack. You terminate the SSL session at a mid-point, thereby having the encryption key, then create a new session to the target server, so you have that encryption key too. The data path now goes User->MitM->Server, where each of the arrows is an encrypted connection. Data returned from the server goes Server->MitM->User, again, where each arrow is encrypted, but the other points are not.

There are ways to prevent this from working, but in the case of a government mandated system, it seems likely that these will be specifically avoided - there may be regulations for companies to provide valid certificates for the "black boxes", so that HPKP keeps working, for example. It is unclear whether such rules would apply to companies which don't operate directly in the UK, or whether there would be penalties for attempting to bypass these rules (for example, by the use of VPNs based in other countries).

Edit based on comments:
Note that it is technically possible to create such a device, but the problems mostly come from requiring cooperation from a large number of parties. As a government, there are options available which aren't possible for smaller actors. For example, it would be possible (if unlikely) to require that all internet connected devices sold in the UK come pre-configured with a government issued root CA certificate, and to prosecute anyone using a device which does not have this installed. This would be terrible for internet security, but so is the overall concept, so it depends on security experts convincing the government just how bad this idea is.


Should Windows 2008 R2 be used as an externally facing DNS name server?

I think you summed up the benefit pretty well.  You have to play in the ball-field that you are comfortable with.  Windows 2008 R2 can support DNSSEC and it is a relatively good server platform.

I'm not sure if I would go that direction, but I cannot say personally that it would be a bad direction to go.  The bigger question is does your in-house staff have the expertise to deploy this solution and keep it secure and available.  I would think you are going to stage this before you go production, why not put this side by side against some of the other options you are weighing?  What other platforms are you thinking about serving DNS?

DNSSEC Deployment Guide

EDIT : Added URL for Windows DNSSEC Deployments


Using and creating a custom 2 way encryption function

You should not attempt to create your own crypto algorithm for production use. Creating crypto systems is work for highly specialised teams of cryptographers, but everybody needs to start somewhere off course. ^_^

Instead, use a well known cryptographic algorithm. If at all possible (and it is possible), use a class that encapsulates all the configuration options for you and provides dummy proof methods.

Take a look at:

Pixelfck/SymmetricEncryption For an easy 'drop-in' solution (their words, not mine).
Libsodium For a more elaborate (hence a bit complex) library.

Normally, I would say: whatever you do, don't go editing the source code provided: a tiny seemingly insignificant edit can jeopardize the whole library, and you won't even know it.

BUT: since you indicate that you want to learn from it, studying and toying around those two solutions may give you a nice start.


Does quick denial tell that you passwords are stored in plain text?

You can't make that assumption.  Hashing occurs extremely fast, even a password that's salted, and uses a secure "slow" algorithm (or even chained set of algorithms) is going to return very fast (for humans).  A ballpark estimate for using PBKDF2 with 10,000 iterations for each logon  attempt could handle 100,000 attempts in a second (when only looking at hashing time).  What seems like "instant" to you is actually quite a long time to the system.

Also remember the page may not have to reload any content, it could have the dialog already rendered just not displayed.  Or the page could use a persistent connection rather than creating a new connection when sending the credentials.  Both speeding up the responsetime.

That's not to say the error for an incorrect username/password can't reveal information.  Some sites will return their error message faster if the username is invalid (and thus didn't bother checking the password).  This can lead to an attacker enumerating account usernames.

Hashing estimates : https://stackoverflow.com/questions/11298184/about-how-fast-can-you-brute-force-pbkdf2


How to generate an OpenVPN 4096 or 8192 bit static key?

The static keys are used to derive symmetric keys and authentication keys. There is no need to have a larger key. In fact, it would have been perfectly fine if OpenVPN used a 256-bit static key and used a KDF (Key-Derivation Function) to expand it into however many bits it needs. It's important to know that symmetric cryptography differs from asymmetric cryptography in that you only need enough bits to make exhaustive search impossible. Larger key sizes do not meaningfully improve security.
According to OpenVPN documentation, the 2048-bit key houses four independent keys which are used for encryption and authentication. You can't increase the size because no more bits are needed.


How can Avast detect threats when I install Kali on VirtualBox?

This is not exclusive to Kali. If you run an apt upgrade for metasploit or mimikaz (from, say, Parrot in a VM), chances are you'll get the same alert from your AV. The reason is that the packet goes through the host machine first (then gets caught by your AV) before being handled by your VM.

  and is normal that be detected as virus? Is false positive?

It's not false positive. It's not a virus either in a sense that it'll cause harm to YOUR machine. Note, YOUR. There are exploits and/or scripts in Kali that can legitimately cause harm and is intended to cause harm to identify vulnerabilities in a system.


Try "acme-tiny"
There is an alternative "Let's encrypt"-client project called "acme-tiny".
It is less automated, but smaller. In their own words:

This is a tiny, auditable script that you can throw on your server to issue and renew Let's Encrypt certificates. Since it has to be run on your server and have access to your private Let's Encrypt account key, I tried to make it as tiny as possible (currently less than 200 lines). The only prerequisites are python and openssl.

Also: regular client in manual mode.
If you trust the general letsencrypt client, but only want to manually create the CSR, you can follow the steps outlined here:

Thomas Pircher, tty1.net, 2015-12-03, Using Let's Encrypt in manual mode (Archived here.)

And the heart of this idea is this line:
letsencrypt certonly \
    --authenticator manual \
    --server https://acme-v01.api.letsencrypt.org/directory --text \
    --email webmaster@example.com \
    --csr signreq.der


Have you created a CA Singing Certificate for your CA? That is the step where you specify the details of your root CA, which will appear in all certificates that this CA creates. This answer is basically a digest of these somewhat terse instructions for setting up your CA that I found on google.

So it looks like before your CA can produce any signed certs, you need to create both a CA signing key (your MYMASTERKEY) and a CA self-signed certificate based on MYMASTERKEY (I think this is what you're missing):

The following command will ask you all sorts of questions about your CA - the information that will appear in certs that it signs - and then it generates the self-signed CA Signing Certificate CAcert.crt:

openssl req -new -key MYMASTERKEY.pem -x509 -days 1095 -out CAcert.crt

Once you have "configured" your CA by creating a CA signing cert, then you can take your client's Certificate Singing Request file (*.csr) and create a cert from it:

openssl x509 -req -days 365 -in MYKEYREQ.csr -CA CAcert.crt -CAkey MYMASTERKEY.pem -CAcreateserial -out clientCert.crt

The resulting clientCert.crt is what you give back to the client for them to install in their webserver, use to sign email, wtv.

Just for completeness for future readers, here's the steps that a client would have to take in order to submit a certificate request to the CA:

1- Generate a key

openssl genrsa -des3 -out <new.key> 2048

2- Generate a certificate signing request

openssl req -new -key <new.key> -out <new.csr>

The <new.csr> file is what you send to the CA to be made into a certificate. Note that the above command will ask you all sorts of questions about the organization or domain that you are requesting the certificate for. If you are planning to submit this to a public CA, then you will want to think carefully about what to put in there.


The key is first put through an algorithm called a key schedule, which splits it up and expands it into a number of 128-bit round keys. These round keys are always 128 bits in length, regardless of the size of the AES key itself. Each of these round keys are fed into the end of each single round of the block cipher using the XOR operation. AES128 expands a 128-bit key into 11 round keys, AES192 expands a 192-bit key into 13 round keys, and AES256 expands a 256-bit key into 15 round keys.

The internals of the AES algorithm are described excellently in A Stick Figure Guide to AES.


How can I prove to a third party that I'm sending the emails I'm supposed to?

I guess it depends on the context, and what a proof would consist of.

It's possible to prove that something was written at a certain time using a timestamping service or protocol. Essentially you just need someone to sign your document along with the time of the signature. There are services that do this at a not-insignificant fee, and there are also "outside-the-box" solutions that accomplish roughly the same task.

But all of these prove that something was written, not that it was sent (or more appropriately, received).

The concept of "sent" is pretty hopeless if not paired with "received", since I can send you an email, but keep it trapped on my own server for some time (and in fact modify it if desired), before eventually letting delivery happen. Likewise, your mail server can "receive" an email but not insert it into your mailbox (think spam trapping).

So, the only useful concept here has to be round-trip verification. If you send an email, and your recipient sends back a reply (preferably signed, and including the claimed signature time), then you can prove that the recipient claimed to receive your email at a given time. It's not quite the same thing, but it could be appropriate for your needs. Alternately, you could use a trusted timestamping authority to certify the time the signed receipt was received.

Some other variation on these concepts might instead be appropriate; all depending on your needs.


Using unencrypted protocols with IoT devices

The same as using plaintext (unencrypted and unauthenticated) communication elsewhere.

What exactly that means, depends on your threat model.

Smart Bulb, Dumb Protocol

Imagine you had a smart lightbulb in your home. You could use an app to control the brightness and the warmth of the bulb. It even offers an API, so you can control it via a Raspberry Pi too, if you wanted. Sadly, the bulb doesn't offer HTTPS, so all your communication is in clear text.

It may sound terrible, but it's probably fine. Why? Because in order for an attacker to do something about it, they'd need to be in the same network as you. And if the attacker is already in your home network, then you probably have more problems than a dumb smart bulb.

But what could an attacker do?

For once, an attacker can read what you send to the bulb, and what the bulb sends in return. This is most likely something like:

POST /api/brightness HTTP/1.1
Host: smartbulb.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

brightness=0.73

And the response would be something like:

HTTP/1.1 200 OK

{"error":false, "status":"STATUS_SUCCESS", "data":{"newBrightness":0.73}}

All in all, very boring data. Yes, technically, your confidentiality was violated, but in this scenario, that's not very problematic. The attacker knows your bulb is set to 73% brightness.

Of course, an active attacker could do more. They could modify what you send to the device, and also what the device returns. Depending on what you do with the data, this might be dangerous.

How can I protect myself?

You can't. Well, technically you can, but it requires some fiddling. Okay, a lot of fiddling. If an IoT device does some task like sending e-mails, but doesn't encrypt them, you can at least use a proxy to remove any sensitive information before an e-mail is sent. It's a lot of work, and will give you very little benefit.

It's easier to just forbid communication with the outside world, if this is possible.

How can developers fix this mess?

Developers can use ciphers specifically designed to require low power consumption and low memory requirements. Yes, it'll make the product more complex to design, and it will make the end result more expensive, but it's more secure than the alternative.