Is it possible to exploit this Zookeeper instance?

First of all, I'm also not familiar with Zookeeper at all but I could give you some general advice from a security perspective.

The Zookeeper commands you listed sounds like administrative functions, that means that they probably should only be accessible after authentication or should, for example, be only accessible inside a private network or accessible from certain IP addresses only.

If you are testing a controlled testing environment I'd suggest to contact the administrator and plan a moment to test the kill command, this will verify if it will really work in such a way. If it does I can imagine something like locating all Zookeeper servers in a cluster and kill them all, causing a shutdown of the service. Security professionals will likely call that an availability risk. Ethical hackers and script-kiddies will likely call that a defacement.

Again I don't have any knowledge of Zookeeper but I could imagine the following theoretical risks.

dump shows the sessions, depending on the exact session information that is exposed, you might be able to confuse the system when trying to spoof such a session. Possibly affecting integrity.
envi depending on the information showed you could use that to get a better view of your target and possibly widen the scope if other related systems are found by that information.
kill as noticed before, availability risk and probably the biggest risk of this list of commands.
reqs information disclosure and depending on the information a possibility of confusing processes by spoofing things.
ruok simple information disclosure, I can't imagine any risk unless there are some Zookeeper specific vulnerabilities known that will only work when it's running in a non-error state. Again error-state/non-error-state is a 50% chance that a "state specific" vulnerability will work. Knowing the actual state increases that theoretically to 100% when the versions and everything match.
srst depending on what statistics it resets exactly, you might be able to clean traces after a hacking attempt. Erasing your tracks.
stat information disclosure. Giving unnecessary insights in the system and possibly infrastructure and can possibility be used to widen the scope.

My general advice would be. Prevent this system from accepting that kind of commands from anyone. Possibly adding an authentication layer like VPN and/or IP restrictions or enabling authentication features within Zookeeper (if they exist). This will make sure that information is not unnecessary disclosed and mitigates the possible availability risk caused by of the kill command.

While kill itself is not a vulnerability, it is a risk. Using the CVSS scoring system, if kill actually works and depending on your exact attack background and factors I'd estimate a CVSS of the availability risk on something like 7.1 (high), (AV:N/AC:M/Au:N/C:N/I:N/A:C).

Also, you might want to check out this:

http://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-27453/Apache-Zookeeper.html
https://nmap.org/nsedoc/scripts/hbase-master-info.html


How unlikely is it that a Google Doc link is guessed?

Assuming the document ID distribution is uniform and unpredictable, here's the math:

44 characters long
Uppercase, lowercase, digits and underscore =
26 + 26 + 10 + 1 = 63 character alphabet

Therefore:
Total possible combinations: 6344
keyspace: 263 bits  ⇐ 44 * log2(63)

And we know that brute-forcing a 263-bit key in any reasonable amount of time (lifetime of the universe) is well beyond what the laws of physics will allow, no matter how advanced and magical and "quantum" the computers may become.

This may seem a bit bold an assertion, but it comes from the fact that the sun simply doesn't put out enough energy in such a timeframe to count that high. See page 157 of Schneier's Applied Cryptography for the details, or look at this answer here where I summarized the math, or this answer where lynks quoted the entire section from Schneier's book.

Specifically, the sun's energy is only sufficient to count to 2187 per year, meaning it will take 276 years with our own sun, 275 years if we could harness 2 suns, etc. You might barely have enough power to count to 2256 if you were to power your computer with the supernova destruction of every star in the Milky Way Galaxy. So that's getting somewhere.


ECC Public Key length differs from bit representation

An elliptic curve is defined over a finite field of size q for some integer q. Each curve element is a point and has two coordinates X and Y, which are curve elements.

The "size" of the curve, which is the important parameter for its cryptographic strength, is close to q. It can be shown that the total curve size n is such that |n - (q + 1)| ≤ 2*sqrt(q) (that's Hasse's theorem). So if you want a "256-bit curve" you will need a 256-bit field.

However, a public key is a curve point, represented by two coordinates. So you end up with two 256-bit values, hence the public key size. Moreover, standard public key formats also include some parameters which specify that the public key is of the "elliptic curve" type, and reference the actual curve from which the point is part. We still call it a "256-bit public key" because that number relates to the cryptographic strength of the key, not to the actual encoded size.

If we dig a bit further, we may note that all curve points must, by definition, fulfil the curve equation, usually Y2 = X3 + aX + b for two constants a and b (these constants actually define the curve). It follows that, if you know X, then you can compute Y2 by using the curve equation. Since we are working in a field, an element has at most two square roots in that field, so from Y2 you can get Y and -Y. This allows point compression: a representation of a point (X,Y) as only X, plus one bit of Y (which is enough to distinguish between Y and -Y). With point compression, a 256-bit EC public key fits in 257 bits (assuming that the information about the used curve is transmitted through some other way).

Unfortunately, point compression, while nifty, appears to have been patented at some point, so a lot of existing implementations don't support it, even though it would be "standard" (it is described in ANS X9.62-2005). From the "RFC" point of view, support of point compression is optional. Therefore, using it incurs a risk of loss of interoperability.

(I don't know if OpenSSL supports point compression. It should be tested.)


REST API security mobile application with PIN

I do not completely understand the question, but it seems that you want to know a good solution to implementing this.

To implement this, I would suggest fetching a unique devide ID (Can be IMEI, but can also be some OS-dependent ID), and then concatenate this with the PIN. Then you use PBKDF2 to derive a key out of this.

You then select a number of iterations that are sufficent to prevent cracking the 5-digit pin by bruteforce, but still doesn't take awfully long time to authenticate.

Here you have 2 choices. Either you can encrypt the OAUTH token with the generated key and store inside device storage, or you can implement a verification on the server side, where you verify the PBKDF2 key when a mobile OAUTH token is used. To sense if it a mobile OAUTH token is used, you can set a flag in the login form to detect mobile logins.

A better solution, if your management allows this, is to use hardware-based storage of assymetric keys instead. (boolean KeyInfo.IsInsideSecureHardware();), where the server will verify that the correct private key exist inside secure hardware (by doing a challenge which the app signs using the hardware key). That will make it possible to strictly bind the app to a specific device, and you can skip PIN authentication, as the user's lockscreen is enough to prevent misuse of the app. (and then you give the users choice too, to not have a PIN if they want, by disabling the lockscreen).


Data extraction, temporary storage and audit log - Advice needed

You should create a mirror of the database. It's not possible to access data on the database when it's offline, so a mirror would make it possible, even a read-only mirror.

When you create a mirror, all the permissions, users and groups are exported too. This would solve issues 1, 2 and 3.

For 4, your application logs and database logs will suffice. You don't need to change anything, just keep the logs as you should been doing.

For 5, it's complicated. Database admins and server admins are in position to copy the entire database, and if it's not too large, take the data home on a USB disk without much trouble. This does not have to do with a temporary access, but even your production state must account for. Proper auditing will help, but not protect your data against a determined and resourceful admin. Just ask NSA about Snowden when you have time.


Harden a server against mass SSH DoS attacks

One usually evoked solution is Fail2Ban: this is a system which uses the firewall rules (iptables) to block incoming connections from IP addresses from which some kind of exhaustive search attack is apparently in progress.

This, of course, won't work with a distributed DoS, coming from thousands of distinct IP addresses. In general, very few things resist a distributed DoS.

Fail2Ban can also be problematic in case of large-scale NAT: it has potential for locking out a whole network of normal users who just happen to share the same IP address, as seen from the outside.

It is highly recommended, when you begin to configure tools such as Fail2Ban, to also run another SSH server on another port, not covered by the Fail2Ban rules, just to allow re-entry in case a bad configuration locks you out.

Another completely different strategy is to keep a connection open at all times. E.g. you have a long-standing SSH between your server and your own desktop system; you may even multiplex other connections on it (with SSH abilities for tunnels, and/or SOCKS proxying). This avoids the allocation problem: you don't need to get a free port for your root connection since you already have one.


None will protect against a replay attact.

In the first case, all the attacker has to do is adjust the timestamp.

In the second case, since H() is not supposed to be secret and since the timestamp is known, and attacker can also adjust the request by creating a valid H(timestamp). There is also the problem that you need to synchronize the client and server so that they both have the same timestamp value.

The best way to prevent replay attack is to use challenge-response (there are other ways to do that, depending on your needs).


Can I safely post the output of lspci, lsusb, lshw?

Syslog contains errors or application logs. You will find php logs, restarts of programs...

lshw will return what hardware you are running in a very detailed way.

lsusb will return info about your usb device and it's driver.

lspci will give some more info about attached pci devices.

It's basic trouble shooting really, they want to know when you insert your SD card what errors are given in the syslog and what type of hardware you are running to check for incompabilities.

It's nothing special actually for a desktop. Just read what you post in the syslog as it might contain an email address from time to time (but probably not because you are using it as a desktop).

So in short, it is not dangerous in your situation.


The 'Salt' that the generateSalt-function generates seems to be a combination of different parameters chained together with '$' followed by the encoded salt.

For example $2a$14$uJFVYDcsSqo.eofbk/xmAu
Where the 2a seems to be the version, and the 14 seems to be the number of iterations. Then in the next step when generating the hash it uses the argument from the string that the generateSalt-function creates as the iteration count in the hash function.

I find it a bit odd to pass arguments like that in the salt string argument of the hash function.

Ref: https://github.com/BcryptNet/bcrypt.net/issues/26


Note: I am assuming you are working for/with that brand.

Most phishers perform the minimum work they can to create the fake page, which means they leave links pointing to your javascript, css, images…

By watching the server logs and the referrer provided by your visitors, you will be able to detect new phishing sites using that code in almost real time.

Also, you can intentionally put absolute urls in the html, css and javascript to increase the odds that it leaves some references to your servers.


Why use HTTPS Everywhere instead of going to the HTTPS site directly?

Suppose you're using a very old browser that cannot connect to the server using TLS, because the server does not support the old TLS versions and/or deprecated TLS cipher suites that the browser supports. For example, IE6 in WinXP supports at best SSLv3 + 3DES, and IE8 on WinXP supports at best TLS 1.0 + 3DES. SSLv3 is insecure because the CBC padding is non-deterministic and not covered by the MAC [1], and 3DES is not very secure (insecure?) because its block size is 64 bits [2]. Many servers don't support any TLS version and ciphersuite that would let Internet Explorer on Windows XP (with all the patches applied) to connect, for example to at least download a newer browser.

If you're on such a browser, and the website implemented a mandatory redirect from http to https URLs, you would be SOL.

Another reason is that some sites are under the mistaken, anachronistic, impression that encryption is computationally expensive and their server's performance would be severely degraded by spending CPU cycles on crypto, and so they use TLS "when necessary" (login page, checkout page) and don't use TLS "when not necessary" (browsing the product catalog), to "improve site performance".

Some sites were built and deployed some time ago and have not been updated in a few years. At the time, people were less aware of the total surveillance situation and the issue of authenticity and data integrity. Basically they thought that if confidentiality is not important, TLS is not needed, and thus bad people can inject bad javascript into sites and viruses into executables as they are being downloaded, with impunity.

1 - https://www.openssl.org/~bodo/ssl-poodle.pdf

2 - https://sweet32.info/


How to track MAC policy violations back to HTTP request?

In very general terms, your problem is one of keeping context information. IF we assume the following:

Each request is handled by some code in the server, with one of the execution threads.
Each thread processes one request at a time.
The server code logs each incoming request with both a high-precision time stamp (milliseconds or below) and the identifier for the handling thread.
The MAC policy engine, when it detects a violation, logs it along with a high precision time stamp and context information, in particular the identifier for the offending thread.

Then it becomes easy to map violations onto requests.

In practice, depending on the involved technology (server code, application design, policy engine...), some of the above information may be missing. For instance, the policy engine may log only the process ID and a process may contain several threads (there are "system threads" handled by the OS, but at application level there can also be so-called "lightweight threads" that the OS is not aware of). Some server engines may pursue several requests simultaneously (state machine design with poll()). Logs may lack sub-second precision. In the server, the I/O accesses may be centralized and shared, so the thread which received the request is not necessarily the one which does the file access.

If you do not have all the needed information, then you will have to analyse all the requests received in the relevant time frame, until you find the funky one. You might want to resort to simulation: keep all incoming requests in a circular buffer, so that at any time you have a copy of the last minute worth of request data or so; if the policy engine detects a violation, make a snapshot (a copy of the requests and the relevant server state). Afterwards, during analysis, resubmit all these requests to a copy of the server, one at a time, until you find the one which triggers the problem.


Is Kaspersky Total Security a good choice against malware?

My question is: by only using Kaspersky Total Security and executing some verifications, can I make sure my PC is clean and safe from viruses?

No you can't. Especially not if you are running the security product from inside a potentially compromised system since in this case you (and the security product) can not really trust anything what the system reports.

Apart from that no security product is perfect. They might cover most of the normal non-risky behavior but if your are deliberately increase your risk (i.e "navigating through some suspicious websites") don't expect them to rescue you in all cases.

If you don't want to avoid such sites use another level of separation like a virtual machine - which is not totally secure either but much safer than using the normal system. See Does a Virtual Machine stop malware from doing harm? for more.

  And if not, what should I do to solve it?

Unfortunately the safest way is to burn or at least reinstall everything which might have been affected and restore from the latest known good backup (which you hopefully have). This not only includes the current system but also the router (which is a common target for infection) and also any other system which is connected to yours or to the router.

A less destructive option would be to boot from a definitely not infected medium (i.e. CD-ROM) and do the analysis from there. Since this only looks for known bad things this is not as safe as restoring from a known good backup. But it is definitely less destructive which is important if you don't have a current known good backup. Kaspersky offers such an analysis medium too (Kaspersky Rescue Disk).


How to add X-Frame-Options header to a simple HTML file?

X-Frame-Options is an HTTP header. As such, it's not part of HTML and can't be set inside an HTML document.

One reason why it's an HTTP header only is that clients should be able to decide if the document is allowed to be embedded in a frame before parsing the HTML code.

Hence, you can't achieve that by editing the file but you need to modify the server's HTTP response. Typically, this is done in the settings provided by the web server software or with a server-side language.

E.g., a setting in Apache could look like this:

Header always append X-Frame-Options DENY

Or, in PHP you could set the header like that:

<?php header('X-Frame-Options: DENY'); ?>

Note that there is a more modern CSP equivalent frame-ancestors. But while some CSP policies can be set as <meta> tags, that's not possible here. This does not work:

<head>
  <!-- This does *not* work! -->
  <meta http-equiv="Content-Security-Policy" content="frame-ancestors 'none'">
</head>

Also have a look at the Clickjacking Defense Cheat Sheet for an overview of clickjacking defense measures beyond setting the XFO header.


Can be used ECDH with static public key and parameters?

The scenario does not seem correct; what's to stop an attacker man-in-the-middle'ing Step 2?

I don't see any way in your protocol for the client to know that it is talking to the real trusted server and not an attacker.

I also notice that your solution provides no way to block a client from joining the network and/or verify the identity of a client prior to letting them in (ie it provides privacy but no authentication). Doing that would require bootstrapping your clients with some sort of certificate / pre-shared key / auth token prior to it joining the network.

Basically, your clients will be communicating security with someone, but they will have absolutely no idea who. When you allow attackers to join the network freely, then what's the point of encryption?

Static ECDH does exist, so you can use it but I personally have never seen it used "in the real world" it's always ECDHE+RSA using a RSA certificate from a CA, or something similar.

Yeah, basically don't invent your own crypto protocol. Just don't.

There are any number of secure networking protocols with open-source implementations that have been well designed by crypto experts. Signal / libsignal comes to mind, though there are many many others. This is a solved problem, don't re-invent the wheel.


Are there actually Wifi boxes out there that support two simultaneous SSIDs?

Yes, this is also a major feature in more advanced wireless systems.

  Two were called XYZ's Wifi and the third was called XYZ's Guest Wifi. One of the ones called XYZ's Wifi disappeared within 1-2 seconds and did not reappear.

That probably relates to the mechanism by which this usually happens. Each broadcast of an SSID uses a different MAC address. It's possible that two addresses were spun up with the same name, then one of them changed to have the guest name.

Having these different identities allows for different settings including varied speed, security, and other settings though security is often the focus in being able to permit an open network and an authenticated network in parallel.

  How can I tell whether they are actually both in the same router, or different routers?

Ultimately, checking the router configuration is the appropriate answer to that question.


The cookie usually doens't hold IP information.  And your browser isn't -as far as I know- able to determine your IP address and pass this on.  Even when it would be, through a plugin/activeX control, it may be the RFC1918 IP address which is fairly useless.

A cookie, however, can identify your browser.  A website can set a unique value which your browser remembers when it visits that site.  If you don't clear your cookies (and there's more ways to do it, see evercookies) - and you connect using a different node.  The target site will see a new IP address, a new country even, but it's the same browser/session, and hereby the site owner may derive that you are the same person.  But as a general rule of thumb, installing plugins could compromise your privacy.

So they may see that you (your session) logged in from China, an hour later from Belgium, then from Ohio.  Assuming you are using some sort of routing network such as Tor.

From an IP point of view, it will be the IP address of the final Tor node.


Course project that teaches secure design

Like @David mentioned, an e-commerce website or anything that handles "sensitive" data will be a good start.

Let's talk about your second requirement. If you are talking about secure design for web applications, you obviously want to point them towards the OWASP Top Ten. While the list is no where near complete, it is a good start. Perhaps have your students read through the it and come up with a design document explaining how they will mitigate each item in the list.

Your first requirement is a little tricky. Code review is a tedious process after all. If your students have prior programming experience and you are not grading them on the quality of the code itself, I suggest taking an entirely black box approach to the grading. Have the students try to attack each others code. I stand by my answer that the best way to learn about secure coding is by having someone break it. Perhaps you can think about dividing the grading into three components. The first component will be the initial design document that details the student's analysis of the threat model as well as proposed countermeasures. The second component will be the report of the "penetration test" against the code of a peer. This can be either a black box attack or a code analysis. The third component will be a report detailing how the students fix the flaws found in the code.

This way, your students get to experience the entire secure development process, up to patching any bugs that occur.


Attack using weird characters followed by some javascript in a URL?

Those URLs look a lot like a buggy crawler and very little like an exploit attempt.

A properly formatted hyperlink will start something like . The interesting part is what is between the " characters. A lazy coder might just look for pairs of " characters and not pay attention to the context at all.

Depending on the structure of the URL, it may be an absolute or a relative URL. I have seen plenty of examples of crawlers incorrectly using an absolute URL as if it was a relative URL. That's another example of how they may get URLs wrong, though I'm not sure if that part applies to your case.

If /js/bundles/ contained a link looking like , that might be interpreted as a relative link pointing to /js/bundles/,!0):this.element.propAttr(. Of course the file didn't contain a link looking exactly like that, but it may have contained the sub string ",!0):this.element.propAttr(", and to a lazy crawler only looking for " characters those two would be the same.

For each of the code fragments in your example you can ask yourself, is it realistic that this would have been found in a context where it was surrounded by " chars. I think it is.

The reason I think it looks very little like an exploit attempt is that those fragments of code could not be executed on their own. If you were to actually try running that code, you'd get syntax errors because parts were missing. Actual exploit attempts usually contains some piece of code, but they contain enough code that the code could actually execute.


Periodic password change needed when using 2-step verification?

Indeed, two factor authentication (2FA) will prevent anyone from accessing an account without having both authentication factors.

That being said, the typical implementation of 2FA online is a password paired with a short code, either on a keyfob or sent via SMS.  The standard RSA SecurID keyfobs that have been around for a couple decades now and Google's 2 step verification program, as a couple examples, both use 6 digit numeric codes as the second factor.  With only 1 million possibilities, that's a fraction of a second to brute-force on even obsolete computing devices.  Granted, there are other security measures in place (like account lockouts and time restrictions) that offer protection against brute force attacks on the second authentication factor, but it's such a small number of possibilities that it's probably feasible to overcome with just a little effort and ingenuity.  For example, renting a botnet (which can be done for literally several dollars) and using a modified "low and slow" brute force attack against the second factor, if the password is known.  As pointed out in the comments, if we assume 3 guesses at one in a million odds per "attack", before the code resets, we get a ~3 in one million chance of succeeding per attack. Assuming we were able to launch one of these treble attacks against the second factor every 30 seconds, we could get a 26% chance of succeeding do in a couple weeks or so (100,000 attacks, 1- 0.999997100000), and better than 50% chance of success in approximately a month (250,000 attacks, 1- 0.999997250000).

And bear in mind that brute-force attacks are not the only possible attack against the second factor or the best, or most likely... they're probably about the worst way to attack this second factor, and they're likely to be at least somewhat feasible.  It's not that difficult to con a cellular service provider into giving over control of an account/phone number (to receive the 2FA SMS message themselves), or steal a keyfob, or exploit vulnerabilities in the 2FA system itself, and so on.

At a high level, 2FA is about verifying someone as an authorized user in two different ways.  "Something you know, and something you have."  People are bad at generating unguessable secrets (something you know), as well as being bad at keeping them secret, and people are also not great at keeping control over physical things (something you have)... but they're much more likely to be able to do one or the other at any given time. As long as I can do one or the other, 2FA will keep my account [relatively] secure.  On its own, that 2nd factor is little more than a very, very weak password, (at least as implemented by most websites/webservices) and people protecting their accounts with very, very weak passwords is one of the reasons that 2FA exists in the consumer space today.

So yes, passwords are still needed with most 2FA, and occasional password changing is still a wise precaution. The relative weakness of the second factor in typical implementations means that it's not secure enough to stand on its own, without the secrecy of a good password for the first authentication factor.  And because a good password as a first factor is still required, that does mean following good password practices (strong password, not re-using it, changing it occasionally).


Does Android have no protection against malicious public USB ports?

Android has this feature now.

Go into either
Settings > System > About phone
or
Settings > About phone.
Inside About phone tap on Build number about 7 times. Navigate back to Settings at the top of the screen and enter 'developer' into the Search View. From the search results you'll need to follow the Developer options link. Inside Developer options flip the switch at the top to On and then scroll down and tap Select USB Configuration. In the dialog select a configuration from the options, and you're all set. To help prevent attacks from malicious chargers you would generally set the configuration to Charging.


How to verify if my OpenSSL version is vulnerable to CVE-2016-7056 (ECDSA P-256 Key Recovery Timing Attack)

Check your open ssl version
openssl
--version

Below are the list of affected versions.

Versions Affected:
OpenSSL 1.0.1u and previous versions
LibreSSL (pre 6.0 errata 16, pre 5.9 errata 33)
BoringSSL pre November 2015

Mitigation:
Users of OpenSSL with the affected versions should apply
the patch available in the manuscript at [1].

Users of LibreSSL should apply the official patch from OpenBSD [2,3].

Users of BoringSSL should upgrade to a more recent version.


How does someone become a man in the middle?

There are many, many ways you can become a MITM, virtually at all layers of the networking stack - not only the physical one. Being physically close to your target can help, but is by no means a necessity.

At the physical layer, the attacks you can get are very overt: splice a ethernet cable, use a optical tap, or capture radio signals.

A passive optical network,  tap - photo by Roens

Some active attacks can have physical access as a precondition - many others do not.

At the data link layer, passive attacks are incredibly easy: just put your network card into promiscuous mode and you can see all traffic on your network segment. Even on a modern (switched) cabled network, MAC flooding will ensure you can see more than you ought to.

For active attacks on local networks, ARP spoofing is quite popular and easy to perform - it basically makes your computer pretend it's someone else - usually a gateway, so that you trick other devices to send traffic to you instead.

ARP spoofing - diagram by 0x55534C

Data link attacks work as long as you are connect to the same local network as your target.

Attacking the network layer is easy if you have physical access - you can just impersonate a router using any modern linux machine.

If you don't have physical access, ICMP redirect attacks are kind of obscure, but sometimes usable.

Of course, if you have enough money on your pocket you can do it NSA-style and intercept routers when they are shipped to their destination by (snail) mail - just tweak the firmware a bit and you're good to go.

Attacks at the network layer can be performed from any point in the (internet) network route between the two participants - although in practice these networks are usually well defended.

I'm not personally aware of any attacks at the transport layer.

At the application layer, attacks can be a bit more subtle.

DNS is a common target - you have DNS hijacking and DNS spoofing. Cache poisoning attacks against BIND in particular were very popular a couple of years back.

DHCP spoofing (pretending to be a DHCP server) is quite easy to perform. The end result is similar ARP spoofing, but less "noisy" on the network and possibly more reliable.

The broadest application layer attacks can be performed from anywhere in the internet.


How do systems protect against a stolen code-signing certificate after the certificate expires?

This is why Microsoft recommends to never remove expired code signing certs from CRLs. An alternative scenario: attacker signs their malware before cert expiry. If they can remain undiscovered past cert expiry, then the cert won't get added to the CRL even on discovery, and their malware will never get blocked. Thus the revocation status of code signing certs must be tracked forever.
From Microsoft's Code Signing Best Practices document:

In most PKI deployments, only certificates that have not yet expired are placed on the CRL. This means that when a revoked certificate expires, it is eventually removed from the CRL. However, timestamping allows Authenticode signatures to remain valid indefinitely. As a result, revoked code-signing certificates should not be removed from the CRL. This paper recommends always revoking compromised certificates that were used to sign publicly released software and maintaining these entries in the CRL indefinitely.
Microsoft Certificate Server enables administrators to configure the CA to keep all revoked certificates in the CRL. However, the CA does not distinguish between code-signing certificates and other certificates. For this reason, administrators should dedicate a CA for the sole purpose of handling code-signing production certificates.

So to answer your question - yes, the malware can run again if the CRL for code signing certs isn't managed properly.


Does NDP (Neighbor Discovery Protocol) reduce ARP (Address Resolution Protocol) attacks?

Similar to typical ARP usage under IPv4 is the ND address resolution function, which is used when a host wants to transmit to an on-link prefix but doesn't yet know the layer two address of the destination host.
The sending host multicasts a neighbor solicitation, and the destination host, if reachable, responds with a neighbor advertisement containing its layer two address.

as in ARP, these exchanges are unsecured., but with The Secure Neighbor Discovery (SEND) Protocol prevents an attacker who has access to the broadcast segment from abusing NDP or ARP to trick hosts into sending the attacker traffic destined for someone else 'ARP poisoning'.

See this question for more explanation.


Is it possible to restrict portions of a web site to only allow access based on geographical region using the IP address?

IF you can map an incoming IP address into a geographical location, then yes you can filter out clients based on their presumed current country. However, this relies on geolocation and its associated databases, which are not necessarily very reliable. Also, whenever someone uses a proxy or VPN or IPv6-to-v4 tunnel, then the IP you see on the server is the IP of the proxy/tunnel exit point, not that of the originating computer.

Conversely, if you restrict access to only US-based IP, then it would suffice to rent a server from a US-based provider, and use that server as proxy, to connect to your server with a "US-based IP" (setting up such a proxy is a matter of a one-line command with any Linux system: ssh -D 5000 theproxyserver). Half-serious attackers will thus not be much deterred by the filter you suggest. This location-based filter will mostly block the non-intelligent automatic attempts from botnets (which try to propagate), and these are the least dangerous of the lot.

Restricting the number of potential customers who can see your Web site does not seem to be, in my opinion, a commercially optimal move. Usually, you do not want to chase customers away.


"First we moved the BGP IP prefix," said Gargula as he detailed the attack, "I tried to isolate legit human traffic from bot traffic and not to mix it up. We sacrificed one of their three BGP uplink layers as a 'canary' to test the sophistication of the attack. Then we changed the configuration for the IP uplink."

"How does moving the BGP IP prefix help?"

I believe they are refering to a sinkhole--a sacrificial router, in this case a BGP router, since BGP may not require much authentication.  By configuring the sinkhole to "advertise routes with bogon destination addresses, you can set up a central trap for malicious traffic of all types" [Hacking Exposed 7: Network Security Secrets and Solutions, 2012].  Lists of bogon addresses can be found online: www.cymru.com/Bogons, slides

"And also, what other sophisticated DDOS techniques are there?"

There are a number of sophisticated DDoS techniques.  DDoS leverages DoS methods using a distributed attack surface.  Most of us probably know about SYN flood, where a syn packet is sent with a spoofed source address and the receiving system tries acknowledge it does not receive a response and is left with partial connection in a short queue that is easily disabled by flooding.  Similarly, a UDP flood is designed and source IP addresses are often spoofed to target DNS servers which rely on the UDP protocol.

Reflective amplification is another DDoS attack (DRDoS) that again uses spoofing.  Often botnets send the packets, the source address is the victim IP address, and the packets are sent to machines that try to respond to the victim simultaneously, generating a flood of packets sent to the victim.  For example, DNS servers respond to small requests with a large amount of information and DNS amplification can overwhelm the victim's system.

Application-layer DDoS attacks use the same ideas at a higher level, such as the web level, rather than the transport or communication level.  Here the goal of the attacker is to find an easy and short request that generates lots of work in the victim's API.  For example, a single-word search request can eat up lots of cycles on the victim's machine.  Or a database-driven site, might have pages that trigger database queries when the URL is requested.  Now, the attacker can use just a few queries per second, either making the requests in a distributed manner or not, and bring the victim's machine grinding to a halt.

There is also a low-rate DoS attack where the attacker causes a TCP connection to enter a retransmit state.  If enough connections enter this state, the victim's machine suffers declining performance.

See Hacking Exposed 7: Network Security Secrets & Solutions for more discussion of DDoS attacks.  See Wikipedia for more attacks: https://en.wikipedia.org/wiki/Denial-of-service_attack


Are there any tools to detect JavaScript-based WCF/AJAX calls?

Im using Firefox plugin called JavaScript Deobfuscator. This works very well as Im able to see all scripts that are compiled and all executed scripts. This updates on the fly, and contains good details on all the executed scripts.

You can also use filters to only capture javascript on a given domain. This plugin has helped me a lot in web pentesting.

You can find it here https://addons.mozilla.org/en-US/firefox/addon/10345/

Quote from the plugin page:

This add-on will show you what JavaScript gets to run on a web page, even if it
is obfuscated and generated on the fly. Simply open JavaScript Deobfuscator from the
Tools menu and watch the scripts being compiled/executed.


Is it acceptable for an employer to install a self-signed root certificate on employees personal devices at home?

This is not a strictly a legal or technical question, but rather an opinion question - "is it acceptable?"  Is it acceptable to you?

You bring up a perfectly reasonable technical point though - in that a root cert in your system store allows the controller of that cert to potentially impersonate and intercept any of your SSL/TLS traffic via MitM techniques.

From a practical standpoint, I'd say it should fall under your company's BYoD policies.  You could request a corp-owned laptop for home use, and only use it for VPN access.  Or, you could not install the VPN client on your hom machine over your concerns.  Your employer can't require you to use your own, personal machine, but their policies probably do cover things like if you are going to use a personal machine on work resources, you must do X, Y, or Z to secure them.  And installing a root cert for VPN access would probably fall under those conditions.

Ultimately, the decision is up to you.  If you feel the potential risk is greater than you are comfortable with, I'd either: request a corp machine for VPN use only at home, acquire an other home machine, isolate it from the rest of your network and install the VPN on that, or go without VPN access at home.  Or perhaps you could spin up a "work-only" VM on one of your home machines with free VirtualBox or VMWare player, and install the VPN in to that?

I agree the "no transparency" and "feels very shady" bits are worrisome, but in most cases, I'd attribute that to apathy rather than malicious intent.  Most folks wouldn't even know what a root cert is, or why installing them on your company's say-so might not be a great idea.  The company probably isn't hiding some nefarious scheme, but the IT folks just want to solve the problem of "get folks access from home" and here is how they did it.

Conclusion: are you being unreasonable? No. But you are making more work for yourself, and that's a reasonable thing if you have concerns.  I doubt you have any particular leg to stand on to push back, aside from simply not using/installing the VPN


Should I change format and/or add data to image files in a file upload?

By changing format, a malicious user cannot force a certain behaviour by the client. If there is a jpeg vulnerability in a well-known viewer, then by changing the image to png, the malicious actor cannot use that technique.

Re-rendering the image does the same thing. A malicious actor cannot embed malicious code to affect your users.

Changing format and re-rendering should not take much time, but you have to budget your server resources so that you do not run out of resources.


Assigning memory address of shellcode to buffer (for buffer overflow input)

The issue was because I was not spawning a cmd.exe process via _popen or system post shellcode execution.


OAuth2 Cross Site Request Forgery, and state parameter

Let's walk through how this attack works.

The Attack

I visit some client's website and start the process of authorizing that client to access some service provider using OAuth
The client asks the service provider for permission to request access on my behalf, which is granted
I am redirected to the service provider's website, where I would normally enter my username/password in order to authorize access
Instead, I trap/prevent this request and save its URL
I somehow get you to visit that URL instead. If you are logged-in to the service provider with your own account, then your credentials will be used to issue an authorization code
The authorization code is exchanged for an access token
Now my account on the client is authorized to access your account on the service provider

So, how do we prevent this using the state parameter?

Prevention

The client should create a value that is somehow based on the original user's account (a hash of the user's session key, for example). It doesn't matter what it is as long as it's unique and generated using some private information about the original user.
This value is passed to the service provider in the redirect from step three above
Now, I get you to visit the URL I saved (step five above)
The authorization code is issued and sent back to the client in your session along with the state parameter
The client generates a state value based on your session information and compares it to the state value that was sent back from the authorization request to the service provider. This value does not match the state parameter on the request, because that state value was generated based on my session information, so it is rejected.

Your Questions

Should the randomly generated state be hashed or can same value be stored and sent to OAuth2 provider?

The point is that the attacker should not be able to generate a state value that is specific to a given user. It should be unguessable.

Is there a difference here, if session back-end is secure-cookies or a server-side storage (in GAE Memcache or database)?

I don't think this matters (if I understand you correctly)

Should state be stored as a key as suggested?

I don't know what this means.

Should state has validity period, or session (if there is one) lifetime is enough?

Yes, state should have an expiration. It doesn't necessarily have to be tied to the session, but it could be.


Solution to calculate and store a hash salt in an open source application?

You seem to think that the salt and/or the salting and hashing algorithm need to be kept secret. They do not.  Salt only protects against very specific threat scenarios.

Remember that computing a hash on a value always return the same hash value (otherwise it would be useless.)  But that means an attacker can use that property to test the hash values in your database by hashing password guesses. If his guess hashes to the same value as a hash in the table, his guess was correct and he knows that password.  Salting helps prevent this from being a problem in two ways.

By adding a long, random salt to the password before hashing, it protects against someone pre-computing the hash values of password guesses. (This is called a 'rainbow table attack'; you can go online and buy a 1TB hard drive with billions of pre-computed hashes already in a lookup table.)
By using a unique salt for each password, you protect against someone spotting collisions in your database.  Without using a unique salt for each password, if my password was ABC and it hashed to 123, and if you also happened to use ABC as your password, it would also hash to 123. Anyone looking at the database would see that we both share a common password.

In no case do the salt and hashing algorithm have to be kept secret in order to preserve these protections, so you can open source all of this work.

For added security, some people add what is called a "pepper" into this algorithm; 'pepper' being a cute name for a common salt value that is applied to all passwords in a system and kept secret.

What's also important for protecting your passwords in a breach scenario is that the password hashing algorithm be computationally expensive.  This helps prevent brute force attacks, because the attacker generally cannot spend enough CPU time to test billions of guesses.  The way this is achieved is through repetition of a cryptographically secure hashing algorithm.  A modern computer with a GPU card can calculate 10s of billions of SHA-1 hashes per second.  If you used SHA-1 as the password hashing algorithm, that means an attacker could test 10 billion password guesses per second.  By using a password hashing function like PBKDF2, you repeat the hash thousands of times, ensuring the attacker could only test a few hundred guesses per second.


Yup, it's fine.  Underneath the covers it users the RNGCryptoServiceProvider to generate the password data, which is .NET's wrapper around the CryptoAPI's CSPRNG to generate the data for the password.   It's good enough for strongly random key material, so its certainly also good enough for a one-time use password as well.


Does my server need to fulfill PCI compliance if it only forwards the credit card number?

Yes, your server as described has to be PCI compliant.  However, most processors support modes of operation, different than you describe, which will limit your scope*.

You say:

  My client sends the credit card information to my server
  My server forwards this to braintree (or paypal) and I get back a credit card ID token

If the credit card data is transmitted, stored, or processed by your server, then you server is in scope, and you are subject to a reasonably large set of PCI compliance such as SAQ C or SAQ D.

However, most processors support iframe and/or javascript technologies that will allow your server to be removed from the loop - the client sends their card data directly to the processor, and the processor hands them some chit which they can hand to you in lieu of a credit card to carry on the purchase.  You, in turn, cash in that chit to get a token representing the card data that they handed the processor.

When such a technology is in use, and insulating your systems from any direct involvement with card data, then your compliance requirements drop down to SAQ A or SAQ A-EP.

You should ask your processor "What offerings do you have for tokenization that will allow me to keep my servers out of scope and reduce my PCI compliance requirements?"  (If they say "huh?", find a new processor.)

  [if so, is it] actually possible to have a payment system that does not
  require a user account at the custodian.

No.  If you are allowing a processor to handle cards for you, then you must give them a bank account for use in transferring funds to (e.g., purchases) and from (e.g., chargebacks) you.  And when they want the bank account, they're going to want all sorts of tiresome information like who you are.  The processor is, in fact, sponsoring you into the card network.  They are liable for your debts if you behave poorly.

(And that's true whether they're managing the actual card data for you (tokenizing) or just processing transactions... Credit card numbers are not useful without processing by the card network; you can't charge them without a connection to the system, and the system isn't designed for anonymous members.  If you want anonymity, charge in Bitcoins or Simoleons instead of credit cards).

*If your business is accepting credit card payments, you're bound by PCI, even if you don't touch the actual credit card data yourself.  The best you can do is reduce your scope - if you are subject to SAQ A, for example, you'll have ~15 requirements instead of ~300 for SAQ D.


Can valid PHP be written and executed in non-ascii character encodings?

No, PHP code is always at least some part readable ASCII.

Typical obfuscation methods are to decode a piece of code and run that:

eval(gz_decompress(base64_decode("0Z074L7expJKXs...")));

But you would still see a PHP function name after <?php.


How does android antivirus scan root files like "/data/data"

Android does not allow access to app private data files under /data/data/<package.name>-<hash>, but the list of files and directories in /data/data is public. Also, the APK files in /data/app directory are readable to everyone, don't require special permissions. The AV scans the contents of APK files (which are signed, but not encrypted ZIP files in disguise), and tries to find signs of malware inside these archives.


Should we use different usernames for each website, to achieve better anonymity?

I am not sure about Chrome, but I have a feeling it was able to remember my username for most sites.

As for anonymity, it really depends on what you mean. Anonymity in the strictest meaning is actually a misnomer. To achieve anonymity, you could not select any username at all. Anonymity means not even two of your posts on the same site can be linked together. So you would not register at all.

Pseudonymity is when you have an identity for certain purpose, that can't be linked to your real identity. There are many "levels" of pseudonymity, you can have one pseudonym for everything on the internet, just not under your real name. You can have different pseudonym for each site or even each user you communicate with. The last one meaning if you send me two messages, I can tell both are from the same person, but if you send a message to my friend, we can't know, whether both were from the same person or not.

Whether you choose to be anonymous or pseoudonymous and at what "level" or type of pseudonymity depends entirely on what you are trying to achieve. Do you care that people can link the identities together? Are you worried you may leak your real identity or clues and you don't want that to "spread"? Do you want people to be able to recognize your username? It is up to you and your preference.


Another interesting (older) encoding library is the OWASP Encoding Project (previously the "Reform" library) - http://www.owasp.org/index.php/Category:OWASP_Encoding_Project

This is functionally identical to Microsoft's AntiXSS 1.x (not unusual - Mike Eddington wrote a lot of the internal Microsoft library that later became AntiXSS, and then WPL), but supports most common web languages except Ruby/Rails.

It implements a pessimistic encoding approach (encodes everything except what is known to be safe), and gives you results like this:

eval(';  --> eval\x28\x27\x3b

eval\u0080 --> eval\u0080

\u003cscript\u003e. --> \x3cscript\x3e.


Is asking for password before asking for email/username more secure?

Answer

People are creatures of habit and have become accustom to the standard login page by now. (i.e., username then password). Changing this flow would undoubtedly create a UX nightmare and may ultimately cause the application it's protecting to receive unfair criticism based solely on the login page.

Alternatives

A better approach would be to not set automatic focus in the username field so that the user has to manually click into the username field, thus increasing his/her awareness of their actions.

Alternatively, if you wanted to do some lightweight testing of your theory, consider setting the focus.onLoad() (I'm pseudo-coding here) to the password field. As a third option, consider hiding the characters of the username as well.


Removal? Forget about it. There is unauthorised root access to your server; anything could have been installed by now and you would have no reliable way to detect it.

Even for a forensic expert with local access, it would take a long time to completely audit a system to ensure no trace of extant malware.

The only reasonable and responsible course is to wipe the disc and reinstall/reimage the OS from a trusted source.


Should I publish IP addresses that try to brute force my private web server?

Legally?  That depends on the laws of your jurisdiction, and is off-topic for this site.

Ethically?  Consider: most of these attacks aren't being performed by computers owned by the attacker.  They're being performed by home routers, security cameras, refrigerators, and the occasional compromised server.  Most of the IP addresses attacking you are owned by people who wouldn't know what an "IP address" was if it bit them, and would react with total confusion if you told them their FitBit or garage-door opener was attacking other peoples' computers.


This is definitely possible after a recent updates to both Mimikatz and Meterpreter. Please refer to the following links:

https://github.com/rapid7/metasploit-framework/pull/8549
https://twitter.com/gentilkiwi/status/872588656967548928

Good luck!


Should I implement incorrect password delay in a website or a webservice?

I assume that your intention with the failure delay is to prevent brute force attacks: if an attacker is trying to guess a user's password, she will first fail many times; if we can make those failures take a substantial amount of time longer, then it will make the attack an order of magnitude harder, and thus unlikely to succeed (in a reasonable time frame).

However.

This assumes that the attacker waits patiently between login attempts. And, as we all know, cyberhackers are a very polite and patient folk.
That said, some attackers may choose NOT to wait, and simply send many requests in parallel. If a login attempt doesn't receive a response immediately, the attacker can interpret that as a failed attempt, kill that request, and move on the next one.

An extra benefit of this scheme is that it would be that much easier for an attacker to create unreasonable load on the server (just send a lot of failing login requests, each one will occupy a thread for several seconds...), and possibly even succeed in DoSing the server.

In fact, the main problem with this solution is that it precisely does NOT prevent many parallel requests. If an attacker is attempting an online brute force attack, she is not going to sit in front of the keyboard typing in many passwords, one after the other, as fast as Hugh Jackman possibly can - if that was the case, you would only be at risk if the user has a dead simple password.
In reality, she will have a script or automated tool send (almost) as many requests as the server can handle, and then keep going. The risk is not that someone will try 30 different passwords a minute, it's 1000 passwords a minute, or 10,000.

The only way to prevent that is user throttling / account lockout / incremental suspension - call it what you will, this is all basically the same idea of allowing X number of login attempts per account within a given timeframe.
So even though this doesn't cut down to "a single login attempt at a time", it does get close enough.


Chrome sends requests to a handful of randomly-generated domain names to detect things like ISPs that return search pages rather than NXDOMAIN, hotspot paywalls (that do much the same) and similar behavior.  The theory is that the 3 random hostnames are unlikely to actually be valid hostnames, and if you get responses to them, something in the middle of your connection is behaving differently than expected.  There's a bug related to this behavior here: https://code.google.com/p/chromium/issues/detail?id=47262


I would say do both to be honest.

GSEC will give you the foundations that you need to know (similar to the information you would get from doing a CISSP) but it won't give you the knowledge you want to be a Security Analyst or Tester.

GCIH is all about incident handling and basic hacker techniques, and as your career progresses you'll learn that they are basic.

To be a good security analyst you need experience, but having those certs will get you on your way. I would also look at the OSCP offering by Offensive Security and the GPEN cert by SANS/GIAC.


securely and conveniently transfer a single file from a desktop to a mobile computer

There's various android apps that support SSH/SCP/SFTP. Since that is encrypted, you'd be on the safe side. Very likely, your favourite third-Party File Explorer does that already. You can, also, install an SSH server on the android phone and go the other way around. SSH will allow you to verify the fingerprint of the other side's cryptographical authenticity. So no man-in-the-middling. That was easy!

Of course, these connections depend on networking, but considering you can usually use Bluetooth to tether and thus, set up a network, that should universally work – both locally as well as over the internet.

  Radio (wireless) link. For example, Wi-Fi, Bluetooth. It is not shielded, so it is not "confidential" without typing a password.

I won't be going into security of wireless links here, but it's not universally true that those are unencrypted. Still, your desire for confidentiality is warranted, since an access point has to decrypt the over-the-air traffic.

No communication in this world is "shielded", by the way, aside from quantum cryptographically secured connections. The word your looking for is "easy to eavesdrop".

  Optical link. 2.1. Infrared communication is not shielded, so it is not "confidential" too.

... and you show me the pair of devices that still have infrared transceivers in 2016....

  2.2. A video camera of one computer pointed to the screen of the other one. I guess that it is more "confidential" than the previous scheme.

It's certainly not. Optics of cameras have a minimal focal length, and since the speed of this method would be pretty low, and you don't want to dedicate both your C_M and C_D for hours to copying files, you'll be creating larger loopholes for people that want to sniff.

  I don't like that the screen is visible to bystanders. QR Code is an implementation of this scheme for small files.

exactly.

  2.3. A light emitter of one computer inserted into a hole with a light sensor in the other computer, and the gap where the light may escape is covered by rubber.

That sounds like you'd actually want fiberoptic networking :)

  It can be manufactured, but I never heard of such technology in consumer electronics.

Depends on what you'd consider "consumer". SFP PCIe cards and SFP 1000Base-SX transceivers can be bought used for very little money nowadays, but it'll be hard to attach those to a smartphone.

If you want to use a screen or the flash LED of your smart phone: Screens have an update rate of let's say 60 Hz. Let's assume you can code 8 bit each time – then you get 60B/s. That'll be extremely slow.

  Cable. 3.1. Ethernet. It is present in almost every device nowadays which is "convenient". It requires configuring a network server of some sort (for example, FTP, HTTP), which is not "convenient".

Aside from your linux system making it extremely convenient to have such. As mentioned faaar above, SSH is available on any linux distro as standard package, and will let cryptographically and/or password-authenticated users access your computer or transfer files. totally convenient.

  3.1.1. LAN. As I said, it is very likely that C_D and C_M were never connected before, so a LAN would require a configuration. Low on "convenient".

Yawn. That'd be true in 1996... nowadays, we have Bonjour/avahi/Windows Networking... things work out of the box as soon as you're on the same network, and you only have to care about configuring either side to use something well-encrypted. For example, many chat clients can be used with end-to-end encryption, and there's Bonjour auto-detection built into clients like Pidgin.IM and so on.

  Note that this LAN must be isolated from other networks, otherwise the scheme is not "confidential".

encryption. It doesn't cost you anything. this is not the early 1980s.

  3.1.2. Internet. Is not "confidential" unless a network server is protected by a password. Take into account that at least one computer, probably both have no global IP addresses.

Whatever applies to network in general applies to internet, too.  You wouldn't want unencrypted file transfers even in a LAN.

  3.2. USB. 3.2.1. C_M serves as a MTP storage over USB. I discovered that even the internal flash memory of C_M is accessible. Contradicts "least privilege".

That's something that you should be able to modify if you roll your own Android. However, I don't know of a single case where access restriction has been implemented – there's simply little demand. Also, plugging your phone directly into a foreign PC is practically the most physical access one can get – the "holy grail" of security loss.

  3.2.2. I suppose that other protocols over USB exist, but I never heard of any one that fits.

Networking! Simply emulate a network interface. Android phones call that mode "USB tethering". Then run a chat client, an SSH client, an SSH server, an FTPS server, whatever you like.

all in all, it feels like you've never heard of encryption, which is the ubiquitous and simple solution to your problem.

Frankly, I'd just take my files, encrypt them, and send them via email (if small enough) or just use encrypted email (there's good email clients for both Linux and Android that support PGP).

If the files were to large to be sent via email, I'd really just push them encryptedly via any other method – probably simply via Bluetooth, or as a file dropped onto a network share. Don't act as if those are hard to set up – in fact, with most linux distros, it should be pretty easy to just share a folder.


Java Applet for mutual authentication with smart card

Yes.  This is feasible.  There is a standard way to achieve this: you use SSL with a client certificate.  This feature of SSL already does exactly what you want, and it has been well-vetted, so I recommend you use it.

In this scheme, the client certificate and associated client private key is stored on the smartcard.  The private key never leaves the smartcard.  To prove the client's identity, the server sends a challenge and the smartcard signs it (and other stuff) with the client private key -- this is all built into SSL, so you don't need to implmeent it yourself, I'm just giving you some intuition for how the protocol works.

No Java applet is needed.  All you need is for your browser to support PKCS#11.  For instance, Firefox supports this.

If for some reason you do want to use a Java applet, you again want to check out PKCS#11, the Java Crypto APIs, and the Sun PKCS#11 cryptographic provider.  See also this question.


What is investigated after a possible hack on servers?

This is largely dependent on the organisation's policies, but what you're talking about is Incident Response (IR), which falls under the umbrella term of Computer Security Incident Management.

The response that is taken usually depends on the type of attack, the known threat actors (if any), and the individual systems or network regions that are known to be compromised. These are important distinctions - you wouldn't take the same actions with a compromised receptionist's workstation as you would a compromised life support system or industrial control system.

The main steps in IR are:

Alert - Someone notifies the team that a potential breach has occurred.
Classification - A first level responder performs a preliminary analysis to identify the level of threat, and takes the prescribed IR steps for the class of threat (e.g. normal, critical, etc.)
Action - Isolation and cleanup of the affected systems, with steps taken to ensure any backdoors are closed and the original hole is patched.
Investigation - Identification of how the threat appeared, attribution of the attackers, etc.

You can then split these down and rearrange them as they pertain to a particular situation. In some cases, the organisation may be solely interested in recovering and continuing, so the investigation phase is minimal or even skipped. In other cases, legal process may be considered, so special care is taken to provide a strong chain of evidence using tools known to be approved by the local courts. Sometimes the action step doesn't involve cleaning the machine at all, in an attempt to log and monitor the behaviour of the attackers in realtime to gain stronger attribution.

In short: the answer is that it depends on the organisation and the situation. IR is rarely black-and-white.


Use a database for sessions.
Regenerate the session on when the
permissions change (e.g., when a user
logs in).
Regenerate the session on every page
load (optional).
Don't expose the session ID in the
URL.
Don't expose any sensitive data to the session.


Somebody bumped into me, next day my storage unit was burglarized

It sounds unlikely.  As @schroeder says - a mag stripe must be physically run through a reader.  So if you must "swipe" the card to get access, you must swipe the card to copy it.  While a pickpocket can take a card out of your pocket, if the card is still in your possession, it's unlikely that this interaction was part of the theft.

Keep in mind, however, that a single instant in time is not the only case of potential intrusion:

any time the card was left unattended for any time is an opportunity
any access to a master card is an opportunity - generally a storage unit will have a master key card - they are loaning you this space, if you default on your rent, or the police have a warrant, they will need to access your space.

Whichever card is used as a source, making a copy should leave no evidence on the card.

It maybe possible, from digital logs, to see what card was used for access at the time of the break-in.  Was it your card?

Chances are, you and the storage space management need to think through who had access to the cards that control your space.

Addition:

Backing up a step to a bigger picture.  In any theft, there's a question of due diligence.  Any type of security is tricky, and needs a diligent design and careful implementation.  This particular issue involves:

electronics - the mag strip key card
physical - the access to your door, and the facility at large, as well as video survellience,
personnel - anyone who was supposed to be watching the video, the people with access to the master card, and overall personnel management

The easiest hack is generally social engineering and working in the nexus of areas of security, where there are often human communication gaps.

The general solution is to work with the site as best you can to determine who might have had access.  Accusing them of a lack of due diligence probably isn't going to get the job of finding your stuff done... but sooner or later, you or the PI may need to go there to figure out if you have a insider threat or a fairly clever outside attacker.

As the comment thread shows, there's numerous options out there that are bigger than the incident you mention that are just as (if not more) likely as someone managing to pick your pocket.


Doesn't the Heart Bleed vulnerability imply that we need to change passwords for *all* systems?

The only major browser I know of that uses OpenSSL is Opera, and the versions I've checked appear to use an older version that isn't vulnerable to the Heartbleed attack.  Firefox, Chrome, and related browsers use NSS for SSL.  IE and derivatives (including most embedded HTML renderers on Windows) use Microsoft's SSPI.  Safari on MacOSX and iOS uses Apple's SSL implementation.  Dillo and Lynx are the closest thing I know of to major browsers that use OpenSSL, and those have a marketshare best measured in parts per million.

Vulnerable clients tend to be special-purpose tools such as "wget" and "curl" (command-line tools for making HTTP requests), or non-browser programs such as email clients.


Password storing in Google Chrome content scripts

Anyone with read access to your computer can get access to the password. Even if the database (localStorage/whatever) is encrypted. All an attacker has to do is copy over the user data directory (~/.config/google-chrome on Linux; somewhere in AppData on Windows), start Chrome on their own pc with the --user-data-dir flag set to the copied directory, and use the app -- the stored credentials will be used to login to whatever site you're using (and they can be easily sniffed via the developer tools).

Instead, I suggest you see if the service has an authorization API. For example, you can have your extension request partial permissions to the Google account. Of course, if the data directory is stolen, then the attacker has access to these permissions. Many sites (like Twitter) support OAuth, that's another thing you can try. Most OAuth-enabled sites only give limited permissions via OAuth.

Otherwise, store the password on your server, and have the server do everything -- just use your extension for communicating with the server and displaying the result. This way, an attacker can only work within the bounds of what your extension can do.

In the end, whatever method you use to secure it, an attacker stealing the data directory will be able to do some damage. All you can do is help restrict the possibilities -- with the direct password, and attacker can do all sorts of stuff like change the password. With a restricted permissions API key, the attacker can only work within the bounds of those perms. If you do everything on the server, then the attacker cannot do much outside the capabilities of your extension, since the server only knows how to make certain types of requests to the page.


After the introduction of transport resiliency in the meterpreter stagers, it will attempt to connect to the handler every 10 seconds (by default) in order to establish a connection with the handler. You can control this through the SessionRetryTimeout setting at the time of generating the stager. This behavior will be repeated till the current time is less than the SessionRetryTotal setting. By default it is 1 hour.

So in short, if listener is not available when the stager is executed at the targets, in the default state it will attempt to connect to the handler every 10 seconds for a period of 1 hour.

Further details are available in the Meterpreter Timeout Control wiki.


How is WhatsApp sending end-to-end encrypted messages in push notifications?

WhatsApp could be using VOIP background mode along with PushKit for solving this problem.

Voip pushes are:

delivered directly to the app.
considered high-priority notifications and are delivered without delay.
delivered even if the app was force-quit by the user.

For details refer to Voice Over IP (VoIP) Best Practices

Once the encrypted payload of VOIP push is decrypted they show a “Local Notification” with the decrypted message.

There is one small issue though, PushKit is available only on iOS 8 and later. So, how is Whatsapp doing it for earlier versions of iOS?
Well, it isn’t. They don’t allow you to see message preview in notifications on versions earlier that iOS 8 (Verified it on iOS 7, see screenshot)


AWS KMS Getting Data Key using AWS Encyption SDK

The entire point of KMS is to securely store encryption keys.  As a result, you aren't finding any options to extract the key because such an option does not exist by design.  This question is like saying, "I need a bank with a secure vault that I can store my driver's license in so it never gets stolen, but I also want to keep it in my wallet for when I go to the store".  These needs are, quite simply, completely contradictory.
If for some reason you did want to do that, then you can use a KMS with a customer managed key.  This will allow you to generate your own key, hand it to AWS, and they will place it in the KMS for you.  At that point in time you can have a copy of the key yourself and AWS will also have a copy of they key that you can use via KMS.
A more common use case would be to use KMS to encrypt the actual encryption key for your data.  This way the key can be stored in encrypted form.  When your application starts it takes the encrypted key, calls KMS to decrypt it, stores the decrypted key in memory, and then can operate normally.


Reasonably accurate. You might also let the Linux server read the files off the PCs, which have no write access to the Linux server (nor even know it's there. They're simply accessed routinely by someone reading all their data).

What you really want, though (because I saw this happen) is an emergency interlock that calculates the size of the new backup, and stops everything if it looks too large. For example if it contains ten times the average daily number of changed documents. Or better still, in that case it freezes the previous backup and starts a new chain, and emails an alert to you. Several other telltales are there: you might for example prepare empty documents ("honey docs") that no one should read. If they abruptly turn out to have changed or disappeared...


You could drop packets from tor nodes all together if you like with ip tables.
List of tor nodes can be found at:

Ref 1: https://check.torproject.org/cgi-bin/TorBulkExitList.py
Ref 2: https://www.dan.me.uk/tornodes

Here is a bash one liner to block all traffic from tor to your web server. There are currently about 2000 tor nodes online now that support port 80. So you will be inserting quite a few iptable's wouldnt really call this a long term fix but should stop the attack.

wget "https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=8.8.8.8&port=" -O /tmp/ip.lst && sed -i -e '1,3d' /tmp/ip.lst && for i in $(cat /tmp/ip.lst); do iptables -A INPUT -p tcp -s $i --match multiport --dports 80,443 -j DROP; done


Redirect OWASP ZAP IP:Port to localhost like in Burp

in the menu bar go to Tools -> Options -> local Proxies

This blog post contains some infomration on how to intercept traffic with OWASP ZAP


None, generally, unless the target site changes in a way that the attacker can detect. CSRF is generally a blind attack; the attacker gets no more feedback that a victim clicked the link or loaded the page than they would about anybody on the internet clicking a link or loading a page on some site that both had visited.
There are some possible exceptions, though:

If the origin of the attack is controlled by the attacker (say, their own personal site), they can put script in that notifies the attacker before attempting the attack. It's not possible to tell whether the attack succeeded - same-origin policy prevents that - but it's possible to tell when it started if you can control scripting around it.
If the attacker is in a position to monitor the victim's network traffic, then it will be possible to determine the extent of the victim's interaction with the target site. Intercepting the actual HTTP is probably impossible, since it will be protected by TLS, but TLS doesn't hide how much traffic is sent each way, or the timing of the request and response. That might be enough to infer whether the attack succeeded.
If the target site changed in some detectable way, this may be visible to the attacker. Some simple toy examples: if you use CSRF to force somebody to tweet a message, you could see the message they posted. If you use CSRF to force somebody to transfer money to your account, you'll be able to see the incoming transfer.


You're correct to say that there is unlikely to be a large increase in risk, so long as you keep control of the CA key that is.

Basically if someone got control of the CA key used by burp, they would be able to carry out a MITM attack on your phone as it would see certificates issued by that CA as valid.

However, as you say, the key is unique to each installation of burp, so as long as you don't lose the key in question, then an attacker won't be able to misuse it.


Is Twitter digits login (sms auth code) insecure?

Digits leverages a single 'factor' typically used in multi-factor authentication: "something you have", which in this case is your phone. Yes, there are weaknesses in the security of a single factor, just like only using a password, but there are strengths over and above a simple password, too.

disturbance - yes, an attacker could spam the phone network, but that in and of itself does not reduce the security of the process. It might create a DoS scenario depending on how Digits is design in the backend.
data harvesting -> malware - I tried the demo with a phone that is not registered with Twitter and it worked. I don't see this as a valid way to discover registered Twitter users for targeted phishing, no more than blanket spam does.
data harvesting -> phishing - As a phishing researcher, I could imagine this could be true. But I'm not sure if a user would realistically be more susceptible to phishing in this way than any other type of phishing for passwords. I don't think I understand your threat scenario here.
the sms is insecure - yes, SMS is not a secure channel, just like email, but you get a code when you have triggered the code to be sent. I'm not sure that one would receive a gratuitous code and start hunting around for an app they didn't log into for the purposes of entering it. As for MITM, the same protections of the website apply for certs, DNS, etc. and the threats would be common for password-based logins.

Given your risk model, I'm not sure that Digits is less secure than a password at all. It is a challenge-response mechanism using a phone as a factor. Protections of the login page and the personal protections of the phone (locks, encryption, remote management) can all be employed by the user to possibly make this more secure than a typical password mechanism. Yes, it is still a single factor, and yes there are ways for a user to make this insecure, but the mechanism itself is not inherently insecure.


Why limit passwords to ascii printable characters?

From a security point of view, it is desirable to have a huge character set to choose characters from, just as you said. The reason why some sites encourage users to stick to ASCII is for technical and organisational reasons:

If the software was written without Unicode in mind or using an environment which does not make unicode totally transparent (such as PHP, old MySQL versions, etc.), it requires a significant amount of work to add Unicode support.

Furthermore if the software is not targeted for the Asian market, the developing company might just not care. It may have no experience and knowledge to test those charsets. Think of resolving combined characters, characters that look exactly the same but have different codes, etc.

This might result in support requests that needs to be handled and therefore result in costs.

tl;dr: If your software can handle Unicode correctly and you can deal with support requests, go for the full range.


No.

There is no guarantee the other machine has a MAC address at all.

Following the IP over everything principle, the connecting partd may be sitting in a tree using IP over avian carriers - and pidgins do not have MAC addresses.
You may only get a MAC address of an IP in your local network at the time the connection in done, as the mapping can change over time by assigning a new IP to that interface and is only available to your local network. If you want to do this, it's

arp -an

Please keep in mind that:
If the IP address is spoofed, a TCP handshake will fail. No no actual connection can be made.


Risk to self-signed SSL certificate on OpenVPN server

If you are using OpenVPN for your organization it is probably better not to use any public certificates for OpenVPN but create your own CA and only accept certificates issued by this CA. This is actually the way proposed in the OpenVPN Howto. This way you are in full control of the certificates and even if some of the public CA's gets compromised and issues certificates in your name then none of your OpenVPN endpoints will accept these, because only certificates issued by your own CA gets accepted.

Apart from that: Using a self-signed certificate does not impose a risk by itself, not for VPN and not for HTTPS. The risk is only if the certificate is not fully validated. A self-signed certificate can not be validated without additional information like the fingerprint received over a secure channel (like phone or printed) and that's why it is common to just skip the validation completely because it looks too hard. Thus not the use of self-signed is the risk but not properly verifying it is.


Is using only secp384r1 and up named groups considered okay?

It seems to me that according to ssllabs.com, supporting only TLS 1.2 (or TLS 1.2 and TLS 1.3), only ECDHE with secp384r1 (no DHE, no RSA key exchange without PFS), should get you support by all the TLS clients you would care about. If in doubt, try ssltest with your server configured the way you want. You can/should try a dev server before changing config on prod.
secp384r1 is not a very good curve - it is too slow for its security level - but it should be fine. It is less used than secp256r1 so maybe the implementations are less reviewed or less optimized, but you probably don't care.


The cipher-name in your example is not '@'. The field you're looking at is actually the hdr_size field.

The mistake you've made is trying to decode a LUKS2 container with LUKS1 encoding. In the table provided, you've shown that the second field (bytes 6-8) are the version data field. And your hexdump clearly shows that the first LUKS container (luksVol1) has version = 00 01 while the second LUKS container (luksVol2) has version = 00 02. These hex values directly correlate the former to LUKS1 and the latter LUKS2.

Quoting from OP that demonstrates this:

root@disp8551:~# hexdump -Cs 6 -n 2 luksVol1
00000006  00 01                                             |..|
00000008
...
root@disp85:~# hexdump -Cs 6 -n 2 luksVol2
00000006  00 02                                             |..|
00000008

Your encoding table in the OP was correct only for LUKS1 as defined in the LUKS On-Disk Format Specification published by Clemens Fruhwirth in 2005.

LUKS2 uses a different encoding that's defined in the LUKS2 On-Disk Format Specification published by Milan Brož in 2018. Here's the updated encoding table for LUKS2. Note that binary headers in LUKS2 must be exactly 4096 bytes long.

+-------+--------+--------------+
| Start | Length |  Field Name  |
+-------+--------+--------------+
|     0 |      6 | magic        |
|     6 |      2 | version      |
|     8 |      8 | hdr_size     |
|    16 |      8 | seqid        |
|    24 |     48 | label        |
|    72 |     32 | csum_alg     |
|   104 |     64 | salt         |
|   168 |     40 | uuid         |
|   208 |     48 | subsystem    |
|   256 |      8 | hdr_offset   |
|   264 |    184 | _padding     |
|   448 |     64 | csum         |
|   512 |   3584 | _padding4096 |
+-------+--------+--------------+

And here's the relevant hexdumps for the data fields shown above on an example LUKS2 container's primary header.

# magic
root@disp4117:~# hexdump -Cs 0 -n 6 luksVol2
00000000  4c 55 4b 53 ba be                                 |LUKS..|
00000006

# version
root@disp4117:~# hexdump -Cs 6 -n 2 luksVol2
00000006  00 02                                             |..|
00000008

# hdr_size
root@disp4117:~# hexdump -Cs 8 -n 8 luksVol2
00000008  00 00 00 00 00 00 40 00                           |......@.|
00000010

# seqid
root@disp4117:~# hexdump -Cs 16 -n 8 luksVol2
00000010  00 00 00 00 00 00 00 03                           |........|
00000018

# label
root@disp4117:~# hexdump -Cs 24 -n 48 luksVol2
00000018  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000048

# csum_alg
root@disp4117:~# hexdump -Cs 72 -n 31 luksVol2
00000048  73 68 61 32 35 36 00 00  00 00 00 00 00 00 00 00  |sha256..........|
00000058  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00     |...............|
00000067

# salt
root@disp4117:~# hexdump -Cs 104 -n 64 luksVol2
00000068  4f b1 7c b2 bf 7d da 1f  15 64 df cc ab 74 68 5c  |O.|..}...d...th\|
00000078  9a f9 3d 02 42 67 0f 92  ee 1d bf 98 11 5b 3d b8  |..=.Bg.......[=.|
00000088  87 e4 e0 a8 76 23 68 86  2f fc e1 98 a7 a1 5a a9  |....v#h./.....Z.|
00000098  b6 c5 e5 e2 9a 87 f7 ff  55 52 dc 07 07 dd fa a4  |........UR......|
000000a8

# uuid
root@disp4117:~# hexdump -Cs 168 -n 40 luksVol2
000000a8  65 63 30 32 36 64 64 66  2d 37 37 36 32 2d 34 34  |ec026ddf-7762-44|
000000b8  64 63 2d 39 65 37 30 2d  62 35 36 66 36 61 65 62  |dc-9e70-b56f6aeb|
000000c8  63 31 32 38 00 00 00 00                           |c128....|
000000d0

# subsystem
root@disp4117:~# hexdump -Cs 208 -n 48 luksVol2
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100

# hdr_offset
root@disp4117:~# hexdump -Cs 256 -n 8 luksVol2
00000100  00 00 00 00 00 00 00 00                           |........|
00000108

# _padding
root@disp4117:~# hexdump -Cs 264 -n 184 luksVol2
00000108  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

# csum
000001c0
root@disp4117:~# hexdump -Cs 448 -n 64 luksVol2
000001c0  d0 9a e0 f8 96 ed 8f db  42 5f 58 19 99 2a 72 18  |........B_X..*r.|
000001d0  01 5e f7 81 34 99 f7 c5  17 a2 07 2f 60 be 40 bd  |.^..4....../`.@.|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

# _padding4096
root@disp4117:~# hexdump -Cs 512 -n 3584 luksVol2
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000
root@disp4117:~#

Note that none of the above fields actually contain the cipher-name. In LUKS2, that's stored in the JSON object. In LUKS2, there's actually six header areas:

  \/ primary binary header          alignment padding \/
+----+----------+----+----------+-------------------+----+
| /\ | 1st JSON | \/ | 2nd JSON |   Keyslots area   | /\ |
+----+----------+----+----------+-------------------+----+
                  /\ secondary binary header

The hexdump shown above only shows the "primary binary header" area. To get the cipher-name, we must look at the JSON area.

In LUKS2, there's actually two copies of the data stored in the "primary binary header" and the "1st JSON" area (the second copy is called the "secondary binary header" and "2nd JSON" area, respectfully). In most cases the data in the "primary binary header" exactly matches the "secondary binary header" and the data in the "1st JSON" area exactly matches the "2nd JSON" area. The data is stored twice to aid in recovery and protect against corruption.

While the "1st JSON" area always starts at byte 4096 (immediately after the "primary binary header" area), its length is variable. The length can be determined by looking at the binary header's hdr_size (ie the same field that you confused for the cipher-name). From the above hex dump, we clearly see the hdr_size field has a value of 0x4000 (hex) = 16384 (decimal). But the hdr_size field defines the size of the the "primary binary header" plus the "1st JSON" area. So the length of the "1st JSON" area is the hdr_size value minus the "primary binary header" length. In this case, that's 16384 - 4096 = 122881. Depending on the length of the LUKS2 container's metadata stored in the JSON object, the JSON area could be up to 4194304 - 4096 = 4190208 bytes long.

So here's a hexdump of the "1st JSON" area, starting at byte offset 4096 with length 122881:

root@disp4117:~# hexdump -Cs 4096 -n 12288 luksVol2
00001000  7b 22 6b 65 79 73 6c 6f  74 73 22 3a 7b 22 30 22  |{"keyslots":{"0"|
00001010  3a 7b 22 74 79 70 65 22  3a 22 6c 75 6b 73 32 22  |:{"type":"luks2"|
00001020  2c 22 6b 65 79 5f 73 69  7a 65 22 3a 36 34 2c 22  |,"key_size":64,"|
00001030  61 66 22 3a 7b 22 74 79  70 65 22 3a 22 6c 75 6b  |af":{"type":"luk|
00001040  73 31 22 2c 22 73 74 72  69 70 65 73 22 3a 34 30  |s1","stripes":40|
00001050  30 30 2c 22 68 61 73 68  22 3a 22 73 68 61 32 35  |00,"hash":"sha25|
00001060  36 22 7d 2c 22 61 72 65  61 22 3a 7b 22 74 79 70  |6"},"area":{"typ|
00001070  65 22 3a 22 72 61 77 22  2c 22 6f 66 66 73 65 74  |e":"raw","offset|
00001080  22 3a 22 33 32 37 36 38  22 2c 22 73 69 7a 65 22  |":"32768","size"|
00001090  3a 22 32 35 38 30 34 38  22 2c 22 65 6e 63 72 79  |:"258048","encry|
000010a0  70 74 69 6f 6e 22 3a 22  61 65 73 2d 78 74 73 2d  |ption":"aes-xts-|
000010b0  70 6c 61 69 6e 36 34 22  2c 22 6b 65 79 5f 73 69  |plain64","key_si|
000010c0  7a 65 22 3a 36 34 7d 2c  22 6b 64 66 22 3a 7b 22  |ze":64},"kdf":{"|
000010d0  74 79 70 65 22 3a 22 61  72 67 6f 6e 32 69 22 2c  |type":"argon2i",|
000010e0  22 74 69 6d 65 22 3a 34  2c 22 6d 65 6d 6f 72 79  |"time":4,"memory|
000010f0  22 3a 32 37 34 35 33 30  2c 22 63 70 75 73 22 3a  |":274530,"cpus":|
00001100  32 2c 22 73 61 6c 74 22  3a 22 71 4a 6e 79 2b 4a  |2,"salt":"qJny+J|
00001110  5c 2f 6f 35 71 77 57 77  35 78 2b 57 31 30 7a 47  |\/o5qwWw5x+W10zG|
00001120  59 54 6f 64 44 64 57 6f  39 6e 74 5c 2f 6c 67 49  |YTodDdWo9nt\/lgI|
00001130  41 61 61 6f 78 5c 2f 45  3d 22 7d 7d 7d 2c 22 74  |Aaaox\/E="}}},"t|
00001140  6f 6b 65 6e 73 22 3a 7b  7d 2c 22 73 65 67 6d 65  |okens":{},"segme|
00001150  6e 74 73 22 3a 7b 22 30  22 3a 7b 22 74 79 70 65  |nts":{"0":{"type|
00001160  22 3a 22 63 72 79 70 74  22 2c 22 6f 66 66 73 65  |":"crypt","offse|
00001170  74 22 3a 22 31 36 37 37  37 32 31 36 22 2c 22 69  |t":"16777216","i|
00001180  76 5f 74 77 65 61 6b 22  3a 22 30 22 2c 22 73 69  |v_tweak":"0","si|
00001190  7a 65 22 3a 22 64 79 6e  61 6d 69 63 22 2c 22 65  |ze":"dynamic","e|
000011a0  6e 63 72 79 70 74 69 6f  6e 22 3a 22 61 65 73 2d  |ncryption":"aes-|
000011b0  78 74 73 2d 70 6c 61 69  6e 36 34 22 2c 22 73 65  |xts-plain64","se|
000011c0  63 74 6f 72 5f 73 69 7a  65 22 3a 35 31 32 7d 7d  |ctor_size":512}}|
000011d0  2c 22 64 69 67 65 73 74  73 22 3a 7b 22 30 22 3a  |,"digests":{"0":|
000011e0  7b 22 74 79 70 65 22 3a  22 70 62 6b 64 66 32 22  |{"type":"pbkdf2"|
000011f0  2c 22 6b 65 79 73 6c 6f  74 73 22 3a 5b 22 30 22  |,"keyslots":["0"|
00001200  5d 2c 22 73 65 67 6d 65  6e 74 73 22 3a 5b 22 30  |],"segments":["0|
00001210  22 5d 2c 22 68 61 73 68  22 3a 22 73 68 61 32 35  |"],"hash":"sha25|
00001220  36 22 2c 22 69 74 65 72  61 74 69 6f 6e 73 22 3a  |6","iterations":|
00001230  36 31 39 34 33 2c 22 73  61 6c 74 22 3a 22 46 69  |61943,"salt":"Fi|
00001240  4c 67 31 35 56 5c 2f 55  56 4b 47 72 72 4e 39 4f  |Lg15V\/UVKGrrN9O|
00001250  52 2b 5c 2f 69 59 46 51  70 38 38 59 44 77 50 4c  |R+\/iYFQp88YDwPL|
00001260  6a 4f 6f 4c 70 6a 77 6d  78 58 77 3d 22 2c 22 64  |jOoLpjwmxXw=","d|
00001270  69 67 65 73 74 22 3a 22  49 70 34 31 5a 58 70 44  |igest":"Ip41ZXpD|
00001280  76 77 52 76 6d 41 73 33  30 58 69 72 6c 48 65 6d  |vwRvmAs30XirlHem|
00001290  57 72 44 67 6c 5c 2f 44  4a 31 36 79 33 31 41 71  |WrDgl\/DJ16y31Aq|
000012a0  66 42 55 6f 3d 22 7d 7d  2c 22 63 6f 6e 66 69 67  |fBUo="}},"config|
000012b0  22 3a 7b 22 6a 73 6f 6e  5f 73 69 7a 65 22 3a 22  |":{"json_size":"|
000012c0  31 32 32 38 38 22 2c 22  6b 65 79 73 6c 6f 74 73  |12288","keyslots|
000012d0  5f 73 69 7a 65 22 3a 22  31 36 37 34 34 34 34 38  |_size":"16744448|
000012e0  22 7d 7d 00 00 00 00 00  00 00 00 00 00 00 00 00  |"}}.............|
000012f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000
root@disp4117:~#

To get the cipher-name specific for encrypting the data in the LUKS container (as opposed to the cipher used to symmetrically encrypt the a given keyslot), we need to check the segments object in the above JSON. Here's the same segments section from above, but formatted for readability:

  "segments": {
    "0": {
      "type": "crypt",
      "offset": "16777216",
      "iv_tweak": "0",
      "size": "dynamic",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  },

LUKS supports many distinct segments, but this LUKS container only has one. The attribute we want is encryption, which has a value in the dm-crypt notation. In this case, it's aes-xts-plain64 -- which means the cipher-name is aes and the cipher-mode is xts-plain64.

This also matches the cipher listed in a cryptsetup luksDump on the LUKS2 container

root@disp4117:~# cryptsetup luksDump luksVol2 | grep -i cipher | head -n1
    cipher: aes-xts-plain64
root@disp4117:~#


Is this authentication scheme using JWT secure?

In general looks good. However, few issues to think of

The userID isn't encrypted. If the request is not going over TLS, it's leaking that info to MITM. You might want to encrypt it.
Once user logs out, what prevents the JWT from still getting used, assuming it's not expired?


How easy is JavaScript code tempering for a mobile application?

Assuming you are talking about a web-app running in browser because of the tags:

That depends, tampering with JavaScript is trivial, if no precautions are made and that is also true for Desktop/Laptop devices.

The simplest and most important precaution is to use HTTPS, therefore preventing the code from being changed using MITM attack.

Another more advanced ones include SRI, which require hashes of the script to be included in the header or at least a nonce being used. This improves security a lot, as an attacker would have to have significant control of the server to subvert it.

However, if an attacker has full control of the web server, there is currently no way to mitigate such an attack other than checking the script manually every time.


The http-post-form module requires three colon-separated arguments, like so:

/login.php:username=^USER^&password=^PASS^:login failed

The "variables argument" where you supply the POST data with username and password placeholders (which I made bold) is the second argument. But you gave the POST data as the first argument which makes hydra think this is actually the path.

So, with your command hydra thinks...

/user=^USER^&password=^PASS^=Ingresar&culture=es-CL&mobile=0&clasica=1

...is the path and...

F=Usuario inexistente

are the POST parameters - which don't contain ^USER^ or ^PASS^ and are therefore invalid.


Arp replay for cracking WEP key IN Aircrack-ng

WEP CRACKING

Weak IVs : Weak Ivs are ivs which reveal information about the wep key itself

RC4 in its implementation in WEP has been found to have weak keys. Having a weak key means that there is more correlation between the key and the output than there should be for good security. Determining which packets were encrypted with weak keys is easy because the first three bytes of the key are taken from the IV that is sent unencrypted in each packet. This weakness can be exploited by a passive attack. All the attacker needs to do is be within a hundred feet or so of the AP.

Out of the 16 million IV values available, about 9000 are interesting to the most popular attack tool, meaning they indicate the presence of weak keys. The attacker captures “interesting packets”, filtering for IVs that suggest weak keys. After that attacker gathers enough interesting packets, he analyzes them and only has to try a small number of keys to gain access to the network. Because all of the original IP packets start with a known value, it’s easy to know when you have the right key. To determine a 104 bit WEP key, you have to capture between 2000 and 4000 interesting packets. On a fairly busy network that generates one million packets per day, a few hundred interesting packets might be captured. That would mean that a week or two of capturing would be required to determine the key

Now lets come to your question

why do we need to wait to capture an arp packet from a client to the AP? Can't we just send a 'fake' arp request to the AP with the client's MAC address instead of ours ?

Yes you are absolutly correct you can do this , this is what aireply-ng
do to crack WEP when there is no client associated with the AP

steps are

1- Set the wireless card MAC address
2 - Start the wireless interface in monitor mode on the specific AP channel
3 - Use aireplay-ng to do a fake authentication with the access point
4 - Use aireplay-ng chopchop or fragmentation attack to obtain PRGA
5 - Use packetforge-ng to create an arp packet using the PRGA obtain in the previous step
6 - Start airodump-ng on AP channel with filter for bssid to collect the new unique IVs
7 - Inject the arp packet created in step 5
8 - Run aircrack-ng to crack key using the IVs collected