Re: [Snort-devel] Final Year Project Custom MySQL Database Server Rules and Classifications Review

[DFIRob via Snort-users <snort-users () lists snort org>]

Hi mate,
To clarify all my questions were obviously, at least to me, in the context
of snort rule writing, ie: can you have flags:PA and flow:established in
the same rule, since instinctively (to me) the flag keyword would apply to
single packet inspection while the flow keyword means the rule now applies
to the reconstructed session.
> The flags and ttl are probably included to ensure the highest probability
of a true positive and lowest probability of a false positive. You could
remove these and achieve the same result.
Well, if the packets really come from $EXTERNAL_NET, you have no way of
knowing what the TTL will be, and it probably won't be 128.

Here are all the rule files from the OP if anyone else is curious, or feels
charitable.
-r

On Wed, Apr 11, 2018 at 5:09 PM, Mkultra <mkultra75 () protonmail com> wrote:

> I'm no snort pro, I grew up on PIX/ASA, but i have been doing netsec stuff
> for a few decades now. I can answer a few of these.
>
> 1. if internet can hit mysql through an edge device (snort at the
> perimeter), you are doing it wrong 99.999% of the time. Of course snort
> could be used in other configurations such as zoning your server farms into
> groups with different security levels, segmenting your internal network
> segments, etc. MySQL is pretty solid in this regard but be extremely wary
> of using a Microsoft product in this manner. I once had a sql server get
> owned and wiped clean so somebody could store german porn and video games
> on it. This was back in the slammer worm days when it took 18 hours to
> restore from tape backup.
>
> when you do flow:to_server,established; and flags:PA; --
> flow:to_server:est & PA means there is a TCP session established already.
>
> Here is a quick rundown of a TCP session
> ------------------------------------------------------------
> ---------------------------
> SYN -->
> <--- SYN-ACK
> ACK --->
> (session is now in the ESTABLISHED state.)
> [send data to and fro]
> [ok done working, time to close the channel to free up resources]
> FIN --->
> <--- ACK
> (session is now closed)
> ------------------------------------------------------------
> ----------------------------
>
> 2. Is this possible?
> ---- yes any packet can be created with any combination of flags, ttl,
> headers, payload, or whatever. search xmas tree attack, etc. see
>  https://www.professormesser.com/security-plus/sy0-401/
> christmas-tree-attack-2/
> and
> http://sectools.org/tag/packet-crafters/
>
> 3. Do we look for all sessions that start with a push-ack?
> ---- no TCP session will ever start with PSH-ACK. The first packet in any
> tcp conversation is always SYN. See RFC 793. Its always SYN, SYN-ACK, ACK.
> http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml any
> session that starts in any other way is automatically bad mojo.
>
> 4. Fourth, about your dos attacks, you probably want to track_by_src, if
> not you're just tracking high usage of your application.
> ---- DOS attacks almost always use spoofed source addresses or use botnets
> where each individual host may make only 50 or 100 connections but 100,000
> separate outside hosts hitting the same inside server causes the DOS/DDOS
> condition. Tracking the source IP for DOS attacks is kind of a waste of
> time since its either faked, or it is just a tiny part of a massive group
> of coordinated zombies attacking you. Back when I was a noob I kept a
> logfile of all those bad people vowing to pillage their village, take their
> women as my own, murder their cattle and salt their fields, but in the end,
> the log file never stops filling up and all the addresses are fake anyway
> so whats the point.
>
> 5. it looks from the rule that the only real positive identifier is the
> sql query itself. The flags and ttl are probably included to ensure the
> highest probability of a true positive and lowest probability of a false
> positive. You could remove these and achieve the same result.
>
> 6. it seems from the OP email below yours that the attacker would be
> hitting a web application and using a SQL injection atack to compromise the
> database server to get a toehold. This makes me think two things.
> a.) you should write a rule that analyzes the web (http/https) requests
> hitting your "damn vulnerable web application" (ha, arent they all) instead
> of focusing on traffic from the web server to the mysql server. Most
> firewall setups sniff either just outside the perimeter or just inside, so
> a snort rule to analyze mysql queries would never hit because when it hits
> the sniffer it will probably be in the form of an HTTP request.
>
> b.) this rule will only work if the sniffer is located between the web
> server and the database server AND the mysql traffic is not encrypted
> (protip: it should be).  A web application won't be (or shouldnt be)
> sending sql queries in the clear (select * from webusers where userid =
> 'admin' and password = '31337HeeHee'). So your question either implies
> horrendous security or horrendous security both of which add up to pain and
> heartbreak.
>
> 7. Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> ---lol get rid of this, you are advertiusing to your enemy that a.) you
> use windows 10, and b.) you use the built in mail app. Thats an attack
> vector. Don't do your adversaries work for them.
>
> Hope this helps.
>
> Cheers,
>
> Mkultra
>
>
> Sent from email program on nondescript PC or Mobile type device.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 10, 2018 5:02 PM, DFIRob via Snort-users <
> snort-users () lists snort org> wrote:
>
> Hi Jack,
> First I think you should loop in snort-users on this, since snort-devel is
> really not the place for rule writing. Then Joel will jump on you saying
> https://www.snort.org/faq/can-i-have-help-with-my-homework, and will be
> totally right in this case.
> Nonetheless ignoring this...
>
> Second, if $EXTERNAL_NET can talk to $SQL_SERVERS, you have a problem
> snort won't be able to fix. What you probably want is $HTTP_SERVERS
> Third, and I'd love to have some feedback on this one, when you do
> flow:to_server,established; and flags:PA; in the same rule, what does this
> mean exactly? Is this possible? Do we look for all sessions that start with
> a push-ack? What about the sessions that don't? And what about your TTL
> flag? Do this apply to all the packets in the session?
> Fourth, about your dos attacks, you probably want to track_by_src, if not
> you're just tracking high usage of your application. But then again if your
> $SQL_SERVERS are reachable from $EXTERNAL_NET...
> Fifth, regarding sid:1000101, how is your false positive rate going? Have
> you tested this on any real application?
> ---
> # Tautology SQL injection rule, searches for SELECT statement in a tcp
> packet and pcre parameter matches any 'n' = 'n' attempt on mysql with a
> packet that has time to live of 128 (usual) with push and acknowlege flags
> set in a mysql tcp packet request established to the mysql server with push
> and ack flags set, main aim of this rule is to detect 'n' = 'n' queries,
> works! #
> # alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306 (msg:"MYSQL-EXPLOIT
> Potential SQL Injection detected using tautology on the MySQL server";
> flow:to_server,established; pcre:"/\'[0-99]{1,}\'\s\=\s\'[0-99]{1,}\'/i";
> fast_pattern:only; ttl:128; flags:PA; reference:url,
> https://arxiv.org/ftp/arxiv/papers/1203/1203.3324.pdf; reference:url,
> https://www.debuggex.com/cheatsheet/regex/pcre; metadata:policy
> security-ips drop, service mysql; classtype:sql-injection; sid:1000101;
> rev:11;)
> ---
> Best regards,
> Rob'
>
> On Sun, Apr 8, 2018 at 7:50 PM, Jack Eastwood via Snort-devel <
> snort-devel () lists snort org> wrote:
>
> > Good Afternoon,
> >
> >
> >
> > I’m a final year Computer Forensics and Security student representing
> > Leeds Beckett University in the UK and finalizing my final year project
> > based on using Snort as an IDS to monitor an active MySQL server.
> >
> >
> >
> > For the basis of my project I have installed and configured Snort as an
> > IDS to monitor an array of activity against a MySQL community server with a
> > vulnerable application called “damn vulnerable web application” (DVWA) that
> > is connected the MySQL database. I have uploaded three files in this email:
> > a general MySQL rules file, a MySQL exploit rules file -where I have
> > written custom made snort rules to detect an array of activity - and a
> > classification configuration file which I have also written custom made
> > classifications in context to my project. For each rule I have inserted
> > comments explaining the function of each rule and the requirements on how
> > each rule gets triggered.
> >
> >
> >
> > I would be thankful if anyone could review these files and provide any
> > form of feedback that could enhance these rules for future research or even
> > potentially be published as official Snort rules.
> >
> >
> >
> > If you would like any more information regarding my project, Snort or
> > MySQL configuration settings or anything else that could benefit the
> > reviewing process then don’t hesitate to contact me.
> >
> >
> >
> > Thanks you and regards
> >
> > Jack Eastwood
> >
> >
> >
> > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> > Windows 10
> >
> >
> >
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel () lists snort org
> > https://lists.snort.org/mailman/listinfo/snort-devel
> >
> > Please visit http://blog.snort.org for the latest news about Snort!

Attachment: classification.config
Description:

Attachment: mysql-exploit.rules
Description:

Attachment: general-mysql.rules
Description:

_______________________________________________
Snort-users mailing list
Snort-users () lists snort org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette