How do I educate others about social engineering?

When I've been asked to setup some presentations about security awareness, I've always used something that is familiar to the user base to demonstrate weaknesses that can be exploited.

Let's take a simple organization, Acme. Acme has about 200 employees, a robust IT infrastructure, top-of-the-line firewalls, secure applications, a smart CISO, etc. Their wireless is WPA2 with RADIUS Auth which uses the user's AD credentials. They also use Outlook Web Applications (OWA) a lot.

If this was an organization I was demonstrating an attack to, I would first set up a phishing site that looked just like the OWA installation. It's ridiculously simple to do with something as accessible as wget, or you could use Trusted Sec's Social Engineering Toolkit to set it up. Once you do that, change the login form so that the username and password entered goes to your own database/file store—or, you can once again use SET's credential harvester. Optional: Buy a domain, such as acme-corpwebmail.com or something like that.

The next thing to do is send a sample email to yourself. It can be something along the lines of how there's an IT upgrade and people need to validate their accounts—focus on the email being believable, with good English, something that can be trusted, even. Log in with the credentials, and show that they get captured.

Use the same credentials to log in to the corporate network (since it is AD credentials after all). Now an attacker has access to everything an ACME employee has access to, and he hasn't even broken an application or entered the building. He can be sitting outside the parking lot the whole time.

Want the extra effect? Make this whole thing a really cool video. It's not hard to do, even if it takes a little extra time.

Once you show how an attacker can get in, focus on what the employees need to do to protect themselves—i.e., make sure that the email is from who it claims to be from. If in doubt, ask the person if they sent an email—it's okay to waste the person's time if it means being safe. If the link is external to the organization, ask the person/the security team before clicking on it. If it is external and asks credentials, assume it is malicious unless told otherwise.

From personal experience, I can tell you that this has been very effective—it makes an impression on people, even if it builds paranoia in some—and a certain level of paranoia is always good. :)

If you want to take it to the next level, I really do recommend checking out what SET has to offer. Dave Kennedy and all the others who have worked on it have done an absolutely amazing job on the tool, and it provides all the tools necessary to teach people about social engineering.


Develop and test a vulnerable login system

In my opinion the easiest way to prepare and test login page vulnerable to SQL injection is without CMS, as follows:

Prepare a HTML web page containing a POST form with fields "username" and "password"
Prepare a DB with table "users" and columns "username" and "password". Populate it manually with a couple of plausible entries.
Prepare a PHP page that receives the POST and opens a DB connection searching for matching DB records where both values match.
Depending on whether a match is found you should return a different message and open a session or not.
Test the page automatically with the software SQLmap or OWASP ZAP and/or test it manually using a local proxy (e.g. Fiddler)

The pivotal point is that the vulnerable PHP page forms the SQL query by concatenating strings (this allows the attacker to forge the ending part of the query, bypassing login or extracting information from the DB). The non-vulnerable page should build the query using prepared statements. If you use a CMS then you should use its own login or anti-SQL injection security features.

A proper login page would also incorporate other security controls like account lockout, password hashing etc. but I think they are outside the scope of your exercise.


Can a smartphone get hacked even when off?

I believe it won't cause it's "turned off". But I think the case is different when your phone is "turned off and charging". You notice when charging that some stuff appears in your screen? Those are programs that run when the device detects that it has plugged into a charger.

But alas, I do not have the knowledge to exactly know the actual things happening underneath all those fancy displays when your phone is charging so I can't really tell if those programs could actually wake and take control of the wireless controller within your Smartphone. But even so, it's not possible to magically hack your phone with this fact because those programs would never wake the wireless controller even if they are capable of doing it.

The only case they will wake it up is if they have been infected/turned rogue by a hacker in the first place that was already able to get high-level access to your phone while it is turned on.

So to TL;DR answer your question.
No, it is not possible to magically hack your phone when it is turned off and even if it is "turned off and charging".

Side note: I do not know if it is possible to turn on a smartphone while it is connected through USB but actually hacking your phone involves it being turned on first. Only then can the hacking actually take place.


Why context sensitive encoding to prevent XSS?

I'm going to use a few examples where various forms of HTML encoding will not help.  All of these are cases I have actually seen in practice.  I will use {{foo}} for the variable to be substituted.  I assume HTML encoding involves replacing < with &lt; and > with &gt;.  If you also escape both single and double quotes, some of them will no longer be exploitable, but some will be.

Clicky

{{foo}}

You might want to check out this blog post for more details.


Contacting customers of vulnerable software, is it wrong?

There are better ways.

If your intention is to inform customers for purely altruistic purposes (and/or, to pressure the vendor to fix, whether or not you receive financial benefits), then there are other avenues you can explore.

You could, for one, contact your local CERT, or the CERT you believe could pressure the vendor into fixing (for the US, see http://www.kb.cert.org/vuls/html/report-a-vulnerability/).

You can also request a CVE (https://cve.mitre.org/) in order to make the vulnerability public, not just known to existing customers.

There are probably a whole ton of other options, but those are (hopefully) a reasonable starting point.

Consider too these provide some kind of peer-review, to make sure you have what you think you have.

If you are intending to contact customers for profit, then the question of how you know who they are would sort of become salient, and you would most likely be considered to be cold calling, which over email (or other mediums) may have consequences, for example related to CAN-SPAM if you are US-based.

I am not a lawyer, but this seems kind of shaky ground.

And the vendor isn't likely to feel warmly towards you if they find out.

If you really don't care about ethics, there are private vulnerability marketplaces you could consider.
This will not lead to any fixes, but exploitation of the bug and personally, I would not feel this the way to go.

Basically: if the vendor isn't paying you for a vuln, then I think (and this is purely opinion) that a public report will make them more likely to do so in future.

Closer to home, you could also check out How to disclose a security vulnerability in an ethical fashion?


Why do SSL enabled sites don't reply back according to "hosts" file record?

The error message indicates that the server expected a HTTP request but got a HTTPS request: \x16\x03\x01\ is the start of an TLS record. This probably means that your server configuration is wrong, i.e. that the server expects HTTP on port 443 and not HTTPS.


can someone manipulate what text shows up on the screen when google shows some examples of addresses that are available?

Not likely. Under normal circumstances this username is generated on one of Google's servers and transported securely to your client.

Of course if your phone has malware it can show anthing, but in that case it is unlikely that only the seemingly random number is changed.

I think you are the victim of confirmation bias or attribution bias. 187 is just a random number, but you interpret it in such a way as to confirm your suspicions.


What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains?

Your premise is wrong.  Script tags and JSON don't bypass the same-origin policy.

The same-origin policy says that evil.com should not be able to read the responses for arbitrary resources on victim.com.  Note that Javascript from evil.com can trigger nearly arbitrary requests to be sent to victim.com (e.g., by creating an IFRAME pointing to http://victim.com/whatever.html).  However, the Javascript from evil.com cannot read the contents of that document: i.e., it cannot read the response to that request.

Now perhaps what you are thinking of is that evil.com can ask the browser to load arbitrary code from anywhere on victim.com and then execute it with all of evil.com's permissions.  That's not a bypass of the same-origin policy.  (Note also that it tends to be a security risk, for the party who is loading Javascript from third-party sites.)

XHRs have to be restricted, because XHR allows Javascript to not only trigger a request to be sent, but also allows Javascript to read the response.  The same-origin policy forbids that, for cross-origin requests.  The same-origin policy says that reading the response is something that should only be allowed if the request is to the same origin as the origin of the Javascript code.  Thus, Javascript from evil.com is allowed to issue a XHR to http://evil.com/doit and read the response, but it is not allowed to issue a XHR to http://victim.com/doit and read the response.

If you want to issue cross-origin XHRs, then the target domain will need to authorize you to send it cross-origin XHRs.  Look into CORS for ways to do that.


How can my IP camera be hacked behind a NAT?

The cameras are often designed for ease-of-use by people who want to watch the streams of their goldfish or children.   To make it easy to use, the cameras often call home to the manufacturer's website for remote viewing.  Often these sites are insecure.

Another method is UPnP sets up automatic port forwarding:

https://en.wikipedia.org/wiki/Universal_Plug_and_Play#NAT_traversal

  One solution for NAT traversal, called the Internet Gateway Device
  Protocol (IGD Protocol), is implemented via UPnP. Many routers and
  firewalls expose themselves as Internet Gateway Devices, allowing any
  local UPnP control point to perform a variety of actions, including
  retrieving the external IP address of the device, enumerate existing
  port mappings, and add or remove port mappings. By adding a port
  mapping, a UPnP controller behind the IGD can enable traversal of the
  IGD from an external address to an internal client.

It's easy to disable these features if you're aware of them.


Making transactions only, or almost only, by QR codes

That probably depends on the banking application and how the bank allows you to recover a lost PIN. I would normally say "you should enable PIN or fingerprint authentication", but in fact you might not be required to. PIN/fingerprint is breakfast for security-aware individuals.
Let's analyse the few information you provided. That you are enabled to pay by QR and that you would like, as myself does, to manage all payments via smartphone.
I will not disclose the name of my bank, but will describe what major banks in Europe normally do. You did not describe how your bank works in the first place
Authentication at banking application level
Assuming you don't have fingerprints enabled, and/or if your bank app doesn't (yet) support that, most banks will, despite the great security APIs of Android, issue you a yet-another new PIN code that is valid only for themselves. It can be equal to your phone's PIN if they allow you to choose.
Since you have to reauthenticate at the banking application ever time you do something, from checking your balance to making a payment, they will be safe. Even if you lose your phone and who finds it has access to Whatsapp and all your emails, they will likely have no immediate access to your banking account. I will be writing a huge footnote.
That is the only security measure you can have, but depends on your bank. Note: we could write an entire book for this paragraph, including OTPs and PSD2 (European Payment Service Directive 2) but those will go beyond the scope of the question, which is about the security measures the OP can take.
Geolocation
A lot of banks require customers to disclose GPS location when doing anything. I am a bit skeptic about anti fraud systems, but at least on paper this works: they already know the location of stores where QR codes are exposed. Once you issue a QR payment, you are supposed to be at the place. QRs can still be sent over Whatsapp, printed and photo-copied for remote payments.
Root checking
Another things banks normally do is to limit or block functionality to rooted devices that do not pass SafetyNet hardware/software attestation.
Disclosure: I am Groot. I will never unroot. But I have to admit that they block root for a reason. Perhaps most of them because OWASP requires that.
In this case, payments with QR codes can be theoretically violated by a malicious root app that forces camera API to read a bogus static image with a QR code owned by attacker. Notice the emphasis on theoretically.
Footnote: recovering credentials on unlocked phone
This all depends on the bank. Losing an unlocked phone with access to email and messaging is dangerous per se, but might or might not be enough to steal money to you. I have already talked about banks requiring you a separate PIN/authentication to issue transactions.
But when you leave unrestricted access to your emails, danger is close. Let's put it extremely simply simple. If your bank allows you to recover a forgotten access code by simple means of SMS recovery and/or email confirmation, you are required to put additional security measures on your phone. A number of banks will at least require you to be physically at the branch before asking you for email/SMS confirmation. If your bank falls in this category, you still might have chances to live without PIN and fingerprints.
Summarizing
Most depends on the security model of your bank. It is trivial to require everyone to use a strong authentication to the phone, but as I have illustrated while banks do enforce their own security in banking applications, odds are that, according to the practices of your bank, you could have a big hole open in your security by leaving the phone unlocked.


Basically, they don't have to be.

While merchants and service providers are often contractually obligated to be PCI-DSS compliant, payment applications tend to be PA-DSS (Payment Application Data Security Standards) compliant and certified (if they want to be used by merchants who wish to maintain PCI-DSS compliance).

According to the PCI Security Council's document, Mobile Payment Acceptance Applications and PA-DSS Frequently Asked Questions:

  Applications used for payment-initiation—for example, those
  downloaded by consumers onto their mobile phones and used for consumers’ personal
  shopping—are seen as similar to the payment card in a consumer’s wallet.

Since Revolut isn't taking payments (well, really they are, but that's a different function than the one you're referring to), but rather acting as your personal, digital wallet in this case, the PCI Security Council doesn't see it as any different than the wallet in your pocket.


Can viruses actually inject their code in other processes?

You can use DLL Injection to inject code into other processes without affecting any other data
(depending on the method, of course).

Other ways include renaming and moving legitimate files and replacing them with infected versions, startup entries, etc., but those are easily removable manually.

The only way that I can think of to permanently infect without personally using OS patches or other data modifications is to use a startup entry to load a rootkit driver such as Migbot or FU that also includes function hooks to hide files and registry entries, making it impossible to remove manually.

However, this type of rootkit usually uses kernel patches, which modify the binary OS data on disk (making a reinstall necessary to completely disinfect) and defeats the whole purpose of not modifying data.

The only alternative is to stay out of the kernel and use a normal process to run the malware and use Windows Message hooks or something similar to apply hooks without modifying data.

There is a downside to this approach though... Userland hooks are very easy to detect, compared to kernel OS patches.

So, therefore, it is possible to have malware that does not modify data, but it is easily detected and removed by any half-aware antivirus/rookit software, which means that not many (if any!) in the wild malware will use non-modifying approaches because patches and such are much better from a stealth standpoint (and sometimes even easier than non-modifying hooks!).


What is the best way to enhance weak keys for mysql aes_encrypt() function

The key in the case of above mentioned function is padded with zero when its length is less than 16 bytes.

That's indeed something you need to address. AES keys should always be 128, 192 or 256 bits in size, and indistinguishable from random to an attacker.

  My question is: How can I perform a key stretching with something like PBKDF2 in mysql to enhance the strength of weak keys.

I'd strongly suggest not to perform such a function within the database queries itself. PBKDF2 (or any other function) needs to be as fast as possible to make the possible advantage of attackers as small as possible. Otherwise the work factor (the iteration count for PBKDF2) cannot be large enough.

Try and find an optimized version of PBKDF2 and integrate it with your software.

  Also I would like to know that if I use a hex value directly from a function like SHA2('Key', 512) as my key for the aes_encrypt() function, will it reduce the strength of the key because there will only be 16 characters in the character set every time a key is generated.

The output of SHA-2 functions consist of bytes, not hexadecimals. It might be that your implementation automatically translates this to hexadecimals. In that case you need to specify raw output explicitly or you need to decode the hexadecimals to use it as AES key.

The problem with just SHA-2 is that it doesn't expect a salt nor a work factor. This means that dictionary attacks and rainbow tables are valid attack vectors. This is why you need a Password Based Key Derivation Function such as PBKDF2.

PBKDF2 is only not needed if the input "password" has sufficient strength. But for AES encryption, you'd need something close to 128 bits of randomness, and that's unlikely to be provided by any password in itsef.


Identifying device based on the MAC address

It could be any product, not just any Apple product.

The first 3 bytes (24 bits) of the MAC address identify the vendor of the NIC (Network Interface Card). If Apple owns the blocks 00:00:01 and 00:00:03, then MAC-address 00:00:02:00:00:01 could belong to Cisco as well as any other vendor.

And besides, almost every NIC allows changing (spoofing) the MAC-address. They are not really that reliable, especially when people know you are trying to identify devices based on their MAC-address.

Edit: In reply to your edit, yes those would all be from the same NIC vendor, given that the user has not changed his MAC-address manually.


Locality Sensitive Hash (LSH) function to approximately match old passwords

A locality-sensitive hash function by definition does not posess the avalanche effect (http://en.wikipedia.org/wiki/Avalanche_effect), which is a key property for a cryptographic hash function.  The properties desirable for LSH are essentially the opposite of what is desirable for a cryptographic hash function.

Effectively, storing the locality-sensitive hash of a password is hardly any better than storing the password in the clear.

A simple method that can be used to check if a password is similar to a previous one, without deviating from the recommended practice of only storing a salted cryptographic hash of the password, is to simply use some method to enumerate a bunch of similar passwords to a given password (e.g. altering, adding or removing a letter), and then for each previous password, compute the hash of each similar password with the appropriate salt to see if it matches.  If an extremely slow password hash is used, however, this method could be problematic.


Is it possible to load an endpoint agent in my Heroku environment? ie: Carbon Black, Crowdstrike, etc

Such endpoint agents require access (and typically root access) to be able to run. As Heroku is just a PaaS for deploying your code, you do not control the environment that code runs in. As such, you will not be able to load an endpoint agent into your Heroku environment.

What you can do for more control and monitoring, is to implement and/or improve the logging of the application you deploy in Heroku.


Mobile Broadband, e-Fraud & Anonymity Against My Website

Conviction depends a lot on the legal system; things are really different depending on whether he is caught by legal forces in Sweden, Belarus, Canada or Ouzbekistan, who have somewhat distinct notions of rights of the accused. Hard disk encryption is here a gimmick to try to evade incrimination, but it won't work by itself, because many countries have laws which will force you to reveal decryption keys (or they will just break your thumbs, depending on the country). What your hacker would need is plausible deniability. TrueCrypt attempts at supporting that, but, to my knowledge, this has never been tested in court.

Tracking is another matter. For the serious cases (e.g. wide terrorist actions), police forces throughout the World will collaborate to tap wires, invest caches, follow people in the street, bribe, interrogate and shovel; and they will usually find out perpetrators because human beings are full of chemical activity and leave traces everywhere. Historically, people who could evade coordinate police action for long periods are people who benefited from at least tacit collaboration of lots of people.

Your attacker may want to stick to "crowded places" but analysis of security cameras will show who was in that area; over time, correlation will pinpoint the specific individual.

Of course, no such wide-scale operation will occur for something as trivial as hacking a Web site. Let's face it: you are not worthy of the full power of police forces. They may still be interested in your story because attackers often have other activities; someone who hacks Web sites repeatedly may also be involved in a quantity of other illegal activities, and will probably be in touch with other people so inclined.

(The implicit message I want to make here is that while hacking occurs in computers, humans are involved, and that happens in the physical world, subject to possible investigation methods which have been honed by policemen for the last two centuries, since the term "policeman" was invented, actually.)


How can encrypted messages from proton mail help data requesters?

What you shouldn't forget about encrypted e-mail, is that while the message body is properly encrypted, some meta data like the subject, sender or receiver aren't.

The subject of the emails, together with the metadata to link the sender-person to the receiver person, can be very valuable.

In an example of a terrorist case, someone who has been suspected of planning an attack, who happens to be mailing with a lot of users that have known terrorist group links, can be enough proof to assume that he was at least involved with them.

This could be a pointer that our suspect is actually what we think he is!


Metasploitable: Change/Location of login page file?

It's been awhile since I've played with this and it can be distro specific but try looking in /etc/issue as mentioned here.


What does the POST data of HackBar (Firefox add-on) do?

It does exactly what it says, it sends a POST request.

If you check "Enable Post Data", the request method will be changed from GET to POST. All data that you enter in the "Post data" field will be send in the body as POST data. The resulting HTTP request will look like this:

POST /?foo=bar HTTP/1.1
Host: example.com
Connection: close

test1=test&test2=test

Compare this with a GET request:

GET /?foo=bar HTTP/1.1
Host: example.com
Connection: close

You can see that the HTTP method is different, and that a GET method will not send a body.

In Burp, you can either just capture an existing POST request and change it on the fly or send it to the repeater, or you can use "right-click -> Change Request Method" on an existing GET request (or just build the whole request from scratch) to send a POST request.


How could `iptables -F` lock me out of the server?

iptables -F does not change the default policy. So when you set it to DROP and do a flush afterwards, it stays on DROP.
I use the following commands to flush the tables

iptables -P INPUT   ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT  ACCEPT
iptables -F
iptables -X

This changes the default policies to ACCEPT for all filter chains, flushes the rules and removes all custom chains.


PGP question decrypting my own message from 2 days ago

I notice that "encrypt to self" is not included until 0.4 of gpg4usb:

  New alpha release 0.4

  added encrypt to self functionality, so that every message additionally is encrypted for the choosen key

Encrypt to self is not usually the default with command line PGP/GPG clients - it's common for command line PGP/GPG systems to not include the sender's key in the encrypt-to list, making it impossible for you to read what you sent.

  Note: PGP Command Line, by default, does not encrypt to the default key. If you want to encrypt to yourself, you will need to specify your key as a recipient.

PGP has --encrypt-to-self for this purpose; GPG uses --encrypt-to your_key_ID instead.


Why does a SSH server need a host key-pair?

You already quite understand how the public key cryptography works and how the client is authenticated to the server using public key authentication.

The same thing is needed on the other direction. Internet and computer networks are evil place and it is quite easy to redirect traffic, spoof DNS or somehow make you connect to evil host, which would like to capture your password or other sensitive information. And it can not be ensured using public key only, because everyone can send you this public key, but only the server you want to connect can send you signature of your data that you can verify using the public key of the host.


RSA key exchange is obsolete. Enable an ECDHE-based cipher suite

It means that the cryptography from the certificate is breakable - the ROBOT attack is a good write up on how.  ECDHE uses elliptic-curve cryptography, which is faster, uses less data for the same level of security, and relies on newer mathematical techniques (although it's not necessarily a good thing...but as a quick aside ECs were needed for solving Fermat's last theorem and that only happened in 1994).

So yes, it's a legit warning.  It's probably just popping up because the site hasn't used a ECDHE cipher.  Which is far from ideal, but if everybody followed best practices I'd be out of a job.


Looking for a specific quote about keys and transparent encryption implementation

You are talking about Kerckhoffs's principle.

From the wikipedia page:

  Kerckhoffs's principle (also called Kerckhoffs's desideratum,
  assumption, axiom, doctrine or law) of cryptography was stated by
  Netherlands born cryptographer Auguste Kerckhoffs in the 19th century:
  A cryptosystem should be secure even if everything about the system,
  except the key, is public knowledge.


sniff mobile application to find whether packages sent to the third person

Typically you sniff mobile applications using a proxy system. You connect your phone to the proxy and then, obviously, all data runs through the computer/device which is running the proxy. Once the data is running through the proxy machine, you can simply open Wireshark, Fiddler, Charles, or your favorite sniffing tool of choice and start recording the packets.

Personally I prefer using Charles for mobile packet sniffing. Both Charles and Fiddler have the built in ability to set up a proxy for your mobile device which makes them perfect for a task like this. (As far as I know, Wireshark does not offer this ability.) However, despite Fiddler's comparable ability, I prefer Charles because of its HTTPS decryption options. If Viber uses HTTPS, you can use Charles to decrypt it by installing the Charles Proxy SSL Certificate onto the device. (The certificate file can be found here.) Charles does come with a price though.

Charles is a paid application and it's not too cheap. As of the time of this posting, the program is $50 USD for 1 license. Unfortunately, Charles also does not offer free updates to new major versions. So if they released a new major version, you would have to pay for the upgrade unless you purchased within 3 months of the update. Their purchase page does say you only have to pay 40% of the price for the upgrade, but that is certainly not free. Even with all of this in mind though, I do still believe Charles Proxy is a good option.

To clarify, I am recommending Charles Proxy based on my own user experience. I use Charles Proxy fairly often to sniff applications and I have never had any problems.


Hardware Implementation of Encryption Algorithm

The AES competition received 15 candidates, two of which suffered from "academic breaks" (weaknesses that are only theoretical, but still demonstrate that the underlying block cipher is not "optimally secure"). The remaining 13 are, to my knowledge, still unbroken to this day.

Therefore, the choice of Rijndael had to be done for reasons other than security. Performance, in particular ease to implement efficiently on a number of software and hardware platforms, was what mattered in the end. Rijndael was chosen because it behaved well on many systems. On a PC, RC6 was faster, but on other platforms (RISC-based CPU like Sparc, 8-bit CPU on smart cards, FPGA...) Rijndael was faster/cheaper (RC6 requires a 32x32 bits multiplication, which is cheap when you already have it, not so when you don't). For that matter, DFC was worse, since it needed a 64x64 multiplication. The "attack" described by Harvey is more an observation that reduction modulo 264+13, though it can be done without a division (which would be even more expensive), can be difficult to do properly, i.e. without leaking information (see timing attacks).

Other informal criteria included the fact that Rijndael's key schedule was fast too (contrary to, say, Twofish), and that Rijndael's inventors were from a non-threatening, non-controversial, quaint little country (Belgium), thus more likely to lead to worldwide adoption.

As another example, pretty much all of the SHA-3 competition was about performance. All 14 second-round candidates are "equally strong" (we don't know how to break any of them, even in an unrealistic academic way) but they were not equivalent when implemented in software or hardware. The ultimate choice criteria were never made clear by NIST (and it seems they changed mid-competition), but the fact that Keccak is devilishly fast in hardware (ASIC/FPGA) was certainly instrumental to its victory.


Is an SSL/TLS HTTPS certificate 'fingerprinting' attack possible?

There is no chance for fingerprint attack.

The first point here is there is no unique certs as you can create and if you try to make it , you need to add digital signature in the certificate( self signed or not ), then you require private key. Its available only with the particular person.

The second point here is you can't establish a secure communication, it will obviously fail during the negotiation.


Is it possible for someone else to add a photo to text messages I am sending?

That would require the connection or receiving app to be compromised, the former an unlikely premise for a modern app using AES, like Google Hangouts or Telegram and I don't believe that rootless apps can manipulate other app content.

In short, yes, it is possible, but if you use a modern, secure app (and don't let your ex use your phone), it can only be from a selfrooted spyware app.

EDIT (questions from comments, until i can comment):
@Steve SMS does not support photos. MMS is a viable attack vector, as it is not often encrypted. As such, migration to an AES encrypted message app is recommended.

@Neil App verification can be completed through secure hash and comparison with a known good copy.


Cloud services - A window to outsourcing illegal activities?

Services and tools are entirely amoral, i.e. they are neither moral or immoral. We, as people, often place moral value on these tools' intended and actual use. Such reasoning is somewhat fallacious, since we cannot pre-judge the intent of every possible user. Any tool intended for "good" might be subverted for "evil", and vice versa.

A screwdriver can be used to construct a cupboard, but it might also be used to stab someone. A gun can be used to oppress, but it might also be used to protect. These are simplistic examples, but the point is that the tool itself has no moral value. Our actions are what carry moral value.

The cloud is merely a concept, which makes this abstraction all the more meaningless. Whilst the term has been heavily bastardised by salespeople, the real meaning of "cloud computing" is simply placing some computational task into a distributed system. Since the task can be anything, we cannot pre-judge intent, therefore it is amoral. Thus, we should not judge such services by their potential misuse.

Sure, the bad guys can use "the cloud" for bad stuff. It opens up new attack models and improved financial efficiency when performing distributed attacks. But is that not the same for any other technology? Brain-computer interfaces, webcams, smart-phones, tablets, smart-meters (electricity / gas), SCADA, Ajax, Facebook, etc. can all be subverted for immoral means, but it doesn't mean we should stop using them. Cloud computing is no exception. It goes the other way, too - tools like oclHashcat, BeEF, Metasploit, nmap, sqlmap, etc. can be used for "evil", but they're also amazingly useful for penetration testers.

In the end, we need to just accept that these services and tools exist, and that attempting to place moral value on them is an exercise in futility. Focus your efforts on identifying the potential problems and finding solutions.


Actually, they don't even have to inject JavaScript into the main page. Extensions can require permissions to make Cross-Origin requests to certain websites, see https://developer.chrome.com/extensions/xhr. They can even use the <all_urls> permission to get Cross-Origin access for all websites. This is not a security vulnerability, as you have to manually install an extension and grant the permissions on installation, making you responsible for anything that happens.


Let's Encrypt and EV certificates for different hosts in the same domain

It is possible to have multiple certificates from different vendors for different parts of the domain and even have overlapping certificates., i.e. multiple certificates which could be used to authenticate the same domain.

Browsers actually only care that a specific certificate is valid for the specific domain it is used on and don't care if the same certificate could also be used for other domains.  They also only care that all content is served over HTTPS (i.e. no mixed content) but don't care if some content is served with a EV certificate while other content is served with DV certificate only.

Apart from that, I recommend  to read Extended Validation Certificates are Dead to get a better opinion if EV certificates are worth their money at all.


What is the purpose of the authorization code in OAuth 2?

The way the “authorization code grant type” is meant to be implemented is in a web app that has public and confidential clients. The authorization code is authorized by the resource owner and the browser (public client) redirects the application to the callback URL, passing the authorization code in the URL parameters. Because the browser is a public client we should not expose the token here. Instead, the (confidential) backend of our webapp, passes that authorization code as well as client_secret to the authorization server and exchanges it for the token.

Do you see how we protect the token and api client_secret by keeping that workflow in the backend?


With GNU/Linux, this should be possible simply by mounting the / file system read-only and adding tmpfs file systems (that saves the data on RAM) for /var/log etc. that needs to be writable.
There are some caveats with this approach, though:

Any process with root privileges might mount the file system as read/write. An optical medium solves this, as it's read-only by nature. I don't know whether e.g. such SSD drives exists that have physical switches for making them read-only. Maybe there's simply not enough demand for them.
You would have to occasionally upgrade the whole image in order to get security updates. Otherwise this approach will produce more security issues that it solves.

For these reasons, I'd suggest full disk encryption for the OS drive, if it's suitable for addressing your current risk models.


Algorithm and key size to choose for SSL certificates (security and CPU wise) in 2020 (using nginx)

Benchmarks on a single core in my aging laptop (Skylake, openssl 1.1.1):

$ openssl speed rsa2048 rsa3072 rsa4096
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000662s 0.000020s   1510.2  49977.8
rsa 3072 bits 0.002078s 0.000040s    481.2  24920.9
rsa 4096 bits 0.004433s 0.000068s    225.6  14614.6

$ openssl speed ecdsap256 ecdsap384 ecdsap521
                              sign    verify    sign/s verify/s
 256 bits ecdsa (nistp256)   0.0000s   0.0001s  37387.6  12823.3
 384 bits ecdsa (nistp384)   0.0012s   0.0009s    855.6   1154.5
 521 bits ecdsa (nistp521)   0.0003s   0.0007s   2881.8   1510.7

$ openssl speed ed25519 ed448
                              sign    verify    sign/s verify/s
 253 bits EdDSA (Ed25519)    0.0000s   0.0001s  21340.9   7981.1
 456 bits EdDSA (Ed448)      0.0004s   0.0006s   2827.1   1599.6

I recommend you run the benchmark on your own hardware and your own version of the TLS library (e.g. SChannel for IIS would have different performance, but openssl adds optimized versions for different microarchitectures as features, so benchmark different openssl versions too).

P-384 is not a great curve, it's slower than P-521 because of the curve parameters, that's not an implementation quirk of openssl. NSA Suite B makes it more popular than it deserves.

In TLS, the server performs "sign" and the client performs "verify", unless client certs are used, then both sides do both (this is rarely used, if you use this you know that you do).

The EdDSA numbers don't matter because although the RFC exists, WebPKI will not use EdDSA, they will upgrade to PQCrypto whenever the HSMs for those standards are out after the standards themselves are out. I suppose for self-signed certs you can use EdDSA (I didn't try that, I don't know what supports this).

You see that the server would prefer to do ECDSA NISP P-256 signatures, because those are fast. The clients would prefer to verify RSA-2048 or bigger RSA and not to verify ECDSA, because that is slow.

The choice between RSA and ECDSA is whether you want to put more load on the server or on the client. Also, some people don't like ECDSA and it's possible some clients are too old to handle ECDSA.

The most popular choice currently is RSA-2048 and it's ok.

Note that if you only allow PFS cipher suites (and you should do that), the key for the certificate becomes useless to the attacker when the certificate expires, so it doesn't need to stay unbroken for decades.

Your ECDH is the part that needs to stay unbroken for a long time to prevent retroactive decryption of recorded traffic.

So if you read that RSA-2048 is no longer considered secure because NSA might soon be able to break it, replace your cert and you're good even for older traffic. But if you read that X25519 or P-256 ECDH is no longer considered secure because NSA might soon be able to break it - too late, they already have records of your TLS traffic protected by those primitives, after you upgrade you only protect future traffic, not older traffic.


Air-gap implementation for personal computer use

I will focus only on some problems with your approach:

The insecure system writes the CD and thus can tamper with both the data on the CD but also with the format of the CD, i.e. the file system.
This CD is then read by the secure (air-gapped) system and mounted there. Mounting is done inside the kernel (i.e. system level access) and there were bugs in the past in this area.
It does not matter if there is existing malware which hijacks this process. With your setup you are aiming more in the area of defending aganst targeted attacks and there it only counts if such malware could be developed. And I think this should not be too hard.

Also, while you encrypt outgoing mails on the air-gapped machine you need to decrypt incoming mails on the insecure machines, because otherwise you could not transform these to plain text like you want. This means that the decrypted and probably sensitive information are available on the insecure machine. If you instead transfer the encrypted incoming mails to the air-gapped machine you then have to deal with (possible malicious) attachments there.

And, while product recommendations are off-topic (but you requested these): I would not recommend any general purpose Linux distribution. Go at least for something hardened with Grsecurity or just go with OpenBSD. They are more focused on security by design and on security in depth than Linux is.


How do exploits and payloads work together?

The vulnerability is just the weakness in the software that allows an attacker to gain control.  For example (since you mentioned buffer overflows), an unchecked buffer copy via strcpy, or using memcpy with an attacker-controlled length.

An exploit is the actual process of leveraging a vulnerability.  For buffer overflows, this is the process of overwriting the saved EIP on the stack, or overwriting a function pointer, or any other process that actually gives you control of the application.

The payload is what you want to do with the exploit: it can run a command (such as a shell), open a network port and listen (a bindshell), connect back to you (a reverse shell), or generally anything else you might want to do.  Often, if you're using Metasploit, you want to start Meterpreter, as Meterpreter is design to let you leverage it to do a variety of different tasks (screenshots, execute commands, exfiltrate data, etc.)


In what cases is it ok keep a user logged in or provide auto login if an app starts?

Congratulations! You have just given a nice example that different applications with different security requirements use different approaches.

The highest requirements for whatsapp are availability and ease of use because they are targetting end users and assume that they can trade a light confidentiality risk (do not ask password on each new session) for ease of use.

On the other hand a bank application allows for financial operations. Here the most important part is to be sure of who  is at the other end of the communication, or at least to be able to prove that they have used state of the art practices to establish it. Because they do not want that another guy could use your smartphone without your explicit permission to transfer money and that you could say (and prove) that you are not at the origin of the transaction. Even if you were forced to give your password because of a rubber hose attack, they will have committen no errors, and won't be liable for any consequences of the operation.

So the rule is: the security rules depend on the security requirements. You know whether for your application, ease of use is more important that security of authentication. I don't.


is it safe to implement custom way of storing cookie in android?

Instead of how it's stored I find it much more alarming that it's transmitted over a custom network protocol. It might either be completely unencrypted or encrypted with a homespun implementation. That's how you are really going to leak the cookies.


What is the benefit of the database's information_schema for a hacker?

He can map which tables are in database as well their columns


Can two TOTP clients register at the same time and generate the same tokens?

Basically, yes.

The algorithm used relies on the secret key (often provided in barcode form) and an accurate time. Based on the combination of these, it provides a short code which the server can compare against.

In fact, the server will usually accept the previous and next codes for a while too, since either the server, or the end user devices might well be slightly out - the tolerance for this is dependent on the security of the service, where high security implementations will assume the end user has a very accurate device, and lower security ones might allow the user to provide one of three tokens at any given time.

You can test this by setting up multiple devices with a single barcode - you don't even need to scan them at the same time. However, you do need their clocks to be in sync - if they are slightly out, one will show the "old" code for a while before updating.


It can matter in some areas, notably how secure the management interfaces are. One potential issue with older switches is that they might support broken or weak encryption, which might allow an attacker to obtain credentials (e.g. the switch might only use a 1024 bit key to secure https).

Similarly, web security has improved over the years, and for switches that provide a web-based administration panel, there may be vulnerabilities in either the web server itself (lighttpd springs to mind, and has CVEs up to 2015: https://web.nvd.nist.gov/view/vuln/search-results?query=lighttpd&search_type=all&cves=on).

A lot of the risks related to these issues can be mitigated by controlling access to the administration interfaces (and the network that provides that access).
In all cases, I would generally tend to think it worthwhile to periodically review known issues and vulnerabilities, to determine what risks may be related to your equipement.

Taking for example the 2.6.7 kernel, a quick, non-scientific check suggests there are two remote exploits to be aware of:

https://www.exploit-db.com/search/?action=search&q=Linux+Kernel+2.6&type=3

I would make sure that those vulnerabilities could be detected, possibly by using or creating appropriate IDS rules. I would also check if there are anyt further remotely exploitable vulnerabilities related to the specific vendor/product.

Local exploits would be the next area I would consider, to understand the risk profile (for example, it may be that local exploits are enough of a concern you will want to prevent humans having access to your equipment, and instead write some kind of script to execute specified actions (or even look at using something like rundeck).

Generally, I think this is a case of first understanding what the actual risks are, and then determining what mitigations exist. This is the same process irrespective of the age of the software.

But do keep in mind the other comments and answers here, which also take into consideration the difference between 'old and working fine' and 'new, possibly safe, but not working'.


once A gets falsely authenticated as B...

On any minimally secure system, this isn't how it happens. From the system's point of view, User B is authenticating himself, not User A. It was not falsely authenticated, it was using the real login and password. It's simple case of Credential Theft. You could harden the system using any form of 2FA, but the system is working as intended.

It would be falsely authenticated as you said if User A uses his own credentials and somehow ends up with the profile of User B. In this case, the attack could be an Authentication Bypass, or Privilege Escalation, and the system would have to be patched.

  So what is the whole point of authorization?

Separating privileges depending on who you are. If someone can use your credentials, it is essentially you, so authorization still holds.

  It is dependent or independent of authentication?

It is independent (though many authorization systems choose to depend on authentication information). Authentications is about who you are. Authorization is what privileges you have. Single Sign-On systems, for example, are used to enforce identity, and another system have to be used to enforce permissions.


The rank refares to the potential impact on the target and is defined by the author of the module. In the case of the encoders it is carried over from the ranking system used on exploits.
MSFVenom replaced the now deprecated MSFpayload and MSFencofe utilities. However the rank gradings did not change between versions.
In 2011's eighth printing of Metasploit The Penetration Tester's Guide the following paragraph outlines how the ranking system applies to encoders;

"... the x86/shikata_ga_nai encoder, the only encoder with the rank of
Excellent, a measure of reliability and stability of a  module. In the
context of an encoder, an Excellent ranking implies that it is one of
the most versatile encoders and can accommodate a greater degree of
fine tuning than other encoders."

The ranks are described as follows when referring to exploitals:

Every exploit module has been assigned a rank based on its potential
impact to the target system. Users can search, categorize, and
prioritize exploits based on rankings.
Ranking Description
ExcellentRanking  The exploit will never crash the service. This is the case for SQL Injection, CMD execution, RFI, LFI, etc. No typical
memory corruption exploits should be given this ranking unless there
are extraordinary circumstances (WMF Escape()).
GreatRanking  The exploit has a default target AND either auto-detects the appropriate target or uses an application-specific
return address AFTER a version check.
GoodRanking   The exploit has a default target and it is the "common case" for this type of software (English, Windows 7 for a desktop app,
2012 for server, etc).
NormalRanking The exploit is otherwise reliable, but depends on a specific version and can't (or doesn't) reliably autodetect.
AverageRanking    The exploit is generally unreliable or difficult to
exploit.
LowRanking    The exploit is nearly impossible to exploit (or under 50% success rate) for common platforms.
ManualRanking The exploit is
unstable or difficult to exploit and is basically a DoS. This ranking
is also used when the module has no use unless specifically configured
by the user

GitHub


Why should passwords be compared by means of a byte array?

There are a couple of issues at play here.  The first, which is referenced in both the Cert Secure Coding example  you linked to and the StackOverflow answer from Daniel Grover's comment doesn't have anything specifically to do with comparing the hash of a user-submitted password with a previously stored hash, but with the storage of the input password itself.  The issue they describe is one of  string immutability in platforms like Java and .NET, which means that if the clear-text password is ever stored as a string, it cannot be removed by the application, but only by the garbage collector, so a memory dump that occurs before that happens can lead to the exposure of a clear-text password.

This, however, is not really an issue when comparing password hashes.  The reasons for using byte arrays rather than strings have fewer security implications, but it is still a good idea.  First, because the input to, and output from a hash function is generally in the form of bytes.  If you put bytes in and get bytes out, converting back to a string to compare makes little sense.    Additionally, you eliminate an entire class of bugs (that could included security vulnerabilities) caused by incorrect string encoding.   For instance, two byte arrays representing two entirely different passwords might falsely report as identical if incorrectly converted to ASCII before comparison, because in many cases, bytes outside the basics 128 character ASCII range will be converted to the same (3F) ASCII character value, opening the potential for string collisions even when the original byte arrays did not.  If you leave the bytes alone, you eliminate this potential vulnerability entirely.

So, thinking of them and working with them as what they are, a hash output of bytes rather than strings leads to simpler, more correct code, and less error prone code.  For security, this is a good thing.


Limit information disclosed in AD Anonymous Bind

Rather than enabling anonymous AD bind consider using LDAP or perhaps a Read-only domain controller (RODC).

Using either of these should allow you to expose limited information without direct access to the upstream AD.

If you really have to enable Anonymous AD bind then use permissions to specify the access the "Anonymous Logon" user has to objects. Use a whitelist approach to specific objects rather than a blacklist approach.

It's worth mentioning although you're on a "private" network there could be threats on the network from either those malicious users legitimately on the network or from compromised hosts.


Interpreting this F-Secure Video of a DMA-Attack

What is happening at the 50-second mark?

Looks like a JTAG-probe or similar, possibly to reset firmware passwords.

  Why does he insert the USB boot-device before doing whatever he does next? Was this necessary?

No, it wasn't necessary, except perhaps to prevent the machine from booting to the installed OS, thus overwriting more of the RAM if it turned on by accident.


Ah, trust, that fickle thing...

Tor provides anonymity for the download part. A download is: to obtain a sequence of bytes. What you do with these bytes is then completely up to you.

Some sequences of bytes encode executable instructions that a computer will be eager to run. Executable files, scripts... fall in that category. If the file you download contains instruction, and these instructions have been designed to be hostile to you and your anonymity, and you execute them nonetheless, well, then you get what you asked for. The warning popup displayed by Tor is a kind of disclaimer: it reminds you that the magic of Tor stops at the downloading, but does not guarantee that the file you obtained is not full of nastiness.

Now for Word documents. Theoretically, a Word file contains the description of a written document, possibly with pictures; but, in practice, a Word document can embed just about anything, including executable applications. Word also supports a complex system of macros, which are, by any reasonable definition, a programming language. Thus, "opening" a Word document is quite akin to running a script. And, indeed, macro virus do exist.

Even with macros disabled, some nifty attacks against anonymity can be performed with Word files. For instance, Word documents can be signed. Word will want to verify this signature, which means first validating some X.509 certificates, which in turn may make your computer download some intermediate CA certificates and/or CRL by following URL found in the certificates themselves. As such, a Word document which you merely open may imply network activity to target names that are embedded in the document (well, in certificates which are embedded in the document). The nice part is that these accesses will be performed by some system components which may completely disregard your browser configuration -- thus happening outside of the Tor umbrella. Goodbye anonymity !

So don't open potentially hostile Word documents. However, if you trust the file, then there is no problem, yes ? At least as long as you can be sure that the file you got is really the one you believe it is... Amusingly enough, digital signatures can help you there, but the mere act of verifying the signature can entail activity which makes you totally non-anonymous, as explained above.

(The same applies to PDF, Excel...)


Evaluating the entropy gathering in a PRNG

"Entropy" is a measure of what some data element could have been. We say that we have n bits of entropy in a bunch of bits if those bits could have, collectively, assumed 2n distinct values with uniform probability (there is a whole lot of complexity which hides under the "uniform" term). To make a cryptographically secure PRNG, you have to:

Gather enough data from random sources so as to reach at least 128 bits of entropy. The idea is that it should not be feasible, for an attacker, to "try" a non-negligible part of the space of 2n possible internal states. n=80 used to be the traditional value for that, but given the technological advances since the 80s', we now prefer n=128, which is a power of two, hence Blessed by the Gods.
Use that entropy-laden seed in a proper stream-cipher-like function: this is a function which outputs pseudo-random bits, based on an initial key; here, the key will be derived from the seed through a one-way function with a fixed-length output (i.e. a hash function). The security characteristics you look for here is that it should not possible, given a sequence of successive output bits, to be able to guess any other past or future output bit with success probability substantially better than 0.5. Mind the "future bits" part: this is not as immediate as you might think.

The second point is not easy. As a basic rule, if the stream-cipher-like function is not a published construction which has been precisely described in some standard, and analyzed by dozens of cryptographers, then you should consider the PRNG as being of dubious quality. A homemade PRNG is as bad as a homemade block cipher: it could be strong, but many homemade PRNG are not strong, and there is no sure test for cryptographic strength.

NIST published a complete description of some "approved" PRNG. If the PRNG you use is one of those, then that's good. Otherwise, you should really raise a warning flag.

As for your exact questions:

The initial PRNG state should be gathered from "good alea sources" which means that the source should not only produce "changing" data, but also in a way such that an attacker cannot observe the changes. For instance, sending "ping" requests to an external network host, and measuring the time it took for the response to come back, is not a good source: it sure looks random, but one has to assume that the attacker can observe your outgoing ICMP requests and the corresponding answers, and thus obtain the same timing measures. For a more detailed treatment of such questions, have a look at this answer (yes, I am quoting myself).
The injection of additional entropy is very similar to the injection of the initial state: the "random data" used as seed if often bulky, hence there should be some mixing step to yield a high-entropy, short sequence. The tool here is any secure hash function. To make things simple, the injection should look like this: we take the current internal state, we concatenate the additional "entropy", and we hash the whole thing; the hash output is the new state. Beware: this kind of thing relies on security properties that are not exactly guaranteed for any given hash function. What I mean here is that being secure for such a usage is not a consequence as being collision or preimage resistant. Hence, there is a kind of leap of faith when using a hash function for that (although you could do worse than using SHA-256, for instance). In the NIST PRNG, I recommend having a good look at HMAC-DRBG, which uses HMAC for that kind of job. HMAC is a Message Authentication Code which uses an underlying hash function in a way which allows better "security proofs" for similar reasons.
The idea of a PRNG refusing to deliver more data until it gets more entropy is a bit of a voodoo ritual: it is important only if you believe in it. If you initialized your PRNG with a random enough initial seed, and then used a proper data-generation function, then there should be no security issue in producing petabytes of pseudo-alea from it. However, it makes some people nervous, hence many PRNG implementations include a blocking behaviour, in which the PRNG will refuse to output more than, say, 1 MB of data from 128 bits of initial entropy. In practice, a blocking PRNG (beyond initialization -- it is necessary to block until enough initial entropy has been gathered) leads to deployment issues (e.g. a Linux OS automatic installation which blocks on a server, when it comes to generating the SSH key, because there is no keyboard or mouse to gather entropy from the user). As a rule:

a. do as the PRNG standard states (see NIST SP 800-90);

b. unless the standard explicitly states otherwise, do not ever block, as long as you got a complete initial seed.

Note that Linux's /dev/random and /dev/urandom both fail at that: /dev/random will block way too often, and /dev/urandom never blocks at all, even if it did not get a good initial seed. Fortunately, any decent Linux distribution will make sure that /dev/urandom is initialized with a good enough seed as part of the boot scripts (including keeping a random seed in a hidden file, generated at the previous shutdown). FreeBSD's /dev/urandom behaves in the way I describe, and that's good.


Finding the firewall port that filters internet traffic

By using the ping command, you are using a protocol and port that is non-standard for Web traffic. Pings are commonly blocked at firewalls.

If you can browse to websites, then you have port 80 (http) open and likely port 443 (https).

What you need is a program that can do the same thing as 'ping' but not using ICMP and using specific ports that you want to test. Nmap can do that as can many other tools. The process you want to do is called 'firewalking' (walking the firewall ports to see what is allowed).

But I have to say that it sounds like you need a little more knowledge on the basics of networking before firewalking will make sense. It also sounds like you have no good reason to know what ports are allowed and that you are trying to bypass the security of your company's network.

Maybe if you explained why you need to know the ports that are open, we can be more specific...


How to implement "remember me" with JWT?

If I understand you correctly, everything will stay the same for a user that uses the "remember me" option? But a user that doesn't will only recieve an acces token? This should not pose any new security problems. All you are doing is giving the user the option to not getting a refresh token, i.e. recieve less access.
One thing, though. For non-remembered users, you plan to expire the session once the access token expires. That will probably either lead to a very annoying user experience where you have to login over and over again, or to long expiration times on the access tokens (which could be a security issue).
To get around that you will need a refresh token for all users, but set a shorter expiration time and perhaps don't store it on clients for as long if the user doesn't use the "remember me" option.


The setup described in the document you cite is suitable for certificate-based authentication. The RSA tag in ipsec.secrets means exactly that the file moonKey.pem contains the RSA private key.

What you need to do to use Pre-Shared Keys (PSK):

in your ipsec.secrets you need a line with the PSK tag followed by the secret itself among quotes. Like this:
192.168.0.1 %any : PSK "v+NkxY9LLZvwj4qCC2o/gGrWDF2d21jL"
since you are not using certificates you need to drop the leftcert and rightid lines from ipsec.conf.
in ipsec.conf add the line authby=secret just below the conn statement to specify the PSK authentication mechanism.
you do not need any .pem files.

I cannot test these modifications right now, so perhaps I miss something.

As a side note, public-key cryptography is not inferior to symmetric key cryptography. If used correctly, they are both secure.


False positive Apache version in scanner results on Centos

What you're experiencing is a common problem.  Vulnerability scanners that rely upon service banners do not deal with vendors like Red Hat which backport security updates.  They are also prone to making assumptions about configuration that lead to false positives.

You may be able to improve the accuracy of the scan by running an credentialed scan.  If your scanner supports it, you can specify account credentials that it will use to log in and look at "internal" information.  For example, it can use 'rpm' to determine which actual Apache package is installed, and base its verdict upon that rather than the banner that the service prints to external scanners.  Such a scanner should have access to an up-to-date database that will tell it what the real issues are.

If your scanner won't do it, then the usual solution is to do it yourself.  You would need to look up whether you're running the newest version.  For example, @Rook points out that there are Apache vulnerabilities newer than the package you reference.  Looking at those vulnerabilities, you can pull the CVE ID and look it up in Red Hat's CVE Database. For example, their entry for CVE-2013-1862 points you to the errata RHSA-2013:0815 which says that httpd-2.2.15-28 contains fixes for that CVE.  It also points out that there's a newer RHBA release, so there's a newer package with bug (but not security) fixes.  Repeat that process for any other CVEs that you're concerned with and you can make an educated decision about whether you're patched despite what the banner says.  If the CentOS package is a direct correlation to the RHEL package, you should be fine - but the RHEL package was announced on 5/13, so I don't know how @Rook's cited 3/2 release date jibes with that.

(The shortest version, BTW, is "yeah, this stuff is a known PITA.")


As a consumer, you do not need to worry about expired SSL certificates on YOUR machine. SSL certificates are owned by web servers and companies.

If this company contacted YOU to tell you something was wrong with your SSL certificates (and you do not own a web server), I can almost guarantee they are trying to scam you.


How to prevent Cross-site Scripting in ajax response

An XSS attack here means that the attacker somehow must be able to compromise the HTML in the Ajax result. Assuming that the connection itself can be trusted (i.e. HTTPS) there are basically two options: sanitize the HTML in the client and/or make sure that there is no XSS in it in the first place in the server.

The latter option is preferred if you have control of the server, i.e. the server should  not generate compromised HTML in the first place. How this exactly is done depends on your unknown web application. But the basic idea that you need to be clear what kind of inputs can be trusted and what not (i.e. can be influenced by the attacker) and then make sure to properly sanitize/restrict the untrusted parts, for example by not allowing HTML input from untrusted sources in the first place.

If you have no control of the server you can only sanitize the HTML inside your client side application. This can of course be done additionally to server side protection (i.e. where you have control of the server) too in case you don't really trust your own server and better want to have a second line of defense. But in general it is easier and more secure to make sure to not include unverified/unsanitized user input in the first place instead of trying to remove it later from the constructed HTML. There are many libraries which help you to sanitize the HTML on the client side using Javascript, see this google search and pick the one which fits your purpose best.


Can a SSH server or client to initiate a unencrypted connection?

Per RFC4253, both the client and server would have to accept none as a cipher type in order to establish a plaintext connection.  OpenSSH (and probably most SSH implementations) refuses to accept none as part of the Cipher configuration, so you would not be able to do this with OpenSSH without recompiling both the client and server to accept none


How are these transaction fingerprints colored?

At closer examination, it seems that the most recent blocks start with three black boxes. Real Bitcoin mainnet block hashes are of very high difficulty to mine, and contain around 18 zeroes in the beginning. This leads me to believe that the first boxes correspond to color code #000000, or black, while the rest of the hash is grouped into triplets of 3 bytes and colored as that hex code. There are 4 left out hex digits (2 bytes, one on each side), as a 32 byte hash is not evenly divisible in 3.

Due to the avalanche effect observed by all modern cryptographic CRHFs, and the fact that the using color technically omits no information (although it might be hard to distinguish #000000 from #010101 visually, it's hard to find near-collisions due to this effect), this seems to be a clever way of representing transaction and block hashes, and may also work well on public key fingerprints. It's much easier to visually verify a few color swatches compared to dozens of hex digits (unless you're colorblind). In the case of colorblindness, a grayscale system of low to high brightness would also work.


Here is a nice visual explanation of the MBR : http://www.nixhacker.com/explaining-the-magic-of-mbr-and-its/.

Except you have to be aware of the LSB or MSB output of the tool. hexdump -C or xxd's output may be easier to read depending on what you're used to, your hexdump output shows the proper byte arrangement as it actually appears in memory with the least significant byte first.

See : hexdump always uses the platforms endianess

The nixhacker link above will be the most useful with xxd's output (or hexdump -C), we have to manually flip the bytes of your output to make sense of it.

1be : 00 00 : 08 would be bootable, 00 is not bootable, 00 Is the Starting Head

1c0 : 01 00 : 01 Starting Cylinder, '00 Starting Sector'

1c2 :  ee feffff : ee Partition Type - EFI GPT Disk (https://en.wikipedia.org/wiki/Partition_type), feffff - ending Head Cylinder Sector values

1c8 : 00 00 10 00 : LBA address of the starting sector (4096)

And so on.

From a quick search you can find MBR parsers that seem to work well:

https://raw.githubusercontent.com/gleeda/misc-scripts/master/misc_python/mbr_parser.py


Can you use Https to prove document was sent from domain?

The application data within TLS are encrypted with a key known to both client and server. The application data are only encrypted and integrity protected by a HMAC but they are not signed by the server. This means that the client could take an existing TLS handshake with the server and use the key exchanged by this handshake to encrypt whatever data it wants. Since the application data are not signed by the server there will be no way for a third party to verify if these data were actually sent by the server or if the client has faked these data.


Start with this guide -- https://github.com/hfiref0x/VBoxHardenedLoader -- it's incredibly up-to date in terms of making a VirtualBox guest VM more-difficult to detect, including techniques valid in 2017. This will definitely make your automated malware analysis initiatives and goals easier to achieve.

Consider tracing and debugging outside of the guest VM using VirtualKD, as seen in the three books 1) Windows Malware Analysis Essentials, 2) Gray Hat Hacking 4th Edition, and 3) Practical Reverse Engineering. You can sync views between Windbg and IDA Pro using qb-sync.

Prefer VirtualKD to other, userland-debugging techniques like Scylla, HideToolz, HideCon, et al. These are not as good because defeating VM detection is difficult enough. Defeating anti-debugging and associated bad behavior just takes too-much work in userland.

Pafish, like sems tool, is also a bit dated. I would suggest that you use -- https://github.com/LordNoteworthy/al-khaser -- to stress test your automated malware analysis with sandboxes such as guest VMs.

There is additional information about VM detection on these blogs:

https://byte-atlas.blogspot.com/2017/02/hardening-vbox-win7x64.html
https://bdavis-cybersecurity.blogspot.com


The whole point of having a "stateless" thing is to avoid maintaining state (here, on the server side). Stateless servers are unavoidably subject to replay attacks, by definition. The problem you are envisioning is basically a replay attack.

If attackers can steal clients' cookies, then you already have bigger issues. If they cannot, then there is no problem. Use SSL.

(SSL is not the ultimate solution for everything, but it helps avoiding cookie-stealing, at least as long as the cookie is marked as secure and HTTP only.)


Does HTTP:// to HTTPS:// redirection means strict HTTPS from server

Python requests almost certainly does not use an https preload list, so the server must be responding to the http request with a redirect.

Does the server "accept http:// requests"? That's a trick question. I could answer: yes, because if the server did not respond to http requests at all, then it would not receive your request and could not respond with a redirect. So it must be listening on port 80 and reading your http request in order to be able to respond with a redirect. But if you are asking whether the server performs the requested action when you request an action over http instead of https, then the answer is probably no. Web servers are usually configured to just return a redirect and the client will just retry the request at the given location.

You also tagged your question with Firefox. Browsers might have features enabled that store a list of websites that are known to work with https, and Facebook would be on there. Because of this, browsers might not connect over http at all, because they don't need the redirect: when you type http, they will just connect over https, without first contacting the server and getting a redirect.


SHA2 certificate and TLS cipher suites compatablity

The signature algorithm used for the validation of the certificate (SHA-512 in your case) is independent from the algorithm used as the HMAC in the ciphers, i.e. for the encryption (SHA-256, SHA-384 in your case).


Can attackers get anything with DoS attacks except crashing the service?

In general a (Distributed) Denial of Service attack will not provide you with much information directly. However, there are a few scenarios where information could be gleaned as a result of a DoS. The following are a few examples, but this is not at all exhaustive:

A load balancer may divulge internal subnet information or leak internal machine names in situations where backing systems are offline.
A DoS that shuts down the database first may cause an application reveal the database engine type, connection username, or internal IP address via an error message.
A poorly implemented API could result in a "fail-open" scenario--DoS'ing a Single Sign On server may give an attacker the ability to log in unauthenticated, or with local credentials.
In Advanced Persistent Threat scenarios, DoS'ing detection infrastructure may allow an attacker to remain undetected during other information-gathering stages.
Similarly, DoS'ing the admin interface of a firewall could hinder network administration's incident response efforts.
In an extreme case, DoS against a key-revocation service could allow an attacker to continue to use revoked, or known-compromised credentials.

Other motives for a Denial of Service attack become apparent if you consider the users of a system as targets in addition to the system itself: A Denial of Service attack against a website that sells concert tickets may allow an attacker to buy tickets to a event that would have otherwise sold out in minutes. A DoS against a version control system could prevent a development company from delivering software on time. A DoS against a social media site could make coordinating political protests more difficult, or event impossible.


The security of dll files in a Client/Server application in .net

As mentioned in a comment above, there are two basic strategies for protecting the IP in your source code:

Make your source code more difficult to understand. This is typically done through obfuscation. Obfuscators attempt to make the source code difficult to reverse compile and/or difficult to understand once they've been reverse compiled. I'm no expert on obfuscation tools so all I can do is point you to this list and suggest you research and post follow-up questions if any arise. Obfuscation is "easy" in the sense that you get the tool, possibly paying for it, and then incorporate it into your build process.
Keeping your code on the server. This involves moving some of your application logic to from the client to the server. There are many reasons to move code to the server. Protecting IP is one. Having logic that requires the server's hardware could be another (common for mobile solutions with low processing power). This is more difficult to implement than obfuscation as it affects your application's architecture. The new architecture would have the client, rather than making a local function call, making a RPC to the server to perform some calculations. SOAP may be the most common technology but there are many others. The exact technology will depend on many factors including the client's and server's platforms (eg: is it a native .NET app, a browser app accessing a .NET server, mobile app, etc...) and you're coding skills.

Hope this helps.


Part of this boils down to how proxychains works in general. In order to proxy traffic from arbitrary programs (that may or may not have proxy support), proxychains uses the LD_PRELOAD environment variable to load itself as a shared library into the program that is being called. Since it is "pre"-loaded, the functions exposed by the proxychains library take precedence over others, e.g. libc. This allows it to hook certain network related functions.

For example, when the program calls connect() on a TCP socket, proxychains has replaced the real connect() function with its own, one that instead knows how to shove the traffic through your configured proxies.

The same applies for DNS, although it is a slightly special case. The application will make a call to gethostbyname() (obsolete) or getaddrinfo() to perform DNS resolution. If the proxy_dns option is not specified in the configuration file, proxychains will call the unaltered libc function, resolving DNS normally through your system. If the proxy_dns option is present, it will instead redirect both functions ultimately to a modified version of gethostbyname() that is fairly more complicated.

This modified version actually doesn't do any DNS resolution at all. Instead, it creates a fake IP address in the reserved 224.x.x.x or 225.x.x.x range, and maps your requested hostname to it in a table (e.g. 224.1.2.3 --> www.example.com). This will come in handy later.

The application then makes a connection to the fake address returned above (224.1.2.3). Proxychain's hooked connect will then set up a connection to the configured proxy. It will then look up the fake IP address in the DNS table to retrieve the original hostname that you were requesting (proxychains says: `224.1.2.3? That was "www.example.com"). Depending on the type of proxy in use, it will request a connection to the original hostname through the proxy. The proxy performs the DNS requests on your behalf since it is the one making a connection to the real destination.

Specifically in your case, if you were to run:

$ proxychains curl https://example.com

The Tor SOCKS5 server will receive a request from proxychains such as:

Hello server! Connect me to www.example.com:443

The Tor SOCKS5 server will then handle everything; performing DNS resolution and sending your packets over the Tor network.

TL;DR: When the proxy_dns setting is enabled, no real DNS requests are made (or needed) from your end.

Source: Read the source code at https://github.com/haad/proxychains/


How to protect iKvM, IPMI, KvM Interfaces from 0day and other exploits

The only solid way to protect a service against zero-day exploits is to keep that service from being accessible from the Internet.  That includes network-internal barriers to keep other compromised servers from being used as a starting point for an attack -- firewalling off IPMI from the Internet is pointless if someone can pass through the firewall to your web server and use it to perform the attack.


A store I visited is breaching PCI DSS. What should I do?

Printing full PAN and expiry date on the customer receipt is a violation of Visa's requirements listed in "Card Acceptance Guidelines for Visa Merchants". Therefore I suggest you to submit merchant violation complaint form directly to Visa. It is located here: https://usa.visa.com/Forms/merchant-violation-complaint-form.html


Is a fake base station needed for IMSI catching?

IMSI Catchers are fake mobile network cells (BTS) and additional equipment for call routing that operates in a "evil twin attack" and MiTM manner. They are usually positioned in places nearby the victim, where their signal is stronger than the signal of the legitimate network service provider cell, so the victim phone choose the fake BTS than the legitimate one.
When the phone try to negotiate the encryption scheme with the specific for the GSM protocol handshake procedure, the IMSI Catcher identifies the victim by it's IMSI and downgrade the required cryptography from A5/1 or A5/2 to A5/0 or "not encrypted". It basically tells the victim phone "i can't support anything but A5/0". When the phone starts to communicate with the IMSI Catcher and traffic channel is allocated for that client, all communications can be sniffed on the traffic channel, because there is no encryption.
Next, with the permission of the network service provider to access their HLR, the communication is encrypted with the subscriber master key, and routed through the network. This way, we can have two-way communication without the victim knowledge about the surveillance actions.

This can't be done without physical BTS, since it needs to receive and transmit on the RF media.


Malware possibly infecting my personal website

Being that you were not connected to the site via HTTPS, there are two ways that the unexpected content that you saw could have been injected:

An attacker gained access to your web server, and modified the HTML page, and injected the content there.

An attacker on the network somewhere between your web server and your web browser injected the content into the HTML page that you requested 'on the fly'.

Securing your site using an SSL certificate, and allowing only https connections to your site, will eliminate the possibility of (2) happening again.  This can be done very inexpensively - you can get an SSL certificate from Let's Encrypt free of charge, and mnay other CA's offer certificates for less than $10.00/year.


Is exploit different from the kernel level or root?

I think you're confused about privilege escalation. First of all privilege escalation is meant to bypass restrictions for a low privileged user in order to execute tasks as a  high (root) privileged user.

Executing a privilege escalation exploit as root is kind of useless (just to state the obvious)

  What right can kernel based exploit give me

root privileges


Is there a way to mitigate BEAST without disabling AES completely?

One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map the attack on plain <img> tags (hostile Javascript which produces such tags, with an attacker-chosen path: the path gets in the request, but it is text-only). In their demonstration, they could use two cross-domain holes, one in a draft version of WebSockets, the other in the implementation of Java from Oracle. Both holes have since been fixed, therefore, right now, BEAST does not apply anymore (unless you did not update your browser for more than one year, in which case you probably have bigger problems).

Since relying on the non-existence of cross-domain vulnerabilities is, at best, flimsy, browser vendors have also included some extra countermeasures, with record splitting. When the browser wants to send a block of n bytes of data, instead of putting it in one SSL record, it splits it into two records, the first being very small. Record boundaries have no semantic significance in SSL/TLS, so you can do such splitting without changing the meaning. However, each record ends with a MAC computed over the record data and a sequence number, and using one key derived from the initial key exchange. This somehow acts as a pseudo-random number generator. Therefore, the small record "emulates" the random IV generation that makes TLS 1.1+ immune from BEAST.

Ideally, the split would be 0/n: a record with no data (but still with a MAC), followed by a record with the actual data. Zero-length records are allowed (as per the standard) but buggy client and server implementations do not tolerate them (in particular IE 6.0); instead, browsers use a 1/n-1 split, which is just as good for defeating BEAST, but also works with almost all existing SSL/TLS clients and servers. At least Chrome and Firefox have pushed it last year.

The good solution is TLS 1.1+ but even on SSL 3.0 and TLS 1.0, the BEAST issue can be considered as fixed, at least in the Web context. Therefore, use AES, and be happy.


Looking for SSH key management tricks that apply to a large fleet of machines to reduce the 'trust of first use' attack surface?

There is no need for tricks, SSH Certificate Authority is designed for exactly this kind of situation.

You install host certificates signed by the Certificate Authority, distribute the Root Certificate to your users, and your users are connecting securely from the first connection.


Secure way to save password in configuration file

Data stored in a text file stay there in clear format unless you encrypt that file itself.

As the other answerer said, better to store your credentials in the MySQL database itself. Hash and salt your password (and why not using a pepper too?)

Useful links with very good answers:

How to securely hash passwords?
How to store salt?
What is the purpose of a Pepper?

EDIT:

Following your comments:

You either want to do the same thing as Wordpress, Joomla and other famous CMS do: create a separate table where you can store such information.
Or may be you are hosting your web application on a server on which you are limited in order the number of DBs and tables within a DB you are allowed to create: in that case, you  can create a PHP configuration file (instead of a text file) where you store that information and follow the good practices in such situations (such as protecting the folder in which this file is located with an .htaccess file)


Does Linux kernel use DEP for kernel memory?

According to “Extending the use of RO and NX”, the Linux kernel applies DEP on architectures that supports it (such as arm and amd64, but not 32-bit x86) since kernel version 2.6.38 (I don't know if RHEL/CentOS have applied a similar patch to their kernel — a lot of the work on DEP originated from Red Hat).

The W^X principle is mostly followed, but not completely: some pages are left W+X, because otherwise it breaks some BIOS. (Don't you love x86?)

DEP was in the grsecurity patch well before it hit the main line.


Losing a password manager's master password usually isn't too catastrophic, just a huge hassle. You can still reset those lost passwords so long as you have your email account and any other relevant form of authentication.

For human-memorable passwords (your password manager's master password, stuff you have to type into anywhere that password managers aren't available such as disk encryption and login, accounts you want to ensure you retain access to like email), Diceware-style passphrases are still the best that I'm aware of. You want more than four words unless you're pulling from an extremely large corpus - the 7776 words of the official Diceware site is a bit short to be safe at only four words long (51.7 bits of entropy, assuming the attacker knows you use that method) - but even just four Diceware words will be much stronger than almost any human-generated password/passphrase. A stronger passphrase can be made using more words (even going just to 5 will be sufficient to resist modern hardware assuming a slow hash is used, but going to 6 or more will be very expensive to break even with a fast hash). A larger word list (corpus) will also help, though less effectively (doubling the number of words in the passphrase doubles the entropy; doubling the number of words in the corpus adds only one bit of entropy per word).

For anything that your password manager will autofill for you, let it generate a nice strong random password. It'll be stronger than a Diceware-style passphrase of reasonable length; there are more than 100 printable characters on a standard US keyboard, and just 16 random characters from a set of 100 is 10^32 possibilities (106.3 bits of entropy) but there's no need to stop at 16. It'll be a pain if you ever have to type it manually, but even somebody shoulder-surfing you isn't likely to successfully memorize it like they could with a Diceware passphrase.


Appilicability of Theoritical Computer Science/Formal methods in Malware research

What makes you think that formal methods or theoretical CS will be relevant?

I think a better question is: what tools from computer science might be relevant to this problem?  My answer to that question would be: statistical machine learning methods may be highly relevant.  (You could also look at stylometry -- author identification -- if you are interested in the attribution problem.  However, that may be a challenging research problem.)

Generally speaking, formal methods and theoretical CS are not used much in malware research.  On first impression, they do not seem very relevant to the malware problem.  Today, most malware research happens in the systems community, which focuses on tools, applied work, methods for software analysis, and so on.

To learn more about current research, I recommend reading the research papers on the subject.  You could look at the top conferences (e.g., Usenix Security, IEEE Security & Privacy, ACM CCS, NDSS) as well as conferences focused specifically on this problem (e.g., DIMVA, LEET, WOOT, etc.).


Find out what process is trying to initiate a connection in Windows

Given your access restrictions, you can do this:

Task Manager > View > Select Columns > PID
netstat -ano | find "127.0.0.1" (put whatever IP you want in the quotes)
Compare PID to active connections.

More information on how to use find, and netstat


Why am I seeing SSL events resolve to OpenDNS IPs?

This sounds like your company is using Cisco Umbrella Intelligent Proxy (Selective Proxy) or Secure Web Gateway (Full Proxy), and is decrypting SSL traffic.

This tunnels all web traffic through Umbrella Data Centres and forms a MITM (man in the middle) SSL connection between you and the HTTPS domain.

Therefore your certificates will be issued from the Umbrella Data Centres as opposed to the domain destination.

https://docs.umbrella.com/umbrella-user-guide/docs/cisco-umbrella-data-centers


Not going to answer the question directly, because I consider it too broad, but I'm going to give some advice.

If you want to clearly understand how certificates work, you will have to develop your learning path. Which will include:

PKI Fundamentals. Hierarchies, components, trust anchors. Wikipedia materials will be sufficient to understand basic concepts.
X.509 profile. Certificate structure and contents: mandatory fields and v3 extensions. These topics are greatly explained in RFC5280 §§1-5
Certificate chaining engine. For start I would recommend something less sophisticated. For example, my own blog post: Certificate Chaining Engine — how it works. Although, it is Microsoft-specific, but general concepts are still universal.
Understand constraints in details: Basic Constraints, Name Constraints, Certificate Policies. RFC5280 §4.2.
Detailed (and a bit sophisticated) abstract certificate chain building and validation algorithm in RFC5280 §6.
Explore Internet PKI regulatory organizations. Learn about CA/B Forum and their Baseline Requirements. RFC is more about X.509 profile itself, while CA/B Forum is more about industry practices used in HTTPS/TLS applications.


Your company might have started doing a POC to acquire McAfee's CASB's product and as such is transparently redirecting some of your web traffic to their products. You might want to reach out to your administrator to get this clarified.


Check integrity of GnuPG inside of GPGTools?

The content provider (GPGTools) provide no means to check the integrity of the files inside the package; they provide no hashes/sigs, so you have nothing to compare to. They appear to compile their versions/ports of other open source projects, so even if you try to compare the check the binaries against their counterparts from another content provider, the check will most likely fail.

Since they provide the package and page showing the sig over HTTPS, you can trust that they both come from GPGTools website and you can trust that you're being handed the authentic package.

Now if you don't trust the source of the package (GPGTools), you probably shouldn't be using their ports/packages in the first place.


Javascript Diffie-Hellman and AES protocols

What bit-length should be the D-H parameters : p, g, a (and b) ? I am currently using p 2048-bit and a,b 256 bit, is that good ?

DHKE is based on the discrete logarithm problem (same as DSA and ElGamal), so the size should be fine.

  At the end of the protocol, I get a BigInteger 2048-bits key, how can I derive a 128, 162 or 192-bit key from it ?

I have to admit that I'm not 100% sure. If you want to be safe, hash it and then take 16 or 24 bytes from the output of the hash function. Or see below.

  Once I get a 128-bit BigInteger key, how can I use it with the AES protocol ?

The Stanford Crypto Library actually exports a high-level encrypt function (see sjcl.json.encrypt), which takes as arguments a ciphertext and a password. You could simply pass in the whole 2048-bit key from the previous step as a password. This also handles block modes and generating an IV for you.

Please note (and the only reason I'm answering is to tell you this), that you're doing everything wrong. First of all, you are running your own crypto(-graphic protocol). Diffie-Hellman, in schoolbook mode, isn't safe though. Moreover, JavaScript crypto isn't safe. Secure delivery of script requires HTTPS, and if you have HTTPS, you probably don't need more crypto.

Please read all of the links and think twice, before you run crypto in production.


Something closer to real life requires an infrastructure with systems and networking equipment. You can virtualize that but it still requires some resources to set up and run. That's why you have to pay for most of the good labs.

BackTrack PenTesting Edition lab is an all-in-one penetration testing lab environment that includes all of the hosts, network infrastructure, tools, and targets necessary to practice penetration testing. It includes: a DMZ network with two hosts targets, an “internal” network with one host target and a pre-configured firewall.

OSCP, OSCE, SANS 660 and HackinkDOJO are some of the paid courses that have good practical labs.

CTF365 is a continuous real world Capture The Flag with free and paid services.

You can also build your own security lab.

And if you want real world pentesting, go do bug bounties and get paid for it at Bugcrowd and HackerOne.


Is Windows+L a secure attention sequence?

Answer is quite simple Win+L is not a sas and it does not need to be. It is used for locking the device.
There is a group policy to control the sas for triggering the login. You may set it so the CTRL+ALT+DEL is required for every login independently of how the station got locked, be it via shortcut, time-out or any other way, after all locked state is locked. Assuming that you require sas upon login there is no need to verify the locking sequence. Malicious software can be written in many different ways so overengineering protection for one feature does not make much sense. Screen overlay could be used to capture the click map used for locking the station from Windows context menu as an example. This is why it is much smarter to require sas on login.
There is whole different debate about users actually noticing the difference on systems that require sas and on those that don't.
It is worth noting that the policy is disabled by default due to wide use of touchscreen devices and overall bad user experience, so it must be activated to be used.


Use the method described in the linked answer. The attacker creates a webpage with a form that automatically submits using JavaScript. Then the attacker submits the URL to the attacker's page to the victim.
If there is XSS in the username field, it is very likely that the application is vulnerable for XSS in many other places. So you may want to continue searching for a place that is easier to exploit.


x.690 universal class tags implementation reference

Okay, I think I've found it. The link below are for those who might need it:

http://www.oss.com/asn1/dubuisson.html
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-200811-S!!PDF-E&type=items