Need help on clarifying some pentesting concepts

What is a vulnerability?

A vulnerability is more than that. It is any state of the software that allows an attacker to do or know something they are not supposed to be able to do or know.

For example, if your website only uses HTTP, that is a vulnerability, because anyone with Man-in-the-Middle capabilities can read and modify the data on your site.

What is an exploit?

An exploit is a way to abuse a vulnerability. It can be code that sends data to your server, or it can be a specially crafted HTTP request, or a maliciously crafted e-Mail.

The term "exploit" generally refers to "the thing that abuses a vulnerability".

What is a payload?

A payload something that can be executed when using an exploit. For example, imagine a vulnerability allows me to execute any code when you open an e-Mail attachment. That piece of code that I execute then is the payload.

For demonstration purposes, some payloads just start calc.exe on Windows. This demonstrates that "any" code can be run. Of course, malicious payloads do much worse, such as adding backdoors, stealing or encrypting your data, etc...

Simply put, the payload is "the thing you want to get from A to B".

How do Vulnerabilities, Exploits and Payloads relate to each other?

Think of a vulnerability as a weak spot in a wall. The Exploit is a rocket going right through that weakspot. The payload is the explosive core of that rocket, designed to explode after the wall was penetrated and destroying everything behind the wall.

How can payloads be delivered?

Your question adds a very specific set of constraints. Specifically, software that has "no vulnerabilities". It is very very difficult, borderline impossible even, to make useful software that has no vulnerabilities. Even the seL4 Microkernel, which was formally verified, has some notable exceptions on their claim of provable security.

Simply put, no software is free from vulns. This is the reason any program bugs you at least once per month to do an update for "various security improvements".

However, assuming that your publicly exposed software was indeed 100% vulnerability free, you still can't know about anything it communicates with. The load balancer may have vulnerabilities, the sysadmin may have been victim of a phishing campaign, the USB keyboard may have been compromised, etc.

Social Engineering are one way of getting a payload on a target system, but with a bit of creativity, there are many more.

Will a Meterpreter executable have the same effect if run by hand as if done through an exploit`

Possibly. It depends on the exploit at hand. For example, if you used ETERNALBLUE, your payload would run as NT-SYSTEM/SYSTEM, which are the highest privileges available on a Windows system. Whereas if you ran the exploit as a limited user, it would run with your privileges, and thus your limitations.


Burp Suite Proxy Doesn't Forward Any Packets

Set Burp proxy (you can leave the loopback alone for other tasks) all interfaces to a port like 8082. Set your iOS device internet options to proxy to your Burp proxy IP/port. Don't forget to install Burp's certificate on your iDevice for SSL. It'd be the same for Android or any other device.


Don't use encryption without message authentication

A MAC uses a key, which the attacker is assumed not to know. The attacker cannot "generate a new MAC".

There are some protocols which use as sort-of-a-MAC a hash value (thus without any key) appended to the plaintext, and then encrypted with the plaintext. Here, the MAC is not the hash value, but the combination of the hash and the encryption (in other words, the encryption key is reused for the MAC). This is a poor way to do a MAC, a very poor one if the encryption uses RC4 or a block cipher in CTR mode (exact reason is left as an exercise)(though very weak, I have seen it deployed in production, for nothing less than an online banking solution !).

A lot of confusion has been produced by this kind of homemade pseudo-MAC schemes. A good MAC algorithm is HMAC.

Even with a good MAC algorithm, the combination of symmetric encryption and a MAC is subject to subtleties, which is what the passage you quote is about. There is some discussion in this question.


What could be the possible exploit for android adware vulnerability?

If Android's safety features are intact (and nothing in the article suggests that they would be compromised), the adware can do only two things:

use the permissions the "mother app" was equipped with
trick the user into installing other apps, in order to deliver new payload and/or gain new permissions

Then the malicious software in the "mother app" or the newly installed app can abuse permissions it has. These abusable permissions include:

Dialing phone numbers and sending SMS directly. The attacker can have your device call or message their paid service without your consent, pulling money out of your account.
Reading contact details. They can get all your contacts' e-mail addresses and put them into a spam database.
Reading/writing the filesystem, gaining access to confidential things you store there. I don't know if it exists yet, but a CryptoLocker for Android could also be possible.

My personal view is that this report has no real information value, it's just some antivirus software marketing or empty content to keep that blog running. I would not even call this a vulnerability, at least not an Android one. It is a human vulnerability. I mean, this kind of thing has been going on for ages. It's the "Don't believe the flashing You're the 1000000th visitor, click here to claim your prize!, Quick painless penis enlargement and/or Viagra for cheap and Install our registry cleaner and speed up your PC" thing all over again. It's maybe meant to be a warning for people who install any seemingly interesting app that crosses their way without even checking the permissions.

From the Android system developers' view there can't be really much done to prevent this. They already really went out of their way to produce a platform that prevents accidental app installs and permission abuse, but there will always be a lot of gullible people who believe flashing ads so much that they disable security measures when they're asked to.

From the app developers' view: don't use ad providers you don't trust. Ad providers often provide obfuscated code for you to include in your app in order to prevent you from tampering with it to trick them. This also prevents you from understanding what the code does, and it could do exactly this kind of thing.


How to be mean to some people that stole my phone

Offensive defense is the type of attack you are looking to perform. You have been the victim of a technological crime, you are the target of a phishing campaign, and you want to get even. This is a very normal response and I can tell you that many organizations, governments, and individuals attempt this on their own daily. There is a major issue with any type of non-legal recourse, however.

Due to the anonymity of the internet, and the relative ease of using a botnet to do malicious activity, it can be really difficult to assure that you only hurt the people you intend to hurt. In attacking an individual through a network relay, you may end up shutting down your own grand mother's computer which is less than ideal and totally irrelevant to the initial attackers. The only truly legal recourse is to co-ordinate with your local authorities and attempt to gain information back on the attackers.

If you can glean any information from your cowardly attackers that may indicate name or location you can use this to work with the authorities. Also, if the phone is on, you can still attempt to use the "Find My Phone" feature to track down it's current location alongside the proper authorities (I do not recommend confronting thieves on your own or without legal support).

In the end, it really sucks that you're in this position and I have compassion for you. Know that your options are limited, but do take advantage of the ones you can so you have the peace of mind knowing you did all you could legally do. That will be far better than putting your self in the position of risking jail time over a device.


Organisation's use of SSL inspection and duplication of root CA certs

Let's unpack your questions:

  Is this quite significant? or should it all be ignored

and

  how can you express the issues associated to computer illiterate administration staff

tl;dr: "It depends".

You've already discussed the privacy / ethics concern with the school fully monitoring all traffic of all devices in their building, so let's assume for now that we're ok with this and talk about the technical concerns:

The CA was rolled over and the old one left of devices.
Graduating students (or guests leaving the building) do not remove the root certs from their trust stores.

Before we can go any further, we need to define our threat model. I assume you're worried about random cyber-criminal-hacker-trenchcoat people compromising these devices because of the presence of these trusted roots?

I think there's only two ways this can happen:

The CA cert uses weak crypto and can be brute-forced before it expires.

Certainly a 10 year cert on RSA-1024 would be in this category. You'll need to look at the root cert itself to see what crypto they're using.

The admins were sloppy about storing the private keys, and hackers were able to hack into the school and steal the private key file.

Yup, now any website visited by a device with the school's root cert could potentially be a phishing site and the device / user won't know the difference.

So, the question is: how hardened are the school's networks against the CA cert private key being stolen. For example, has the school hired external penetration testers to help them harden? The way to pitch this to administration is the cost of hardening the network vs the risk of making every student / staff / guest's device vulnerable to attackers both on and off the school's network.


What parts of IPv6 address may I show publicly and safely?

First of all, it is important to keep enough bits from the start of the address that it will still be clear which class of address it is. How many bits are needed in order to know that does however depend on which class of address it is.

Here are a few examples:

2001:0:xxxx:xxxx:: a Teredo address - 32 bits (two groups of digits) is enough to know it is a Teredo address.
2002:xxxx:xxxx:: a 6to4 address - 16 bits (one group of digits) is enough to know it is a 6to4 address.
2a01:xxxx:xxxx:: a globally routable address 3 bits is enough to know it is globally routable, but publishing the full first group is usually better in order to avoid confusion. If you showed two groups (32 bits), it would be enough to know country and provider, with only 16 bits available it would still be clear which continent the address belongs in.
fdxx:xxxx:xxxx:: a ULA address. 8 bits is enough to know that it is a ULA address. There is nothing in the address directly pointing to you, so publishing the full address is not enough on its own to identify you. However the next 48 bits are supposed to be globally unique, so correlation with ULA addresses published through other channels could be possible. So you might want to censor the following 40 bits.
fe80:: a link-local address. 10 bits is enough to know that it is a link-local address, but the next 54 bits are generally 0, so the first 64 bits are well known in this case.

That covers the common cases for the first 48 bits. The next 16 bits of the address are usually indicating which segment on your LAN is referred to. Since it is important to know whether two addresses are on the same segment or not, those 16 bits should not be censored, as they very often contain information of importance to your question.

The last 64 bits may contain your MAC address, as in this example: fe80::220:40ff:fe30:20d7. Here the ff:fe in the middle of the last 64 bits will indicate that it is generated from a MAC address. 0220:40 will indicate the vendor of the hardware, and 30:20d7 will identify the specific device within the series.

Don't censor all of the MAC address, as it is relevant to know whether two addresses are based on the same MAC address. I would consider fe80::220:40ff:fexx:xxd7 to be a reasonable compromise. It will indicate the vendor, but not uniquely identify the device, and should you have a few successive MAC addresses from the same series, they can still be told apart by looking at the last bits.

If 2001:db8:5c1d:c698:220:40ff:fe30:20d7 was a full address, which I wanted to censor, I would write it as 2001:xxx:xxxx:c698:220:40ff:fexx:xxd7. All you can really tell from this address is that it is a globally routable address, and it was generated using the MAC address of some Motorola hardware.

Never write an address belonging to someone else when censoring an address. If you need to write out a full address and cannot write any x somewhere in there to indicate that it is censored, there are a few options. For a ULA address you are allowed to replace the 40 bits after the initial fd with a random value. If I used fd59:f1b8:8740:: locally it would be acceptable for me to just write fd8f:ed38:64da:: if I wanted to censor it. For a globally routable address anything starting with 2001:db8: is fair game for examples, like in my example above.


New to IRC specifically BitchX, what is the best way to remain anonymous

I finally answered my own question:

Using *nix in your local directory if the file .bitchxrc does not currently exist then go ahead and create it

touch .bitchxrc

then inside that add your irc commands for these 2 environment variables

/ircname Phrase you would like or name
/ircuser username

save file
relaunch bitchx
type /whois

bam -> you're no longer showing your personal info


PPTP is thoroughly broken. At this point nobody who cares in the least about the communications they intend to protect should be using it. And it's not a matter of choosing someone's implementation over another; its most serious flaws are in the protocol design and cannot be fixed.

MSCHAPv1 was broken 15 years ago, as you noted in your question. Its replacement, MSCHAPv2, has been known to be weak for nearly as long; now it can be brute forced in a matter of hours; this was demonstrated at last year's DEFCON and you can now use an online service to break it.

You can use EAP-TLS authentication with PPTP, though this requires a full public key infrastructure and isn't something you're necessarily going to put effort into unless you're building an enterprise VPN. There are a lot of moving parts, so it's not something you are likely to do for a personal project.

And then, the above only deals with authentication. The encryption, MPPE, uses RC4. But, there is no message authentication, so it is possible for an attacker to modify your traffic in transit, quite possibly without it being detected. And RC4 is getting weaker by the day (which is a whole other topic)...

Microsoft, for their part, recommend using L2TP or IPSec or SSTP. OpenVPN is also a possibility, especially if you are dealing with non-Microsoft systems.

Finally, the implementers of PoPToP, the Linux implementation of PPTP, recommend against using it, and have done so for almost a decade.


Is protecting a parent folder secure enough to protect files within that folder?

There is an excellent answer for this question on SE Unix & Linux.

In short, and to quote the answer:

  The precise rule is: you can traverse a directory if and only if you
  have execute permission on it.


The problem you're describing lies with the Java settings of your Windows machine, not the ASA appliance.  Change the Java security permissions (under Configure Java > Security) and make an exception to the IP address of the ASA port which was configured to accept the HTTPS connections from the ASDM.  Assign a static address to the Windows machine - don't use DHCP - and allow it to access the ASA.


If Xampp is not secure enough for a production environment what should I use?

You are using an Ubuntu machine and there for it comes with it's own LAMP stack.  Just type in sudo tasksel and then select lamp and hit enter.  Done!

(Also yes,  Apache Fiends XAMPP is insecure,  usually outdated,  and doesn't update as nicely as apt)


How to find the IP address of a CCTV camera connected to laptop via ethernet

One method is passive; use a packet capture tool such as Wireshark or tcpdump to see if you can see the device communicating on the network.
If that fails, try netdiscover, which can actively sweep all subnets to find devices.


A list of BIOS passwords is here. Note that while BIOS passwords help to protect to a certain extent, they are no barrier when someone has gained control over a computer. They could use utilities like flashrom to change the password, or even embed a rootkit into the BIOS flash chip.


Obtaining .p12 certificate from PEM file and CRT file provided by GoDaddy

Based on the comments following the question, it seems that you do not have the private key that corresponds with the public key in the certificate files that you have.  Without the private key, the certificate is not of much use, as clients will not be able to complete an SSL/TLS handshake with a server secured with this certificate without the server having the private key.  See Could a stolen certificate show as trusted? for more info.
If you do not have the private key that the certificate originated from, then you may need to start over, by generating a new private key, then creating a certificate signing request (CSR) from this private key, then submitting the CSR to a certificate authority (CA) who will issue and sign the certificate.  These steps can all be completed using openssl.
Many CA's (e.g. Comodo, GeoTrust, etc.) charge less than $10.00 USD for a one-year certificate, so loosing the private key is not a outrageously costly mistake.  LetsEncrypt even offers free certificates.  Also, some CA's will let you re-key an existing certificate in the event that the private key is lost or stolen.  This basically amounts to the CA revoking the old certificate, and issuing a new certificate for the remaining life of the old certificate, where the new certificate is derived from a new private key.
Whichever route you go, the CA will probably issue the new certificate in PEM or CRT format.  If your server requires the certificate in PKCS#12 or PFX fornat, you can use openssl pkcs12 to convert it.  See https://www.openssl.org/docs/man1.1.1/man1/pkcs12.html for more info.


Blind SQL injection: Can you execute a hex string as part of the query?

For a UNION to succeed, both SELECTs need to select the same number (and possibly compatible data types) of columns.

So your first task would be to identify the number of columns in your initial SELECT. You can do this with the ORDER BY clause by specifying the numeric position of the column to be sorted by:

' ORDER BY 1,'

This would end up the the query as follows:

SELECT * FROM table WHERE title='' ORDER BY 1,''

A non-existing column position would result in an error. So just increment the number until you get an error (or false response).

Then you can construct your second SELECT with that exact number of columns and UNION it with the first one. Depending on the DBMS and column types, you may need to fiddle a little bit around with the column types of the second SELECT to find compatible types.


You seem to have the basic user data covered, but I'm not sure why try to isolate it like that.  I would run each user's browser instances with an in-memory home directory/storage area.  Then when the process terminates, all of the data is destroyed, no risk of leaving anything behind.  Headless Webkit like PhantomJS provide flags specifically to move these data to their own directories, which can be placed on a tmpfs ramdisk.  (Webkit-gtk seems to be a library, so I assume you've wrapped this in your own program?)


How can I protect myself against software installing insecure root certificates?

There isn't a completely sure way.

The best option I can think of is to check the certificate store before and after running software installs.  If a new root CA is installed, consider your computer compromised, publicly post about the issue, and reformat.

There is inherently a lot of trust involved in installing software as the installer is given fairly broad rights on your system.  Post-install app usage is not such a concern unless the app systemically uses UAC elevation to gain superuser privileges.

This is a very old problem.  Ken Thompson's Turing Award Lecture Reflections on Trusting Trust was back in the ever appropriate year of 1984.


Is there any reason to not use DKIM, SPF, and SenderID because it affects plausible deniability?

In my opinion, yes it is. These technolgies can be use as a basis to affect plausible deniability but are not strong enough to put the person in verdict. The answer to the question whether these technolgies affect or not plausible deniability lies from within the technical objective of these technologies and the strong justification of the technical components and reliability along with court evidences.

DKIM, SPF, SenderID's are used to improve mail deliverability based on the domain's trust relationship. On the other hand, when a private key has been used along with the above technologies to sign the message, it will be difficult for the sending party to deny and justify the fact that the message has originated from the domain and specifically to his/her account.

This particular instance removes doubt to the authorized sender having the knowledge in sending "something" internal to a recipient outside of the corporate realms and jurisdictions and proves a possible violation of corporate policy. In this regard, it is stronger from a technical perspective given that there is a technical prima facie evidence.

On the other hand, the burden of proof lies from within proving to the court that the evidences was not altered and the actual behavior of the allegation was committed by the person in charge.


(i.e. a PKCS#7 object containing the signature but not the data that was signed)

That describes exactly what a detached signature is, a signature separated from the data which was signed.


Is it possible to spoof the IP once a TCP handshake was performed successfully?

No.

A TCP session is defined by four items:

Source IP address
Source IP port
Destination IP address
Destination port

This comes from RFC 793:

  To provide for unique addresses within each TCP, we concatenate an internet address identifying the TCP with a port identifier to create a socket which will be unique throughout all networks connected together.

  A connection is fully specified by the pair of sockets at the ends.

If you were to:

  2) Use the session (with a different IP) and send a request

When you change any one of those four parameters, like the source IP, the new packet is no longer a part of that TCP session, and will not be "delivered" because it does not match the session definition.  Instead, it'll be an out-of-state packet, and dropped or rejected.


Is it ok to share relevant login information on an API's public endpoint?

Yes, it's a valid approach. The metadata is public information.

The implementation depends on the protocol(s) supported by your API. In case of OpenID Connect as the protocol, OpenID Connect Discovery specification talks about the metadata a service can publish to describe various aspects of its implementation. From OIDC Discovery spec:

  Once the OpenID Provider has been identified, the configuration
  information for that OP is retrieved from a well-known location as a
  JSON document, including its OAuth 2.0 endpoint locations. [...]

  The response is a set of Claims about the OpenID Provider's
  configuration, including all necessary endpoints and public key
  location information.


Is it possible to encrypt a download twice, once with a different encryption method?

Yes, absolutely.  You can re-encrypt an encrypted file however you'd like.  For example, if you'd like to encrypt it once with asymmetric (public-key) encryption, and then again with symmetric (password), you'd need both a password and a private key to decrypt it.  The same would be true if you encrypted it multiple times with symmetric encryption (multiple passwords, a new one each time a layer of the onion so to speak is peeled back), or keys (multiple public keys, again, onion-esque).

That said, I think any benefit to the multiple methods of encryption is only going to be marginally beneficial.  A strong cryptosystem in the first place sounds like the best solution, e.g. 4096 bit rsa, or 256-bit elliptic curve.   I'm not sure this approach solves your problem though.

Remember, each board needs to have a different key and you can't share the same private key or symmetric key with each piece of hardware without creating a huge security hole.  In such a way, updates should be signed with a private key only you (the master code distributor) possess and the boards should validate the signature in traditional code-signing fashion.


Did the "Malicious SHA-1" technique enable the NSA to insert a backdoor into SHA-1?

This attack is not about generating a modified SHA-1 that makes collisions easier, it's about generating a modified SHA-1 as part of the process of generating one specific collision.  The modified hash function so produced is only useful for creating the single collision used in the generation process; it is no more vulnerable to collisions in general than ordinary SHA-1.  See the bottom of page 5 of the research paper.

The constants in ordinary SHA-1 are the square roots of 2, 3, 5, and 10, times 2^30.  Yes, it's possible that those four numbers were picked because they permit the creation of a single highly-valuable collision somewhere, but it's unlikely.


Any disadvantages to long-lived self-signed certificates for personal use?

There are a number of arguments for a shorter lifespan of certificates. You already mentioned the possibility of a compromised certificate.
Other reasons may be that, as domain names can change ownership, it is possible to own a valid certificate for some period of time for a domain you no longer control.
But that has little to do with your set-up with self-signed certificate. Basically, as long as your private key is not compromised, your set-up should be secure enough for private use.
What you should also note is, that Apple and Google have limited the validity lifetime of the certificates that their browsers accept. I don't know how you read your email, but it may just be that a new version of the email-reader will also no longer accept certificates that are older than a year.


Encrypting files in a windows environment

Ehmn, the 'industry standard' for client-side (laptop/desktop) and server-side (network share) workgroup file encryption in a Microsoft SMB environment is -- you're not going to like this -- don't do it. Seriously, very very few people do this, for many good reasons.

OK, you said "requirement", so the next best solution is Microsoft Encrypting File System together with Active Directory for management.

The good properties of EFS are:

The encryption is almost completely transparent to end users. EFS files are used just as plain un-encrypted files are; decryption permissions are inherited from the logged on Windows user account.
Pretty good performance, EFS is integrated with NTFS and decently fast.
Advanced management capabilities. Via Active Directory you can create multiple layers of admin accounts for unlocking files in an emergency; handle team / group / department permissions, etc.

Bad sides:

If you ever loose all keys, then you're in deep deep trouble.
Setting up a good, robust & safe EFS infrastructure for a company is a lot of work, and requires very careful risk assessment. You might start by reading this overview, and read the "Recovery" section twice.
A few applications, mostly client-server style apps which run on a desktop PC but use user credentials other than the logged in user, will fail to run. Or worse yet, run, but silently fail.
A few applications may have strange bugs. For example, with EFS my Google Chrome browser is frequently complaining about an unclean shutdown and looses its settings. Without EFS I do not have this issue.
EFS can be counter-intuitive. For example, the default behavior is that if you copy an EFS file to an unencrypted destination via common icon drag'n'drop, then the file is transparently de-crypted. But if you do the exact same via some command line tools, then the file remains encrypted. This has tricked more than one file backup, and caused data loss.

  You can't set multiple users to decrypt a file without explicitly adding their cert to the file though Windows Explorer (from what we have discovered)

The solution is Active Directory & Group Policies. Active Directory can be daunting. No offense intended, but if this is new to you, then maybe you should find an experienced Microsoft sysadmin to lend a hand with the design.

Regarding Truecrypt: Personally, I would never use Truecrypt for this. I love Truecrypt, and use it every day on my own PC's. But at heart it is a single-computer solution, with no group management / multi-PC deployment tools / multi-layered key management capabilities. It's not the right tool for workgroups / companies, other than perhaps full-disk laptop harddisk encryption (and even there, Bitkeeper is stronger on management capabilities).


How can CVE-2016-2324 and -2315 be mitigated on Mac OS X?

Most developers I know who are using OS X are using Homebrew for a variety of reasons; in addition to providing easy installation of tools not available from Apple, the updated versions of Apple-provided tools provide bugfixes and security fixes.  And yes, Homebrew is currently distributing git 2.7.4.


Why is there a "des-ede3-cbc" in my rsa private key?

Your private key is encrypted with Triple DES. While DES is easily broken, Triple DES is safe for now, especially in this context. AES was made to replace Triple DES not so much because Triple DES was broken, but because it was way too slow. In the context of private key encryption, a non issue.


What are the implications of running a Tor non-exit relay node?

Traffic analysis can defeat your plausible deniability. When you relay traffic, there is a packet in for every packet out, but if you're an endpoint the traffic patterns look different - even though they can't see the packet contents.

I think it's very unlikely you'd get any comeback from being a non-exit relay. You may unknowingly forward illegal traffic, so there is a theoretic risk of some legal sanction depending on your local laws, but it wouldn't worry me. It's not traceable to you, and you are not able to decrypt the traffic, so there's nothing you could do to filter it.

Ultimately the risk are minor, but the benefits are minor too. I think most relays are motivated by supporting the tor project. It's a different story for exit nodes where many are motivated by wanting to sniff the exit traffic, and are willing to accept legals risks around this.


To be working with malware, especially reverse engineering, then you must be good at programming, especially low-level programming. There is only one way to be really good at programming: learn many languages. This helps a lot finding out what really is at the core of the concept of programming, and what is purely a matter of syntax.

You know that you master a language if you are able to, at least conceptually, write an interpreter or compiler for that language. If you want to analyze malware which has been written in C, then you must know how a piece of C code gets translated to assembly.

So don't ask on what language you should concentrate; you should be learning all of them. Or at least a decent selection. I suggest assembly (for at least two platforms, e.g. x86 and ARM), C, C++, Java or C#, with a bit of Forth, and some Lisp dialect (Scheme would be best here). For a start.


Which public key encryption method should I choose to sign?

I've used secp521r1 (elliptic curve) public key crypto, and using a key of 521 bits yields good results for the signature size.


What are the differences between an encryption seed and salt?

Seed:

Encryption is powered by random numbers, but how do you generate a truly random number? The current millisecond? The number of processor threads in use? You need a starting point. This is called a seed: it kicks off a random number.

Salt:

When you hash a string, it will always end up with the same hash.

foo = acbd18db4cc2f85cedef654fccc4a4d8 every time.

This is a problem when you want to store things that you want to keep truly hidden (like passwords). If you see acbd18db4cc2f85cedef654fccc4a4d8 you always know that it is foo. So, you simply add a "salt" to the original string to make sure that it is unique.

foo + asdf = e967c9fead712d976ed6fb3d3544ee6a

foo + zxcv = a6fa8477827b2d1a4c4824e66703daa9

So 'salt' makes a 'hash' better by obscuring the original text.


Could a computer turn itself on if the BIOS was modified even if it was turned off by holding the power button down?

Hard power-off of a Windows machine will ensure that wake-on-lan isn't functional, but there are two possible combinations of bios settings that can lead to machine waking up without power button press:

Restore on power failure: Always on\Previous state
I am not entirely sure that powering off via holding power button will account for power loss though. If so, machine would power itself back up straigh away within a second or two.
In the scenario when a machine has Always on setting and is powered off, disconnecting and reconnecting the power will make the machine power on.
I haven't seen this particular setting on laptops, as they have battaries, which is an internal UPS in essense, so these conditions only apply when the battery is dead.
Wake up on Real Time Clock
This one would just schedule power on and wake the machine regardless of other software settings.

Summing up suggestions from comments: any random power-ups with consequent shutdowns are likely a hibernation after sleep. Imagine sleep timer is set to 10 minutes of inactivity, second timer hibernates after 300 minutes.
If you leave your laptop at 22:00 at 22:10 it will fall asleep, at 03:00 it will wake up, dump RAM onto the drive and power off, which might take a few seconds to few minutes, but the machine will spin up the fans and flash all its activity LEDs as it is under considerable load copying data.


Does password-protecting a database living next to the application add any security?

It makes sense to password protect the database if you secure access to the application's config file that holds the plaintext credentials. When you restrict read access to the application's account only, the attacker requires root access to see the password. In case he breached any other (less privileged) account, he will not be able to gain access to the database.


What is the correct way to seed CSPRNG functions?

As anywhere in engineering, there's no "unique" best way; there's always going to be tradeoffs between:

entropy of the source of randomness,
rate of the entropy (i.e. how many bits/second can you get?),
suitability of the source distribution,
computational resource and energy usage,
lack of side-channel attacks on the entropy generation,

and finally, and really not unimportant,

cost.

For example, if you had a truly random source of entropy that you could ask arbitrarily often per second, you'd need to do little CSPRNG – you'd basically have a CSRNG, nothing pseudo about that! All that the generation would do would be a bit of distribution shaping to get uniformly distributed bits, which is what most crypto algorithms need.

Now, since you don't have that, in general, you'd want a source that is

uncorrelated, actually even
unpredictable,
unmanipulatable, and
doesn't have any side effects, neither whether it's currently working, nor about the random data it's producing.

As such, high-quality sources used where it actually matters are often of a quantum nature: spontaneous emissions of photons in excited matter, often.

However, as anything, "the best possible" will set you back a couple thousand dollars, not fit in your rack server, laptop or smartphone, and actually be resistant to ... no attack anyone would ever try to do, realistically.

So, as always: Model your threads. Then define the number of truly random bits per second you'll need. See whether built-in methods (CPUs these days have truly random number generation – is that enough for you, assuming that you can isolate that CPU well enough to make any kind of side channel attack impossible?), together with state-of-the-art entropy pools. For all things I can imagine, Linux' /dev/urandom, using the ChaCha20 algorithm on such hardware sources, is cryptographically secure!


Replaying SSL traffic in an active connection

SSL connections use a stream cipher (RC4) or a block cipher in CBC mode (AES, DES), i.e. (very roughly speaking) ciphers where the next encrypted block is a function of all previously encrypted blocks.

Therefore an attack like the one you propose is not effective.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html


Evidence of any large scale data breaches from lack of physical security?

Such breaches are topics for security breach engineering (through human being weakness, mechanical breach). No organization is willing to risk their reputation to show their blunders.

All you can do is audit possible scenario and implement correspondence policy.

Take the milk ladies as an example, a camera and double access door, plus a 10 seconds door open alert alarm will prevent breach due to physical entrance breach by negligence.

It is possible to implement similar control for important facilities like CDC (central of disease control), but not all enterprise has the resources to implement such control.  So some level of damage control must also be implemented to confined possible breach.


Port Knocking using only Iptables/netfilter

It looks like you are using this howto. You may want to look at this howto instead. The key issue here is that you're using the --set parameter in conjunction with -m recent, whereas the linked howto is using --rcheck.  With --rcheck, you can specify the --seconds parameter to specify a length of time. It would probably be a good idea to review the parameters for the recent patch


Keyfiles have nothing to do with OTP encryption. Rather, they are, as the name implies, files that each contain a key. Naturally, trying to change the key midway through an encryption round-trip will not work at all, so yes, you have to use a file with identical contents to decrypt.

A good keyfile is a few kibibytes or more of randomized data stored in a largely inaccessible and (if possible) suitably obscure spot, say buried as one photo among a couple thousand mediocre shots of family holidays and the like. (I suppose the randomization could be added steganographically.) It functions much like a very long randomly-generated password stored in a file, and like a password, anyone that knows the right one can decrypt accordingly. But again, just like a password or any other key, you don't simply pipe /dev/random to it and call it a day: you have to keep the random-generated data around.

And to emphasize again: if you have a file with the right contents, you can decrypt; if you don't, you can't. This does mean that backups become just that little bit more important, and perimeter/physical security too.


Persistent Bootable USB with Write Protection?

Put an additional partition on your USB drive.

Mount it as write enabled from CAINE. Target your extractions to this partition.


Can I describe the PDF's certificate-based signatures using W3C's DSIG Core?

The publsisher house must to publish in two formats, PDF and EPUB (or other XML-based format), both with the same signatures, and authors using the same tools and same certificates.

Given that the PDF and EPUB content is different (i.e. different bytes) it is impossible for both to have the same signature.  But since they are probably generated from the same source document one could create a signature for this common source document. If the instructions on how to create the PDF and EPUB from this source are relevant one could also sign these instructions together with the source document.

If it is relevant that both the PDF and the EPUB have signatures which can be verified in the reader applications then one must generate signatures which match the different standards used in PDF and EPUB. It is probably possible that the same certificates can be used for this. But it might be that there is no single tool yet which can handle both PDF and EPUB and create signatures in the appropriate formats - in which case it should not be too hard to use two different tools with the same certificate.

  But this question is about simplifications and abstractions, so the better is to (only) imagine a use case.

Abstracting this use case again the OP is essentially asking if it is possible to have the same signature for essentially the same content but provided in different formats, i.e. different bytes. In this case the answer is no, i.e. since the bytes are different the signature will be different too. It is also not possible to derive one signature from the other.

It is possible though to use the same X509 certificate to add a format-specific signature to the various formats which then can be verified in readers supporting such signatures (not all do). This is at least true if the signature is based on X509 certificates (it commonly is) and the common X509 certificate fits the requirements for signing in both formats (which have usually the same requirements).


Any way to avoid man-in-the-middle over http

P.S. please don't tell me about SSL/TLS.

TLS is the solution. It ensures that you are talking with the holder of the private key corresponding to the certificate. It's made for this purpose. It's tested for this purpose. It's built explicitly to withstand MiTM-attacks.

If you distribute certificates ahead of time, you can ensure that there's no man in the middle with TLS. The CA-infrastructure is basically this distribution.

  It is all about trust to a third-party CA.

Then don't use a thirdparty CA - roll your own, and take the pains of distributing certificates manually.

Or roll with HPKP, which basically validates that the public key (and thus the private key) has not changed, which means a fraudulent CA can't replace the certificate.


Spectre and Meltdown being used in large scale attack on unpatched systems

Wannacry was a remote attack: an attacker could point their exploitation program at another computer over the network and infect it, and could have that infected computer attack others in turn.

Meltdown and Spectre are both local attacks: an attacker needs permission to run code on the target computer in order to perform the attack.  Additionally, both are "read-only" attacks: they permit an attacker to read otherwise-protected data, but they don't permit an attacker to modify that data.

Spectre has the additional problem that it requires precise tuning to the CPU, OS, and program being attacked: for example, a Spectre-style attack to retrieve SSL certificates from Apache 2.4.10-10+deb8u11 on Debian Wheezy on a Core i5-8600K might be unable to mis-train the branch predictor on a Ryzen 5-1600, will be looking in the wrong place for Apache 2.4.28 on Gentoo on a Core i5-8600K, and will be completely lost when trying to attack Nginx on Fedora 26 on a Via C7.

The only real threat for large-scale attacks is Spectre-style attacks on web browsers.  For example, all copies of Firefox 57 on Windows are identical, so an attacker who puts malicious Javascript on an ad server could reach out of the Javascript sandbox and collect browser passwords with reasonable success.

(Incidentally, routers and most smartphones aren't vulnerable.  They tend to use cheap, low-end ARM CPUs, which are too primitive to be affected by either Spectre or Meltdown.)


What are the risks of connecting a Raspberry Pi to a PC?

The answer depends on what you mean by "connect through a USB port" A Raspberry Pi has two types of USB port: the data ports using full-sized USB headers, and the power port using a microUSB header.

Power Port

If you are connecting the Pi's 5V power port to a PC for the purposes of powering the Pi, then you are safe because the microUSB's data pins are disconnected [source]. I suppose there's a risk of over-voltage and frying the Pi / PC, but that's hardly a security issue.

Data ports

If you are connecting the data USB ports of the Pi to a PC - either with a male-male USB cable, or through a hub, then all bets are off. A malicious Pi could advertize itself to the PC however it wants, as a HID device, as a USB harddrive, printer, wtv, the PC won't be able to tell the difference.


Your base assumption is correct, your VPN provider is very literally a MitM and can use that position to conduct all the questionable snooping and tampering an attacker can normally do. As you said, if you are making a connection over HTTP the VPN provider could easily sniff all of your traffic and data and based on their privacy policy, most likely are.

With that said, according to the following article: https://www.thesslstore.com/blog/trust-manually-installed-root-certificates-in-ios/ from iOS 10.3 and onwards, a user has to manually accept/allow a new root certificate to be installed. Therefore, it is impossible for this VPN app to install a root certificate on the device without the users permission. Which means even if they try to do it without telling you, all of your visited webpages over HTTPS will be flagged by your browser as dangerous. Alternatively if you never accept a root certificate and your browser is not warning you about HTTPS traffic's bad certificates, then you appear to be home free!

Hope it helps!


Authentication even with incomplete password

Not sure I understand exactly what it is you are proposing. But unless I misunderstand you completely it would be a security disaster:

If the server gives any kind of indication (if only just in the time it takes for it to respond) if an individual character was correct or not it makes the password much easier to brute force, since you can just do it letter by letter. You end up having to make l*n attemps instead of l^n, where l is the length and n is the size of the alphabet.
If the server lets you in after just half a password you have negated the whole benefit of having a long password. As techraf comments: Your scheme is called "a shorter password".
You can not hash the passwords if you want to be able to check them character by character. That makes safe password storage an impossibility. (Well, you could hash them a ltter at a time but then we are back at the brute forcing problem.)


Is there a difference in security between an IP address white list and a domain white list with TLS?

tl;dr: different things, both useful for different scenarios, IP whitelisting is not a bad sign

You are indeed comparing apples and oranges.

IP-based filtering happens at the network layer of the OSI model, whereas certificate validation happens on the transport (and/or application) layer.

Allowing access only to/from specific IP addresses reduces the possible attack vectors whereas certificate validation is ensuring the connection is indeed with the expected party.

IP address based filtering is rather a

  I don't want to talk to people, except my friends

approach, whereas certificate validation is rather a

  Let's see what you have to say and then decide if we talk

approach.

There are several reasons IP based filtering is used, here are some that I find important to mention:

It reduces the surface area of a network or machine massively

If you let your system communicate with everyone, you must be sure that all communicating processes are following the rule.

If you choose to use IP address based whitelisting, you at least can make sure that the communicating processes, as far as they establish connections, are expected to not try and break your system.
It is easy to maintain

A system-wide setting is easier to update than, let's say, 20 web applications.
It is fast

establishing a TLS session is relatively costly, discarding packets based on origin is not.

So if both technologies are used together, they are very useful - and being asked for IPs for a whitelist is no sign of bad security meassures. Often, quite the opposite is true.

There is another part of your question I'd like to address:

  It seems to me that an IP address white list relies on easily spoofed information[.]

While it is true that you can spoof the originating IP address of a packet, this usually does not allow to establish connections.

A TCP handshake will fail and on UDP you are not getting the response - except if you are a man in the middle.


'Removing' telecom provider from my phone

Baseband processors (modem) are not vulnerable by design. They can be as secure as the operating system. Network operator doesn't have any special privileges over them unless your device is a carrier locked device whose firmware was installed by the carrier in factory.
OS updates for carrier locked device are delivered by carriers themselves. They don't have to compromise modem to remotely execute some code. If that device is connected to internet, that is enough for them to compromise it. Carrier locked devices may already have a vulnerability that is only known to the carrier.
If both of your devices are retail devices then there's nothing carrier can do to compromise either of them unless there's a critical vulnerability present either in the driver or in the firmware of the modem, that is known to the carrier.
Your setup is not providing any more security than using a single custom ROM device directly. If your network operator is a threat to you, you need to be wary of OS updates that were last rolled out for your device and known unpatched vulnerabilities in modem. Chipmakers do roll out patches for critical vulnerabilities in modem but old devices that are no longer supported by OEMs are left unattended.
In carrier locked devices, carriers also add further delay in delivering OS updates once OEMs deliver them to carriers. This is where the gap between security holes and security patches start rising.


Can a revoked certificate be re-instated?

The only option to unrevoke is when certificate is revoked with certificateHold reason (§5.3.1 in RFC5280). In all other cases the certificate (and the key) must be re-created.


Can a computer's contents be downloaded wirelessly?

In a corporate intranet it is not uncommon for the hard drives of every computer to be accessible through Windows Shares/Samba for ease of IT Support. If your teacher has encountered this, he may infer the same for any intranet and for wireless also.

In practice wireless networks are secured differently from wired networks as wired network topology and security can be controlled through routers and switches; while a wireless network is a public mesh network of nearby transceivers converted into whatever logical networks a device has authentication for, using some flavour of VPN.

Obviously if the computer's wireless interface is off then siphoning of data in this fashion is impossible. If it is on, the security of computer will depend on the intelligence and robustness of the firewall and firmware stack.

If you aren't running a service (implicit "helpful" Windows defaults or otherwise) that serves file content, the attacker will have to breach your computer sufficiently to install a siphoning tool or reactivate built-in file servers. This breach can also be user installed trojans.

Short answer: Yes if the wireless interface is turn on; but unlikely with even modest security precautions.


Ads embedded in phone apps - what is accessible?

It actually depends on the implementation.

If the ad service just needs to pull a randomly chosen image from a website query then there is no risk at all there.

If the ad service needs a query to a page which needs to run javascript(Or other type of code execution) then there might be a information leak but ONLY if the app is able to do so for example with androids permission system an app that can only display UIs wont be able to read the phones data.


The code doesn't actually run on the remote host.
The ruby module is executed on your machine and uses the Metasploit api to execute code on the other side. The Metasploit api has alot of windows apis mapped as rpc calls (called railgun).
Meteterpter is written in cpp, there is no ruby component or embedding done on the "client" side.
Read more here: How to use Railgun for Windows post exploitation.


Is unused before domains' whois info being scraped automatically on registration?

Correct. Information that can be seen, can be copied.

Your scenario portrays some amount of time where the information of the registrant that was submitted to the domain registration service is available publicly before being privacy-preserved with pseudo-fake data.

Since you do not control these scrapping services nor you know them all, and even if you do, anyone can still issue a query and collect the data, you are exposing the personal information for that (brief) amount of time.


How does a firewall help to protect a server?

A firewall allows you to limit access to ports you specify, and you can specify sources as well.  For example, you can prevent non-root users from creating services that accept connections, so an attacker can't create a new shell backdoor.  You can even limit outbound connections to reduce the possibility of reverse shells.  A not uncommon practice is to only allow SSH connections from "internal" IPs.

Security is about minimizing attack surface, and a firewall is a component in that.  Like any tool, it can be almost useless or very useful, depending on how you use it.


Prevent Database from accessing with knowing system admin user

If the attacker has full access on the database server AND has access to the server decrypting the data you lost with any of these database systems. I have heared about mainframes and custom built systems where the database is integrated into the operating system and you don't get any real admin-access but even for those an attacker with high enough privileges typically can set the read-limits high enough to read the whole database row by row and nothing off the shelf below 100.000 USD per year.

In your case with SQLite with SQLcipher you will need to store the decryption somewhere and because with SQLite it is typically the application server the attacker typically only needs access with the rights of the application/webserver to get all the data. Other database systems provide similar functionality like mentioned below but might be only available in certain editions like for Microsoft SQL Server in the Enterprise and Datacenter editions.

Ways to make it harder for the attacker:

Harden your server (keep software up to date, firewall, secure settings for applications, restrict (maintenance-)access to certain ip-address-ranges, pentesting, don't run services as admin, rate limiting, ...)
Don't store data you don't need to or in a form you don't need (no passwords in cleartext, sometimes you don't need the name of a person for processing but only unique identifiers, ...)
Database encryption: Some databases provide different database encryption options like whole database, tables, columns for example see here. Beware that this might mean a big performance reduction. This causes the attacker to also need the encryption key but if he has full access on the database server he can also sniff the key sent to the database server except in the case of Client-Side Encryption but then he would only need sufficiant access to the server accessing the database.
Limiting attack surface: You can put more sensitive data on separate servers with better security audits. For example for user names and passwords you can use a separate server with a single webservice with the functions "Check password for user id", "Add password for user id", "Remove password for user id" and an extra database server for those data which only accepts connections from this server. Because it has less functionality/code it is easier to audit and has less attack surface.

Of course you will too need other security measure not mentioned in your attack vector like physical access to server, encryption of harddisks/backup, ...


What are the different security concerns associated with open ports on mobile vs open ports on servers?

I found out that, because of the non-static IP address of mobile phones, their open ports are supposed to be more susceptible to attacks.

I think you misunderstood the paper, most likely this segment:

  In the recent evolution to the mobile era, smartphone operating systems inherit the support for open port. But for smartphone applications (apps), traditional open port use cases such as hosting network services no longer apply. One major reason is that compared to stationary server machines with wired network connectivity, the mobility nature of smartphones makes it difficult to maintain a stable IP address. Moreover, the IPs assigned to mobile devices are often behind a NAT (network address translation) pre-venting incoming network connections. Also, continuously receiving network traffic can easily drain the battery of a mobile device, leading to a form of denial-of-service (DoS)attack [49]. Due to these inherent differences, our current understanding about smartphone usage of open ports are rather limited.

What this section is saying is that our assumptions about open ports only generally appearing on servers, as they have a fixed IP address (or at least domain name) that we can talk to rather than a dynamically assigned address, mean that people haven't really considered looking into open ports on mobile devices from a security perspective. The fact that the IP is dynamic doesn't factor into the security considerations all that much, but the assumption that mobile apps wouldn't bother opening ports because there's no real way to know what external IP address that mobile device will be using (and that it may be behind NAT) is wrong, and that incorrect assumption means that many users and vendors don't consider open ports as part of their security model. As it turns out, many apps do indeed open ports, and the paper describes a few ways that certain apps can be abused because of it.

An open port on a mobile device is no more or less secure than an open port on a traditional computing device such as a laptop or server. The difference is that mobile operating systems don't typically run a firewall, and running one by default would probably make for a poor user experience in general since most users wouldn't know how to configure it properly. The end of the paper instead focuses on ways that apps can mitigate problems with open ports, since a general-case firewall is not ideal.


Is it possible for an attacker to redirect a packet sent by a client, modify it then sent to original server

Yes, it's perfectly possible. The answer is to use encrypted connections, since encryption protocols such as TLS/SSL and SSH will stop the attacker from seeing what's in the packets, and also allow the server to detect and reject any changes from what was sent by the client.


Are there any security disadvantages of using production SSL certificate in non-prod environments?

I would assume that the test/dev environment is more 'open' than Prod, in terms of who can access it with admin privileges, etc. If this is the case, and e.g. the dev team and/or external resources have access to the additional environment then that potentially increases the risk that the private key is compromized.

If this is a concern, I would splurge out and buy $10 SSL certs for each dev/test/etc environment. That way the wildcard prod key stays on prod, and won't have to be revoked+replaced if the key for any reason would fall in the wrong hands...


Solution: serveo.net can be used for tcp ports as well, not just ssh, and ssh can be used for tunnelling.. my bad.

I used ssh in par with serveo.net to reserve a static port on serveo.net which is a tunnel to my local server. Problem solved.


The details of how Google implemented this functionality is unknown and proprietary to google so it isn't possible to answer your question completely. However, here are the high points:

Google will have to save your POP3 account password in their system. There is no way around this because POP3 has no is no standard way to delegate rights to a third-party server. Speculative: Google probably keeps this copy of your password encrypted in a reversible fashion in their database. I base this speculation on the company history of putting high emphasis on security.
Google servers will, indeed, periodically contact your POP3 server and download new messages from there. If you have checked the "Always use a secure connection (SSL) when retrieving mail" option, it will do so over a secure channel.
The safety of the system depends on the context. You're placing your POP3 account credentials in the hand of Google. Due to the nature of that information, it could potentially be subpoenaed by authority, stolen by an employee or otherwise leaked. Given Google track record in security, uncontrolled disclosure seems unlikely but definitely not impossible. On the other hand, by using this functionality, you're already trusting Google with the content of your email and with the capacity to impersonate you. It can be argued that, unless the credentials your handing out allow access to other resources and assuming you do force the use of TLS for password check, you're not extending the trust by much with the actual account password.


Double signature with GPG, only validate one key

Sign the file two times with detached signature and move the signature files to file.sig1 and file.sig2. When verifying, move the one you have the key for back to file.sig.

If you do not know which one should match, test both, i.e. gpg --verify test1.sig || gpg --verify test2.sig.


How do I demonstrate OpenSSH redhat/centos patchlevel to auditors?

Providing the SA and version should be good enough since the SSH patch has been implemented. If they have problems with this then they would have to take it up with Redhat version control themselves.

After all if you can demonstrate that the attack will not work because it has been patched, version number means nothing. It's already patched regardless of what the version says.


Does ASP.NET guarantee the integrity of a page's controls on a post back?

Viewstate is what you're looking for.

It secures the page cryptographically, although it has known limitations that are located elsewhere on this site.

An optional MAC should be enabled for sensitive pages, such as yours, that allows the client to post back prices that are used by the business layer.


Depends. If the server responded to the PHP Easter eggs they found out you're on PHP. Now they're probably running through a list of common PHP frameworks looking for those URLs. You need to make sure those URLs aren't able to be accessed by anyone other than yourself and your predefined IP address in the .htaccess file. Otherwise they'll eventually find the URLs, and start attacking them to get access.

Best practices for securing a web app

Make sure the administrative or any damaging pages can only be accessed from pre-defined static IP addresses that need access
Make sure that anyone who shouldn't have access to your website doesn't have access to your website(if it's only for a specific country, limit access using a GEO-IP service)
Utilize your services and control devices to lock down as many features of your application/server as you can until it's at a bare minimum use state(block incoming ports you don't need, limit access, limit access rates by IP, so forth and onward)
Make sure you aren't leaking data
Make sure your SSL is up to date and you don't use out of date vulnerable ciphers

There are a lot of things I've forgotten, but this is a good first few steps.


Putting my PGP ID/link on printed business cards

Considering that your public key is only usable by a computer1; you can remove clutter from your business card by having all electronic data accessible online and referred to by a QR code.

The link could refer to a vCard file stored on, say, a public Dropbox. As the vCard format can store any business or contact information including OpenPGP keys.

Alternately a high resolution QR code could store the entire public key on the back of your business card. Which has certain security advantages.

1. Hand ciphers notwithstanding.


Using a bastion server: how to model an emergency entrance?

This is just an expansion of what @schroeder said in the comments.  You can access (A) or any of (B)'s without SSH if you are using a decent provider.

Most VPS services allow a console login.  The console login is not performed through ssh but through a getty (or agetty, mgetty or other variant) process talking to the virtualisation supervisor.

As an example that I often use (and so do most VPS services), the KVM virt-manager has a virsh console command.  Then the VPS provider only needs to pipe input and output of that process into the web/app console.  The

  PasswordAuthentication no

in /etc/ssh/sshd_config is never used by that method since the sshd process is not being touched.

As for the security considerations of this method, they're in your VPS provider court.  Most providers provide a pretty decent set of checks before you can login into the console (linode, digital ocean and AWS are three that I did use the console and I could configure dual factor auth).  That said, this is simply analogous to going into a server room and connecting a physical console to the console port of your machine.


Concatenating files encrypted by same key

If you are using a reasonably sensible algorithm then there are 2 methods to protect against this kind of attack.

One is the security mode of the encryption. By selecting one which uses feedback (i.e. NOT ECB) decryption of the appended password would be dependent on the original password (which wasn't there when the appended password was encrypted).

The other is use of an initialization vector. This is a random string combined with the cleartext and also maintained alongside the ciphertext. Because each encrypted entity should have its own initialization vector, the appended password cannot be decrypted using the IV and key for the initial password.


XSRF token appended to forms dynamically

Dynamically injected CSRF tokens are a field-tested approach without inherent security flaws.

E.g., the OWASP CSRFGuard project supports that feature:

  OWASP CSRFGuard 3 supports the ability to dynamically inject CSRF prevention tokens throughout the DOM currently loaded in the user's browser. This strategy is extremely valuable with regards to server-side performance as it simply requires the serving of a dynamic JavaScript file.

The iFixit tech blog also has an article on their own "minimalist" implementation of that idea:

  We use a small amount of javascript to automatically set a cookie and add a form field immediately before a form is submitted. The server then compares the form field with the cookie and ignores the request if they don't match. This frees us from the hassle of ensuring every form includes a hidden csrf <input> in every template.

In their code sample you can see that the token is added just before submission which is probably safer than adding it on document load (since something could cause the form target to change in the meantime):

window.addEvent('domready', function() {
   /**
    * Setup triggers on the .submit() function and the `submit` event so we
    * can add csrf inputs immediately before the form is submitted.
    */
   $$('form').each(function(form) {
      // Ensure all forms submitted via a traditional 'submit' button have
      // an up-to-date CSRF input
      form.addEvent('submit', function() {
         ensureFormHasCSRFFormField(form);
      });
      // Ensure all forms submitted via form.submit() have an up-to-date CSRF
      // input
      var oldSubmit = form.submit;
      // Wrap the default submit() function with our own
      form.submit = function () {
         ensureFormHasCSRFFormField(form);
         return oldSubmit.apply(form, Array.from(arguments));
      }
   });
});

There are no inherent security problems with this approach as long as you ensure that the form target has the correct origin.
It even mitigates some attacks, e.g. in this scenario. (The article is about an XSS flaw where the CSP prevents all inline scripts, so the attacker is limited to pure HTML injection. The author presents a method to change the form-action target without any JS in order to exfiltrate a CSRF token set in a hidden input field. Now if that token was instead added dynamically, the attack would have failed because your script would recognize that the form submits to an untrusted origin.)


What is the security of one time login with SMS code?

SMS spoofing is certainly possible. However, SMS spoofing doesn't make your security verification any less secure. All spoofing does is allow an attacker to send your user a different code. The code will obviously be wrong, and may confuse the user, but it doesn't hurt anything, in the sense that an attacker can't gain access to someone's account by spoofing texts. What would be a problem is SMS interception. If an attacker can intercept the message then they would be able to login to someone else's account if they also somehow already know that account's username and password.


How great is the risk in publicly sharing part of a private key?

Providing any part of the private key makes it less secure, at least marginally, simply because it provides an attacker with a smaller potential key space to explore.

I fail to understand what you want to achieve.  The only thing two people need to do to check if they hold the same information is exchange a hash.

If you are designing a protocol and are worried about replay attacks, you can protect against it by performing a challenge response using a HMAC.

Edit:

As suggested the comments and explained in D.W.'s insightful answer, I need to emphasis that the impact on the security of your private key will depends a LOT of exactly what algorithm you are using. In the worse case scenario, revealing only a small part of the private key will completely break the security of that key.


Forged SSL without installation of root CA, possible?

No. Interception of HTTPS connections is usually done by governments in cooperation with ISPs. Governments obtain a valid certificate from any one of the CAs who have their Root certificate among the Trusted certificates in browsers and operating systems. Governments use legal means to force CAs to issue them certificates. This is only possible for governments who have a CA within their jurisdiction, meaning all the large states of the world have this theoretical capability. How widely this is used in practice is unknown. It can be (sort of) detected by SSL Observatory and I have seen some extensions for Firefox that notify you if SSL certificate has been changed since your last visit.


Should I store my intellectual property / code online?

You're not being paranoid at all. First and foremost you must consider requiring a VPN (and maybe 2 factor authentication) to access your company data/intranet. Passwords should be stored in absolutely nothing less than an application like KeePass or LastPass.

I am a huge fan of a Wiki. But you need to draw a line between what is "the internet" and what is "our private network" - Anything you put on "the internet" should not be intellectual property. The internet is a public place no matter how you look at it.

Secure your network and your websites and data behind it will be secured also.

VPN + Wiki on Apache/IIS with proper IP restrictions + KeePass and you're good to go


How ARP spoofing works when the attacker has a different IP address than target?

In many cases, the attacker doesn't need to be configured with the victim IP:

If they only want to capture packets intended for the other IP, assuming the attacker can capture raw packets on their system.
If they're spoofing to overload or DoS the network, e.g., a MAC table overflow attack.
If they're sending data via UDP/ICMP, either to exfiltrate data or to provide a false trail pointing at the victim's IP

In some cases, the attacker might need to configure their system to use the victim's IP - when they're actively masquerading as the victim, and are taking steps to block the victim from disrupting connections.  But those cases are relatively rare, compared to the abuses above.


How to locally monitor outgoing internet traffic?

If you are not interested in the actual content, but only the websites visited by machine, then a local, filtering/monitoring DNS server is the tool you are looking for (probably in combination with fixed IP addresses per machine, using the DHCP server of your router). For the VM's, you want to make sure, they get their individual IP addresses.

There are many options out there, some free and open source ones too. A local DNS server can:

Log the websites visited
Log the DNS queries by machine (with source IP)
Have "user accounts" by IP. With fixed IP addresses, this allows to track usage by machine.
Do filtering (not what asked, but my be useful)

Note: Product recommendations are off-topic, so I will not give them. Google for "local DNS filtering device", but then do not use the filter feature of these products.


The question is not whether there will be an exploit but what will be the range of upcoming exploits.

This vulnerability receives so much attention precisely because of its impacts.
Would it be a theoretical weakness reserved to potential state agency or a thing easily fixable as part of automatic update processes, nearly no one would have ever heard of it outside of the IT-Sec world.

But the real question in such situation is: what's next?

Once a security flaw is published, it attracts a worldwide attention to a specific piece of code, usually resulting with other flaws being found or other ways to use the discovered flaw with more impact or efficiency.

Simply look at the flaw discoverer, Mathy Vanhoef: between the time he wrote his paper and the time he publishes it he himself discovered new techniques making some attacks significantly easier than what he initially thought.

So bring this to a worldwide scale, and you understand why Mathy chose to end
his KRACK Attack page as follow:

  So you expect to find other Wi-Fi vulnerabilities?

  “I think we're just getting started.”   Master Chief, Halo 1

If you remind of the WEP total failure, the issue was not to be found in a single security issue but in a series of several flaws:

It is possible to replay some packets.
Some cryptographic initialization may be reused.
The encryption strength is limited.

Taken alone, they are not very powerful. But associate them, using the replay attack to force initialization vector to be reused and allow to break the encryption key, and WEP becomes fully broken with war-drivers roaming across streets.

Here we have one flaw affecting the WPA2 protocol. It is already very impacting and, as you said, a large proportion of devices will never get patched. But will this stop at this (WPA2 being better engineered than WEP we might hope so), or is it the first discovery of a dark series affecting the WPA2 protocol? No one knows for now, and a lot of people are working on this.

So:

  KRACK: will there be an exploit soon?

Yes, and yes it will have the impact you describe, and not only that new discoveries may potentially make the situation even worse.


What's a proper way to secure REST interface from session stealing?

I think you may be misunderstanding CSRF as a threat vector.   A CSRF attack is one where the the attacker does not have access to the DOM, and is able to force the user's browser to submit a request which includes the user's authentication token.  XSS is where the attacker is able to manipulate the DOM.  If the attacker can manipulate the DOM, he can force the user to submit any requests, and it will include both HTTPOnly cookie values and any anti-CSRF tokens.  Any CSRF mitigations put in place can be bypassed if an attacker can control the DOM (XSS).

Given this, the best implementation would include both an HTTPOnly authentication token and an anti-CSRF token which is accessible to JavaScript.

Also, anti-CSRF tokens can be implemented which do not need to be maintained server-side using HttpOnly cookies.   You include a randomly generated token in an HTTPOnly cookie, and include the same token in a DOM-accessible fashion.  When the client returns the request, include the anti-CSRF token as a header (or through a similar method.)   Then, on the server, you validate that both the HTTPOnly token and header tokens match.  A CSRF attack will submit the HTTPOnly token, but it cannot submit the the matching header token.  An XSS attack will still be able to bypass this, but as we said above, anti-CSRF mitigations will not work if the attacker controls the DOM.


Kali Linux + How to find information behind NAT

I can not say how exactly you can solve you're problem.  But to collect information with kali, you can use 2 Types of tools scanner and sniffer. Until now it seems you only used Nmap(scanner)

Here a list of other tools.

Portscanner & Co.

Nmap(most common)
Lanspy
Essentiel NetTools
Winfingerprint
Xprobe2
p0f

Sniffer

dsniff-Suite(dsniff,mailsnarf,urlsnarf,arpspoof)
PHoss
Driftnet
Ettercap
tcpdump
Wireshark(most common)

I would give you the advice to use Wiresahrk or the dsniff-suite. Both of them are very powerful. The Difficulty is to filter the information , that you get only usefull information.

Look for steer-codes and headers

If normal methods are not working try:

ARP-Spoofing
MAC-flooding.


Because the SSH connection exchanges a key in such a way that only the holders of the two private keys can have access to the shared key, there is no way for the routers to inject meaningful information.  They could attempt to inject information, but because the information they inject is not encrypted with the mutually agreed upon shared encryption key, it would only come out as garbage on the other end and if the stream was in a chaining mode, it would also potentially corrupt the entire session.

SSL uses a similar mechanism where the end user will be able to tell which server the information was sent from and only the server which the end user intended to talk to can get access to the encryption key that the client selects.

The one thing that can not necessarily be determined is if the client B is actually the client unless they also have a public/private key pair that is either CA signed or previously known.  Both SSL and SSH have mechanisms to support mutual authentication, but frequently only the server is authenticated against a CA.

Regardless, while R1 or R2 (or anyone) could claim to be B, they would not know what B's request was under either system, thus they could not try to convince B that they were in fact A so long as B attempts a handshake with A's public key.


Is encryption still applied if you ignore the SSL certificate warning for self-signed certs?

If you ignore the certificate warning the encryption still applied, but because it's an unauthenticated encryption, the encryption is useless against active adversary (an MITM adversary that can intercept and modify the data passing through it), as the active adversary can just reencrypt your connection.

The best practice to use self signed certificate in production environment is to compare the certificate fingerprint with the expected certificate fingerprint obtained through a trustworthy channel. After you verified the certificate fingerprint, you then should pin the certificate by adding it to the trusted list. Additionally, if you need to work with lots of certificates and lots of devices, you can create your own certificate authority and add that root CA certificate to the root trust list.


web security testing - vulnerability issue

The web server seems to apply different security control whether the access comes from HTTPS and from HTTP.

Most probable is that the designers thought that this file would be accessible only to HTTPS users, and missed the fact that this URL can also be served through HTTP.

In your question you refer to:

A7 – Missing Function Level Access Control: This flaw is about a mismatch between the options proposed in the web interface and the options actually accepted on the web server side, the error being to disable an option only on the interface without disabling its use on the server side. Here there no mention of web interface, and allowed user should use HTTPS link anyway, so this is not the correct topic to classify the current issue.
A4 – Insecure Direct Object References: This flaw seems to address merely internal objects access, ie. objects which should not be accessed at all. However, one may argue that this file should indeed not be accessed at all through HTTP, so from this point of view it might be a correct topic.

Otherwise, "A5 - Security Misconfiguration" may also match since this is just a setting issue, either an HTTPS file access setting wrongly affecting HTTP accesses, or a missing restriction on HTTP file accesses.

Regarding the technical impact, it gives unauthorized people access to this file. The business impact directly depends on the file's content.


There is no XSS in the pasted code. This is only setting the hash of the URL

e.g. https://example.com/foo/1#var/1

using the location object. XSS can only occur when something in an HTML document is set without proper encoding.

Note that this answer is based on the posted code only, and no assumptions are made about where the hash is later used. If the use of the hash gives rise to a vulnerability, the vulnerability lies here than rather with the posted code.

The reason for this is that the application is then processing user input as though it is trusted. If the above code could create a dangerous hash, then an attacker could also create the dangerous hash without using the posted code in exactly the same way as a reflected XSS attack works. e.g. the attacker gets the user to visit a specially crafted URL like

https://example.com/foo/1#<script>alert('xss')</script>

to trigger the attack. It is upto the hash processing code to deal with this, not the code that generates the hash.


No. There is no mechanism in SNMP protocol to identify the source program.
If SNMP string is not set to default public then only it helps that a certain program/source can make a request. In your case you have public default string.

Read about SNMP Reflection attack, source IP in the UDP packet is a spoofed address of the target, SNMP response packets get sent back to the target instead of the attacker to cause DoS.


Decrypting SAM hive after Windows 10 anniversary update?

Why not just resetting the password? This is much easier and the process could be done in less than 5 minutes.

For password recovery, Ophcrack seems more effective than mimikatz.

Credit: A list of the top 10 free password recovery tool for Windows


User entered Javascript security implications

The Same Origin Policy for DOM access isolates sub-domains,  therefor the impact of XSS is isolated to a specific sub-domain.   The Same Origin Policy for Cookie scope isolates sub-domains in that they cannot read or write another sub-domain's cookies.   Just make sure your main site is www.site.com and no cookie is scoped to *.site.com,  as this would be accessible (if it was an HTTPOnly cookie,  it would not be accessible from JavaScript regardless of its scope).


Is this a virus or what? DECRYPT_INFORMATION

From a bit of googling the DECRYPT_INFORMATION looks like a thumbprint of Hermes Ransomware, symantec has a technical description here

According to the link the executed Trojan creates the following files, which you could search for to confirm, but definitely don't click on that Reload.exe file if you find it:

  %AllUsersProfile%\Reload.exe
  %AllUsersProfile%\shade.bat
  %AllUsersProfile%\system_.bat
  [LOCATION OF ENCRYPTED FILES]\DECRYPT_INFORMATION.html
  [LOCATION OF ENCRYPTED FILES]\UNIQUE_ID_DO_NOT_REMOVE

And creates the following registry subkey:

  HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\allkeeper

It targets files with a range of extensions, available at the Symantec link, but the recommendations apply mostly for network admins and won't help you much.

Note: I'm sharing this bleepingcomputer forum post just for information, not at all suggesting to follow the suggestions there.

From this bleepingcomputer forum post, it seems that the Hermes Trojan may have some difficulty traversing directories, so it could be minor if you don't make things worse in your detective work.

I suggest backing up any information on your computer that you don't want to lose, and opening files by right-clicking them and opening them in notepad instead of double-clicking.

If I remember right Windows has the unpleasant feature of hiding file extensions and you don't want to stumble on any more executables in case it has more landmines.


There are two different situations:

1. You are going to run the software as root

In this case you should really trust the source code before using it.  Either by auditing it, or by trusting the author and the delivery method.

If you are going to be recompiling the code, then I think the source files should be owned by root, so that an unprivileged user cannot modify them.  And if the source tree is owned by root, then you will have to compile as root.  If you trust the source code more than you trust your users, then that is the safer option.

2. You are going to run the software as a user

Ideally you should trust the source code before giving it to your users.  But let's say that criterion is relaxed, and you don't fully trust the code.

Then it's not a good idea to compile or run the software as root.

Traditional installation, only partially as root

You can compile the software as any user, e.g. by running ./configure && make

But you might still need to run sudo make install to make the compiled code visible to other users.  In this case, you only need to audit the Makefile before running it.

Build a package for root to install

Alternatively, on Debian and derivatives you can use something like equivs-build or fakeroot equivs-build which will create a dpkg which you can then install as root.

But be aware that packages may have post-install scripts which could do anything with root privileges.  So this may also need auditing.

Safest: Install the software to a non-system folder

With this approach, root's involvement is minimised:

# Create a folder as root, and give one of your users control over it
sudo mkdir /opt/package_name
sudo chown user1:user1 /opt/package_name

# Now do compilation and installation as user1
./configure --prefix=/opt/package_name
make
make install

# Finally, make the executable easily accessible to users
sudo ln -s /opt/package_name/executable /usr/local/bin/


Cookie stealing, what prevents a rogue wireless AP from stealing website cookies?

"Rouge" is a kind of lipstick. You mean a rogue access point.

There is nothing which prevents an evildoer from setting up an access point which mimics, from a outside, an access point that you would like to use. At least for any "open" access point. An attacker could find it somewhat more difficult to mimic an AP that requires authentication and does it properly (WPA2), such that your own computer is aware that authentication is expected and would complain loudly if it is not required by the AP. This also depends a lot on the exact kind of authentication. It is best to assume that rogue access points are always a possibility, and, indeed, ready-to-use hardware for that is available.

In reality, this is not different, qualitatively, from the Internet "in general". It should always be assumed that anything which goes over the Internet can be eavesdropped on and altered and rerouted; the WiFi part is just the first step in the journey over the wild Internet, and it is no more protected than all the others, despite tenacious beliefs to the contrary. (I think it comes from the authentication with a password; people think that "if there is a password then it is secure", without realizing that the password is not for their protection, but to limit access to the Internet access which is beyond the access point.)

The comprehensive solution against cookie stealing is HTTPS (aka "HTTP-within-SSL"). Even attackers who can redirect your requests to their own server cannot impersonate an https:// powered Web site (and steal the corresponding cookies), at least as long as:

the site does things properly (i.e., mostly, site-wide HTTPS, with no HTTP-only part, and cookies flagged as Secure and HttpOnly);
you take care to use HTTPS and not be directed to an HTTP-only clone of the site, in particular if the site requests a password entry;
you do not "click through" any warning about a bad certificate (and that's crucial for the whole thing).


What is the difference between RBAC and DAC/ACL?

RBAC (Role based access control) is based on defining a list of business roles, and adding each user in the system to one or more roles. Permissions and privileges are then granted to each role, and users receive them via their membership in the role (pretty much equivalent to a group). Applications will typically test the user for membership in a specific role, and grant or deny access based on that.
Discretionary Access Control (DAC) allows a user or administrator to define an Access Control List (ACL) on a specific resource (e.g. file, registry key, database table, OS object, etc), this List will contain entries (ACE) that define each user that has access to the resource, and what her privileges are for that resouce.

The main benefit of RBAC over DAC, is ease of management - in principle you have a very few roles, centrally administered, no matter how many users, and its just a question of granting each user the correct role; as opposed to DAC, where for each new user (or change in user, or deletion, etc), you have to go around to all the resources she needs access to and add them to the list.
On the other hand, DAC is often simpler, and generally more granular. Also, in the DAC model the data owner can decide who has access (if he has that permission on the data) and add or remove people from the list.

Very common example of DAC is the Windows file system. On the other hand, very common example of RBAC is the DAC on corporate file servers - anyone in the "Sales" ActiveDirectory group will have access to the \Sales\ shared folder.  More commonly is the Administrators group in Windows.

MAC is Mandatory Access Control, this can be seen as a classification or privacy level. This is most often used in military systems, and back in the Mainframe days :). Not so much used anymore, though current OS's are implementing a flavor of this, such as Vista/Win7's Integrity Levels.

To sum up the differences:

DAC is based on personal permissions, RBAC on "group"-level permissions
DAC is set by the data owner, RBAC by the system owner/s (usually the developer defines the access given to each role, and the operational admin puts users into roles)
DAC definitions are typically attached to the data/resource, whereas RBAC is usually defined in two places: in code/configuration/metadata (the roles access), and on the user object (or table - the roles each user has).
On the other hand, RBAC roles are centrally administered (who is associated with which roles), whereas DAC is administered "on the resource" (i.e. you administer each resource individually).
The definition of permissions per role is typically static in RBAC, and users are only granted roles; in DAC the permissions per resource are often changed at runtime.
DAC should be seen as enumerating "who has access to my data", and RBAC defines "what can this user do".


Using digital signatures to identify users

Your thoughts go into the right direction in my opinion, although I hope I can convince you in the following to take a slightly different route.

Let's analyze your requirements:

You want to guarantee mutually authenticated requests for payment processing, i.e. a client initiating such a process would want to be sure of talking to the right server, and a server accepting a request would like to be sure of the identity of the peer. So the solution has to have server authentication plus client authentication
Integrity of the requests is another must - nobody should have the chance to alter anything in the request while it is on its way

These were the major requirements you listed. I would also add privacy to the mix - you possibly don't want anyone listening in on the traffic to be able to learn what the client purchased or the amounts of money they pay.

And now comes the tricky part. You can indeed achieve these goals with a mix of asymmetric and symmetric cryptography. But I think a manual scheme is not appropriate here, and here's the reasons why:

You are trying to secure the transport and the protection is ephemeral - once the transaction is done, you need no longer persist the request data (unless you try establishing an audit trail)
By securing the transport, you are actually designing a security protocol here. And getting them right is probably one of the hardest problems in cryptography. If you read about the Needham-Schroeder protocol: they were dead serious about this protocol for a couple of years, convinced that it was perfectly fine. And they had every right to do so, being decorated cryptographers and all. But three years later they were presented with a valid attack... you probably know where I'm heading and you yourself already mentioned the various things you would have to care about when trying to make this thing secure...

But not all is lost, because there's a perfectly fine protocol already doing all of the above and much more for you. It's TLS! It supports all of your requirements and has been tested by millions, so chances are overwhelming that your manual solution won't be able to compete with it anyway. And on the bright side, it's also already supported in all popular programming languages, no need for you to invent anything.

PS: When to use signatures vs. when to use TLS: it has always helped me to analyze my situation asking me this question: "Do you want to secure the transport?" vs. "Do you want to secure the data/document?"


Is eval() in JavaScript considered self-XSS?

Self-XSS means XSS'ing yourself by running things in console, or stored XSS in an area that only affects the user that injected the XSS. Based on your comments it sounds like you've found self-XSS, since in order to exploit it you have to enter browser console commands.

The reason that entering console commands doesn't count as a vulnerability is that every website is vulnerable to that - you don't need code in the page to use eval or anything like that in order to write a malicious payload into the console and run it.