PCI scope when entering card details into browser

Caveat IANAQSA

  In these three scenarios, is there a difference in PCI scope for the
  server running in Azure? What is the scope? Does our Azure
  infrastructure need to undergo an annual audit?

Scope here should be measured as a per-merchant thing, not as a per-server.  Yes, your Azure servers would be covered by your scope (the level of which I'll discuss below).  AWS is the gold standard for cloud providers helping you understand which scope issues are yours versus theirs.  Azure appears to be less helpful in that vein; they point you to PCI, but at least they have a Compliance Matrix.

(absent other details), Scenario A would likely be considered SAQ A-EP scope and scenarios B and C would be SAQ A.  Here's a good description from PCIComplianceGuide.org:

  the Council says that a merchant can still use SAQ A if:

  Merchant website provides an inline frame (iframe) to a PCI DSS
  compliant third-party processor facilitating the payment process.
  Merchant website contains a URL link redirecting users from merchant
  website to a PCI DSS compliant third-party processor facilitating the
  payment process. (Source: Understanding SAQs for PCI DSS Version 3, p.
  5)

...

  Does it make a difference if I am a merchant myself (so the third
  party gateway is using my merchant account on my behalf) vs a gateway
  that processes transactions with their own merchant account, and then
  reimburses me later.

I don't believe so.  Customers go to your site; customers whip out their card and type numbers in; customers expect goods or services in return.  You're a merchant, whether you're managing your account with the payment processor or going through a payment facilitator.

  I'm led to believe there is a difference in PCI scope between these
  scenarios, but I can't really see why. If the Azure server is
  compromised, an attacker could serve malicious pages and capture the
  user's card regardless of which approach is used.

There is a difference between the SAQ A and A-EP scopes; the former is 14 questions; the latter is closer to 100 and requires scans.

In actual security terms there is negligible difference.  Speaking for myself, I think the reasoning that suggests iframes are more secure where javascript is less secure are specious and not technology-driven.  Both are equally vulnerable to a malicious attacker who compromises the web server and replaces {iframe,javascript} with their own.

  I see ecommerce sites using scenario A all the time, but I'm quite
  sure very few of them are running in PCI compliant environments.

I'm sure quite a few of them have properly filled out SAQs.

Some subset of those are actually PCI compliant.

Some subset of those are actually secure.


Testing your site for the heartbleed vulnerability?

The SSL Labs test will give you the most information about your site, including heartbleed status:
https://www.ssllabs.com/ssltest/analyze.html?d=

This site has worked pretty well for me in testing specifically for heartbleed:
http://possible.lv/tools/hb/

Lastpass uses some other assumptions about previous information to make pretty good guesses:
https://lastpass.com/heartbleed/


Well any program can have security flaws and one's that interact with the Internet are exposed to potentially malicious content.  That said the major browsers have pretty good track records (all things considered) at reacting to security issues and issuing appropriate patches.

If you do decide to try to protect yourself from this, it might make sense to isolate your browser from the rest of your system.

The level of isolation you implement would likely depend on how much inconvenience you were willing to put up with and how concerned you were.  Some options would be

Run the program in a dedicated VM that rollsback all changes on reboot.  This avoids any state being saved and if an attacker can write to the filesystem, the change is lost on reboot.
Implement some kind of linux container (e.g. docker) to run your browser in.  This has the advantage of a smaller performance hit and less disk space utilization, but you lose a bit of isolation.
Use something like AppArmor or SELinux to restrict what the application can do on your system.


What is the impact of certificate validation level (or class) on deployed web applications?

The certificate level usually can be seen in the certificate (e.g., StartCom free certificates have OU=StartCom Free Certificate Member, O=Persona Not Validated in the subject DN — apparently not anymore (see below), and separate intermediate CA certificates are used for different levels). But at least in Firefox this information is not easily available in the browser UI (you need to get to the certificate properties window with lots of technical information to see it); only EV certificates are clearly indicated, and everything below EV is basically treated the same.

CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (version 1.0 adopted on 22 Nov. 2011 with an Effective Date of 1 July 2012) specify two Certificate Policy identifiers which could optionally be used by CAs to assert the identity validation level:

2.23.140.1.2.1 — only a domain validation was performed;
2.23.140.1.2.2 — the subject identity was validated before issuing the certificate.

At least StartCom now uses 2.23.140.1.2.1 in newly issued Class 1 certificates, and no longer includes a human-readable OU=StartCom Free Certificate Member, O=Persona Not Validated in the subject DN. However, browsers currently do not seem to pay attention to these policy OIDs when displaying the certificate information (e.g., the Mozilla bug #740571 is still open).
Using level 1 certificates for commercial purpose may be against the CA policy. The CA may refuse to issue the certificate if the domain name obviously suggests commercial use, or revoke the certificate later for violating the policy.
If a certificate is valid (not expired, the corresponding root certificate is trusted, there are no problems in verifying the trust chain, and revocation checks pass successfully), there will be no warning pop-ups irrespective of the certificate validation level.


What algorithms are used in Bluetooth Secure Simple Pairing LE for authentication, key generation and encryption?


No

Security code review is a good idea, but it does not protect against unpatched software. For example, if your server uses Nginx, it could have been vulnerable in the past to CVE-2013-2028. It doesn't matter what application code is present, because the vulnerability is in the web server itself. The best way to fix this vulnerability is to patch the server. There may be other ways to mitigate the vulnerability, but patching is almost always the best solution.


The IV is a random non-secret value. Its sole purpose is to prevent two similar blocks from yielding the same ciphertext as it could give information away about the structure of the plain text.

In general you just generate the IV randomly and concatenate it to the ciphertext. The IV must be of the same length as the block for AES-CBC, which is 128 bits. You can just concatenate it the to the ciphertext (e.g. IV+ciphertext). You know the first 16 bytes will be the IV.

EDIT

  If it's common to put the IV directly in front of the ciphertext, isn't it a security risk to do it like that?

The sole purpose of the IV is to randomize the ciphertext to prevent two similar plaintext blocks yielding the same ciphertext. This is especially important for files with a fixed structure. Have a look here on why this is important.

In CBC you XOR the ciphertext version of the previous block with the current block before applying AES on it. The reason you have an IV is because the first block doesn't have a block-1 to be XORed with. Hence you just generate 16 random bytes. It's similar to salting passwords.

  What makes putting a random IV in front of the ciphertext more secure than choosing a static IV?

A static IV would defeat the purpose as you would still have all similar first blocks yielding the same ciphertext.

  In both cases the IV would be plainly visible. Doesn't having the IV
  allow you to quickly brute-force the first block?

The IV is not part of AES, it's part of a mode of operation which AES supports.

I see you are quite confused about these concepts. If you want a good read and introduction you should have a look at Keith Martin's "Everyday Cryptography". It's a good book that explains everything step by step. Cryptography is complex, hard and mistakes can have devastating consequences. Be careful when implementing existing ciphers, if it is for use in application you are better off using established, vetted libraries.


Is there any security concern to host Wordpress on the main web server?

Installing more software on any machine (almost) always increases the number of ways the machine can be attacked.  So it is generally good practice to segregate components when possible. Suppose there is an attacker can use a flaw in the wordpress blog to execute PHP code, now the server hosting your main site is owned.

Another issue that comes to mind with this new setup is that hosting the blog on the same domain as your main site can give the blog access to cookies set by your main site. So now these cookies might be vulnerable to XSS attacks on the wordpress site, when they would not have been if the main site was hosted on www.example.com and the blog on blog.example.com.

EDIT:

Since you asked: I believe the admin on a wordpress site can install plugins/upload php files, so if this account were compromised then the machine would be compromised as well.


How to detect a keylogger in a USB keyboard? Can a USB keyboard host a keylogger?

Regular USB key loggers that exfiltrate their data via Bluetooth or WiFi can easily be hidden inside a keyboard.  The Bluetooth loggers require the attacker to come into range to dump their contents, but a WiFi based adapter that's pre-configured with a network key doesn't even require the attacker to be present to win.  He can plug it in and let it sit there forever.  Such keyloggers have been commercially available for many years.  There are even open source implementations available from the NSA Playset project, which are devices designed to emulate the spy devices found in NSA's leaked and now infamous ANT catalog.  But now, there are new options that are even more sophisticated.

The BashBunny is a commercially available hardware implementation of a USB chameleon that performs these kinds of tasks; the USB Rubber Ducky is simply an Evil Keyboard Simulator.  The BashBunny works by running a small Linux computer that emulates generic USB keyboards, USB mass storage devices, USB serial ports, and/or USB network adapters.  The emulated devices leverage the existing signed Windows drivers that are used by generic chipsets.  Such devices can exfiltrate captured data via the victim PC simply by emulating a USB keyboard and typing instructions to send it elsewhere.

Here's a simplistic example of how they could exfiltrate data through the victim PC.  Imagine that the hidden USB device contains a data logger, and records your secrets for a day or two.  (The BashBunny does not contain a keylogger; it gets its data from scanning the host system.  Of course it could install a key logger, then harvest the data at a later time.)  When it's time to send the data, it generates USB messages that contain keystrokes, but the user isn't typing them.  By hitting <Windows>R, then typing http://www.evilhax0rs.invalid/key_logger_dump_page.php* it can bring up a mostly empty-looking page with a hidden input box located so far down the screen that you need scroll bars to find it.  Now, imagine the rogue keyboard hitting <Windows><Shift><Down-Arrow> to slide the browser window completely off the screen, hiding it from the user's view.  Next, the fake keyboard starts typing all its logged keystrokes into the input box (base64 encoded, naturally), and hitting <Enter> when finished.  Finally, after all the secrets have left the building, it types <Windows><Shift><Up-Arrow> to restore the browser, then quickly types <Control>F4 to close the tab.  Even if the user noticed the windows popping up before sliding out of view, it can happen so fast the typical victim won't have the chance to figure out what's happening.

As I said, these are commercially available and open source products you can buy today; the source code for the evil devices and the "ducky scripts" that do the phantom typing are all hosted on github.

* not a real page.


which hashing algorithm is better to use to store a password, sha256 or sha512?

To expand on the point that @cthulhu makes in his comment, the correct answer to this is "nether".  SHA2 family hashing algorithms are not designed for password storage and unless you have no choice but to use a general purpose hashing algorithm, they should not be used.
To quote this answer the main reasons for this are

A basic hash function, even if secure as a hash function, is not appropriate for password hashing, because:

it is unsalted, allowing for parallel attacks (rainbow tables for MD5 or SHA-1 can be obtained for free, you do not even need to recompute them yourself);

it is way too fast, and gets faster with technological advances. With a recent GPU (i.e. off-the-shelf consumer product which everybody can buy), hashing rate is counted in billions of passwords per second.


Can ICANN deny Internet service to people?

ICANN only has authority to assign blocks of IP addresses to regional nics -- e.g. ARIN, APNIC, RIPE.  From there, the regional NIC (in the U.S. ARIN) then decides how to allocate the IP address to various entities like ISPs and corporations.  So, ICANN is at a much higher level than individual IP address assignment and it's very unlikely they'd ever become involved in this level of detail -- this is for regional NICs to handle.

As far as domain names go, ICANN has the authority to accredit registrars, but does not actually supervise them on the level of granting/revoking domain names.  Sure, if a registrar went against their policies they could theoretically revoke that accreditation -- but that would be unlikely since it would probably cause issues for all the other domains registered through that registrar.

I think you and your co-worker might misunderstand about "control of the internet" -- that's largely due to US control of the root DNS servers of the internet.  Previously, Jon Postel (the closest thing to a saint in internet history); an inventor of DNS, tried to move control of DNS from a US corporation to IANA (now part of ICANN) -- but was met with swift rebuke and clawback from the Clinton administration. Reference: https://en.wikipedia.org/wiki/Jon_Postel

As it turns out, control of the root DNS servers has been interpreted by the press as "control of the internet," but other nations such as China and Russia laready have contingency plans to migrate to their own DNS system if relations degrade with the US.


Is it dangerous to let the user input into a LIKE sql statement

The risk is no different than accepting user input for a regular evaluation. You still need to sanitize the data as well as use safe practices such as stored procedures.

The unique issue with LIKE comes into play when it is used but shouldn't be. For example your application wants to retrieve something with a certain ID but using LIKE could return a similar but different ID. One you wouldn't returned to your end user. But this isn't an issue you should have with a search engine.

On an additional note using LIKE with MySQL will give you a very basic and limited search engine that doesn't scale well at all. For alternatives consider matching against FullText searchable columns or using something meant for the job like Lucene, Sphinx, Elasticsearch, Solr.


Centralized brute force login detection using netflow data

This sounds like a very inefficient method, mostly because in netflow data you're lacking a lot of information. You only have source and destination IP's, protocols and (if relevant) port numbers, so there's no real way to distinguish valid requests from invalid requests, you're missing the payload for that, which is not available in netflow.

What you're describing are just assumptions on ways to detect attacks on some characteristics, which will most likely lead to a lot of false positives and missed attacks.

You need the payload to see what exactly the request was an IP address was doing. And since that often will be TLS, you need to look at end points where TLS is terminated.

If you don't have it, look into aggregating your fail2ban logs and deploying bans for IP addresses from identified attackers from those logs to all your machines.


RADIUS by itself provides no  encryption of all traffic. It protects only a small part of the traffic, notably the passwords. To cite from Wikipedia: Radius - Security:

  The RADIUS protocol transmits obfuscated passwords using a shared secret and the MD5 hashing algorithm. ... additional protection, such as IPsec tunnels or physically secured data-center networks, should be used ...  the user's security credentials are the only part protected by RADIUS itself, ... The RadSec protocol claims to solve aforementioned security issues.

RadSec is supported by FreeRADIUS. But to actually use it you of course need to configure it with the necessary certificates (i.e. no "encrypted ... by default") and your (unknown) radius client must support RadSec too.


Should I invest my time in making my site HTTPS-only?

Is HTTPS needed in this case?

In every case that I can think of HTTPS is beneficial.

The trivial case is if you don't have sessions, why would you need a secure connection if there are no sessions and everything is public? Having a secure connection actually helps your Google PageRank, and it also helps the user feel more secure by visiting your site

If you actually have sessions and dynamic content the benefits are of course more substantial.

One easy way to implement SSL/TLS certificates is using CloudFlare or some similar service.


Best alternative for monitoring traffic safely?

That is exactly the problem you're running into. You cannot decrypt HTTPS traffic without having a Trusted CA installed on the phone, and the security implications of being able to do so easily would not be pretty.

I decrypt traffic in certain OUs, but phones still get domains blocked. It's not the control you're probably hoping for, but it is what it is.


Both tools have a command line option to run benchmarks on your current setup:

For John the Ripper, use --test.
For hashcat, use --benchmark (or -b).


ASLR Randomization and different regions

why ASLR doesn't randomize text, bss and data regions of the process?

It does. The base address of the module is randomised, and therefore the virtual address of all sections will be randomised. However, the relative virtual address of sections from base must remain static, as most memory-access instructions work by relative offsets. Otherwise you'd need to generate fixups for every mov that crosses section boundaries (e.g. an instruction in .text that reads from .data).

It just wouldn't bring any real benefit, would cause lots of problems, and could be easily bypassed by reading known instructions in the current section (fixups are applied in memory).

  Also in the newer version of kernels (such as Linux kernel version 3.x) along with process base, libraries and stack addresses, are the heap addresses also randomized?

Yes. Each heap's virtual base address is random, and heap allocations are performed within that heap as normal.


Does using an UPS mitigate power-analysis attacks on a keyboard?

It very much depends on the UPS. Most UPSes, particularly under-desk form factor ones for home and small office use do not include power conditioning or filtering.

A simplified topology of a common UPS design looks a bit like this:

The AC usually flows directly from the AC IN to AC OUT, and the controller leaves the right hand side of the transformer unloaded. When the power fails, the controller senses that the input power is no longer present and starts producing an AC power source from the battery, which is stepped up by the transformer to take over the supply. The diagram above is heavily simplified but it gets the point across - when the regular AC power is present it's just like running the device straight from the wall socket.

There is another type of UPS design which includes a feature called power conditioning. These UPSes are usually very expensive and tend to be found in rack mount form factors rather than desktop units. Power conditioning UPSes usually include additional filtering in the form of an LC circuit (large toroidal inductor plus a large capacitor array) which acts like a low-pass on the power signal to remove noise and improve power factor. Depending on the characteristics of the filter, this may prevent power analysis side-channel attacks such as the one you described.

Yet another type of UPS is a DC UPS. These are usually used in specialist datacenter applications where it is more power-efficient (and sometimes heat-efficient) to have one large integrated UPS and switching DC power supply solution that provides a DC rail (usually 48V) to all systems in the datacenter, rather than each server switching down from mains AC to the required board-level voltages. Such a design would likely filter out power noise from the servers, thus preventing a side-channel attack, although in most situations you would expect the main UPS to be fed by 3-phase at higher-than-domestic voltage, thus making any direct interface with that power rail extremely dangerous, which is a pretty good deterrent.


The only realistic solution is to reimage any system that is known to be infected. You will want to take care to ensure the new image has every Windows patch on it. You will also need to examine your file sharing configuration on these systems as it looks like this worm will attempt to spread to those as well.


X.509 - How Is Certificate Chain of Trust "Subject Name"-"Issuer Name" Match Comparison Made?

As per RFC 5280 §4.1.2.4 (and as specified in §7.1), binding is done by using case-insensitive match between Issuer distinguished name string of leaf certificate and Subject distinguished name string of a potential issuer.
Bear in mind that Key Match, Exact Match, Name Match techniques are used only to bind certificates and build as much chains as possible (build complete chain tree). It doesn't tell anything about trust/validity. When completed, tree is passed to validation routine which excludes invalid/non-suitable certificates and returns only single best chain. Full validation process is defined in RFC 5280 §6.
Certificate validation is a 3-step process:

Tree building (from leaf to root)
Tree validation (from root to leaf)
Revocation checking (from leaf to root)

Name Match binding is used only during first process.


(Why) should the clipboard be cleared when it contains content from a closed program?

On X11 this happens because "Copy" doesn't actually copy anything - just tells the program to take ownership of the 'CLIPBOARD' selection. When you paste, the target program sends the selection's owner a request of the contents. This was initially done for performance since most or even all clients might be running on a mainframe and just connecting to your local terminal, so if there was a shared buffer then copying large amounts of data would have caused long delays. It is also more flexible because the program can offer copied data in many types (e.g. a word processor might have its own internal format, plus RTF, HTML, and plain text, or an image editor many different formats), and in the X11 case it doesn't need to pre-convert to all of them - just to a single format it was requested. In contrast, programs on Windows have to put all formats in the clipboard, and copy operations can be slow if you use Remote Desktop.

(Note that this doesn't depend on the desktop environment much, with the exception that some DEs - e.g. KDE - have "clipboard managers" that automatically hold a copy of the "copied" data. Beyond that, all X11 programs behave the same way and all Windows programs behave the same way.)


Has HTTP bogus request type "COOK" been used in any known website attacks?

As @WhiteWinterWolf mentioned, Pepoluan answered over here on ServerFault:

  The COOK verb appears to be synonymous with the User-Agent string containing "Synapse". The term Synapse is a free TCP/IP library written in Pascal (see here: http://wiki.freepascal.org/Synapse#From_an_HTTP_server) that is used to create bots, scrapers and crawlers as well as other legitimate software.


Does the DICOM file header gets lost when transferred over the network?

When a file is being sent over the network using the DICOM protocol, the file header is lost. This is because the only fragments or parts of the file that is sent are the P-DATA-TF packet data unit which contains patient information as well as the image pixels.

The only way to keep the file header when sent over the network is by using a transfer protocol such as SMB or TFTP.


Decrypt file using Key and Initialization Vector in Linux

First of all, GPG has its own message format. Unless this is what is produced you won't be able to use it for decryption.

Openssl should be the better option for you. According to the documentation link you provided, the encryption is done using the AES cipher in CBC mode with PKCS#5 padding (all of those are important, AES128 is not a full encryption scheme you can use).

The command you gave in your question looks OK. I have to guesses what might caus the problem (assuming the encrypted file, key and IV are correct):

BASE64 encoding: You use the -a switch which indicates BASE64 decoding. Are you sure your ciphertext is BASE64 encoded?
Key/IV format: Did you put the KEY and IV there in the correct format?

As a guide, here is a MWE of such an encryption and decryption with openssl:

$ echo "foo" > input.txt

$ openssl enc -aes-128-cbc -e -a -nosalt -K 0102030405060708090a0b0c0d0e0f10 -iv 00112233445566778899aabbccddeeff -in input.txt -out input.txt.enc

$ cat input.txt.enc
oo9TBVgBrcfUHd5wE3gctw==

$ openssl enc -aes-128-cbc -d -a -nosalt -K 0102030405060708090a0b0c0d0e0f10 -iv 00112233445566778899aabbccddeeff -in input.txt.enc
foo


Prove a client sent a request - voting system

Your specs begin with:

  Each IP would allow a single vote

Do not go further. If you can control a router for example in a corporate environment, you can:

either make all internal machines present externally the same address (and only one user in the organization could submit a valid vote)
either allow the router admin to submit a valid vote by faking any of the addresses of their organization

And as a single person, I currently use:

a private computer
a corporate computer (only presents the IP address of the corporate firewall)
a private smartphone
a corporate smartphone

Does it mean that I can submit 3 different votes or 4 in nobody in my organization has already submitted one from its corporate computer?

Above was about why I think that your idea is wrong. Following part in my opinion of how to build a voting system.

I just think that I am not clever enough to invent from scratch what others have built upon centuries, so I will just try to translate in IT world how an ordinary election work.

Rule 1: all voters are registered, and their identity must be controlled before a vote is accepted as valid - stop imagining anonymous votes for a serious election.
Rule 2: the content of the vote must be kept secret - nobody except the voter himself should be able to know what the vote contained
Rule 3: it is possible to know who participated to a vote - at least to control that dead people did not vote (it used to be common in some places)
Rule 4: the observance of the previous rules can be controlled by people representing the various candidates (a candidate can be here a human being, a full staff, or a simple proposal)

Those 4 rules are observed for physical voting, as well as post voting. For the latter, an inner enveloppe (no possible identification of it) contains the vote, and an outer one carries the name and manual sign of the voter. The outer enveloppes are opened only by the people in charge of controlling the validity of the vote.

In IT world it would give:

each voter should be informed of the how to vote
the system should be able to identify each voter. The up to date way would be a certificate on a smartcard, but depending on the importance/cost ratio a username+password could be considered
the voting system should keep a track of which user voted and when - this is the voting register
the voting system should increment counters and not store any individual votes
it must not be possible to know at what time the counter changed value to prevent correlation with the time at which someone voted (may impact the underlying counter store). Only the final value must be kept.
the counters should not be accessible to anybody before the end of the election, unless it can be proved that it does not allow to know the recent votes by polling the counters on short intervals
the system should be audited before and after the vote by the candidates or people representing them


libraries alternative to gcc stack-protector / fortity source feature on linux

Carnary protections rely on the compiler adding code before and after each function body, and possibly resorting the function's local variables, so this is not possible for item 1.

As for item 2, the only thing that does come to mind is running the executable under Valgrind for analysis. You will not want to do that in production, as it's slow. Furthermore, some GCC builtins behave badly under Valgrind (e.g. the strlen builtin can read up to 3 bytes (on i386) past the end of an allocated buffer), so this will emit false positives.

I'd say, your only way forward is to recompile the application with SSP enabled (also, GCC ships libssp which contains functions to do item 2). Many other C libraries contain SSP supporting code (it's not much code, really) already, so not using the GNU libc is not a problem.

Some other C compilers also contain boundary checks, buffer overflow checks, stack overflow checks, etc. in various states of usability.

You should also look into your malloc implementation. Some implementations – most notably omalloc from OpenBSD – offer reserving “guard pages” before and after page-sized allocations, and moving smaller allocations to either the beginning or end of a page, to catch accesses beyond the buffer.


How DNS hijacking was myetherwallet.com fault even though AWS DNS server was hijacked yesterday

There are several things which went wrong here and MyEtherWallet could have done things to reduce the risk. The issue was that the traffic to the DNS server was hijacked and thus queries for specific domains resulted in a spoofed response, thus directing the browser to the attackers IP address with a server impersonating the original site. There the user was presented was a fake site which looked like the original one.

DNSSec is designed to prevent exactly this kind of spoofing, i.e. detect that a response is fake. But, DNSSec requires support from the domain owner (must sign records),  the DNS server (must return the signed records) and from the client (must require signed records). While MyEtherWallet could have configured there system to offer DNSSec for the domain it has no control over the client part: the attacker could have just returned an unsigned response since only some clients will request DNSSec in the first place and even fewer will insist on getting only a signed response.

Easier would have been to set HSTS for the domains of MyEtherWallet. If this HTTP header is set modern browsers will remember that the domain always needs to be accessed by HTTPS and that no exceptions in case of SSL problems are allowed. To bypass this simple to setup protection the attacker would also need to get a valid certificate for the attacked domain. It is often possible to get such a certificate if the attacker temporarily controls the domain (as seen in this report from an attack against Fox-IT) but by using a CA issuer with additional controls and by restricting the issuer CA using DNS CAA records it could have been made impossible or at least very hard for the attacker to get a certificate for this domain from a  public CA.

In summary: MyEtherWallet could have done several things to make it harder for the attacker. Some of these would be easy to implement but still very effective (HSTS). Others (like DNSSec) require adequate support on the client side which is not reality today.


Microsoft support asking me for my phone IMEI?

Your IMEI is not bound to your IP stack

An IMEI number is used to identify a phone and is bound to each individual device, much like a MAC address is unique to a network interface an IMEI is bound to a device.  Unlike a MAC address it does not exist in your network stack.

IMEI stands for International Mobile Station Equipment Identity.  IMEI numbers are used for identity (not related to personal identity) on GSM networks.

Security Concerns

IMEI is the core of the handset's identity and is used for authentication with the carrier.  It's difficult but possible to leverage the IMEI to pose as another handset and make calls that will map back to the primary users billing and audit trail of calls.

Identity theft is not typically possible as personal information in a handset is not bound to an IMEI, the carrier would need to be compromised in order to map back in IMEI to personal identifiable information.

IF a IMSI and IMEI information can be obtained it would be a another story as both of these numbers could be used to get blacklisted and stolen phones opened back up with the carrier in order to resell them and have them function again in the carrier environment.

I would not be concerned with giving your IMEI to a technical support representative but of course would only want to give it to a legitimate entity for the sake of personal standards, much as yourself, of privacy and personal security.


Is opening image from the web in google chrome safe

David has a valid point about image-based exploits (we did see a few) - but those are the kind of threats where ordinary folk can't keep losing sleep on.

Mainstream browsers are mostly safe if you only open the image. Do make sure -

that you're not opening the image in an untrusted site's html page. You did mention this - direct image link, not an external html page. Be wary of being redirected from what looks like an image link though.
to protect against script attacks after redirection, use a script-blocker (like NoScript) or ad-blocker (like uBlock Origin and/or uMatrix).


JWT: In a server-to-server request, should I sign the entire request body?

after some research and discussion about this question, i think found the answer to move on

i've moved from symmetric (HS256) json-web-tokens to asymmetric (RS256)

now each server has its own private key, and they share each other's public keys
this means neither server can impersonate the other
this is a superior architecture for microservices, because now a third-party (untrusted) microservice can participate in the network

next, should we place the entire request body into a JWT?

sure, this will work and be secure
however, it's technically overkill — we could just use the underlying crypto to sign the whole request body, and then attach the signature as a header — which would be nicer, because then the request body isn't obfuscated as base64, which would be convenient
for my use-case i will explore the idea of attaching a signature as a header, however if it feels shaky and like i'm rolling-my-own, i might just stick to only using JWT and wrapping the entire request that way as a token, which lessens the number of ways that i'm using crypto altogether in the system, so it's a trade-off


How to exploit escapable JSON parameters

I am going to ignore everything cept:

  and is there any risk associated with the fact that they don't filter braces at all

In a word No.

What you are looking at is all Client Side HTML/JS and while I could see how you would believe modifying it would be a security flaw ... It isnt really, because it only effects you and your computer.

For example if you press F12 in your browser and type the following into the console:

y = document.getElementsByClassName('gravatar-wrapper-32');
for (idx = 0, len = y.length; idx < len; ++idx) {
  y[idx].firstChild.src = "https://www.gravatar.com/avatar/370bb2bee74fc88763dc0fe35477e24c?s=32&d=identicon&r=PG"
}

All of the gravatar images on the page will be changed to mine ... and this is how you hack the gibson ... just kidding

But if you bring up the same page in another tab you will notice that this change has only effected the first tab ... thus it will not effect anyone else on the site.

The same is true for your login-page params ... if you wanted to you could just change the entire string on client side and ... no one would really care.  when you submit the JSON is the real test.

If the developer of the Server Side code does not properly validate the JSON to make sure extra things where not added or removed THEN there would be risks associated (but that is a topic for another question).


What is my recourse if someone made a gmail account with my name?

Your issue is not that someone made a free email account with your name. There are hundreds of "John Smith"s, "Jay Kim"s, and "Maria Garcia"s with that issue, and they manage to live just fine.

Your issue is "which was somehow linked to my credit card". Focus on finding out how that happened, and fixing it and then let the email account worries be a distant second worry compared to that.

It is very unlikely that you will succeed in getting the account disabled unless you can prove some fraud activities are taking place.


sample .apk file fore testing the Directory traversal vulnerability

The example in the book, Hacking Android, covers the Adobe Reader 10.3.1 APK (Adobe_Reader_10.3.1.apk) using the free open-source attack tool, MWR Labs Drozer. The book section title is Path traversal in content providers, part of Chapter 8 on Client-Side Attacks - Dynamic Analysis Techniques.

dz> run scanner.provider.traversal -a com.adobe.reader
Scanning com.adobe.reader...
Vulnerable Providers:
content://com.adobe.reader.fileprovider

MWR Labs Drozer includes a purposely-vulnerable APK called Sieve. If you want to write code to exploit Sieve, check out the -- https://github.com/tanprathan/sievePWN -- project, which includes source code to build your own APK2APK attacks, including the targeting of Directory (aka Path) Traversal. If you search for "apk path-traversal" you are bound to find dozens, if not hundreds, more.


Should CRLs be published for Standalone Offline Root CA?

You should publish the Root CA's CRL otherwise there will be no way to revoke your Issuing CA's certificate if the worse came to the worse and that CA was compromised.  Your only option at that point would be to wipe your whole chain (including Root) and build again from scratch.  That would also involve ensuring that each relying party has removed the original Root CA certificate from their trust-anchor store - not a trivial task.  Without a CRL you lose effective control of all subordinate CAs and end-entities and consequently the trustworthiness of your Root CA.

Note that even with a Root CA certificate CRL, ensuring that every single relying party has the freshest CRL possible after a compromise of the Issuing CA can be challenging.  Many relying-parties cache CRLs therefore you'd need to ensure that this cache is cleared on every single one - again not a trivial task.

Things get even more complex due to the fact that many browsers (Chrome, Firefox) don't even check CRLs any more.

Pragmatically, if you publish the CRL and an Issuing CA is compromised, at least you can take the moral high-ground. If a relying-party's software (which you have less or even no control over) doesn't check this CRL for another 6 months then nobody can point the finger of blame at you.  However, if you chose not to publish a CRL, you'd have some explaining to do.

You can publish the Root CA's certificate via HTTP but if you do, you should also provide an alternative method for relying-parties to confirm that this Root CA certificate is the genuine one - somehow publish a SHA-1 or SHA-256 hash of the file or the value of the SubjectKeyIdentifier extension of the certificate if present.  In a Windows environment it is more common to present the Root CA certificate to the AD administrator who can distribute it to all Windows devices using Group Policy.  However, it is useful to have it published so that non-Windows devices can download and install it.

There is no need to publish CRLs in LDAP these days as it's slow and not all relying-parties can access it.  Far better to publish to a HA HTTP service.

There is no point in publishing the Root CA certificate in LDAP as any party which will relying on it will have it in it's trust-anchor store.  If it doesn't have it in the store, it has either decided not to trust it, or needs to securely add it to it's trust-anchor store first.

So, simply remove all references to the LDAP:// URLs and only keep HTTP:// URL in the CRLDistributionPoint registry key.


Mitigating TrueCrypt Attack Vectors in Memory and System Cache

Keys in Memory

Unfortunately, the OS needs to store the key somewhere in order to encrypt/decrypt data as requested. There are "workarounds" such as TRESOR which stores the key in CPU registers instead of main memory. This comes with some advantages but the underlying attack vector cannot be closed.

  Cached Data on Disk

One solution to this is encrypt the whole disk with full disk encryption (FDE).

A more elegant solution is to use a live system which runs entirely in RAM so that such data leaks are unrecoverable after a system shutdown.


Another method to erase hard drives securely?

Would it be an acceptable alternative to encrypt a whole volume with a program such as TrueCrypt with an extremely strong encryption key and algorithm, then format the disk?

Well, if you're trying to delete it then just overwrite it with random data and you've done effectively the same thing. Truecrypt will write over every block of a drive when encrypting it.

The added bonus, though, is that if you've been running TrueCrypt the entire time and you have a strong passphrase or a keyfile that is separate from the drive, "forgetting" it will also render the drive essentially securely erased.


Manually creating computer account and SPN's in Kerberos (krb5) keytab file for Window Active Directory domain

The tool I was looking for is called "msktutil", by Dan Perry and others (https://github.com/msktutil/msktutil). It can create the keytabs I was looking for (COMPUTER$@DOMAIN.EXAMPLE>COM). A man page (Ubuntu) is here: https://manpages.ubuntu.com/manpages/eoan/man1/msktutil.1.html

It's a useful tool when you want to script docker images/containers that need to integrate with Windows Active Directory, while avoiding SSSD and mount-binding the host /var/lib/sss/pipes directory as data volume to the container. This utility also allows me to keep things nicely in sync with AD.


Key(session token) authentication vs default login/pass authentication

Maybe I'm missing something, but this still feels like reinventing the wheel. As you keep adding provisions for potential issues, I feel you'll converge close to something we do use currently.

I think of authentication as this:

At signup, I declare that I'm X (my UserID / email); and I provide some secret (the password Y) that only you (the site) and I know.
When I return to  login next time, I tell you that I'm X; and to prove it, I tell you the shared secret Y that we agreed upon when I signed up. Thus you accept that I'm the same X.

In security parlance we treat this as just one of the 3 common factors. You could add more factors, but I'm unable to see how we could reduce the first factor from the pair of data items (X,Y) to just one data item.

In general though, it is absolutely essential to provide completely smooth UX to users - and any attempt in that direction is laudable. For example, the way we do it in our website security app ActiFend is by

Not asking for registration at all (first time sign-in = registration)
Accepting federated authentication: Use their Google/FB/LinkedIn account and obtain the email address (only that) from there. If Google says "hey I checked this user and am accepting this user as X", that's good enough for us for this purpose.
For those who want another option, we send an email-based OTP, so that no need to store / save any password; complex or otherwise.

We're not the only one who's trying new ideas for this... e.g., Slack uses "magic links" (a user friendly term to depict alternate-channel authentication); Twitter and Google accept similar alt-channel auth (authenticate from another device where you're already logged in).

There are many ideas - but none of them have managed to pare down the data items to one. You might hide one of the items from the user (e.g., you could take the device ID as X; or their IP address as X.. each with their own issues), but can't avoid it altogether, I think.

I'm unable to articulate this any better... I hope this still helps.


Full IP spoofing is hard for the commoners.

Everything in IP is made of packets. Each packet has a source address and a destination address. IP spoofing is about sending packets with a wrong source address. Sending such a packet is simple enough with a few lines of code (it tends to require local Administrator / root rights; on Linux, this is a matter of a socket() system call with the SOCK_RAW parameter).

Making the packet reach its destination might be a bit problematic. Normally, packets hop from router to router, and routers only look at the destination address (they are interested in where the packet should go, not from where it comes). However, some routers enforce anti-spoofing mechanisms: the routers "know" what IP addresses are behind it, and will see that the spoofed packet is not "possible" (its source address is not one of the source addresses which are normally behind the router). Such routers react by dropping the offending packet. Some ISP employ such routers, because they do not want to be seen as lax ISP who let their customers engage in network practices of questionable morality and legality.

Assuming that your ISP is lax and lets the spoofed packets transit, you reach the other problem known as "TCP sequence numbers". A Web server does not expect lone packets, but a TCP connection. The TCP connection begins with the "three-way handshake":

Client sends a first packet containing the SYN flag.
Server responds to that packet with a packet containing the SYN and ACK flag.
Client responds to that packet with a packet containing the ACK flag.

Each packet with SYN contains the initial sequence number (a 32-bit value) for the data stream originating from the same machine. Indeed, each data byte will be "numbered" and the counter starts at a value that the sender chooses. These values are used in the TCP control flow; client and server use them to tell to the other machine which bytes have been received (the "acknowledge"). In particular, the third packet for the three-way handshake (the ACK from the client) MUST contain the sequence number that the server sent in its SYN+ACK packet.

But a spoofing client never gets that SYN+ACK packet. Indeed, the server sends its SYN+ACK to the alleged client address, which is the source address in the SYN packet. By definition, the spoofing client used a fake source address. So the SYN+ACK went to that fake address, not to the client. Not having received the SYN+ACK, the client has no way of guessing the sequence number which the server put in its SYN+ACK. Therefore, the client cannot send a valid ACK. The server will thus never consider the three-way-handshake as completed. No handshake, no data. No data, no HTTP request or response. The attempt at connecting with a fake source address will simply not work.

Guessing the server's sequence number is hard if the server uses a decent random number generator. The TCP sequence prediction attack is about first opening some connections to the target server, to get a few fresh "random" sequence numbers. Then, the attacker tries to work out the internal state of the Random Number Generator used by the server's operating system to produce the sequence numbers. If the RNG is of cryptographic quality (as it should be in any decent operating system), such prediction is not feasible, and the attacker has to rely on luck. Since sequence numbers are over 32 bits, the attacker has one chance in about four billions to get it right. That's not good odds for the attacker...

To be able to finish the three-way-handshake, the attacker must thus, practically, "see" the SYN+ACK packet, even though it is sent to the fake address. This requires the attacker to be "close" to the target server, on the same LAN or maybe one or two routers away, at most. This explains why I said that full IP spoofing is hard for the commoners: as a basic ISP customer, you do not have the physical access to the wires required to make a full TCP spoofing on a generic Web server. Of course, employees at the facilities where the server is hosted can do a lot more things...

And the answer ? Even if you succeed in making the three-way-handshake and sending the HTTP request, the server will send the HTTP response to the fake address, not to you. There again, you need extensive wire-level accesses to get the response. Otherwise, you could, at best, send "blind" request but not witness their result. This might be enough for an attack, or not, depending on what the server does and why you try to contact it under a fake address.


Can a user be redirected to a malicious website if only a part of the url can be controlled by user input?

Is there a payload for 'returnPath' parameter which an attacker can
  use to redirect an unsuspecting user to https://evil.com.

No.If you only control a part of redirection URL a Open redirect vulnerability is not possible in such a case.

  Is there any other attack possible with this code? [perhaps XSS as
  user supplied value gets reflected on the address bar.

XSS is definitely possible but it is impossible to answer with the information you have provided.Maybe the returnPath variable gets reflected back into the html page without input sanitization,Maybe its gets stored and then reflected without sanitization(far fetched) or maybe it gets printed via Sinks(DOM based).

  Is there any other attack possible with this code?

By that i assume the three line code you pasted?No.


it seems there is one prime contender for the solution, which is to
  encrypt parts of the URI or all of it. Hashing does not seem to be an
  option since the data is highly predictable and calculating the entire
  set of values is easy. Encrypting the entire URI will limit a lot of
  the advantages of the approach. Symmetric encryption requires
  distributing a secret key widely and therefore defeats the purpose.
  The option that seems the best is to encrypt on the sensitive data
  with a public key.

Your logic is sound.

I know of one product that does exactly as you suggest; sensitive data is encrypted in the end-users browser by Javascript code, and an HTTPS GET request is made in which some of the 'key=value' parameter pairs have a public key encrypted, base64 encoded string.

The advantage is that these requests can be passed across networks with multiple TLS endpoints without the sensitive data being subject to decryption, and any web server logs or proxies in the middle won't have access to the sensitive data.

  Does this approach seem valid and/or is there anything else I am missing?

It is valid, but here are the things you don't want to miss:

You need to have a client with enough intelligence to perform the encryption for you.  That means Javascript, or a custom app, or something.
Don't roll your own crypto.  Use a solid, reputable library and get a code review of your app.
Key management.  You need to generate keys, publish keys, rotate keys, and retire keys... and you need to do it carefully, because to do it right means to balance between losing control of the data and losing access to the data.

  Would it be valid to use the same key-pair that would be used for TLS?

I would recommend against it.  Aside from the general rule-of-thumb of "don't overload cryptosystems," there are some situations where that key isn't "trusted".  One that I've run into is that DDoS mitigation services often like to have a copy of your web certificates and keys if they're fronting your traffic during an attack.

  There probably needs to be some other information in the encrypted portion
  to avoid replay attacks

That depends; if the REST transaction you're working with is idempotent, then it's not that important.  If it does change something, then yes, replay protection is more important.

  or mapping an encrypted value back to given key, correct?

Yes, it's not absolutely necessary - depending on how many keys you use and how long their OUP and RUP tail is - but it's much easier not to have to guess which key :)


Sample test cases for all owasp top 10 vulnerabilities

There are loads. Mutillidae, Damn Vulnerable Web App, WebGoat, BWaPP etc. Also, check out vulnhub, hack.me and others like them.


WDigest password stored in cleartext - Windows

This is to allow the user access when there is no domain controller. If you've ever turned off a domain joined computer, disconnected it from the domain, and turned it back on, you'd notice you can still log in with the domain account you usually use.

Regardless of whether you disable or enable WDigest, Windows will still store cleartext credentials for Kerberos authentication, so that it can renew tickets and stuff without you having to type the password every time. It's not necessarily a Windows issue, as it's the same for Linux and OS X.

Cleartext password dump for Linux:
https://github.com/huntergregal/mimipenguin


Should I be concerned when a "Forgot Password?" tool sends my password in plaintext?

Yes you should be concerned if you use the password on other websites or have personal data stored on it. This is one of the reasons you have to have different passwords for every website. They are storing your password plain text. I'd stay away from with personal data. It's one of those basic security principles they violated, chances are that there will be more.


VPN helps change the IP but why I still get banned from a website's chatroom?

The problem you run into is while your intentions may be noble many people use these VPN services to circumvent bans, geo restrictions etc.

So many site operators blacklist all IPs that are known to be associated with VPN providers, some go even further and add addresses associated with hosting providers to the blacklist to.


How do I get started with security? (beginner)

There are so many things to do and read that it's impossible to list them all all here. However, here is a collection of links to questions on this site to get you started:

Beginner level security for a CS student
I want to be web security consultant?
Resources to learn about security
Video Tutorials resources for IT Security
Best resources to learn web security attacks?


How does buffer overread cause arbitrary code execution?

Here's a simple example:

struct {
    char userControlledIndex[2]; // single-character string
    char whocares[6]; // some more data of arbitrary purpose
} blob;

Our user is malicious:

blob.userControlledIndex = '62'; // Look ma, no null terminator!
blob.whocares = "177"; // or {'1','7','7',0,0,0}, maybe not attacker controlled?

Here's where the input is consumed:

typedef void (*func)(); // func is a pointer to a parameterless function
func func_table[10] = { f0, f1, ... , f9 }; // an array of 10 nice safe functions
int index = atoi(blob.userControlledIndex); // totally safe, will be one of 0-9
#if DEBUG
printf("index is %d\n", index); // no possible way this prints "62177", right?
#endif
func_table[index](); // invokes one of ten safe functions

Overreading the string (char buffer) resulted in control over the program flow. If the attacker knows where the func_table variable will be relative to executable program code, and can find a suitable target within the range of "indices" they can select, then they can use this as the entry point for a ROP or return-to-libc attack.

Of course, such attacks are complicated by the presence of ASLR... but buffer overreads can also give you the information necessary to defeat ASLR, by exposing a masked pointer's value inadvertently.


What is pseudo-encryption key vulnerability?

Normally this would be a "fake encryption key".

In the response to the report:

  Now you are making **** up. As it turns out, I was told what you might
  be hinting at here, and it’s clear you have no idea what the **** you
  are talking about.

In other words, in this context it's just a made up thing.

However, there are other situations, for example IPSEC "NULL Encryption Algorithm" or in GSM (A5/0) where you might give a key during a setup call that would then be ignored.  You could then call it a "pseudo-encryption key" since it would be in the place where an encryption key should be but would be ignored.  This would happen, for example, in some kind of encryption downgrade attack.


Reason behind sending multiple probes when scanning?

The main reason is the one you've stated, which is that there's a risk of packet loss on any connection and as a result it's prudent to send more probes to reduce the risk of missing an open service.

With scanners like nmap it's possible to over-ride the default configuration and reduce or increase the number of retries it will make. This can be handy to either reduce the time the scan will take (with a larger risk of missed services) or increase the service detection likelihood when scanning over flaky networks.


This is probably a bad mechanism, since it violates Kerckhoff's principle. If an attacker knows how your "encryption" works, he can just encrypt his own CSRF blob for a specific user and use it in targeted attacks.

CSRF leverages the fact that your browser will send a cookie containing a session ID that authenticates you to the server, even if the request is generated by an automated script. In order to protect yourself against this, you just need to require a token that is unknown to an attacker, and that is not automatically sent by the browser without direct instruction. The standard way to do this is to generate a random value, known as a CSRF token, and add it to the parameters of a POST request. As long as the target script verifies the CSRF token somehow, you're protected.

The simplest way to do this is to generate a random CSRF token when the session starts, and store it as a session variable. It can then be injected into forms that require CSRF protection, and checked by the target script.

Adding any "extras" to this scheme, like encryption / timestamps is snakeoil - i.e. it provides no real security and complicates the scheme, which results in a potentially greater attack surface. Remember: don't be a Dave!


Is it an actual piece of hardware? (I have seen both hardware and software online).

as you stated, it can be both.  Windows has a built in firewall ... but there are also hardware devices that are dedicated to the task (usually for larger networks)

  How do firewalls work in tandem with Active Directory?

Um, it doesn't?  Unless I am missing something in your question they are unrelated.  Both can be use for security, but firewall is to protect against network traffic at lower levels through rules and filtering and AD is more for protection against unauthorized access to a specific computer at the application level through use of credentials and permissions.

  what servers live in the DMZ zone?

Servers that host external information and services ... like a web server or email server.

  Is there an application where you control firewall controls over the other servers? or is the firewall regulated manually in each server?

Firewalls can be administered remotely via a GUI or via SSH ... it is also possible for a firewall rule to be automatically created via tools like fail2ban


For the question about what you could have missed:

At the time you encrypted the data on the server, you can use rsync to securely synchronize the data to the backup.

rsync -aHSv --del --progress ~/<encrypted-data> user@remote-backup-server:/<destination-directory>./ -n

The use of --del is to remove old stuff in the remote destination (you can safely remove that option if you want to keep all the history).

For the question about security:

The advantage of doing things with rsync is that you could secure the backup server firewall to works with only some IP on some ports and use your RSA Keys with ~/.ssh/authorized_keys

OpenSSL or LibreSSL?

I think that point could be interesting to dig as explain on security.stack


I know salt and hash(password + salt), how do I get hash(password)?

You cannot extract a substring from a hash, and that's what you are asking to do.

Take the terminology out of your question and it becomes: How do I get

hash("apple baker charlie") from hash("apple baker charlie delta")?

You cannot. Hashes are one-way processes. You would have to crack the entire hash, know what the salt was, then rehash the original string (the password, in your example).

Knowing the salt does one thing (potentially) for you: you know that you have cracked the hash because you can identify the salt in the result. But this does not technically make the process faster.


How can my ISP block certain websites if I'm using a VPN?

Run a tool like tracert and you will see where your traffic is lost.

If your connection to the website is routed via VPN, your ISP provider cannot block it.

1) Check the routing when VPN is activated. It may happen, that traffic to some hosts or networks is routed not via VPN, but via your provider.

2) When traffic is really routed via VPN, then the VPN provider may block some hosts.

3) ExperssVPN is not an internet provider. It operates in the networks of different ISPs. Some of these ISPs may block your website. Try to select another ExpressVPN server, e.g. from different country. You say, via Tor it works. Check via what IP you are reaching the website, and in ExpressVPN select a server from the same country as Tor exit node.


What is the difference in security between a VPN- and a SSL-connection?

VPN means "Virtual Private Network". It is a generic concept which designates a part of a bigger network (e.g. the Internet at large) which is logically isolated from the bigger network through non-hardware means (that's what "virtual" means): it is not that we are using distinct cables and switches; rather, isolation is performed through use of cryptography.

SSL (now known as TLS) is a technology which takes a bidirectional transport medium and provides a secured bidirectional medium. It requires the underlying transport medium to be "mostly reliable" (when not attacked, data bytes are transferred in due order, with no loss and no repetition). SSL provides confidentiality, integrity (active alterations are reliably detected), and some authentication (usually server authentication, possibly mutual client-server authentication if using certificates on both sides).

So VPN and SSL are not from the same level. A VPN implementation requires some cryptography at some point. Some VPN implementations actually use SSL, resulting in a layered system: the VPN transfers IP packets (of the virtual network) by serializing them on a SSL connection, which itself uses TCP as a transport medium, which is built over IP packets (on the physical unprotected network). IPsec is another technology which is more deeply integrated in the packets, which suppresses some of those layers, and is thus a bit more efficient (less bandwidth overhead). On the other hand, IPsec must be managed quite deep within the operating system network code, while a SSL-based VPN only needs some way to hijack incoming and outgoing traffic; the rest can be down in user-level software.

As I understand your question, you have an application where some machines must communicate over the Internet. You have some security requirements, and are thinking about either using SSL (over TCP over IP) or possibly HTTPS (which is HTTP-over-SSL-over-TCP-over-IP), or setting up a VPN between client and server and using "plain" TCP in that private network (the point of the VPN is that is gives you a secure network where you need not worry anymore about confidentiality). With SSL, your connection code must be aware of the security; from a programming point of view, you do not open a SSL connection as if it was "just a socket". Some libraries make it relatively simple, but still, you must manage security at application level. A VPN, on the other hand, is configured at operating system level, so the security is not between your application on the client and your application on the server, but between the client operating system and the server operating system: that's not the same security model, although in many situations the difference turns out not to be relevant.

In practice, a VPN means that some configuration step is needed on the client operating system. It is quite invasive. Using two VPN-based applications on the same client may be problematic (security-wise, because the client then acts as a bridge which links together two VPN which should nominally be isolated from each other, and also in practice, because of collisions in address space). If the client is a customer, having him configure a VPN properly looks like an impossible task. However, a VPN means that applications need not be aware of security, so this makes it much easier to integrate third-party software within your application.


Are Self-Encrypting Drives (SEDs) used in cloud environments?

I haven't been able to find information on the specific providers you named, but you may be interested in these two articles.

Self-encrypting Drives in Datacentres

Self-encrypting Drives vs software-based encryption

In terms of security benefits, the encryption key is stored on the disk as opposed to the OS, which makes it harder to extract. By erasing the encryption key, they you can render the data practically irrecoverable, allowing you to securely dispose of an SSD in a relatively convenient manner. Plus, it is a lot quicker and cheaper to wipe in this way than pretty much any other safe method.

Not that they're a magic bullet to all problems. The second article I linked details how, with physical access, a powered-on SED is still vulnerable to some of the same attacks as software-encryption, and potentially other methods as well.

Finally, not a security point, but SEDs have dedicated crypto processors, meaning the data encryption and decryption functions aren't vying for CPU usage, so you do see some performance related benefits from that.


How to make an image shown only on a particular domain

There is the notion of a HTTP "referer" (originally a misspelling of "referrer") which your browser will send when requesting pages and assets (images, stylesheets etc). Some security products scrub this though (as a privacy risk) so if you're not willing to accept some false positives (users unable to see the images who should) then this would be a bad solution.

You could set it so the images are not revealed if the referring page is not your website/domain and can either do it:

On the web-server if it supports it like using .htaccess permissions on Apache

Or

You can have your images link to a script which will display the correct image if the referrer matches but send a different file if not (i.e. yoursite.com/showimage.php?image=holiday.jpg ) for instance, which would check the referrer in code and decide whether or not to show the image, see $_SERVER['HTTP_REFERER']; for PHP.

The HTTP REFERER is set by the user so can easily be forged so is not a good security mechanism for a determined attacker at all.. but should serve a useful purpose for most non-technical users where it is only your bandwidth you are trying to protect.

You can see what headers are set by your browser by clicking on this link which should show that you were directed to it via this site.


What is zero-legged OAuth (or does it exist)?

The authentication is in practice no different- the same secret is used as in other flows by the client to create a signature or otherwise provide proof of  possession of the secret.

The difference is on the service providers side. Every service provider endpoint participating in zero-legged-auth needs to know how to access the provider's form of the client secret, to be able to directly validate requests signed with the secret.

This is a less capable, more monolithic and potentially less secure architecture- less secure because of the need to distribute the actual shared secret, rather than a limited-use token.


Firefox and chrome infected with hohosearch and newsearch123.com

I'm afraid wiping the machine, changing all your passwords from another good machine, doing a fresh install from known good install media, and restoring the data (carefully) from backups really is the only solution guaranteed to clean your machine.

In the trade we call this "nuke it from orbit", and the reason it is the only way to be sure is that you don't know what malware has infected your machine. Even if you disassemble the keygen file to work out what you were initially infected with, modern malware is modular in design; once you were infected the malware may have gone off and installed a variety of other pieces of malware, and they in turn may have installed further infections. You can run malware clean-up tools, and they will find some of it, and maybe find all of it, but you can't be sure.


Is rounds in a cryptography algorithm same as iterating the algorithm?

The simple answer is No.

"Rounds" are internal operations inside the AES (or DES) algorithm.  These algorithms use a mixing function that is repeated internally a defined number of times.  Sometimes you read about people cryptanalyzing "a reduced round variant of AES", they are talking about attacking a modified form of the encryption algorithm.  These may or may not indicate a weakness in the published, full-round algorithm.
It may help security slightly, it may do nothing, or it may actually harm security!  It depends on how it's implemented.  Cases where it helps are in protocols like PBKDF2, where the increased number of iterations is used to make breaking the algorithm take a long time.  Cases where it could harm include certain ciphers where a second encryption might result in a decryption of the first!  And there are cases where the intersection of two encryptions can yield information about the key.

In general, randomly throwing cryptographic algorithms at a problem in hopes of making it "better" is an extremely risky approach, and is not recommended.


Public Key Cryptography designates the class of cryptographic algorithms that includes asymmetric encryption (and its cousin key exchange) and digital signatures. In these algorithms, there are two operations that correspond to each other (encrypt -> decrypt, or sign -> verify) with the characteristic that one of the operations can be done by everybody while the other is mathematically restricted to the owner of a specific secret. The public operation (encrypting a message, verifying a signature) uses a public parameter called a public key; the corresponding private operation (decrypting that which was encrypted, signing that which can be verified) uses a corresponding private parameter called a private key. The public and private key come from a common underlying mathematical object, and are called together a public/private key pair. The magic of asymmetric cryptography is that while the public and private parts of a key pair correspond to each other, the public part can be made, indeed, public, and this does not reveal the private part. A private key can be computed from a public key only through a computation that is way too expensive to be envisioned with existing technology.

To make the story short, if you know the public key of some entity (a server, a human user...) then you can establish a secured data tunnel with that entity (e.g. with SSL/TLS in a connected context, or encrypting emails with S/MIME).

The problem, now, is one of key distribution. When you want to connect to a server called www.example.com, how do you make sure that the public key you are about to use really belongs to that server ? By "belong", we mean that the corresponding private key is under control of that server (and nobody else).

Public Key Infrastructures are a solution for that problem. Basically:

The goal of a PKI is to provide to users some verifiable guarantee as to the ownership of public keys.
The means of a PKI are digital signatures.

In that sense, a PKI is a support system for usage of public key cryptography, and it itself uses public key cryptography.

The core concept of a PKI is that of a certificate. A certificate contains an identity (say, a server name) and a public key, which is purported to belong to the designated entity (that named server). The whole is signed by a Certification Authority. The CA is supposed to "make sure" in some way that the public key is really owned by the named entity, and then issues (i.e. signs) the certificate; the CA also has its own public/private key pair. That way, users (say, Web browsers) that see the certificate and know the CA public key can verify the signature on the certificate, thus gain confidence in the certificate contents, and that way learn the mapping between the designated entity (the server whose name is in the certificate) and its public key.

Take five minutes to grasp the fine details of that mechanism. A signature, by itself, does not make something trustworthy. When a message M is signed and the signature is successfully verified with public key Kp, then cryptography tells you that the message M is exactly as it was, down to the last bit, when the owner of the corresponding private key Ks computed that signature. This does not automatically tell you that the contents of M are true. What the certificate does is that it moves the key distribution problem: initially your problem was that of knowing the server's public key; now it is one of knowing the CA's public key, with the additional issue that you also have to trust that CA.

How can PKI help, then ? The important point is about numbers. A given CA may issue certificates for millions of servers. Thus, by action of the CA, the key distribution problem has been modified in two ways:

From "knowing the public keys of hundreds of millions of server certificates", it has been reduced to "knowing the public keys of a thousand or so of CA".
Conversely, an additional trust requirement has arisen: you not only need to know the CA keys, but also you need to trust them: the CA must be honest (it won't knowingly sign a certificate with a wrong name/key association) and also competent (it won't unknowingly sign a certificate with a fake name/key association).

The PKI becomes a true infrastructure when recursion is applied: the public keys of CA are themselves stored in certificates signed by some über-CA. This further reduces the number of keys that need to be known a priori by users; and this also increases the trust issue. Indeed, if CA2 signs a certificate for CA1, and CA1 signs a certificate for server S, then the end user who wants to validate that server S must trust CA2 for being honest, and competent, and also for somehow taking care not to issue a certificate to incompetent or dishonest CA. Here:

CA1 says: "the public key of server S is xxx". CA1 does not say "server S is honest and trustworthy".
CA2 says: "the public key of CA1 is yyy AND that CA is trustworthy".

If you iterate the process you end up with a handful of root CA (called "trust anchors" in X.509 terminology) that are known a priori by end users (they are included in your OS / browser), and that are considered trustworthy at all meta-levels. I.e. we trust a root CA for properly identifying intermediate CA and for being able to verify their trustworthiness, including their ability to themselves delegate such trustworthiness.

Whether the hundred or so of root CA that Microsoft found fit to include by default in Windows are that much trustworthy is an open question. The whole PKI structure holds due to the following characteristics:

PKI depth is limited. A certificate chain from a root CA down to an SSL server certificate will include 3 or 4 certificates at most.
CA are very jealous of their power and won't issue certificates to just any wannabe intermediate CA. Whether that "CA power" is delegated is specified in the certificate. When a CA issues a certificate to a sub-CA, with that specific mark, it does so only within a heavy context (contracts, insurances, audits, and lots of dollars). Ultimately, trust is ensured through fear. Offending CA are severely punished.
Nobody really has interest in breaking the system, since there is no readily available substitute.

Note that, down the chain, the server S is verified to really own a specific public key, but nobody says that the server is honest. When you connect to https://www.wewillgraballyourmoney.com/ and see the iconic green padlock, the whole PKI guarantees you that you are really talking to that specific server; it does not tell you that sending them your credit card number would be a good idea.

Moreover, all of this is association between the server name as it appears in the target URL and a public key. This does not extend to the name intended by the user, as that name lives only in the user's brain. If the user wants to connect to www.paypal.com but really follows a URL to www.paaypaal.com, then the PKI and the browser will in no way be able to notice that the user really wanted to talk to PayPal, and not another server with a roughly similar (but not identical) name.

The main use case for a PKI is distributing public keys for lots of entities. In the case of Web browsers and SSL, the browser user must be able to check that the server he tries to talk to is indeed the one he believes it to be; this must work for hundreds of millions of servers, some of which having come to existence after the browser was written and deployed. Reducing that problem to knowing a hundred root CA keys makes it manageable, since one can indeed include a hundred public keys in a Web browser (that's a million times easier than including a hundred million public keys in a Web browser).

Client certificates are a SSL-specific feature. In all of the above we talked about a SSL client (Web browser) trying to authenticate a SSL server (Web server with HTTPS). SSL additionally supports the other direction: a SSL server who wants to make sure that it talks to a specific, named client. The same mechanism can be used, with certificates.

An important point to notice is that the server certificate and the client certificate live in different worlds. The server certificate is validated by the client. The client certificate is validated by the server. Both validations are independent of each other; they are performed by distinct entities, and may use distinct root CA.

The main reason why SSL servers have certificates is because clients cannot possibly know beforehand the public keys of all servers: there are too many of them, and new ones are created with every passing minute. On the other hand, when a server wants to authenticate a client, this is because that client is a registered user. Usually, servers know all their users, which is why most can use a simpler password-based authentication mechanism. SSL client certificates are thus rather rare in practice, because the main advantage of certificates (authenticating entities without prior knowledge) is not a feature that most servers want.


Its a base 64 encoded payload. Web firewalls are familiar with base64 encoded payloads and try to defend against them hence the attacker is using a technique to evade firewalls that search and filter the call to base64_decode.

Eventually the $l___l_ parameter will hold the decoded content

So instead he constructs it as follows:

_ $l___l_='base'.(32*2).'_de'.'code' => base64_decode
$l___l_=$l___l_(//content) => base64_decode(content) => decoded content

the string replace just deletes the new lines (\n) from the content before decoding

from studying similar looking attack on this blog it seems that the content you receive after base 64 decoding is an encrypted payload. The password to decrypt the payload is obtained by a POST request to another server.


Would memory of EC2 instances behind a vulnerable ELB be readable by heartbleed exploit?

No.

The heartbleed-bug only compromises the memory of the operating system process which uses OpenSSL. The memory of any other processes is not compromised. When load-balancer and application server are different processes AND the load-balancer acts as TLS server (instead of just routing the raw data-stream to the application server which then does the TLS), the memory of the application server can not be compromised.


What's the best duration for storing e-mail?

First check with your legal expert if there are any laws in your country which require you to have a minimum retention period. For instance depending on your industry you might have to take into account either of these regulations:

Sarbanes-Oxley regulations: To comply with SOX guidelines,
companies must retain auditable emails for a minimum of five years
from the end of their last fiscal year.
FINRA rules demand that financial services firms establish formal,
written policies and procedures that detail their email retention
policies. After outlining these policies, a business must then
demonstrate that all retention processes are in full compliance with
FINRA guidelines. According to SEC 17a 3-4 you should retain email for three to six years (depending on the type of record), the first two years in a readily available location.
HIPAA regulations apply: The retention period for a medical record is a
minimum of five years, though some related rules dictate that
information should be retained for the life of the patient. (HIPAA isn't officially approved yet I think)

Also have a look at this paper published by contoural on how to build a good email retention policy.


Is it possible to detect the application level protocol in a TLS tunnel without interception?

It is possible to do limited traffic analysis without doing decryption based on timing, size and direction of transferred data. For example HTTP/1 has a request-response pattern where the requests from the client are usually small while the responses from the server are much larger. Additionally the information in the TLS handshake often allow to distinguish normal browsers from other clients based on supported ciphers and their preferences, used TLS extensions etc.

There are actually many articles and publications about this topic which you can find when searching for passive traffic analysis tls.


Recommended Crypto Security Setup (Implemented Algorithms)?

One of the biggest issues that you face is not the algorithms you choose, but how you implement using them.   There are many good algorithms for various purposes, and virtually any of them, improperly applied, can result in a disastrously broken cryptosystem.

This is one of the reasons people offer advice like "use libsodium" because libraries like libsodium abstract most of the decisions that you might get wrong.

However, to answer the question that you asked specifically, regarding algorithms:

Asymmetric encryption:  User RSA-OAEP.
Password hashing algorithm or KBKDF for symmetric encryption:  Use bcrypt.
Symmetric encryption:  An AEAD cipher.  I know OpenSSL has AES-GCM.  You might also find ChaCha20-Poly1305.  Or you could use libsodium.

One specific point to reiterate about item 3...Don't use the password directly as the key.  Use bcrypt (or another suitable KBKDF) to generate a proper key, in a properly slow manner.  You may already know this, but it's worth pointing out for future readers.

Another critical point - Even with all of the best algorithms, and the proper implementation, key management is a crucial component of the system.  If you don't think hard enough about secure key storage and management, everything else could be for naught.


Which type of encryption algorithms android supports, and which would be better?

On DES and AES: use AES.

DES and AES are block ciphers: they encrypt data by "blocks", where a block is a 64-bit (for DES) or 128-bit (for AES) quantity. To encrypt a "message" which is not a single block, you need to use a "chaining mode" and possibly a "padding": the chaining mode defines how data is split into blocks and assembled again, and the padding consists in extra bytes added at the end of the message so that the total length is appropriate for whatever splitting the chaining mode uses. The padding must be such that, upon decryption, it can unambiguously removed.

The "standard" chaining mode and padding are called, respectively, CBC and PKCS#5. The PKCS#5 padding adds between 1 and n bytes, where n is the block length (hence 8 for DES, 16 for AES), so that the total padded length is a multiple of n. CBC links blocks together and requires an Initialization Vector (IV) which should be a sequence of n random bytes; it is very important that the IV bytes are generated with a cryptographically strong random number generator (i.e. java.security.SecureRandom) and that you generate a new IV for each message. The IV must also be sent along (unencrypted) with the encrypted message, because the receiver will need it to decrypt the data.

For the block cipher itself: DES comes in two flavors, the "original" DES, and "Triple-DES", also called "3DES" or sometimes simply "DES". The original DES uses a 64-bit key, out of which 8 bits are ignored, so the effective key length is 56 bits, and that's too short for security. 3DES uses a 192-bit key (24 bits are ignored, so 168-bit effective key length) and is believed to be robust; it is also three times slower than DES, which is already not that fast.

AES was designed to replace DES, and is generally thought to be better in all respects. AES has three flavors, dubbed AES-128, AES-192 and AES-256, which differ by the key length (of 128, 192 and 256 bits, respectively). 128 bits are more than enough for security, and longer keys imply a slight computational overhead, so a 128-bit key is preferred.

To get a list of algorithms supported by a Java virtual machine, try this:

import java.security.Provider;
import java.security.Security;
import java.util.Map;
import java.util.TreeSet;

public class ListAlgo {

    public static void main(String[] args)
    {
        TreeSet<String> algos = new TreeSet<String>();
        for (Provider p : Security.getProviders()) {
            for (Map.Entry<Object, Object> e : p.entrySet()) {
                String s = e.getKey().toString()
                    + " -> " + e.getValue().toString();
                if (s.startsWith("Alg.Alias.")) {
                    s = s.substring(10);
                }
                algos.add(s);
            }
        }
        for (String a : algos) {
            System.out.println(a);
        }
    }
}

(This is for "normal" Java; for Android you will probably need to change things a bit with regards to the final output.)

The encryption algorithms will be those where the string begins by "Cipher.". Anyway, if you want the most widely supported algorithm combination, it will be "AES/CBC/PKCS5Padding" with a 128-bit key: if a given Android-based supports a single cipher, it will support that one.

If you are in a situation where encryption is warranted, then chances are that you will also need an integrity check; see javax.crypto.Mac. For a MAC, when in doubt, use HMAC with SHA-256 (if SHA-256 is not supported, fallback to HMAC with SHA-1).


Connected to my server through VPN. Should I change my key?

You're probably fine. SSH key-based login is designed to work over untrusted networks, without exposing key data - a VPN, even one which you don't control, doesn't change this.

At no point in the sign-in process is the whole private key sent across the network - this would be a massive flaw in the system if it was the case, and would make SSH key login useless over the internet.

In order to steal your key, the VPN provider would need to:

Perform a successful MitM attack on your connection to the server (which would require access to your private key to be successful)

and

Either inject a command to your system to read your private key, or coerce you into sending it to a remote point once they have a successful MitM in place.

If you were using third party VPN software, there would be a risk of that reading the key directly from your machine, but no more than the risk of any other software you run doing so.


Is it posible to bypass BIOS password without owner knowing later on?

Yes it's possible.

BIOS passwords are not usually taken seriously by manufacturers as a meaningful security measure on their own, since most people don't take care to secure their systems physically. Instead it's expected to act as a deterrent in cases where physical accessibility is reduced, such as public access terminals in schools or offices, to prevent users from tampering with settings that could case maintainers a headache.

if an attacker can get hold of your device he could apply hardware debugging techniques to extract your current password, or as is much more likely, install a keylogger and wait for you to enter the password for him.

If you want to secure your device against attackers bypassing the BIOS password, you should lock it away in a tamper proof hard case, which will allow you to determine if an attacker has had physical access to the device.


Use of pwgen with sha1 to create recreatable passwords

It all depends on the context, which you do not specify. You want to be able to recreate the passwords for some reason; depending on that reason, inability to do it without a Linux machine at hand may or may not be a problem. In any case, the README file points at some ports to other systems, e.g. for Windows; moreover, chances are that the original "for Unix" pwgen could be compiled and executed without any change on a Windows machine with the help of cygwin. And you always have the option to run a VM (e.g. with Virtualbox), install a minimal Unix-like system in it, and run pwgen on that.

When you create passwords deterministically from a file and a seed (that's what the -H option does with pwgen), then the resulting passwords are no stronger than the file and seed are secret. Typically you would use the target server name as seed, and the file as a secret (that way, you can derive multiple passwords for many sites, from a master secret file); if you can keep a file secret, you might be able to keep a text file secret. That text file would simply contain your passwords so far, added with a text editor. This might be a simpler model, and it abstracts away all considerations about portability of a specific application to various platforms.


What are downsides of not using SSL/TLS but using same encryption as SSL/TLS does?

The biggest downside is that you're expecting that because you're writing something smaller, it will also be safer.  In reality, this is really hard to do.

Given that you must control both ends of the connection in order to even consider implementing a custom protocol in place of TLS, there are other way you can increase the security and reduce the attack surface without going through the exercise of inventing and implementing a custom protocol and hoping it's safer.

For instance:

You want to prevent downgrade attacks?  Disable everything except for TLS v1.2 on your servers and clients.

You want to ensure only strong cipher suites are used?  Disable anything except for your AEAD cipher suites.

You have lots of options when using existing TLS libraries to lock them down and harden them, and even with all of their warts, they've undergone far more analysis than a custom protocol you build ever would.  You're better off not re-implementing the wheel, but instead simply taking advantage of your opportunity to configure TLS as securely as possible.


Possible to generate short signed strings?

Yes, but with your requirements it is not really going to be very secure. With 10 characters and 100,000 valid values, the search space is just too small. However, since this seems only to be an optimization step, it may be acceptable.
Simply sign the value, base-36 encode the signature and truncate it. So you would call HMAC(key, inbox), convert its output to alphanumeric and take as many characters as you want.
When creating the inbox identifiers, you could take five random characters and append a signature of five characters. When validating, you recalculate the signature over the first five characters and check that against the last five characters.


That IP is another device on the network and, based on its IP, I suspect it's the gateway. You can't change that MAC from your Kali box, you'll need to do it from the device broadcasting that MAC.


To which entity merchants must report credit card breach?

As per the DSS, the merchant is required to notify the card brands:

  12.10.1.a Verify that the incident response plan includes:

  Roles, responsibilities, and communication strategies in the event of a compromise including notification of the payment brands, at a minimum

And the DSS recognizes that other notification requirements may be compelling (e.g., each merchant is subject to whatever notification laws apply to their jurisdiction):

  Analysis of legal requirements for reporting compromises (for example, California Bill 1386, which requires notification of affected
  consumers in the event of an actual or suspected compromise for any
  business with California residents in their database)

Needless to say, the jurisdiction question is a problem, given the viral nature of the more progressive state's laws, and the widespread customer base of many web merchants (including international, as your link suggests).

So: the merchant must notify the card brands, which in practice means they will notify their acquirer/processor and it will chain from there.  As to individuals?  DSS recognizes that may be necessary, but doesn't compel it.  Whether it makes sense for a merchant to notify individuals is a question that their public relations and legal teams usually tackle together.


DHCP Exhaustiation / Rogue DHCP interrupted by real DHCP NACK

Plan A: Try using another ip range than the real DHCP server.

A DHCP server is not supposed to NACK a request for an ip outside it's IP range.

Plan B: it is a race condition, so flood the client with DHCPOFFER messages.

Plan C: use arpspoofing, it's much easier.