All of my most important information was hacked from Equifax. Now what? Equifax announced yesterday that there was a security breach and the private information of 143 million Americans was stolen. That information may
have included SSN, name, address, birthday, driver's license, and credit card numbers. Based on the announcement and the survey on the related website, it seems likely that my information would have been stolen in this attack.

Given that most of my financial information is secured by info in this hack, how can I possibly prevent fraudulent use of my personal info? What are the hackers likely to target?

how can I possibly prevent fraudulent use of my personal info?

Apply to all three of the credit bureaus to put a security freeze on your credit report (not a fraud alert, they are two different things-- the latter is temporary). It will cost you $10 or so for each one and be painfully inconvenient when you need to do anything involving credit (applying for job, buying a cell phone, etc.).

Keep an eye on Credit Karma. Be mindful of inquiries you didn't initiate; it's an indication someone is hammering your credit for new lines.

Dispute anything fraudulent as soon as it shows up, before the thief has an opportunity to max out your accounts and bust out. Not that the stolen money is your problem, but the banks and credit bureaus will certainly act like it. Mitigate this damage.

Alternately you can sign up for one of the credit monitoring rackets to protect you against the very threat they created.

  What are the hackers likely to target?

As to what they'll target, it's all the same stuff they always have:

Tax returns. File early, before fraudsters do.
Employment records, including modification of direct deposit accounts.
Health savings accounts.
Existing credit lines. Your card issuers will likely be sending out new cards in the next few weeks, but you can pre-empt this and claim all your cards were stolen and have them re-numbered.
Opening new lines of credit. Everything from credit cards to HELOCs. They have everything they need to impersonate you.

If you have money stored anywhere other than your mattress, assume it's open for the taking unless it's secured by credible 2FA.


Hide Database Secret in offline Java application without user credentials I've been searching the whole last week for any solution but could not find any proper answer and I hope one of you can help me.

I've got an Java desktop application which uses a local H2 database (embedded mode) on a linux machine. The database uses an symmetric encryption with a password.
The application can be used by anybody without asking for any kind of credentials, passwords or login information.
The database secret should be hided and not be visible or editable by users. Finally the application does not have a internet connection.

Is there any solution to provide the secret to the application for database encryption while protection the password from users?
Or is there any other solution to protect the database data from user access while providing the data to the application?

Thank you in advance

Sebastian

Do your users have admin rights on their respective desktop machines? If yes, there's no way you can hide the password from a motivated user for long. Methods like obfuscation and so on may help preventing a curious but lazy user from discovering your secrets, without any guarantee though.

If no, allow your users to run the application but forbid debugging it and reading the secrets file. How exactly do you do that depends on what OS is used in your organization.

Note that this also requires you to install all the security updates on users' machines as soon as it's possible, as elevation of privilege is among the most frequent consequences of vulnerabilities out there.


very bad malware that masquerades as spyware? Has there ever been a known case where a machine acquired spyware like a browser toolbar, or plugin but that spyware also deployed more dangerous malware like a trojan, botnet, or worm?

Yes. What happens is that something gets a foothold on the system, phones home, and then is bootstrapped with a rootkit that is suited to the browser or operating system.

Once compromised, the attacker can deploy different payloads - this month it might be a bitcoin miner, next it could be ad injection into the browser, whatever it is that they are being paid to do.

It doesn't always happen, but I'd say it is pretty common. This leads us to conclude that to be certain your machine is not compromised, always rebuild, no matter how mild the infection might appear to be.


What is the most powerful type of DDOS/DOS attack? What I mean is what protocol are best to DOS something like TCP, UDP, HTTP?

You are probably referring to DoS attacks that are carried out by excessively sending out i.e. flooding some type of packets, consuming all resources of the target. From that perspective the less resources you need to use compared to the resources exhausted on the other end makes the attack more powerful. In reality, this type of DoS is the least powerful.

In the most powerful DoS attacks there must be some vulnerability that can be used for crashing or shutting down an entire software/system with a single carefully crafted packet or request. It's easy to find many such vulnerabilities by listing DoS vulnerabilities and ordering them by severity (score).

Let's take an excellent historical example:

ping -c 1 -p 2B2B2B415448290D 198.51.100.99

The pattern 2B2B2B41544829 is the hex code equivalent of +++ATH0 ASCII string and 0D is a carriage return character. The count -c 1 is here to emphasize that a single packet can be efficient.
The target answers to this ICMP echo request with an echo reply having the same contents.
Some modems treated the +++ as an escape string to enter the command mode (for commands intended for the modem itself), even without the time guard interval (Time Independent Escape Sequence, TIES). This was to avoid licensing Hayes's patent.
These are Hayes command set a.k.a. AT commands, and the H0 hook status "hangs up the phone, ending any call in progress". The target immediately loses Internet connection.

Of course this example is not so useful today, because modems are becoming rare and the problem has been mitigated long before e.g. using different escape sequences. Critical DoS vulnerabilities like those found on the vulnerability database are also fixed on a high priority. Despite that, this is the most powerful type of DoS, as it takes the least amount of own resources having a huge/lethal impact on the target.


Using AES for IoT Security I am trying to built a home automation solution with following use case

User registers on server with username and password_a
User sets the password_b for IoT device
The connection between user and server is TLS encrypted
The IoT device connect to server with unsecured websocket connection
The server acts as medium to pass the data to/from IoT device from/to user
The datapackets for websockets are encrypted by AES using password_b to generate key
Only user and IoT device can encrypt/decrypt the data

Is this a secure way to communicate? Are there any pitfalls with this approach?

I am new to security.

The main problem I see with this scheme is what's called the Key Distribution Problem: how do you securely deliver password_b to the device?

In step 2, the user inputs password_b into a web-form. Presumably in step 5 password_b is sent to the device over an unsecured websocket connection. From then on, the device encrypts all websocket data using AES with a key derived from password_b.

My issue is with step 5: if it's being sent in plaintext then an attacker on the same network as the device could just wireshark the password out of the packet. Even if you use a standard server-authenticated TLS connection, the server would have no way of proving which device it's talking to and an attacker could connect and claim to be the device and get the server to send it password_b.

My suggestion is that if you can afford to run a TLS library, then give each device a client certeficite during manufacturing and have the server keep a table of which public key belongs to which device serial number. This way, when a device connects to the server over TLS, the server knows which device it's talking to just from the public key / signature.

Usually you would use an SSL/TLS ciphersuite that wraps AES, rather than inventing your own protocol because as @Rook suggests, there's just so many ways to shoot yourself in the foot. I understand that some low-power devices can do AES but don't have the memory footprint for a full TLS library. Fine, but you'll have to either become a crypto expert, or hire one, to be sure you're doing it right because you're going off the beaten trail here.


Western Union prompts for bank login information — ridiculously bad practice? I was trying to initiate a Western Union transaction from my bank account, but toward the end of the process I was prompted by this request, which is to type in my bank's login information.

The request evidently comes through PayWithMyBank, which I guess is what Western Union uses to process bank transfers.

I can't imagine how this passes any kind of security muster — disclosing one's bank login information to a third party? It sounds ridiculous, and I can't even imagine what they do with the login credentials. (And this is not even a bank, as in this related question.)

(Both site's security certificates checked out, BTW.)

Is there any angle from which this isn't a completely insane scenario?

Is there any angle from which this isn't a completely insane scenario?

No this is not an insane scenario.I think it simply boils down to trust factor and since your bank trust this third party you will also have to trust them.If they do some foul play wouldn't it be easier to catch?
Also their FAQ pretty much answers everything.

Your online banking ID and password allows your bank to verify your
identity and connect you to your bank account from the merchant’s site
or app. We do not store or share your online banking login
information.

.

PayWithMyBank leverages your bank’s security infrastructure. In fact,
when you use PayWithMyBank, it’s your bank that verifies your
identity. If you change your password with your bank online, the next
time you use PayWithMyBank you will need to enter your new password.

also

No, PayWithMyBank does not store or share your password. Every time
you use PayWithMyBank, you will be required to enter your online
banking password.

Could they lie to you about this?Sure
But i see no reason they would and at the end of the day you will have to trust your bank to make correct decisions about your security.
Also i might add that teaching people to give away their credentials in such a way might not be a good practice in terms of security.That's all i can think of


Prevent untrusted user from running Java bytecode Suppose Windows users have a legitimate need to run certain Java applications. Is it possible to prevent users from introducing and running their own JVM bytecode?

I have only found methods of running untrusted java code in a sandbox, e.g.

java -Djava.security.manager=COM.abc.MySecMgr SomeApp

However, an untrusted user can simply specify their own security manager or policy file.

java -Djava.security.manager -Djava.security.policy=pURL SomeApp

Is it possible to give users access to some pre-installed Java-based applications, but prevent them from introducing and running other Java applications?

One way to perform what you want it to use a delegate user. That works best with tasks that do not have a GUI but it could work with GUI tasks as well (whether it actually works or not depends on too many details to be described here: you need to experiment)

You need to prevent the windows users from running any Java application (for instance through a change to permissions on the file system where the JRE is located).

You then create a different user that has the necessary right to run your application and write a small script that starts your application. That script must also be protected against modification (at least) by the regular user.

Finally, you create a scheduled task for running your script (optionally, you can run the whol JRE command line from that scheduled task but it's less adjustable) and set it to run as the delegate user. You need to give the regular user a way to start the task: you can explain how do that from the task scheduler itself or, like I prefer to do, set it to run when a specific event appears in the even log and use the eventcreate command in a batch file to add that event.

Another way it is to use Citrix or RemoteApp on a different machine (with a seamless application). You'll need to lock down the session quite a lot to prevent the user from running a command-line.

Finally, on Windows 10/2016, you could try to use a docker container. For automated tasks, that will work just fine. For GUI applications, I'm not sure it can work: I know it's possible on Linux but I haven't tried it on Windows.


Required a simple guide for secure messaging application For my personal research, I have to create a messaging app, but security is only important part of application, security from MITM (man in the middle attack), at device end, and at server level. (note: this will not end to end encryption, as I want to backup messages on server for cross-device access like telegram).

I created the following model:

Server creates RSA key pair first time at installation and keeps private key in a file on server, and broadcast public key with its clients, (A, B)
A&B also create RSA key pair at first-time login, and stores private key at device level and sends public key to server.
A sending message to B:

create a random salt_key
encrypt message with this salt_key (AES)
encrypt salt_key with server's public key (RSA)
send RSA encrypted key, and AES encrypted message to server
server can decrypt salt_key with RSA private key and then message
server will do same as A did, but with B's public key
and B will decrypt salt_key with private key then decrypt message.

Is this a secure way, or any another way to secure my messaging app?

This is actually just the opposite; it is a rather in-secure way of handling messages.  Repeat after me: "My server should never, ever, be able to read the contents of a 'secure' message."  Because you encrypt everything to the server who then re-encrypts & sends it on to someone else, if there is ever a compromise of the server then the entire system is compromised.

You really need to instead think of your messages as two separate parts, and to keep it conceptually simple we'll think of it as an old-fashioned snail-mail.  You have an envelope and a letter.  The envelope is readable by the mailman/post-office (your server), but they can't open it and read your letter, that's only for the ultimate recipient.  In the scenario you describe, it is more like a postcard where the post office can read the message (you don't want that).

Instead, consider a scenario more like this.

You have a server that handles two functions: message delivery (+ storage while waiting for offline clients) and recipient lookups.  You have clients that connect to the central server, their whole job is message encryption & decryption (and any local storage/filing of messages you want to include).

For security against the cases you listed, you need multiple layers of protection.  All communications should be over a transport-encrypted link to prevent Man-in-the-Middle attacks (sounds like a perfect match for TLS).  The server should generate an RSA key pair for itself, then as a recipient lookup function, it should publish the public component of this key in its own internal directory (prob with a reserved name that cannot ever collide with a user name).  Each client should also generate an RSA-styled keypair for message protection (or import an existing key pair, if you want to join multiple clients to your account you'd import the same key pair onto each client); when this key is generated the public component should be sent to the server (along with a lookup value, think username or email address).  The server would then add this key to the public directory.  An important security feature is that the server should be able to translate lookup-values into public key IDs (and public key IDs into the full public key -- break that into 2 steps to avoid unnecessary data transmission, making things faster); but the server should never accept the public key ID/data and return the lookup value (with the encryption key a public user shouldn't be able to look up who the key belongs to).

Whenever you want to send a message, you put in the intended recipient(s) on the client-side.  The client looks up each recipient to get their key ID.  If the client already has the corresponding public keys in the local cache it uses them, elsewise it requests the full pub-key data from the server (by ID) and caches/uses that.  At submission, the client makes multiple encryptions, one of the envelope (it encrypts the list of recipient key IDs using the server's public key) and another of the letter (the message itself is encrypted, but only to the recipients, not to the server), and finally a signature of each of those (so that the server can verify it is a legitimate message that should be delivered, and so the recipients can verify the message wasn't tampered with while in transit).  The message is submitted to the server which decrypts the envelope data and puts copies of the message in delivery queues for each intended recipient (by public key ID, not by username/email).

Periodically your clients should query the server to see if there are any messages waiting on them.  The query should be validated by the server by requiring the client to sign a random message with their private key (so you don't deliver the messages, even if they are encrypted, to the wrong person).  Just have the server generate a random byte array of sufficient size to have high random-entropy, then ask the client to sign it with their private key (which is verifiable with the server's stored copy of the public key) before releasing messages to the requesting client.  If you want the server to contain a backup of all messages, then have the server save the full message (envelope and letter) -- for security, the server still doesn't decrypt the "letters" but it can retransmit them down to any client that is checking in (and if the clients share the same key pair, then they will download the same message set, and can decrypt it on their end)

Once the client has the downloaded messages, it can locally decrypt using its private key and display the "letter" to the end-user.  This guarantees that the message itself cannot be seen by the server, thus filling in the security hole that you had in the original design.

Basically, use your server like a PGP keyserver, MTA and storage point; and make your clients into the crypto-end-nodes.  Your server can lookup public key data for any user, given that it is provided with the value (username/email/etc) to lookup --- but it will not provide the lookup value from the public key data (this prevents someone looking up who is communicating if they manage to compromise a message envelope).  All of the message content is encrypted directly between clients (this prevents a server-side attack from compromising the message content, though it may allow the attacker to see who is communicating since the server has a database somewhere that maps key IDs to lookup values).  The envelope is signed by the sender, this verifies to the server that the transmission is from a legitimate source (otherwise it should discard the message as an attempted attack).  And the letter is signed by the sender, this lets the recipients verify that the message is really from the sender (prevents a MitM or server-side attack from sending messages to the "recipients" that aren't really from the purported sender).

Layering all that inside TLS for good measure (helps prevent MitM attacks) and you have a pretty durn secure system.  You can ratchet it up by adding things like "password protect the private key data" (so a compromised client node doesn't immediately give stored message content away) or time-based-envelope/letter expiry (so that messages are transient and don't persist).  On the server-side you could also do thinks like holding all your queues as encrypted data that only resides in memory (if someone steals the server and try to leave with it so they have time to brute-force your keys, the loss of power will also lose the messages sitting on the server, yielding a physical server attack less effective)

This isn't quite as strong as a full double-ratchet system, but it is nearly so.  And it is fairly trivial to implement (RSA keys and PGP en/de-cryption are known processes that are rather easy to drop into a project).


Email including self-shredding macro after "Seen" flag is set Bob sent an email to Alice with nothing much useful and tenuous ( but because it isn't useful it can ruin Bob's reputation if bad Alice decide to publish. )

Is there a way for Bob to include a suicide-after-a-specified-time macro inside the email or similar after the "Seen" flag is set, that is still paired to Bob and not lost on Alice's inbox?

Edit:
I was thinking about a CURL request, that should be embedded somewhere, but then i will a shell PID and need Alice her credentials, this won't be possible by just opening the email.

curl --url "imaps://imap.gmail.com:993/Inbox;UID=1" --user "user:password" -X "STORE 1 +Flags \Deleted"
curl --url "imaps://imap.gmail.com:993/Inbox;UID=1" --user "user:password" -X "EXPUNGE"

Thanks in advance.

No, it's not possible. It would be difficult to implement securely, and also pointless because of all the ways to get around it. What if Alice saves the email externally? Or screenshots it? Or uses an email client that doesn't support macros? If something is displayed on someone else's screen, there's usually nothing you can do to prevent them keeping a copy of it forever if they want to (this is why even with all our clever cryptography, online piracy is still a thing).

However, if Alice won't realise immediately that it's something she wants to keep a copy of, you could achieve a similar effect by making a post somewhere on the internet - ideally your own website - and emailing her a link. Then you can delete the post, so the link is useless. Alice can still copy the message, but only if she does so before it gets deleted.


Is it safe to use an AD account to run an App Pool in IIS in order to provide SQL read/write permissions to a web app? I've been working on an intranet web application that provides read/write, role-based access to a database.

I have been asked to configure the IIS application to use an AD account for the Application Pool, in order to provide the database permissions.  The reason for this is to avoid giving read/write access to the individual users.

I'm concerned about the possibility of malicious code being added to the server, and then having access to the database by virtue of the app pool.  Is this a valid concern?  Are there other risks or concerns with this approach?

From my point of view your concern is valid.  And managing access from
  your IIS web server to your SQL server database with such
  configuration is a good approach. It is also true that if your web
  server is compromised by a malicious code execution (source),
  attacker could elevate privileges, collect credentials, impersonate any IIS App Pool account and get access to your SQL Server. I can suggest the following and specific security recommendations to increase your architecture security :

Lifecycle management for service account:

Define a password policy rotation to frequently change passwords (some Password Access Management solutions can address this problem)
Use complex password policy
To reduce workload from previous points, use Managed Service Accounts (source). They will provide accounts with complex passwords and automatic rotation
Respect the least privilege (as mentioned by @Jeroen) for each of you App Pool and never grant full admin or DB admin privileges to a service account
Use Kerberos authentication (not activated per default). This will require several configuration (source) and usage of SPNs

Server security:

Enable Windows advanced logging and PowerShell logging to detect strange behaviors (like new process, application crash, failed logons, new service, lateral movement...)
Enable SQL Server logging
Enable IIS logs (txt format files)
Do not store front end servers in the same network or subnet than your sensitives servers (eg: database servers, AD, PKI, ...) and use a firewall to filter only the necessary traffic (in your case the port used by your SQL instance).
Switch your IIS server to Core mode (source) to reduce its surface exposition

  So at the end there is no "magic" solution to address your issue, except following basic and advanced security best practices. Having a log collector (eg: SIEM) in place will be also helpful to increase your security coverage from all your logsources (firewall, Windows, Linux, Unix, routers, IDS, IPS, ...).


Web browser password management security Possible Duplicate:
  How are browser saved passwords vulnerable?

How secure are the password managers that are built into modern web browsers?

Currently I use lastpass plugin as I believed the browser based password managers were not secure. It is also the solution that I promote when friends and clients ask me about password security. However, I recently noticed that Firefox and Opera have the ability to set a master password on their stored passwords. I also notice that Chrome does not have such a feature (or am I missing something somewhere.)

Are these browser based password managers, with master passwords turned on, any good?

Should I continue to advocate lastpass and similar to my friends?

OR

Should I advise them to simply enable the master password option on their browser of choice?

Personally, I use browser-based password managers.  As far as I'm concerned, they're secure enough.

I don't bother with a master password, as (a) no one else uses my machines, (b) I have good physical security on them, and (c) my machines are secured enough that I'm not very worried about malware on them.  As far as I am aware, browser-based password managers are fine for almost all web sites (including, e.g., webmail, e-commerce, etc.).

I do make one exception: I do not trust my online banking passphrase to my browser's password manager.  (But my bank has things set up so that my online banking passphrase won't be stored in my browser's password manager anyway.)

The primary downsides with browser password managers is (as far as I am aware) not security, but rather convenience: if you use have more than one computer (e.g., a home PC and a laptop), then you'll need to manually keep the passwords on all of them in sync.  If you are in that situation, you might look at Firefox Sync or Chrome password sync, to keep your passwords updated on all your browsers.  In that situation, make sure your master password is long and strong.


Which attributes in the subject of a X.509 certificate from a certificate authority are used as the "identifier"? I've been trying to follow certificate chains of random websites I visit and see if I do indeed find them in my Windows 10 trusted root certificate authority store.  I almost never find an exact match, especially with the Common Name "CN" attribute. So which of the subject attributes eg (CN, OU, O, L, S, C, etc) does your browser use to say "Oh, this certificate out of the trusted certificate chain, matches this particular one I already have installed and trust"?

The full subject of the issuer certificate should match the full issuer attribute of the issued certificate.

  I almost never find an exact match, especially with the Common Name "CN" attribute.

My guess is that you look at the issuer of the server certificate and then try to find the matching root CA. But usually there is an intermediate CA in between server certificate and root CA. This means the issuer of the server certificate is the intermediate CA and the issuer of the intermediate CA is the root CA.

In other words: The server certificate is not issued directly by the root CA. The issuer of the server certificate is therefore not the subject of the root CA. And you cannot find the root CA just by looking at the server certificates issuer.

Instead you have to explicitly take intermediate certificates into account. For example:

Server certificate of security.stackexchange.com:

subject: /C=US/ST=NY/L=New York/O=Stack Exchange, Inc./CN=*.stackexchange.com
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA

Intermediate certificate - subject matches issuer of server certificate:

subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

Root CA - subject matches issuer of intermediate certificate:

subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
issuer:  /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

For more information see also SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?


Are there reliable Linux ChaCha20-Poly1305 implementations available for stream encryption? I'd currently encrypt a stream by piping it through the following command:

openssl enc -aes-256-cbc -pass file:/[keyfile path]

Is there a reliable implementation of ChaCha20-Poly1305 that I can use instead?

Last I read openssl enc specifically avoids providing a MAC or AEAD cipher because they're worried about providing a footgun to inexperienced users. And rightfully so, if you were to pipe the decryption output somewhere that processes it (rather than a temporary file) you would be processing unauthenticated data, only verifying the authenticity after the damage has been done.

While it's possible to safely stream encryption, it is definitely not safe to stream decryption, so I expect you are unlikely to find such an implementation. If you do, expect it to be insecure.


How come domain resolves to another IP? I tried to ping http://crashsafari.com in my CMD:

Right there, it resolves http://crashsafari.com to 54.231.48.170 which is
http://s3-website-us-east-1.amazonaws.com.

But,

http://crashsafari.com and http://s3-website-us-east-1.amazonaws.com are not the same when I type them in my browser and visit the website.

I want to know what exactly is happening? Where exactly does the problem exist?

Where exactly does the problem exist ?

Nowhere. There is no problem.

With ping you are working only at the network layer and on this layer there is no such thing as a hostname, there are only IP addresses. And crashsafari.com has the same IP address as s3-website-us-east-1.amazonaws.com because this is just an alias (DNS CNAME):

$ dig crashsafari.com
...
;; ANSWER SECTION:
crashsafari.com.        59      IN      CNAME   crashsafari.com.s3-website-us-east-1.amazonaws.com.
crashsafari.com.s3-website-us-east-1.amazonaws.com. 59 IN CNAME s3-website-us-east-1.amazonaws.com.
s3-website-us-east-1.amazonaws.com. 4 IN A      54.231.17.132

But when using a browser to access a site you are using the application layer protocol HTTP instead. Within this protocol the hostname is sent by the client (HTTP Host header) and thus different hostnames with the same IP address can be distinguished by the server. A request to http://crashsafari.com looks like this:

GET / HTTP/1.1
Host: crashsafari.com
...

whereas a request to http://s3-website-us-east-1.amazonaws.com looks like this:

GET / HTTP/1.1
Host: s3-website-us-east-1.amazonaws.com
...

And based on the Host header the server will use a configuration specific for the given hostname, which makes both sites look different even if they share the same IP address.


Is it possible to verify identity of site that sent request to you? I'm developing a JS widget that can be embedded by 3rd party websites. When widget is shown, it sends request to my site. When this request is received, I know that it was shown to the user and pay website for this view. So I don't want to pay if widget is rendered not at the target website.I think that to verify site's url, I need to send embedding page's url in request parameter when widget is rendered. However, it will be possible to send such request from any place, not only from this site's page.

Is it possible to verify url where widget was placed?

As an alternative to having the widget "report back to home," you could write a simple robot that crawls the websites and verifies that the the websites are indeed hosting the widget.

To avoid fraud, you would build the robot with the following considerations:

Hidden identity. Make sure the site isn't only serving widget to robots by disguising your robots identity.
Random crawl sampling. Ensure that your crawling uses a random sampling for when you crawl the sites. This prevents a site from anticipating the crawl and serving it only during that time.
Verify that the widget is visible. Don't only check for the existence of the widget, but that the widget itself is visible and not hidden.
Manual overview. Have your robot generate screen captures so you can review manually whether the widget is appearing.

There are some inherit difficulties that you will be faced based on the "pay-per-view" nature of leasing (to what extent, I do not know because I don't know the specifics of your agreement). The biggest problem is not people placing the widget in non-authorized URLs, but rather abusing the system by automatically (fraudulently) crawling the site to boost view counts. That should be your primary concern, as it is where the majority of the fraud will stem from.

The problem is, it is difficult to verify the legitimacy of a view from an embedded widget. With only access to JavaScript, you have limited capabilities for differentiating between a robot, a user constantly hitting refresh, and a legitimate user. Without access to the server side, your best option to prevent fraud is through browser fingerprinting. This will assist you monitoring abuse of your widget via constant refresh, et al. It is not a catch-all because it is still vulnerable to no-js / torbutton  users which can spoof identities, but it does provide a good first-level of protection to repeat view fraud.


Is it possible to attack car key fobs with regular RF devices? I hope most of the key less entry cars are using rolling codes in order to improve the security between the key fob and the car. Is it possible to intercept this communication using a device such as HackRF?

Can we jam the signal from the key fob to the car and replay it later to crack the rolling code sequence? If so, how can we secure this?

Yes, it is, using either the HackRF or other SDR devices capable of replaying the signal.
You can jam the key fob by simply listening to the signals, the frequency on which the key fob operates gets interferred, then you are free to use the first code you got and store the later one to open the car in another moment.
To secure against this hashing the button should do it, or using time-based algorithms

Source: https://www.youtube.com/watch?v=1RipwqJG50c


How can kids transfer data to a school computer safely? I have a primary-school-aged daughter who needs to bring a presentation to school.   Classmates are bringing their presentations on a thumb drive, but I have some security concerns.  (One, two, etc etc)

I don't want to buy a new throwaway thumb drive every time she needs to bring a presentation with her, and moreover I don't trust a pre-teen to remember to dispose of a "dirty" thumb drive properly every time, or go through an ornate sanitiziation procedure that probably involves a trip through a standalone Raspberry Pi or some such.  The point is, I need a child-proof solution that minimizes the chances of the drive being infected by the (probably compromised) system at school.

I'd like to implement the solution using equipment I already have, but could buy a dedicated "safe for school" device as a one-off if need be.  Alternately, I think the school machine is Internet-connected, so suggestions for an online method of transferring data could work, as long as she wouldn't need to log into a sensitive account (because, again, I'd assume the system is likely compromised).

I'll argue that you're taking on this from the wrong side.  Instead of trying to protect the pendrive from malware assume that the pendrive is compromised as well (since it may at some point connected to a compromised system) and act from there.

I managed to get family members to assume that if their pen drives connected somewhere that is not under their full control then it likely contains malware.  And I do have a machine in which I can plug the drive, link the device, check partition signature, check filesystem signature, and (only then) mount it.  All this is done by a script that I know what is doing, not some automated auto-mount system which may try to read "smart" caches from the pendrive (autorun.bat anyone?).

The ornate procedure you link can be almost fully automated.  But there is more.

  who needs to bring a presentation to school

This means that the transport is one way (home -> school).  So the contents of the pendrive can be completely discarded once the presentation is made.  This makes things a lot easier!  There absolutely no need to mount the pendrive.  Your procedure can simply by to erase the partition table and write a new one.

So, your daughter can get a presentation to school, catch all the malware she wants in the process.  Return home and plug the drive into a "cleaning machine" which would simply overwrite the partition table.

Extra: overwriting the first, say, 16MBs of the drive (before recreating the partition table) may also be useful.  Software that creates partition tables may be buggy, and may not overwrite every byte of the old partition table, this would make sure that the old table (and some of the old filesystem) is completely erased.


How does Linux know if a new password is a "wrapped" version of a old one? How does Linux know if a new password is a "wrapped" version of an old password?
(or, the process of creating a new password) know "certain" parts of one's password?
Let's say I have the password abcEFGH123321 and I set a new password to be: acbdEFGH123321 (added a d).
it displays:
new password is a wrapped version of the/an old password
My guess
..is that the whatever application handling the setting & reading new & old account / sudo passwords    maybe hashes X amount of the first bits of the entered password,
For example;
Say the password abcd is set,
via passwd (e.g) and, you change it (the password)
abcd to abdc (swapping the last 2 characters).
Does it maybe take the old password: abcd and hash the first 3 characters of it?
H₁ -> H('a') -> stores it
H₂ -> H('b') -> stores it

and so on, for - x times. (in this case, maybe x is a hard-coded constant , 3 for example)

If it stores this:
Where does it?
Where does it store the "parts"? Note I am not asking in general - if it knows this - But rather how it does it.
An explanation answer- with references would be great!

The answer is cracklib.
CrackLib will take the new password and modify it in a lot of ways to see if the modification is the same as the current password, that you had to type before changing the password.
So if your old password is
acbEFGH123321 and the new is acbdEFGH123321, and Linux complains, it means cracklib took the new password, added/dropped chars on each position, and discovered that you added one single letter. And that's bad.
Performance penalty on this is negligible. Linux have both the old and the new passwords, and a simple compare between strings can detect differences.


Does TLS fallback only keep from downgrades to SSLv3? I have read the RFC on this and can't seem to find what I am wanting to know. When implemented, if a client and a server support TLS fallback protection, does it only keep them from downgrading to SSLv3, or for example if the connection is made at TLS1.2, will it hold it there? Or will it allow it to fall back to 1.1 or 1.0?

The TLS_FALLBACK_SCSV draft RFC protects against any downgrade attack. When a client's first handshake attempt fails and it falls back to a lower TLS version (including but not limited to SSL 3), it will include the SCSV, and the server can know that the client wants to support a higher version but was prevented from doing so. If the server also supports a higher version than the one the client fell back to, it will generate a fatal alert, since there should be no reason for the client to fall back below the server's highest-supported version.


Covert Channel Bandwidth I have designed a covert channel using ICMP protocol by making use of the data field when sending pings. I am trying now to analyize the bandwith of this channel but I don't know how. Any ideas?

Let x be the maximum bandwidth possible on the network using the protocall without beeing detected (using the whole bandwidth of a network just for ICMP isn't really covert, is it?). Calculate y=(size usable for data in a packet)/(whole size of a packet). (Bandwidth of the covert channel) = x*y.


Do XBAP applications have the same vulnerabilities as Java Web Apps? In response to the popular decision in disabling Java Web Apps, there has been very little mention of XBAP applications.

XBAP applications are similar to Silverlight but it offers more options to the developer from a sandbox perspective.

Should XBAP applications also be considered when disabling Java Web Apps?
Is IE the only browser to be concerned about?

XABP is documented to run on Firefox too. However, it does not seem to be supported by Chrome, or on any browser when the underlying OS is Linux.

XBAP tries to apply the same model as Java applets, and that is known to be a hard problem, therefore a fair share of similar vulnerabilities can be expected. E.g. such as this one, which is recent (January 8th) and looks scary (complete hijack of the computer by browsing a malicious Web page), but, strangely enough, does not make the news, contrary to Java applet holes. I think it tells quite a lot on the current deployment of XBAP (i.e. almost nobody uses it, even potential attackers).


Are there any known exploits targeting Google Authenticator on Android phones? My Android 7.0 phone is somewhat lagging behind on the security updates, a situation I cannot change unfortunately (unless I would root the phone).

I am not too concerned about this in general since I don't run critical apps on the phone - with one exception: I'm using Google Authenticator to generate 2FA keys on this phone.

Hence the question: are there any known exploits directly targeting Authenticator, or (indirectly) by allowing an attacker to read out the keys as they generated on a compromised phone?

One thing I found in previous research. The database is a simple sqlite database which can be copied to extract keys and recreate the QR codes. If somebody were able to exploit your phone and root it they, in theory, could copy this database.

Disclaimer: I haven't personally done any of this, so no guarantees.

Extracting the database: https://gist.github.com/jbinto/8876658

Creating QR codes from the DB: https://gist.github.com/naftulikay/5702d57eb4cb6ef6e7e8


How to protect REST JWT authentication from accepting calls from browser? I've made a simple REST client-server system using JWT tokens.

On my mobile app, you can exchange your Facebook/Google access token for a JWT with the server and then make calls with it, for ex. fetch your friends/data in the app.

Now, I want to limit this so the server will accept only responses posted through the android app, not the classic web browser.

This scenario can happen, when for example user posts his POST request through an app like Postman for Chrome.

How do you handle this kind of things?

It sounds like what you are trying to do is to identify the software being used to access your API. The way I look at this, it is independent of user authentication. User authentication tells you who is using your API, you are interested in what is being used to access your API.

The fundamental problem you face is that you can't trust 100% the code that is running on the client. You have no control over it and a malicious user can modify it or reverse engineer it or as you suggested use something like Postman to send synthetic requests.

You have a number of options of how to proceed:

Remove the problem

It may be that you can re-architect your app and server so that you no longer care what is being used to access your API. It is difficult to trust code that you don't control so if possible it is good to move as much of the functionality to the server.

User-Agent String

A basic method of attempting to identify the source of a request is to look at the user-agent string that is included in the headers of the requests coming to your API. You could filter out requests coming from things that are not your android app. The problem is that it is just a header and is really straightforward to fake. So it doesn't do much in practice.

API Key (and Secret)

Another thing that you could do would be to use an API key. This is an identifier that you use to let your server know that the client accessing it is genuine. To prevent it being stolen by just observing the connection with a proxy, you have to use TLS which encrypts the connection between the the client and server so third parties can't easily eavesdrop. You may still be vulnerable to a man-in-the-middle attack though (look at pinning if this is a concern).

You can enhance this scheme by combining or replacing your key with a secret that you store in the app and never transmit. Instead you sign the traffic you send to the API using an HMAC. If anyone alters the message you send, the signature will not match and you can reject the request. Because your app is the only thing with the secret, another app will not be able to access your API.

This holds true as long as your secret remains hidden, but if you have released your app into the wild, someone malicious can still potentially get access to the app and try to look inside it to retrieve the secret. How hard this is depends on how hard you hide it. You can obfuscate your secret or embed it in native code but a sufficiently motivated individual will probably be able to find it given enough time.

In conclusion

None of the options for identifying the source of an API call are perfect, people will rightly tell you that they can all be cracked. The decision you have to make is how important is whatever you have behind your API and how much do you want to protect it. Only you can can answer that one.

I work at a place that does this sort of stuff and one of my colleagues has just started writing a series of articles that go into a bit more detail about mobile API security. If you want some more detail it might be of interest.


Why is this 435 × 652 pixel JPEG over 6 MB? This was, before someone helpfully fixed it after seeing this question, a relatively unassuming and tiny photo of a  ̶f̶i̶s̶h̶ nudibranch, with 283,620 pixels. It has some metadata: text Exif tags as well as 8.6kB of Color Profile information, and a 5,557-byte Thumbnail as well as a 648,534-byte Preview Image (that I cannot read) and some other random things (like Face Detect Area) that take up little space.

Using

exiftool -a -b -W %d%f_%t%-c.%s -u -g1 -ee -api RequestAll=3 temp.jpg

extracts a total of <650kiB of stuff.

Are there any strategies or tools that one might use to discover what is going on, and whether something has been hidden in the file?

In case it makes things easier, the same or very similar inclusions appear to affect multiple files by the same Flickr user: 2, 3, 4, 5

Short answer: It's an artifact of Nikon Picture Project

I had difficulty finding "Nikon Picture Project" but finally found a 1.5 version to try. The last version produced was 1.7.6 .

It turns out that "Nikon Picture Project" does indeed implement non-destructive editing with undo and versioning capabilities. Unlike every other photo editing software I've ever seen, it does this by directly altering the JPG file structure and embedding edit controls and versions directly in the JPG. There is an Export JPEG function in the software to flatten and remove history but it looks like the native munged JPGs were posted instead of using the export.

I loaded up your first reference image (resized here)

.

Sure enough, "Nikon Picture Project" showed it as an edit and crop of a much larger picture (resized here)

.

Checking the before and after file structures verifies the weird artifacts.

Thanks for the puzzle!


How to Determine Malware Outbound Traffic? My aim is to tighten the firewall on my AD domain PC running Windows 10. Even though Windows firewall is already turned ON - I am not confident that it is blocking malware outbound traffic

What is an effective way to determine which outbound traffic are malware and which are initiated by legitimate apps (such as email and other business-related apps) ?

My initial thoughts are:

Since a legitimate app can make outbound calls to multiple IP (eg. MS telemetry services) - I will need to keep a track of all the legitimate IP (let's call it my IP whitelist)
Any outbound traffic to IP that is not on my whitelist - will be get blocked by my firewall rule

But this will be a costly task - as I will have to monitor and confirm each and every IP outbound connection :(

I know there must be a more effective way to achieve my aim - but not sure where to start

Malware uses many ways to communicate, including misusing twitter feeds, comments in forums or hacked sites with a higher reputation. Malware can also do their communication by hijacking browsers. Thus, it is impossible to simply block all malware communication simply by restricting access to specific IP addresses or by only allowing connections initiated by the browser or mail client.

AV products or perimeter firewalls might help to block a major part of malware traffic (but not all) by using curated blacklists and/or deeper analysis  of the traffic. And, depending on the role your system has in the network you might explicitly limit its connection to the specific hosts it should communicate with and deny everything else (i.e. use a white list of a few known good and trusted hosts/networks and not a black list).


Java is running even after it is disabled To prevent adds and pop-up that seduce users to install or download viruses I have disabled Java. But I have noticed that even with Java disables Firefox is still running it. The pop-ups are coming up. I even tried switching it to Private Mode just to see and ti still allowed the Java to run. This happened since the last update. Anyone out there have an answer? Is this a bug in Firefox or is Java running some new script that can't be disabled? Or is there another browser out there that is more secure?

Java and JavaScript are not the same.  They aren't even related.  JavaScript is an interpreted scripting language that is used by websites to automate site behavior and interactivity on the client side.  Java is an actual computer language that is run by a Java Virtual Machine (JVM) and is used for applications or occasionally applets that may be embedded into a website.  JavaScript is what is disabled by the browser.  For Java you would need to change the settings for the Java add-in for your browser.  It will be called "Java Platform something-or-other", depending on your version when in Firefox.

Update: If these are disabled or not installed already, then you probably already have adware on your system that is causing the pop-ups by actually asking the browser to load them directly.  Try running something like Malware Bytes to see if it finds anything.


Are there privacy implications with ESET Web Protection? I got the most recent ESET Cyber Security Beta for Mac. It offers a mode called “Web Protection” and “Email Protection”.

The documentation don’t really explain what these two modes does, and I’m curious about the potential privacy implications. In a Web browser, the domain name of the sites you are visiting are sent securely to the browser vendor and checked against a list to form what browsers call “fraud/malware protection”. In effect, this means that what you do online is shared with a third party. Is the same happening when using ESET’s functionality?

ESET Consumer Support have, unfortunately, been unwilling to answer questions about what the feature does and how it works.

They are both passive features. In either case when it detects a file it will scan it, before the file is created on the disk, in theory preventing the malicious file from ever existing on your drive. This is at least how it works on the Windows side.  In the case of the Outlook plugin it will scan the file atachements, and in the case of the "Web Protection" it scans files as you download the file, all detection is passive without user ction.


Why is it allowed to change dates to absurd values in OS? I have always considered this a bad practice, although it's true it's not a big issue because any software that depends for something important on dates is mostly gonna work using a reliable source to get the date, on the rare situations this would happen I think it could be a potential security risk.

That a user needs to change date can happen from time to time, which looks totally insecure is allowing for example to set as system date one from the year 2000 in a system that runs Windows 10.

Why is something like this allowed even though it may have some security risks?

Because there can be numerous good reasons to force a system date at an old value or in the opposite in the future. And an OS vendor that would implement a feature forbidding to set a date older than the one of the OS release would unplease his customers!

You may have to re-run old programs with old values to build again reports from example if the original report is no longer available but you still have the original values. Some programs were clever enough to accept a month as input and use automatically the year corresponding at the 12 last months. Or do not ask for any date and automatically use previous month - expected to be run on a monthly base from a cron. Ok, the program should be re-written to allow entering a date. But re-writing of old programs comes at a rather high cost (need to find programmers able to understand old dialects, need to find old compilers or port the whole code to a new version of the language), while changing a date is a trivially simple operation. Ok it is just a workaround but it is a simple and sufficient one for use cases like that.

A real use case I have seen was a workaround to keep old applications that used to store the date in only 2 digits. In fact they could only accept dates in the range 1970 (origine of most dates in system format) and 1999. Only 30 years available. The trick was a calendar has a period of 28 years (bissextile * day of first of january). We were glad in to 2000' to be able to declare to the stupid computer hosting the stupid app that the year was actually in the 70'...

Anyway changing the date is an administrative task (in the sense requiring administrator priviledges). So a normal user should not be able to do it. And administrative priviledges include really dangerous operations such as formatting a disk full of data. Or erasing the boot sector from a system disk. Or [write here the most stupid action your imagine on a computer]. And there are indeed correct use cases for them such as re-using an old disk.

That's the reason why a system normally trust his admin, whatever he asks for. There are indeed warnings more or less saying Hey admin, this looks a really weird and dangerous thing! Are you sure you really want it???. But as for almost any stupid action an acceptable use case can be found, the system just obeys.


AES-256 Decrypt a VHD File I recently messed up with my McAfee Encrypted Laptop (2 Drives) and got MBR overwritten by Linux (Ubuntu).
I used DETech CD on C: but after 2% it failed due to Bad Sector.
Using a safety precaution i have cloned the drives using Clonezilla and the D:> i have restored onto the Virtual Hard Disk (VHD)

I have also kept VHD file for decryption using a VirtualBox and DETech ISO but takes lots and lots of time.

I'm Looking out for a Windows/Linux Tool which can take VHD file as an input and Decrypt it with 256 AES Algorithm.
What are the best Data recovery Tools.

For the first question you can use openssl for decryption:

$ openssl enc <MODE> <ENC/DECRYPT> -in <INPUT_FILE> -out <OUTPUT_FILE>

As an example:

 $ openssl enc -aes-256-cbc -d -in encrypted.VHD -out decrypted.VHD

See this list of system recovery tools for linux distributions: SystemRescueCD, gddrescue and testdisk.

The later can be found in the main repository in ubuntu/debian:

$ sudo apt get install gddrescue testdisk


DoS testing as a part of penetration testing I am doing penetration testing on web application in my local network. As a part of testing procedure I am planning to perform DoS testing. Because I am using just one PC I think that the only reasonable DoS attack to test will be those type of attack that do not demand sending very large number of request, I mean:

Slowloris - Slow HTTP Headers
Slow HTTP Body

But these attack are known from many years, so does this make sense to still test these vulnerabilities nowadays? Is this enough to test that the application uses actual web server, which shouldn't be vulnerable? I've read that this vulnerability depends on configuration but is this issue still actual in modern server versions (majority of articles I found come from 2010 - 2014)?

Are there any other DoS test that I should perform which are reasonable on local network and will not affect my network which is used also by other users?

First, I would not rely solely on banner enumeration to determine vulnerability in terms of a penetration test.

Second, it might not be correct to assume these are the only viable DoS attacks. Web applications (particularly ones that are homegrown) are often vulnerable to all kinds of interesting DoS attacks. One example might be an application server that has a connector that interfaces incorrectly with a partnering web server and a series of requests (ie. content discovery with a tool like dirs3arch) for non-existent content will cause the server to fall over.

And for the slowloris style attack, any servers that will keep connections open indefinitely when receiving incomplete requests will be vulnerable. I've found quite a few applications where this is true in real-world penetration tests.


How does this SQLi statement work? Hey i'm trying the hacker101 CTF's im still pretty new at this stuff

The CTF answer to the flag i'm trying to understand is https://github.com/testerting/hacker101-ctf/tree/master/micro-cms_v2/flag0

The important part of the error you get when you put a single ' in the username field
if cur.execute('SELECT password FROM admins WHERE username=\'%s\'' % request.form['username'].replace('%', '%%')) == 0:

The solution to the flag is to input this into a username field

' UNION SELECT '123' AS password#

This is the statement I don't understand. I googled "SQL AS keyword" and I got something saying something along these lines, "The as keyword is a alias for a column or table" But '123' is a string, right? I got then got fustrated and moved on to the other thing I don't understand about the statement, the # at the end of password. I then also googled the "sql pound symbol" and I got it was referencing a temp table, which again, I don't really get..

Thanks!

In MySQL, # represents the start of a comment. This means the rest of the line will not be parsed as SQL. This is a common technique in SQL injection to force the trailing SQL after the injected SQL to be ignored.

In this case, by putting ' UNION SELECT '123' AS password# in the username field, it makes the command that's executed:

SELECT password FROM admins WHERE username='' UNION SELECT '123' AS password

This returns a row with '123' as the password column (regardless of the username provided), allowing you to log in with any username and the password '123'.


Preventing fraud in bitcoin mining pools So bitcoin mining pools are very common, almost no one mines alone, because of the great difficulty in mining a block. So mining in a pool has pretty much been the standard.

However, how do people ensure that they are not getting cheated when mining with others? I can see two possible scenarios in mining pools whether the miners or the pool coordinator first confirms a valid hash for the block.

If the miner first detects that he was lucky enough to successfully find a valid hash for the current block. Then he could configure or reverse engineer his mining software, to not tell the mining pool he has guessed the correct hash, and broadcasts the block onto the network himself with a separate address, to reap all the rewards instead of sharing it.

Or

If the hash is first sent to the pool coordinator's servers, which then detects that the hash does validated the block, then the coordinator could broadcast that block onto the bitcoin network without telling any of the other miners that the pool was successful, so that it won't have to share any of its reward to all the miners. The pool could do this 10% of the time for all blocks mined in the pool, to not make it suspicious that the pool is not mining any/few blocks.

The bitcoin whitepaper does not speak about trustless pooled mining and I have not found any technical material that shows how a trustless mining pool can be achieved.

Bitcoin is a great trustless model for preventing reversed transactions or solving the double spending problem, but is all pooled mining based on trust or is there a cryptographical/mathematical way of preventing fraud here?

I've written this in Info Sec stack exchange instead of the bitcoin one because I believe the answer would be a technical one based on cryptography, math, hashing, proofs etc. and is not a question about the details of bitcoin.

Idea One: Even if possible, when he submits the block to the blockchain himself, the payout still would go to the mining pool. The payout address is part of what is being hashed.
Idea Two: The pool wouldn't know to payout your share either in that scenario.


Do I need a "cryptographically secure" random value for an unguessable URL? tl;dr: Is a pseudorandomly generated string unguessable enough to be used as token in a URL?

I'm making a web application, let's for the sake of argument assume it's another PasteBin.  I allow users to paste text and I generate a random URL for them that they can pass to their friends but otherwise will remain unknown to the public.

How should I generate this URL? It'll be something like https://pastebin.example.com/%s where %s is a random string.

How secure is it to simply use a pseudo-random value, such as the result of uniqid?  How will using something as openssl_random_pseudo_bytes improve how un-guessable the ID is?

Assume that users will not be able to submit arbitrary many pastes per minute, there is some rate-limiting system (such as a captcha and IP check).  Also assume that I have taken measures to prevent search engines from indexing the page.  The risk of sharing information protected just by an ungessable URL is outside the scope of this question.

For clarity: the random string is ONLY used as an identificator, it is NOT used for cryptographic operations afterwards.

uniqid might not be the best choice, in part because the docs do mention (in red):

  Warning
  This function does not guarantee uniqueness of return value. Since most systems adjust system clock by NTP or like, system time is changed constantly. Therefore, it is possible that this function does not return unique ID for the process/thread. Use more_entropy to increase likelihood of uniqueness.

And I would tend to suspect that ID collisions would be fairly disastrous in your case.

I think the basic answer is that if you really have a requirement for unguessable, as opposed to simply unique, you probably want to use a cryptographically secure RNG.

Or use a UUID (https://en.wikipedia.org/wiki/Universally_unique_identifier) - there are options, specifically UUIDv5, that would seem better suited to your usecase that uniqid.


What is the point of encrypting my files (on a server); if I can decrypt them why can't a hacker do that too? I help maintain a webserver that users use. They store data on our server. Most of the data is not sensitive, but some of it is highly sensitive. So, it seems like we want to encrypt it so that if someone compromises our server, they will only find encrypted data. However, to serve up the data to users on the website, the code is essentially like (pseudocode)

encryptedFile=getEncryptedFile();
decryptedFile=decrypt(encryptedFile);
serve up decrypted file

So, if our server is compromised, what is to stop the bad actor from finding this code and just running the decryption algorithm on their own? It seems like I am missing some step on how to prevent an attacker from finding the decryption key even if the server is compromised.

Essentially it boils down to: If I as a sysadmin creating the decryption system for the website can encrypt/decrypt files, what is to stop the hacker who compromises my server with root level access from the doing the same thing?

I don't know what decrypt() does, but you probably mean your OS-specific cryptography API. On Windows, this is protected with your account password. If the data gets downloaded or stolen, it will be much harder to read, even knowing you password. When your server is rooted, all bets are off, this just obfuscates it.


Parallel systems, in case any of two has known exploits As software becomes more and more complex it's harder and harder to keep it secure down the entire line. Discussing this problem with a friend we were opting some pretty extreme solutions and wondered whether the following is done anywhere (presumably in companies that would also air gap at least parts of their infrastructure):

  Having two parallel systems ready and switching whenever a dangerous public exploit is known about any of the software in any of the two stacks. For example, one setup based on Microsoft software, and another set up based on open source software. This could be done on any level, be it routers, server and even down to actual desktops ("PA: Please reboot your system as soon as possible to the Windows OS until further notice").

Now, I have never even needed to consider such a set up, but I have been in situations where I knew our systems were hackable, but sometimes had to wait for hours before some kind of temporary workaround was available online. In those cases you watch your logfiles a bit more closely and shut down your entire system in case of  a breach I guess, but that's far from foolproof (especially in cases where no identifiable logging is available in the first place).

While most items have already been picked up and discussed by dr jimbob in his answer, I would like to draw your attention to the following:

This kind of problem is called "common mode failure".
Nancy G. Leveson has studied common mode failures and the purported solution of redundant software (software stacks, as you describe) and noted that commonality may go much deeper than expected. For instance, both systems may share an implementation of some protocol, which means you're hosed if there's a vuln sitting somewhere inside. The same developer may have been hired by the two companies, or the coders were too lazy and unimaginative to invent their own algorithm and simply picked the same algorithm from a publicly available source. There's really no limit to such commonalities, and you cannot rule out any of them without thorough examination of the code.
Having both stacks online means a gifted and resourceful adversary will be able to get inside both and possibly subvert the switching mechanism.
Having a hot and a cold stack means the cold stack has to be kept up-to-date with all security patches (hence, it's not entirely cold, even if updates are done behind the air-gap, and does not provide total availability).
The biggest drawback of your scheme is that there is a fundamental commonality in place: both systems are implemented in software. If you really want to defend in depth against an advanced threat, build a separate, simplified system that does not rely on sophisticated networks. Plain old telephony (even sound-powered telephony) and human operators are very useful for this very purpose.


Security of running openpgp.js in a browser with the private key in HTML5 localStorage If I were to write a web application using openpgp.js (http://openpgpjs.org/) for creating PGP encrypted/signed messages and if I stored the user's private key in localStorage, would this be vulnerable to the same complaints about JavaScript cryptography on Matasano's webpage (http://www.matasano.com/articles/javascript-cryptography/)?

As far as I can tell, the main points outline by Matasano are:

"Secure delivery of Javascript to browsers is a chicken-egg problem." (This could be fixed by using HTTPS)
JavaScript isn't well suited to cryptography
Browsers are too complex for cryptography since they have the potential to contain multiple attack vectors.

If localStorage isn't the best place to store something sensitive like a private key, what would be a better place?

HTTPS is still an absolute requirement, and Matasano's main point is that JavaScript can never replace HTTPS.   A MITM attack could deliver a custom JavaScript payload that could read any secrets in localstorage, and an XSS payload could also compromise this data.

Matasano is wrong in regards to random number generators in JavaScript. Most browsers provide a very secure random number generator window.crypto.getRandomValues().  I guess Matasano hasn't read the w3c Cryptography API for JavaScript.  This API contains a random number generator that uses the operating system's entropy pool.


Open-source penetration-test automation What order do typical open-source penetration tests operate? Which tools are run first, second, third -- and how do you control them?

Does one simply use Metasploit RC files? A network vulnerability scanner in a special way? A command-line, custom, or headless web application security scanner?

Any other ways (or even ideas) to speed up penetration-tests that you would be willing to share?

Are there open-source projects to help with this process (besides Metasploit RC files or the `save' command under the MSF console)?

The Metasploit Framework is my go-to tool for pentest automation still to this day, however, I do like what I've seen of CORE INSIGHT and Immunity Security SWARM. There are a few tools such as Loki (or the older Yersinia tool), intrace, Chiron, mana-toolkit, mitmf, bettercap, and Responder.py that must be run outside of the Metasploit framework, but so many things can be done inside msfconsole these days (`load kiwi' comes to mind). If you want to see some amazing resources, check out this document which covers performing the full PTES using Metasploit.

Metasploit is catching up a little bit here and there (to nearly every tool and technique in existence!), such as the auxiliary/server (and capture) modules. However, many questions remain, such as performance comparisons between auxiliary/spoof/arp/arp_poisoning, arpspoof, macof, arp-sk, nemesis, and ettercap. Does auxiliary/sniffer/psnuffle work any differently than dsniff? What's the difference between Squirtle, auxiliary/server/http_ntlmrelay, and auxiliary/server/capture/http_ntlm? How does http_javascript_keylogger compare to BeEF? How do auxiliary/spoof/llmnr, auxiliary/spoof/nbs, auxiliary/server/wpad and auxiliary/server/capture/smb compare to Responder.py? Clearly others are simply superior, but I'd like to recode them (or see someone do this) to be part of MSF. For example, shouldn't dns2proxy (from sslstrip2's author) features exist in auxiliary/server/fakedns?

Much of the early work in network penetration testing is done with either nmap or unicornscan, although pbscan, zmap, and masscan have gained a lot of ground in recent years. In particular, dnmap is a sleek approach. There is even a web interface to dnmap called Minions.

Here are a few flags I enjoy with regards to nmap:

Slow scan (but not too slow), evades IDS, and gives the reason why the packets didn't make their destinations. Best performed one port at a time with data-length or string set when the destination protocol or port isn't known by nmap. Use robtex and csrecon to check your target IP prefixes. Try to identify one or two ports you can leverage that are not web servers, but that have historically been vulnerable to remote code exploitation (N.B., you may need to correlate this data with cvedetails.com or exploitsearch.net). You will notice I have chosen TCP port 623 (IPMI RMCP, an already slow-to-respond service that benefits from these slow scans) in the example, but you could easily change this (although I don't recommend obvious ones such as SSH or RDP -- at least check the Shodan HoneyScore before challenging these).

  -T1 --max-retries 0 --randomize-hosts --reason -n -Pn -sT -p 623

HTTP or TLS targets will typically run the default ports, so I like to SYN scan them first before scanning other HTTP/TLS targets on non-default ports. The second command will be very slow, but it will likely go under the radar (especially if you use this patch taken from this blog post), allowing full pivot to the web layer undetected. If you find that the web-related ports are open but the http-title script fails, then something is amiss -- potential honeypot warning! Look for correlation between an open port and a valid, corresponding HTML title element tag that matches the service name and purpose. If a particular IP always responds to any port, then use nmap's --exclude <ip> directive or --excludefile <filename> if you have a list of IPs (similar to nmap's -iL flag).

  -T1 --max-retries 0 --randomize-hosts --script http-title --reason -n -Pn -r -p 80,443

  -T1 --max-retries 0 --randomize-hosts --script +http-title --open -n -Pn -p 81,457,902,995,1100,1128,1241,1581,1883,1944,2301,2375,2381,3010,3037,3128,3780,3790,3872,4000-4002,4100,4567,4848,5000,5250,5800-5802,5814,5986,6060,6405,7000-7002,7080,7181,7272,7443,7510,7770,7778,8000-8001,8008,8014,8028,8040,8081,8085,8088-8091,8095,8140,8161,8180,8200,8222,8300,8400,8443,8500,8776,8834,8880,8883,8888,8980,8999-9000,9002,9060,9080,9084,9090,9191,9292,9389,9443,9495,9990,9999,30821,50000

If everything is in order, switch to faster scans and check for IDS/IPS. You'll know something went wrong when all of your scans stop, but you can be a little more efficient about it by using nmap's traceroute flag (or combine it with the firewalk script), intrace, lft, ttl-mon.py, or osstmm-afd to try and map out these systems. Typically, firewalls that include IPS/IDP functionality, network-based IPS/IDP appliances, UTM, NGFW, and similar network-stack gateways will only sample the traffic to be analyzed every 8-11 seconds. Longer delays between port scans (e.g., the 15-second default in nmap T1 scanning, or by setting a specific 12-second delay in T2 scans) and the lack of parallelization are typically what make these slower scans sneak by intrusion detection of all kinds. Repeat traffic, such as that which is directed to a single port, could also cause intrusion detection bells to go off, identifying traffic as an attack or automatically rejecting it. During the sampling period, intrusion detection might also look for sequential ports. There are a variety of factors to try and identify or play with. Thus, the next nmap flags seen below should be modified to test for this series of IDS-identification strategies. If the first test case (T2 scan with 12-second delay, no retries, and no sequential ports) gets by but the second does not, then you will want to figure out why. Nmap's packet-trace and traceroute capabilities are highly suggested, but other tools such as hping3 or nping may come in useful to support this effort.

If you find your traffic blocked (e.g., responses completely stop), you may need to switch the source public-IP (or LAN IP) you're coming from, so I suggest that you run most of these at Starbucks or off your primary, usual location (dnmap will likely also help here). Try not to hit any honeynets (e.g., Fortinet FortiGate, TrapX DeceptionGrid, etc) either, or at least identify them so that you can exclude them in future scans. The best way to avoid these traps is to leverage that scans.io and SHODAN data (and knowledge about the target environment, the kinds of technologies in use -- more useful when performing internal network scans), grab a scoreful of ports (nmap or dnmap at increasing speeds, each with 20 or so unique ports), and avoid the overly-shiny services that are potential honeypots, i.e., 21-23, 25, 53, 110, 135-139, 445, 1337, 1433, 1723, 3306, 3389, 5060-5061, 5800, 5900, 8080, 10000, 31337, and 44443 (N.B., DON'T scan these port numbers yet!).

  -T2 --scan-delay 12s --max-retries 0 --randomize-hosts --open -n -Pn -p26,66,79,113,389,407,465

  -T2 --scan-delay 9s --max-retries 1 --randomize-hosts --open -n -Pn -p512-514,523-524

  -T2 --max-retries 3 --randomize-hosts --open -n -Pn -p548,554,587,593,873,993,1026,1050,1080,1099,1158,1344,1352,1521,1604,1720,2202,2302,2383

  --max-rate 20 --max-parallelism 2 --max-retries 3 --randomize-hosts --open -n -Pn -p2628,2869,2947,3000,3031,3260,3478,3500,3632,3689,4369,5019,5040,5222,5353,5357,5432,5560,5631-5632

  --max-rate 40 --max-parallelism 4 --max-retries 3 --randomize-hosts --open -n -Pn -p5666,5672,5679,5850,5920,5984-5985,6000-6005,6379,6481,6666,7019,7210,7634

  --max-rate 80 --max-parallelism 8 --max-retries 3 --randomize-hosts --open -n -Pn -p8000,8009-8010,8834,9160,9999,11211,12000,17185,13722,19150,27017,30718,35871,49152,50030,50060,50070,50075,50090,52822,52869,60010,60030,64623

Written below is the next level of nmap scanning (default speed, no randomizing because of the qscan latency checks), giving you lots of detail and potential for movement. Use mostly port numbers you know are open, although select one port that is potentially not open (especially ones in the past that had ambiguous results). Avoid using dnmap or other inefficiencies that will break the qscan script. TCP (typically HTTP or SSL/TLS) ports could be behind reverse-caching proxies, load balancers, redirected at the network level, or similar. The qscan script should help identify these situations, although you will likely want to supplement them with other tools such as halberd (or additional NSE scripts such as http-affiliate-id and http-favicon). In this phase, you can use either IP prefixes, hostnames, or a combination. I suggest using one strong tool here, such as blacksheepwall. Be careful when targeting hostnames because Passive DNS sensors will give away your location and/or intentions much more easily than you think, leading to blocks similar to IPS or WAF (and at this point you will need to be able to distinguish between those three, as well as other defensive countermeasures). Keep testing all ports in the manner directly above until you've exhausted what you already know about the target network(s) and domains. If you have a target SSL/TLS port, the duplicates script will help you understand when a single host is speaking on multiple IPs or networks (typically multihomed).

  --script qscan --max-retries 7 --reason -Pn --version-intensity 0 -sV -p80,(other found-TCP ports)
  --script qscan,duplicates,ssl-cert --max-retries 7 -v --reason -Pn -sV --version-all -p80,443,(others previously-found)

Follow this line of thinking with some single port checks using a bad TCP checksum. Utilize your knowledge of the past and build on it. Before you proceed, make certain you have a good idea about the network paths and internals of every packet you send, and predict the responses from this point on out. If you want to build a little extra knowledge at this stage, you might want to use different tools, such as pbscan, portbunny, masscan, zmap, or unicornscan (the -w file.pcap flag could be repurposed here to allow for packet capture analysis much like MSF's pcap_log, but I don't necessarily suggest either approach as cool as they initially sound). If you do have a way (preferably a separate, inline system so that the disk I/O, CPU, and memory usage doesn't affect your scans) to perform packet capture, typically you will want a tool such as netsniff-ng to save pcaps (or a different tool if you require pcapng) and then process the results with p0f and/or PRADS. Fingerprinting can get complex, and there are a few tools besides nmap that you will likely want to leverage at this stage. Targeting port-specific versions isn't necessary quite yet, although it can be accomplished here. I suggest going heavy on the OS-level fingerprinting with "just enough" service identification to correlate. There are old techniques (such as a fork of nmap called cron-os) that should be ported to a newer tool with a fp database refresh to modern platforms (which is why I suggested p0f and PRADS earlier -- they tend to keep up with the constant change of technologies). Rapid7 has a big-data project for service fingerprinting, recog. Nmap's service versioning is only average when compared to tools such as amap, and there are many point-solution tools such as fpdns, ntp-fingerprint.pl, info2cpe, et al. Vuln scanners such as Nessus incorporate hmap (an HTTP fingerprinter), but there are many tools in that space as well (httprint, httprecon). It's annoying that OS fingerprinting and service versioning are highly problematic. I suggest you do the best you can with the methods and tools I described.

  --script qscan --max-retries 7 --badsum -v -O --osscan-guess --max-os-tries 1 --reason --send-ip --version-intensity 0 -sV -p80,(at least one closed port)

If, and when you do, run into any obvious IPS or other blocks, see the section far below which mentions sniffjoke and other advanced evasion techniques (AETs). If you can actually fingerprint the system(s) blocking your traffic then your best bet is to run a sniffjoke client/server pair in another similar environment where you have server access already (N.B., this could be from a previous pen test or from a lab or mock environment). The above badsum trick should preempt most IPS systems. Other techniques we've been through may have also uncovered these blocking systems. If you find a good AET then you will likely want to run all of your previous port scans over again to see if you have similar results. If you feel that SYN traffic is being throttled (one way to check is to use nmap against a bunch of known-open ports with full TCP connects and the same ports with standard SYN-only), see the below section about SYN-cookie evasion as well as the even-further section on using tcptrace to detect such issues.

Scan a few UDP ports, but check with a few different tools to be sure. Learn how to import Nmap data to MSF in order to leverage hosts -R in modules like empty_udp (but modify the script to remove 1-1024,2049,5060,5061). We aren't checking any low-range ports because of honeypots, intrusion detection, logging, or other inconsistencies at this time. If any UDP ports are open, this knowledge should supplement what we already know about the live TCP ports on this network. If, because of past knowledge about the target types (from OS or version detection) or target environment, you feel that you could gain more knowledge by scanning for IP protocols such as SCTP, ICMP, IGMP, or otherwise -- then, be careful, consider the consequences, and send out a few probes to verify or build on that knowledge.

  --max-rate 100 --max-retries 0 --randomize-hosts --reason -Pn -sUV --version-all -p500,523,623,1604,1645,1812,5353,5632,6481,6502,10080,17185

  unicornscan 10.0.0.0/24:500,523,1604,1701,1812,2000,3478,5353,5632,10080-10081 -Iv -mU

  for i in ike db2 citrix net-support netop ; do udp-proto-scanner.pl -p $i 10.0.0.0/24 ; done

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p132

  --max-rate 400 --max-retries 0 --randomize-hosts --reason -n -Pn -sY -p1167,1812,1813,2225,2427,2904,2905,2944,2945,3097,3565,3863,3864,3868,4739,4740,5090,5091,5672,5675,6704,6705,6706,7626,8471,9082,9084,9900,9901,9902,14001,20049,29118,29168,29169,36412,36422

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p1

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --send-ip -n -PM -sn

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -p2

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --send-ip -n -PP -sn

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO -F --exclude-ports 1,2,6,17,132

  -T2 --scan-delay 1s --max-retries 0 --randomize-hosts --reason -n -Pn -sO --exclude-ports 1,2,6,17,132 --data-length 3

To be absolutely pedantic, run the below on every active host that responded to anything from past scans.

  -T2 --max-scan-delay 90ms --max-retries 9 -v -O --osscan-guess -n --send-ip -PE (or -PP if successful and/or -PM if also successful) -sTUV -pT:(at least one closed port but also one open if possible),U:(as T:) --version-all

After this most-recent run, you must know nearly everything you can about each host, each port -- it should be obvious to you if there is a honeypot or IDS/IPS/IDP/etc. You'll be able to group them into categories even if not absolutely sure, e.g., "probably Cisco", "flavor of Unix", "definitely IP phones or softphones of some kind", or "unknown hosts but these match a certain profile even though they have differing ports open". You feel ready to start vulnerability analysis and exploitation against these hosts and their identified and/or unidentified ports.

You will need to add ports previously found to the following nmap port list so that you get a suitable Nmap XML file for importing into Metasploit or querying with metasploitHelper. Be sure to add TCP/SCTP ports to the "T:" section and UDP ports to the "U:" section.

  --min-rate 100 --max-rate 400 --min-parallelism 16 --max-retries 9 --defeat-rst-ratelimit -sUS -n -Pn -pT:0,1,19,42,49,85,105,111,143,264,402,444,446,502,515,631,689,705,783,888,910,912,921,998,1000,1099,1211,1220,1533,1582,1617,1755,1811,1900,2000,2001,2067,2100,2103,2207,2362,2380,2525,2940,2947,2967,3050,3057,3200,3217,3299,3460,3465,3628,3690,3817,4322,4444,4659,4672,4679,5038,5051,5093,5168,5227,5466,5498,5554,5555,6050,6070,6080,6101,6106,6112,6503,6504,6542,6660,6661,6905,6988,7021,7071,7144,7414,7426,7579,7580,7777,7787,8020,8023,8030,8082,8087,8503,8787,8812,8899,9100,9200,9256,9390,9391,9788,9855,10001,10008,10050,10051,10202,10203,10616,10628,11000,11234,12174,12203,12221,12345,12397,12401,13364,13500,16102,18881,19810,20010,20031,20034,20101,20111,20171,20222,22222,23472,26000,26122,27000,27960,28784,30000,31001,32764,34205,34443,38080,38292,40007,41025,41080,41523,41524,44334,44818,46823,46824,50001,50013,55553,57772,62514,65535,U:19,42,49,69,111,161,631,1900,2049,2362,7777 -oX nmap_target1.xml

If you find a good target, you may want to utilize custom Metasploit resources (or "rc") files that consist of notes on modules, their settings, and how to run them. You can find port-number specific rc files here, which can get you on the fast path to a shell. It may require some troubleshooting, but attacking the infrastructure this early on could indicate IPS (network or host) presence or lack thereof. It could also get your IP address blocked, so proceed with caution. You also might want to run some of these port-specific NSE scripts, some of which have important script-args and other tuneables. If you already know for sure that a port is open, or even confident in the target OS/service, then you might as well do something to get more information about their runtime states. Your call, but at this stage in the testing automation you will definitely need to increase the information available to you for decision advantage.

Another possibility is to pivot to the web layer, which typically involves running carbonator after a little nmap and nikto action (N.B., you will want to modify your nikto.conf to modify the user agent to one of a normal web browser and perhaps comment out the two mutate lines). You will also want to discover more hostnames and IP prefixes at this time (domaincrawler.com, fierce, knock, dnsmap, and subbrute will help with subdomains and dnsrecon should handle all of the rest). If you have tons of targets then you may want to use webshot to drop images that you can sort through and triage your target selections. If you definitely know there is an IPS or WAF in place, then you may want to switch tactics.

  -Pn -p 80 --version-all -sV --script "http-waf*",http-devframework,http-enum,http-vhosts -oG - | nikto.pl -h - -Tuning x04689c -D 1 -output nikto.xml

  -Pn -p 443 --version-all -sV --script "http-waf*",http-devframework,http-enum,http-vhosts -oG - | nikto.pl -h - -ssl -Tuning x04689c -D 1 -output niktotls.xml

Now is the time to engage any anti-IDS mechanisms (e.g., sniffjoke, fragroute, and Evader) or run any last-minute SYN-cookie, IDS, IPS, and WAF detection checks. Finally, go for it! No sense in scanning a single port or small set of ports at this point.

  --script banner-plus --min-rate 450 --min-parallelism 20 --max-retries 5 --defeat-rst-ratelimit -n -Pn -p-

  unicornscan 10.0.0.0/24:a -D -L 20 -r 450 -Iv -mU

  unicornscan 10.0.0.0/24:9,42,49,67,88,135,139,162,213,259,260,407,445,464,514,517-523,546,631,657,826,829,1069,1194,1558,1645-1646,1900,1967,2055,2362,2427,2727,2746,3001,3283,3401,3544,4045,4500,4665,5060,5350,5351,5355,5405,5432,6481,6502,8905,8906,9999,17185,18233,26198,27444,32822-32823,34555,41250,47545,49152,49599,54321 -r 450 -Iv -mU

The above rates (--min-rate in nmap and -r in unicornscan) are measured in packets-per second (pps) and can be modified up to 10000 when on a local network or other ideal conditions. There are patches to change nmap's scan rate dynamically (interactively) here (amazing when combined with tcptrace.org looking for retransmissions and modifying either the min-rate, max-rate, interactive equivalents, min-parallelism, min-hostgroup, or max-retries until maximum bandwidth is acheived). It is difficult to get nmap into best-fit approach for bulk SYN or UDP scanning, even when using pedantic min-hostgroup, min-parallelism, and min-rate parameters. This is why many people turn to unicornscan, zmap, or masscan. If your target networks and services have very reliable and consistent round-trip times in their server responses (or if you have the time and patience to figure out the network characteristics), nmap/dnmap may be your best bet for tooling consistency if nothing else.

You may need to verify new IPs, hostnames, or ports that you haven't seen in the past (such as the honeypot ports we avoided earlier, including SCTP ports 5060-5061 with -sY). Go back to the stage where you ran qscan and retry scenarios using the new information. Continue to check for honeypots by using additional techniques such as Metasploit's detect_kippo module. Be sure to rerun metasploitHelper if applicable. Keep track of all of your information, perhaps by using Dradis, MagicTree, discover.sh XML to CSV conversions, Lunarline VSC, Prolific Solutions proVM Auditor, Cisco Kvasir, or FishNet LAIR. These are better alternatives to Notepad, etc because they are penetration-test data aware. Similar to earlier, you may find that the duplicates script helps identify multihomed hosts. Common scenarios include Windows machine with or without SSL/TLS -- or possibly a non-Windows machine running SSH, SSL/TLS, or both (although it is possible that a Windows host could be running SSH, but that's a severely strange corner case).

  --script qscan,duplicates,nbstat,ssl-cert --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sSUV --version-all -pT:135,139,443,445,U:137

  --script qscan,duplicates,nbstat --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sSUV --version-all -pT:135,139,445,U:137

  --script qscan,duplicates,ssh-hostkey --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sV --version-all -p22

  --script qscan,duplicates,ssh-hostkey,ssl-cert --max-retries 7 -v -O --osscan-guess --max-os-tries 1 --reason -Pn -sV --version-all -p22,443

If you find any open ports with services (or apps of any kind) that require any form of authentication, then you will want to read and configure the protocol-specific scripts, but generically your nmap/dnmap command-line arguments should look like:

  --min-rate 100 --max-retries 5 -n -Pn --script brute,creds-summary --script-args unsafe,brute.mode=pass,userdb=usernames.lst,passdb=passwords.lst,brute.firstOnly,brute.guesses=2 --version-all -sV (-sUV or -sUSV, if appropriate)

The above could be performed with dnmap using a different passwords.lst file on each server in order to increase attempts, to brute from different IP addresses, or a variety of other scenario-dependent options.

Finally, let's talk about how nmap/dnmap can really shine -- by bringing it all together after you know that SYN scanning works, you have UDP probes figured out (note that many of the below are missing in the nmap-payloads, nmap-service-probes, Unicornscan etc/payloads.conf, and udp-proto-scanner.conf files -- so you may have to create them manually!) and that IDS/IPS isn't going to be a bother for your automation. Let's say you aren't just on a coffee break, you can't take "just another nap", and your significant other demands some attention and a normal 8-hour sleep routine. Well, fire up nmap/dnmap this way and you'll get some great results for when you come back to the console!

  --min-rate 100 --max-retries 5 --defeat-rst-ratelimit --randomize-hosts --open -Pn -v -O --osscan-guess --max-os-tries 1 -sUSV --version-all --script banner,duplicates,nbstat,ssh-hostkey,ssl-cert,vuln,vulscan,brute,creds-summary --script-args vulns.showall,unsafe,vulscanversiondetection=0,brute.mode=pass,userdb=usernames.lst,passdb=passwords.lst,brute.firstOnly -pT:0,1,19,26,42,49,66,79-81,85,105,111,113,135,139,143,264,389,402,407,443-446,457,465,500,502,512-515,523,524,548,554,587,593,623,631,689,705,783,873,888,902,910,912,921,993,995,998,1000,1026,1050,1080,1099-1100,1128,1158,1167,1211,1220,1241,1337,1344,1352,1433,1521,1533,1581,1582,1604,1617,1720,1723,1755,1811-1813,1900,1944,2000-2001,2067,2100,2103,2202,2207,2225,2301-2302,2362,2375,2380,2381,2383,2427,2525,2628,2869,2904,2905,2940,2944,2945,2947,2967,3000,3010,3031,3037,3050,3057,3097,3128,3200,3217,3260,3299,3306,3389,3460,3465,3478,3500,3565,3628,3632,3689-3690,3780,3790,3817,3863,3864,3868,3872,4000-4002,4100,4322,4369,4444,4567,4659,4672,4679,4739,4740,4848,5000,5019,5038,5040,5051,5060-5061,5090-5091,5093,5168,5222,5227,5250,5353,5357,5432,5466,5498,5554-5555,5560,5631,5632,5666,5672,5675,5679,5800-5802,5814,5850,5900,5920,5984,5985,5986,6000-6005,6050,6060,6070,6080,6101,6106,6112,6346,6347,6379,6405,6481,6503,6504,6542,6660-6661,6666-6667,6704-6706,6905,6988,7000-7002,7019,7021,7071,7080,7144,7181,7210,7272,7414,7426,7443,7510,7579,7580,7626,7634,7770,7777-7778,7787,8000-8001,8008-8010,8014,8020,8023,8028,8030,8040,8080-8082,8085,8087-8091,8095,8140,8161,8180,8200,8222,8300,8400,8443,8471,8500,8503,8776,8787,8812,8834,8880,8888,8899,8980,8999,9000,9002,9060,9080,9082,9084,9090,9100,9160,9191,9200,9256,9292,9390,9391,9443,9495,9788,9855,9900,9901-9902,9990,9999,10000-10001,10008,10050-10051,10202,10203,10616,10628,11000,11211,11234,12000,12174,12203,12221,12345,12397,12401,13364,13500,13722,14001,16102,17185,18881,19150,19810,20010,20031,20034,20049,20101,20111,20171,20222,22222,23472,26000,26122,27000,27017,27960,28784,29118,29168,29169,30000,30718,30821,31001,31337,32764,34205,34443,35871,36412,36422,38080,38292,40007,41025,41080,41523-41524,44334,44443,44818,46823,46824,49152,50000-50001,50013,50030,50060,50070,50075,50090,52822,52869,55553,57772,60010,60030,62514,64623,65535,U:7,9,11,13,17,19,36-37,42,49,53,67,69,88,111,123,135,137,139,161-162,177,213,259,260,407,445,464,500,514,517-521,523,546,555,623,631,657,826,829,921,1069,1194,1434,1558,1604,1645-1646,1701,1812,1900,1967,2000,2049,2055,2221,2302,2362,2427,2727,2746,3001,3283,3401,3478,3544,4045,4104,4500,4665,5060,5350,5351,5353,5355,5405,5432,5555,5632,6481,6502,7001,7004,7777,7983,8905,8906,9999,10080-10081,17185,18233,26198,27444,27960,31337,32767-32774,32822-32823,34555,41250,47545,49152,49599,54321

Just a little effort with nmap can save you a lot of time if you engage with OpenVAS or Metasploit later on. I prefer to run nmap and OpenVAS from within the msfconsole so that all of that data makes it into the MSF database. One could also export tool data to Metasploit-consumable XML, or use a tool like nmap2nessus. An important lesson to learn about vulnerability scanners is that they miss a lot of real-world vulnerabilities. By running nmap/dnmap overnight in the manner described above you will get to see the potential for every single vulnerability path. Most of them won't work at first shot -- nmap/dnmap will tell you that they failed (but not the real "why", even if you think its reason is valid) -- so it is up to you to figure out if the vulnerability can lead to exploitation or not. Go back to the earlier discussion about port-number specific Metasploit and Nmap NSE files, it is even more relevant now. Know the internals of these scripts and how to troubleshoot each line of code that they consist of. A little offset, a small parameter, or a few combinatorial tweaks will grab that shell that every other penetration tester would have missed.